- NANOG - lists.nanog.org

Charter CPE engineer
by samual carman 13 Dec '17

13 Dec '17

Are there any charter CPE engineering team members on here? Preferably someone who deals with modems and firmware for the modems There an issue I have been noticing on multiple modems(same model) and my attempt to reach local engineering team members have not been met with success Sam Mettai Inc Sent from my iPhone

1 0

Target.com NOC Contact
by Jason Canady 13 Dec '17

13 Dec '17

Hello, Would anyone here have a contact for Target.com NOC? Thank you! - Jason

1 0

Any Telus (AS852) BGP customers in the house?
by Jason Lixfeld 13 Dec '17

13 Dec '17

Hello! As a fellow AS852 BGP customer, I’m looking to chat with other AS852 BGP customers on the topic of modifications to the prefix filters attached to your BGP session(s). Specifically, understanding the procedure Telus wants you to follow to request any changes, how long it takes the requested changes to be implemented, and whether or not there are any costs associated with those changes. Off-list is probably appropriate. Thanks in advance!

1 0

Switch/Router
by K MEKKAOUI 13 Dec '17

13 Dec '17

Hi I am looking for a router preferably (or switch) with the following specs: 1- Carrier grade 2- Dual power supply 3- 1RU 4- Gig and 10Gig interfaces. 5- Does support protocols like BGP, etc. Any recommendation please? Your help will be appreciated. Thank you KARIM M. MEKTEL INC. Tél. : 1(855) 563-5835 poste 404 www.mektel.ca

9 9

Call for Participation -- ICANN DNSSEC Workshop at ICANN61 San Juan, Puerto Rico
by Jacques Latour 12 Dec '17

12 Dec '17

