- NANOG - lists.nanog.org

Amazon Peering
by Darin Steffl 30 Jan '19

30 Jan '19

Hey all, Does anyone have a direct contact to get a peering session established with Amazon at an IX? I sent a peering request Dec 2017 and two more times this Sept and Nov with no response. I sent to peering(a)amazon.com and received one automated response back so I know they received my email but nothing since. -- Darin Steffl Minnesota WiFi www.mnwifi.com 507-634-WiFi <http://www.facebook.com/minnesotawifi> Like us on Facebook <http://www.facebook.com/minnesotawifi>

11 18

Call for Presentations - CHI-NOG 09 (May 23rd)
by Tom Kacprzynski 30 Jan '19

30 Jan '19

CHI-NOG 09 - (Chicago Network Operators Group) May 23rd, 2019, Chicago, IL The Chicago Network Operators Group (CHI-NOG) is a vendor neutral organization. Our goal is to create a regional community of network professionals by presenting the latest technology trends, enabling collaboration and providing networking opportunities. CHI-NOG will be hosting its ninth annual conference on May 23rd, 2019 in downtown Chicago. For more information on the conference please see event's page ( http://chinog.org/chi-nog-09/) The CHI-NOG Program Committee is seeking proposals for presentations on relevant networking technologies with the focus on the following topics: * Network Automation / DevOps / CI-CD * Edge Computing and Networking * Interconnection/Peering * 5G Mobile * Open Networking * Overlay Networking Technologies * Low Latency Networks/Financial Networks * Network Security / DDoS * Academic Research in Networking and Related Infrastructure Fields. * Internet Monitoring * AI in Network Analytics * Advanced BGP/MPLS Technologies * Optical Networking/Data Center Interconnect * Content Delivery Networks (CDNs) * Software Defined Networking (SDN) * Network Traffic Engineering (TE) * Data Center Fabric * Tutorials Session Format Each presentation is 30 minutes, which includes a question and answer time. The duration can be extended per individual request to 60 minutes and will be considered by the program committee. Presentations should not contain any marketing material and should avoid discussion of commercial products but rather focus on the underlying technology. Key Dates 3/25/2019 - Presentation Abstract Submission Deadline 4/02/2019 - Program Committee's Selection Decision 4/15/2019 - Full Presentation Slides Submission Deadline 5/23/2019 - Conference Submission Please submit presentation’s abstract proposal by filling out the submission form at http://chinog.org/chi-nog-09/abstract-submission/ . Once your presentation is selected please provide the program committee with your photo and a short bio for web publication. All accepted speakers will receive complimentary tickets to the conference. For past presentation please see the archives at http://chinog.org/presentation-archive/. The program committee is looking forward to your submission and attendance.

1 0

AT&T Fiber Outage in Holmdel, NJ
by Amauris Rodriguez Martinez 30 Jan '19

30 Jan '19

Did anybody here have fiber issues yesterday night about 9:30 pm? Best Regards, Amauris Get Outlook for iOS<https://aka.ms/o0ukef>

2 2

NIST looking for comments on "Secure Interdomain Traffic Exchange – BGP Robustness and DDoS Mitigation: NIST Releases Draft NIST SP 800-189"
by Warren Kumari 29 Jan '19

29 Jan '19

Hey all, NIST is looking for comments on "Secure Interdomain Traffic Exchange – BGP Robustness and DDoS Mitigation: NIST Releases Draft NIST SP 800-189" They recently extended the deadline for comments to March 15, 2019, and so it looks like they would really like feedback.... ----- From: NIST Computer Security Division <csrc.nist(a)service.govdelivery.com> Subject: Secure Interdomain Traffic Exchange – BGP Robustness and DDoS Mitigation: NIST Releases Draft NIST SP 800-189 NIST has released Draft NIST Special Publication (SP) 800-189, Secure Interdomain Traffic Exchange: BGP Robustness and DDoS Mitigation, which provides technical guidance and recommendations for deploying technologies that improve the security of interdomain traffic exchange. The document focuses on securing the interdomain routing control (i.e., Border Gateway Protocol) traffic as well as mitigating Distributed Denial of Service (DDoS) attacks. It is intended to guide information security officers and managers of federal enterprise networks. The guidance also applies to the network services of hosting providers (e.g., cloud-based applications and service hosting) and Internet Service Providers (ISPs) when they are used to support federal IT systems. The guidance will also be useful for enterprise and transit network operators and equipment vendors in general. A public comment period for this document is open until March 15, 2019. Email Comments to: sp800-189(a)nist.gov Publication Details: https://csrc.nist.gov/publications/detail/sp/800-189/draft CSRC Update: https://csrc.nist.gov/news/2018/nist-releases-draft-sp-800-189-for-comment Warren. -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf

