- Test - lists.nanog.org

Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?
by John Kristoff 25 Aug '20

25 Aug '20

On Tue, 25 Aug 2020 12:40:43 +0000 Pim van Stam <pim(a)vanstam-ict.nl> wrote: > Ohter opinions on this? IETF RFC 768 - User Datagram Protocol weighs in: "Source Port is an optional field, when meaningful, it indicates the port of the sending process, and may be assumed to be the port to which a reply should be addressed in the absence of any other information. If not used, a value of zero is inserted." In practice however, most applications I've seen that do not expect a response still set a non-zero value (e.g. flow-export, syslog). John

2 1

Recently Completed BGP Study on "Peerlock" Defensive Filtering
by Tyler McDaniel 25 Aug '20

25 Aug '20

Hello! My colleagues and I at the University of Tennessee recently completed a study on the “Peerlock” route leak protection system ( https://archive.nanog.org/sites/default/files/Snijders_Everyday_Practical_B…) and related defensive filtering techniques. Specifically, we probed for evidence of these systems on the control plane and attempted to locate filtering sites. Additionally, we evaluated the system's effectiveness in simulation. The pre-print of this paper is available at: https://arxiv.org/abs/2006.06576. While this work was previously mentioned here by Job Snijders, we want to make an additional push for comments from network operators. Our experimental design and findings in Section 3 may be of some interest. Most importantly, if any of the Tier 1 networks could confirm or challenge our findings with respect to their filter placement, that would be enormously helpful! We realize that this information is often secret/under NDA, but providing some element of ground truth would assist us in correctly evaluating our work. Thank you! Tyler McDaniel Graduate Research Assistant/PhD Candidate Computer Security Laboratory Department of Electrical Engineering and Computer Science University of Tennessee, Knoxville

1 0

Orange : Propagating Bogus Saudi Telecom Announcement
by Tom Beecher 24 Aug '20

24 Aug '20

Saudi Telecom ( AS 39386 ) is currently announcing Equinix NY9's IX prefix, and Orange is gladly sharing that for the world to see. Zayo : You might want to not be using that either when you're directly connected to that exchange. :) *Router:* New York, NY *Command:* show route protocol bgp table inet.0 198.32.118.0/24 terse exact inet.0: 833301 destinations, 5821043 routes (833250 active, 16 holddown, 88 hidden) + = Active Route, - = Last Active, * = Both A V Destination P Prf Metric 1 Metric 2 Next hop AS path * ? 198.32.118.0/24 B 170 100 4294967294 5511 39386 39386 39386 39386 I unverified >64.125.29.222 64.125.29.220 ? B 170 100 4294967294 5511 39386 39386 39386 39386 I unverified >64.125.29.222 64.125.29.220 ? B 170 100 4294967294 5511 39386 39386 39386 39386 I unverified >64.125.29.220 64.125.29.222 ? B 170 100 4294967294 5511 39386 39386 39386 39386 I unverified >64.125.29.220 64.125.29.222 ? B 170 100 4294967294 5511 39386 39386 39386 39386 I unverified >64.125.29.220 64.125.29.222 {master}

3 3

Mail rejected at secureserver.net/godaddy any contacts over there?
by Drew Weaver 24 Aug '20

24 Aug '20

I've attempted to contact them using their form but I feel as though I am stuck in a loop with their diligent and no doubt hard working staff they have manning that post. Can anyone put me into contact with someone that can answer a few questions? Thanks, -Drew

2 1

Get ready to hack!
by NANOG News 24 Aug '20

24 Aug '20

Join many of the brightest minds in our community at the NANOG 80 Virtual Hackathon. Our first all-virtual hackathon kicks off Saturday, October 17 at 1:00 pm EDT — the weekend before the NANOG 80 <https://www.nanog.org/meetings/nanog-80/> conference. As always, participation is free, and open to all who register. Get all the details about the format, schedule, and more! And if you'd like to participate but aren’t sure where to start, we have lots of topic ideas to share. Please reach out to us: hackathon-support(a)nanog.org. Learn More + Register Now <https://www.nanog.org/meetings/nanog-80/nanog-80-hackathon/>

1 0

00:aa:bb:01:23:45
by Baldur Norddahl 24 Aug '20

24 Aug '20