Hi All! The next ICANN DNSSEC Workshop will be on Wednesday, March 14, in San Juan, Puerto Rico. If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-sanjuan(a)isoc.org by **03 January 2017** Thanks, Jack Call for Participation -- ICANN DNSSEC Workshop at ICANN61 San Juan, Puerto Rico The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop during the ICANN61meeting held from 10-15 March 2018 in San Juan, Puerto Rico. The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments. For reference, the most recent session was held at the ICANN Annual General Meeting in Abu Dhabi, UAE, https://schedule.icann.org/event/CbKE/dnssec-workshop-part-ii[schedule.ican…<https://urldefense.proofpoint.com/v2/url?u=https-3A__schedule.icann.org_eve…>, and https://schedule.icann.org/event/CbKF/dnssec-workshop-part-iii[schedule.ica…<https://urldefense.proofpoint.com/v2/url?u=https-3A__schedule.icann.org_eve…>. At ICANN61 we are particularly interested in live demonstrations of uses of DNSSEC or DANE. Examples might include: * Innovative uses of APIs to do something new and different using DNSSEC/DANE. * Email clients and servers using DNSSEC, OPENPGPKEY, or S/MIME for secure email. * DNSSEC automation and deployment using CDS, CDNSKey, and CSYNC. * DNSSEC signing solutions and innovation. * Tools for automating the generation of DNSSEC/DANE records. * Services for monitoring or managing DNSSEC signing or validation. * Tools or services for using DNSSEC/DANE along with other existing protocols and services such as SSH, XMPP, SMTP, S/MIME or PGP/GPG. Our interest is to provide current examples of the state of development and to show real-world examples of how DNSSEC and DANE related innovation can be used to increase the overall security of the Internet. We are open to presentations and demonstrations related to any topic associated with DNSSEC and DANE. Examples of the types of topics we are seeking include: 1. DNSSEC Activities For this panel we are seeking participation from those who have been involved in DNSSEC deployment and also from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment. In particular, we will consider the following questions: Are you interested in reporting on DNSSEC validation of your ISPs? What can DNSSEC do for you? What doesn't it do? What are the internal tradeoffs to implementing DNSSEC? What did you learn in your deployment of DNSSEC? We are interested in presentations from both people involved with the signing of domains and people involved with the deployment of DNSSEC-validating DNS resolvers. 2. Impact of Root Key Rollover We would like to bring together a panel of people who can talk about the impacts to ISPs, equipment providers and end users, and also what could be done to mitigate those issues. In particular, we are seeking participation from vendors, ISPs, and the community that could be affected by distribution of new root keys. If you have a specific concern about the Root Key Rollover we would like to hear from you. 3. Implementing next generation DNSSEC signing at Registries and DNS Operators Now that DNSSEC technology has matured many Registries, and DNS Operators have upgraded their legacy DNSSEC signing services with innovative solutions. * Real world use cases of HSMs and key management. * Signing at the edge. We would be interested in seeing presentations or demonstrations on those topics. 4. The operational realities of running DNSSEC Now that DNSSEC has become an operational norm for many registries, registrars, and ISPs, what have we learned about how we manage DNSSEC? What is the best practice around key rollovers? How often do you review your disaster recovery procedures? Is there operational familiarity within your customer support teams? What operational statistics have we gathered about DNSSEC? Are there experiences being documented in the form of best practices, or something similar, for transfer of signed zones? 5. Innovation around DANE and DNSSEC application automation For DNSSEC to reach massive deployment levels it is clear that a higher level of automation is required than is currently available. There also is strong interest for DANE usage within web transactions as well as for securing email and Voice-over-IP (VoIP). We are seeking presentations on topics such as: * How can the industry use DANE and other DNSSEC applications as a mechanism for creating a more secure Internet? * What tools, systems and services are available to help automate DNSSEC key management? * Can you provide an analysis of current tools/services and identify gaps? * What are some of the new and innovative uses of DANE and other DNSSEC applications in new areas or industries? * What tools and services are now available that can support DANE usage? We would be particularly interested in any live demonstrations of DNSSEC / DANE application automation and services. Demonstrations of new tools that make the setup of DNSSEC or DANE more automated would also be welcome. 6. DNSSEC and DANE in the enterprise and in the enterprise tool set Enterprises and enterprise software can play a critical role in both providing DNSSEC validation to their internal networks and also through signing of the domains owned by the enterprise. We are seeking presentations from enterprises and enterprise software providers that have implemented DNSSEC on validation and/or signing processes and can address questions such as: * What enterprise software support or plan do you have to support DNSSEC? * What are the benefits to enterprises of rolling out DNSSEC validation? And how do they do so? * What are the challenges to deployment for these organizations and how could DANE and other DNSSEC applications address those challenges? * How should an enterprise best prepare its IT staff and network to implement DNSSEC? * What enterprise tools and systems are available to assist enterprises in the deployment of DNSSEC? * How can the DANE protocol be used within an enterprise to bring a higher level of security to transactions using SSL/TLS certificates? 7. Implementing DNSSEC validation at Internet Service Providers (ISPs) Internet Service Providers (ISPs) play a critical role by enabling DNSSEC validation for the caching DNS resolvers used by their customers. We have now seen massive rollouts of DNSSEC validation within large North American ISPs and at ISPs around the world. We are interested in presentations on topics such as: * Can you describe your experiences with negative Trust Anchors and operational realities? * What does an ISP need to do to prepare its network for implementing DNSSEC validation? * How does an ISP need to prepare its support staff and technical staff for the rollout of DNSSEC validation? * Can you provide results and/or impacts of the impact of root key rollover? * What rollover technique do you use, i.e., RFC 5011 or other? In addition, we welcome suggestions for additional topics. If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-sanjuan(a)isoc.org<mailto:dnssec-sanjuan@isoc.org> by **03 January 2017** We hope that you can join us. Thank you, Kathy Schnitt On behalf of the DNSSEC Workshop Program Committee: Jean Robert Hountomey, AfricaCERT Jacques Latour, .CA Xiaodong Lee, CNNIC Russ Mundy, Parsons Ondřej Filip, CZ.NIC Yoshiro Yoneya, JPRS Dan York, Internet Society Mark Elkins, DNS/ZACR Jacques Latour, CTO Canadian Internet Registration Authority (CIRA) cira.ca<http://www.cira.ca/> Tel.: (613) 237-5335 x294

1 0