1 0

NANOG 75
by Bradley Raymo 29 Jan '19

29 Jan '19

NANOG Community, The NANOG 75 Agenda is published at http://www.cvent.com/d/1bqspy/16K and available as an iCal Feed <https://pc.nanog.org/static/published/meetings/NANOG75/agenda.ics>. The Program Committee has worked closely with our speakers to develop a first-rate program and we encourage all attendees to enjoy the whole conference. As we review submitted content, minor changes to the agenda are possible and will be updated in the online feed. Thank you to the many members of our community who submitted interesting content for NANOG 75! Over 700 attendees have registered and the NANOG family looks forward to welcoming all of you to San Francisco. Useful Information - NANOG 75 General Information and Registration: http://www.cvent.com/d/1bqspy - NANOG 75 Agenda: http://www.cvent.com/d/1bqspy/16K - Hotel Room Block(s) Information: http://www.cvent.com/d/1bqspy/8K - Reminder, registration is required to participate in the NANOG 75 Hackathon: http://www.cvent.com/d/1bqspy/4K - A welcome message that will be sent to registered NANOG 75 attendees a week before the conference will provide more information on scheduled events and applications to help you to make the most of your time in San Francisco. Safe travels and see you soon. Sincerely, Brad Raymo NANOG PC

1 0

Re: Verizon(AS701) announcing Comcast(AS7922) subnet 68.80.240.0/24
by Smith, Courtney 28 Jan '19

28 Jan '19

On 1/28/19, 2:08 PM, "Job Snijders" <job(a)ntt.net> wrote: Can you create RPKI ROAs for the 68.80.0.0/13? That is the most unambiguous, programmatically verifiable statement Comcast can make about what the rouing intentions of its prefixes are. Job, Working on plans for 2019.

1 0

Verizon(AS701) announcing Comcast(AS7922) subnet 68.80.240.0/24
by Smith, Courtney 28 Jan '19

28 Jan '19

Verizon (AS701) is currently originating 68.80.240.0/24. This is part of 68.80.0.0/13 allocated to Comcast (AS7922). We have reached out to Verizon to stop the announcement. Until that occurs, we request you block the 68.80.240.0/24 announcement. Thanks. route-views>show clock 18:35:15.335 UTC Mon Jan 28 2019 route-views>show ip bgp 68.80.240.0/24 longer-prefixes BGP table version is 34517149, local router ID is 128.223.51.103 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * 68.80.240.0/24 203.62.252.83 0 1221 4637 701 i * 162.250.137.254 0 4901 6079 3257 701 i * 207.172.6.1 0 0 6079 3257 701 i * 202.232.0.2 0 2497 701 i * 208.51.134.254 0 0 3549 3356 701 i * 89.149.178.10 10 0 3257 701 i * 144.228.241.130 80 0 1239 701 i * 212.66.96.126 0 20912 174 701 i * 132.198.255.253 0 1351 6939 701 i * 207.172.6.20 0 0 6079 1299 701 i * 202.93.8.242 0 24441 3491 3491 701 i * 208.74.64.40 0 19214 3257 701 i * 195.208.112.161 0 3277 3267 1299 701 i *> 137.39.3.55 0 701 i * 134.222.87.1 18750 0 286 701 i * 203.181.248.168 0 7660 2516 701 i * 217.192.89.50 0 3303 3320 701 i * 114.31.199.1 0 4826 1299 701 i * 209.124.176.223 0 101 101 2914 701 i * 193.0.0.56 0 3333 1273 701 i * 91.218.184.60 0 0 49788 174 701 i * 37.139.139.0 0 57866 701 i * 94.142.247.3 0 0 8283 57866 701 i * 12.0.1.63 0 7018 701 i * 194.85.40.15 0 0 3267 1299 701 i * 162.251.163.2 0 53767 3257 701 i * 198.58.198.255 0 1403 1299 701 i * 198.58.198.254 0 1403 1299 701 i * 154.11.12.212 0 0 852 1299 701 i * 173.205.57.234 0 53364 3257 701 i * 206.24.210.80 0 3561 209 701 i * 140.192.8.16 0 54728 20130 6939 701 i * 64.71.137.241 0 6939 701 i route-views> -- Courtney Smith Network Engineer Comcast TPX http://as7922.peeringdb.com https://www.comcasttechnologysolutions.com