Hello By accident I noticed several of my VPLS instances have 00:aa:bb:01:23:45 in the MAC table. We never sent anything just received a little traffic from that. Obviously not a real MAC address so I tried to search Google for it. I find several hits with apparently ADSL users doing pppd (which we do not have). Anyone have any idea what this could be? Regards, Baldur

2 1

Re: RPKI for dummies
by John Kristoff 24 Aug '20

24 Aug '20

On Sun, 23 Aug 2020 12:40:19 +0000 Dovid Bender <dovid(a)telecurve.com> wrote: > Ok. So here is another n00b question. Why don't we have something > where when we advertise IP space we also pass along a cert [...] Take a look at: Stephen Kent, Charles Lynn, and Karen Seo. 2000. Secure border gateway protocol (S-BGP). IEEE Journal on Selected areas in Communications 18, 4 (2000), 582–592. and Russ White. 2003. Securing BGP: soBGP. Internet Protocol Journal 6, 3 (Sept. 2003), 15–22. Two precursors to the system we have today. Both proposed some form of including PKI-related matter in BGP messages. Neither system gained much actual traction outside of the design phase as far as I know. Some might suggest that a lot of time was spent debating how to do it with little actual progress or experimentation done. The current approach has echoes of those ideas with the obvious difference as you imply, it is independent from BGP. This poses some challenges to providing a complete solution, but was probably necessary for deployment and might prove useful if something other than wants to BGP uses it. John

3 2

Re: RPKI for dummies
by John Kristoff 24 Aug '20

24 Aug '20

On Mon, 24 Aug 2020 13:01:15 +0000 Robert Raszuk <robert(a)raszuk.net> wrote: > I would not say that either S-BGP nor so-BGP were precursors to BGP > origin validation ( I am assuming this is what you are referring to > as "system we have today"). I would consider origin validation as just one application of the system we have today. Does that sound better? John

2 1

Re: RPKI for dummies
by John Kristoff 23 Aug '20

23 Aug '20

On Thu, 20 Aug 2020 13:20:53 +0000 Dovid Bender <dovid(a)telecurve.com> wrote: > How do ISP's that receive my advertisement (either directly from me, > meaning my upstreams or my upstreams upstream) verify against the > cert that the advertisement is coming from me? Nothing about your BGP announcements needs to change. Through ARIN you create one or more route origin authorizations (ROAs) with your public key. ARIN can even do all the work of creating the key pair for you if you like. You might try creating test ROAs in their operational test and evaluation environment (OTE) environment to see how this process of creating a ROA works. ISPs obtain these ROAs apart and separately from the BGP system. ISPs that fetch your ROA(s) and other RPKI objects through the RPKI ecosystem, perform validation, and communicate AS origin and prefix information contained in these ROAs to BGP routers. At that point this information is used to inform the route decision process, comparing received routes with processed ROAs as part of a route import policy. > If say we have Medium ISP (AS1000) -> Large ISP (AS200) in the above > case AS200 know it's peering with AS1000 so it will take all > advertisements. What's stopping AS1000 from adding a router to their > network to impersonate me, make it look like I am peering with them > and then they re-advertise the path to Large ISP? In a nutshell, today, ISPs will only be able to validate the prefix and origin AS you publish in the ROA, this is known as route origin validation (ROV). Today someone could advertise your prefix and post-pend your AS to appear as the origin. People are working madly on solutions to protecting other parts of the BGP route attributes the origin AS, but nothing is currently, widely deployed to provide that protection with the RPKI today. John

3 2

RPKI for dummies
by Dovid Bender 23 Aug '20

23 Aug '20

Hi, I am sorry for the n00b question. Can someone help point me in the right direction to understand how RPKI works? I understand that from my side that I create a key, submit the public portion to ARIN and then send a signed request to ARIN asking them to publish it. How do ISP's that receive my advertisement (either directly from me, meaning my upstreams or my upstreams upstream) verify against the cert that the advertisement is coming from me? If say we have Medium ISP (AS1000) -> Large ISP (AS200) in the above case AS200 know it's peering with AS1000 so it will take all advertisements. What's stopping AS1000 from adding a router to their network to impersonate me, make it look like I am peering with them and then they re-advertise the path to Large ISP? Again sorry for the n00b question, I am trying to make sense of how it works. TIA. Dovid

5 7