Packets Broker (aka: WAN Accelerator (aka: Congestion Algorithms (aka: You call yourself a network engineer?) )
by Alain Hebert 12 Dec '17

12 Dec '17

Hi, We're used to fix Long Fat Network issues ourself... But I'm stuck in a case where we need to transparently proxy TCP connections to apply congestion algorithms (cubic, htcp, etc) since some of our newer customers are ... well ... refusing to acknowledge that reality. Any good lead for a 1U platform averaging ~10Gbps of throughput, that isn't some PC hack in a box? ( off-lists would be nice, unless you think that could be useful to others ) Thanks for your time. -- ----- Alain Hebert ahebert(a)pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443

2 1

quake3-master-getservers:
by Richard 11 Dec '17

11 Dec '17

NANOG group, at a client site who was complaining of having their Active Directory passwords changed every week. Found a PPTP which had been put in place by a ex employee. Fixed that. I have no idea what a master-get servers is. If anyone can ping me-off-list to educate me a bit more, please do. Sincerely, Richard

3 2

Survey about interconnection agreements
by Pedro de Botelho Marcos 11 Dec '17

11 Dec '17

Dear community, We are a group of researchers conducting a survey about the future of the interconnection agreements. Our goal is to understand the current process and reasons for establishing inter-domain interconnection agreements and how this ecosystem can be improved in the future. Can you please help us by answering a set few objective questions reflecting your views? This survey will take you less than 10 minutes, and you can earn a prize by doing it! Survey URL: https://goo.gl/bJxJzZ This survey is in the context of our proposal to create truly dynamic interconnection agreements. Please watch this short (3 minutes) introductory video. https://youtu.be/DVbjR7JQTvo We are offering a redeemable prize worth 25.00 USD (twenty-five United States Dollars) for the first 200 (two hundred) respondents that meet the following eligibility criteria: - You must be a peering coordinator or a network operator working with inter-domain interconnection aspects - Your organization must operate an autonomous system (AS) - You must be able to provide personal information that allows us to verify if you are eligible You can also participate in the survey without disclosing your identity. In this case, you are not eligible for the prize. Research records will be kept confidential. All data will be anonymous and collected and published in a manner that would not allow identification of your identity. A summary of the aggregate results will be made available to the community and used as a part of a scientific article. If you have any question, do not hesitate to contact us. Also, if you want to know more about our project, please visit our website: https://dynam-ix.github.io Thank you very much, -- Pedro Marcos Federal University of Rio Grande do Sul

1 0

Re: Static Routing 172.16.0.0/32
by Ryan Hamel 09 Dec '17

09 Dec '17

1. A single known ip address that redirects to the closest internal repo server. 172.16.0.0/32 redirects to a usable subnet ip in 172.16.xx.xx by static route. 2. Internal private network that is reachable by clients. -------- Original message -------- From: William Herrin <bill(a)herrin.us> Date: 12/8/17 1:34 PM (GMT-08:00) To: Ryan Hamel <Ryan.Hamel(a)quadranet.com> Cc: nanog(a)nanog.org Subject: Re: Static Routing 172.16.0.0/32 On Thu, Dec 7, 2017 at 10:13 PM, Ryan Hamel <Ryan.Hamel(a)quadranet.com<mailto:Ryan.Hamel@quadranet.com>> wrote: A colleague of mine has static routed 172.16.0.0/32<http://172.16.0.0/32> to a usable IP address, to have a single known IP address be static routed to a regions closest server. While I understand the IP address does work (pings and what not), I don't feel this should be the proper IP address used, but something more feasible like a usable IP in a dedicated range (172.31.0.0/24<http://172.31.0.0/24> for example). Hi Ryan, Some clarifications: 1. You say, "static routed to a regions closest server." What do you mean by that? A static-routed anycast address? 2. In what reachability context? Is this a private network? An ISP network where the reachability should be the ISP and its customers? Regards, Bill Herrin -- William Herrin ................ herrin(a)dirtside.com<mailto:herrin@dirtside.com> bill(a)herrin.us<mailto:bill@herrin.us> Dirtside Systems ......... Web: <http://www.dirtside.com/>

6 8

Re: Static Routing 172.16.0.0/32
by Ryan Hamel 08 Dec '17

08 Dec '17

> At some point, some chucklehead is going to look at that .0.0 and mentally think /16, and things will go pear-shaped pretty quickly.... Same for a /12, which is RFC1918. -------- Original message -------- From: valdis.kletnieks(a)vt.edu Date: 12/8/17 1:46 PM (GMT-08:00) To: Ryan Hamel <Ryan.Hamel(a)quadranet.com> Cc: nanog(a)nanog.org Subject: Re: Static Routing 172.16.0.0/32 On Fri, 08 Dec 2017 03:13:57 +0000, Ryan Hamel said: > Greetings, > A colleague of mine has static routed 172.16.0.0/32 to a usable IP address, > to have a single known IP address be static routed to a regions closest server. > While I understand the IP address does work (pings and what not), I don't feel > this should be the proper IP address used, but something more feasible like a > usable IP in a dedicated range (172.31.0.0/24 for example). Probably depends on what your colleague is trying to do. Nothing in the rules says the .0 address on a subnet is reserved (though you're in for a surprise if there's any gear still on the net with a 4.2BSD stack). > I would to hear everyone's thoughts on this, as this the first IP address in > an RFC1918 range. > At some point, some chucklehead is going to look at that .0.0 and mentally think /16, and things will go pear-shaped pretty quickly....

1 0