3 3

Since today is a day ending in "Y" it's route hijack day? (Excelcom - as24203 please call)
by Christopher Morrow 28 Jan '19

28 Jan '19

Howdy! ExcelCom, you are being difficult to reach today AND you are originating prefixes which are not yours to originate: * 176.119.0.0/24 me 24203 I * 176.119.1.0/24 me 24203 I * 176.119.2.0/24 me 24203 I * 176.119.3.0/24 me 24203 I * 176.119.4.0/24 me 24203 I * 176.119.5.0/24 me 24203 I * 176.119.6.0/24 me 24203 I * 176.119.7.0/24 me 24203 I * 176.119.8.0/22 me 24203 I * 176.119.12.0/22 me 24203 I These prefixes are part of: inetnum: 176.119.0.0 - 176.119.15.255 netname: VSERVER-NET country: UA org: ORG-FGLP1-RIPE admin-c: LPG-RIPE tech-c: LPG-RIPE tech-c: VSRV-RIPE status: ASSIGNED PI mnt-by: RIPE-NCC-END-MNT mnt-by: VSERVER-MNT mnt-routes: VSERVER-MNT mnt-domains: VSERVER-MNT created: 2012-06-06T09:08:16Z last-modified: 2017-06-06T13:41:24Z source: RIPE # Filtered sponsoring-org: ORG-ML410-RIPE Looking at IRR data for AS24203: $ ./bgpq3 AS24203 | grep 176 $ ./bgpq3 AS24203 | grep 140 ip prefix-list NN permit 140.213.0.0/16 but the proper owner does have this content in their IRR data: $ ./bgpq3 AS58271 | grep 176 ip prefix-list NN permit 176.119.0.0/20 ip prefix-list NN permit 176.119.0.0/21 ip prefix-list NN permit 176.119.0.0/22 ip prefix-list NN permit 176.119.0.0/24 ip prefix-list NN permit 176.119.1.0/24 ip prefix-list NN permit 176.119.2.0/24 ip prefix-list NN permit 176.119.3.0/24 ip prefix-list NN permit 176.119.4.0/24 ip prefix-list NN permit 176.119.5.0/24 ip prefix-list NN permit 176.119.6.0/24 ip prefix-list NN permit 176.119.7.0/24 ip prefix-list NN permit 176.119.8.0/22 ip prefix-list NN permit 176.119.12.0/22 Could you please stop breaking someone's internet? :) -chris

1 0

Comcast email contact
by Josh Smith 27 Jan '19

27 Jan '19

Can someone from comcast email please contact me off-list. You all appear to be black holing email received from $DAYJOBS domain. Your support from indicates we are not blocked. Our logs indicate the mail is accepted for delivery but they never make it to users inboxes, or junk/spam folders. Thanks, Josh Smith

2 1

Process for deploying new BGP attributes (experimentally or otherwise)
by Amir Herzberg 27 Jan '19

27 Jan '19

Following our recent attempts to experiment with potential use of BGP attributes, I would like to understand better the desired process for using new BGP attributes. As mentioned earlier, we investigate currently one usage of BGP attributes for improving BGP security - specifically, adoption of RPKI. I also have some future ideas on other ways BGP attributes may be useful to improve BGP security; and surely other applications, security or otherwise, may exist. So I think we need an acceptable process to do it. Indeed, while we aborted that experiment, I doubt that the right conclusion is that one should simply never use a new BGP attribute... And I even hope that the community would want us to complete our research, to see if the particular approach we evaluate may indeed be beneficial. I think that these sentiments were also expressed by many members of this community. So: - Is there some document discussing the desired (best practice) process? [if not, maybe such document should be written?] - We used unassigned attribute. Should one always assign an attribute before using it? That's a possibility, but has some `costs' - and may yet fail to prevent problems to some non-conforming networks. - Is there an agreed-upon list of the forums and mailing lists on which one should warn in advance about such planned announcements, and the details that should be included? Thanks, Amir -- Amir Herzberg Comcast professor for security innovation Dept. of Computer Science and Engineering, University of Connecticut Homepage: https://sites.google.com/site/amirherzberg/home Publications and projects: https://www.researchgate.net/profile/Amir_Herzberg/contributions <https://www.researchgate.net/profile/Amir_Herzberg/publications> Lecture notes in intro to cyber: https://www.researchgate.net/project/Lecture-notes-on-Introduction-to-Cyber…

1 0