- NANOG - lists.nanog.org

BGP route hijack by AS10990
by Clinton Work 27 Aug '20

27 Aug '20

We saw a bunch of our IP blocks hijacked by AS10990 from 19:15 MDT until 20:23 MDT. Anybody else have problems with that. ASpath: 1299 7219 10990 50.92.0.0/17 AS10990 198.166.0.0/17 AS10990 198.166.128.0/17 AS10990 162.157.128.0/17 AS10990 162.157.0.0/17 AS10990 50.92.128.0/17 AS10990 -- Clinton Work Airdrie, AB

30 88

Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?
by K. Scott Helms 26 Aug '20

26 Aug '20

To be clear, UDP port 0 is not and probably shouldn't be blocked because some network gear and reporting tools may mistake a fragmented UDP PDU for port 0. That's an implementation error, but one that may be common enough to create issues for users. Blocking inbound TCP port 0 is something that I've personally done in dozens of ISP networks over more than a decade without a single reported issue. Scott Helms On Tue, Aug 25, 2020 at 7:39 PM narhiro <blackperl.narita9(a)gmail.com> wrote: > > > > "Port 0 is a reserved port, which means it should not be used by > > applications. Network abuse has prompted the need to block this port." > > > > "What about UDP IP fragmentation?" > > > > I'm not sure I follow this. The IP packet will be fragmented with UDP > > inside it. When the IP packet gets put together the UDP PDU will have > > a port number. It's possible that some packet analyzers or network > > gear will improperly "see" a partial UDP flow as port 0 but that's a > > mischaracterization of the flow. > > > > > > Scott Helms > > > > Scott Helms > > > > > > > >>> On Tue, Aug 25, 2020 at 8:17 AM Job Snijders <job(a)ntt.net> wrote: > >>> > >>>> On Tue, Aug 25, 2020 at 07:27:33AM -0400, K. Scott Helms wrote: > >>> I think a fairly easy thing to do is see what other large retail ISPs > >>> have done. Comcast, as an example, lists all of the ports they block > >>> and 0 is blocked. I do recommend that port 0 be blocked by all of the > >>> ISPs I work with and frankly Comcast's list is a pretty good one to > >>> use in general, though you will get some pushback on things like SMTP. > >>> https://www.xfinity.com/support/articles/list-of-blocked-ports > >> > >> I may be reading the table incorrectly, but it seems to me Comcast is > >> *not* blocking UDP port 0 according to the above URL? > >> > >>> Transit providers are a little bit different, but then again port 0 is > >>> also different since AFAIK it's never had a legitimate use case. It's > >>> always been a reserved port. I'd personally block it if I ran a > >>> transit, but I'd be more willing to open it up for one of my large > >>> customers (in a limited way) than I would on the retail side. > >>> https://www.iana.org/assignments/service-names-port-numbers/service-names-p… > >> > >> What about UDP IP fragmentation? > >> > >> Kind regards, > >> > >> Job

2 2

RPKI chain of trust
by Fabiano D'Agostino 26 Aug '20

26 Aug '20

Good morning everyone, I have a doubt about RPKI chain of trust. The 5 RIRs hold a self-signed root certificate for all the resources they have in the registry. The root certificate is used to sign the LIR's certificates that lists LIR's resources. LIRs use their private key to sign ROAs. LIR's public key is used to verify ROAs signatures and RIRs public key is used to verify LIR's signatures. Is this correct? Thanks in advance, Fabiano

2 3

TCP and UDP Port 0 - Should an ISP or ITP Block it?
by Douglas Fischer 26 Aug '20

26 Aug '20

I think that the subject of the e-mail is very self-explanatory. With some analysis of what is running over our network, ISP or ITP, we will be able to see some TCP/UDP(mostly UDP) packets with source or destination to port 0. I can think of a genuine use of it. (Maybe someone cloud help me see what I'm not seen.) So I have two questions: a) Should an ISP block that Kind of traffic? (like anti-spoofing on BNG/B-RAS) b) Should a Transit Provider block that Kind of traffic? -- Douglas Fernando Fischer Engº de Controle e Automação

13 18

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