TCP and UDP Port 0 - Should an ISP or ITP Block it?
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
Douglas, 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 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-po... Scott Helms On Tue, Aug 25, 2020 at 7:16 AM Douglas Fischer <fischerdouglas@gmail.com> wrote:
Job, Comcast is blocking it. From the table on that page. "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@ntt.net> wrote:
TCP vs. UDP. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "K. Scott Helms" <kscott.helms@gmail.com> To: "Job Snijders" <job@ntt.net> Cc: "NANOG list" <nanog@nanog.org> Sent: Tuesday, August 25, 2020 7:27:24 AM Subject: Re: TCP and UDP Port 0 - Should an ISP or ITP Block it? Job, Comcast is blocking it. From the table on that page. "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@ntt.net> wrote:
a. some systems show UDP fragments as UDP port 0. So if the filter also handles fragments as UDP port 0, then you have a problem b. if you don’t reassemble UDP fragments and filter on port number, like 11212 (memcache) or 389 (ldap), then fragments will be forwarded and still be a problem I think in general you can say that problems with UDP port 0 are in fact fragments. Ohter opinions on this? Best regards, Pim van Stam
On Tue, Aug 25, 2020 at 08:27:24AM -0400, K. Scott Helms wrote:
The 'Transport' column seems to indicate that TCP port 0 is blocked, but not that UDP port 0 is blocked. I believe there are comcast people on this mailing list, it would be interesting to hear what the considerations were to block one but not the other.
You are absolutely right. There is no layer-4 header in a fragment. 'port 0' in netflow/ipfix traffic analyzer tools when displayed may be the result of a lack of ability to label it differently in the datastructures used. "mischaracterization" is a fitting word :-) Kind regards, Job
On Tue, 25 Aug 2020, Douglas Fischer wrote:
When an application sends more data via UDP than can be fit in a single packet, only the first packet has a UDP header [where the port info is stored]. The rest of the fragments have no UDP header, which most things will report as UDP src/dst port = 0. That traffic may be totally legitimate, so I would say, as an ISP/Transit Provider, you probably wouldn't want to just block all UDP port 0 traffic. For each link in your network where you have the ability, you might profile and then police UDP traffic, especially the ports commonly seen in reflection DDoS attacks (and port 0). ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route StackPath, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Peace, On Tue, Aug 25, 2020, 2:14 PM Douglas Fischer <fischerdouglas@gmail.com>
I can think of a genuine use of it.
I'm curious which one. With Berkeley sockets there's technically no way to bind(2) to this port without some amount of kernel patching applied, and the system cannot allocate it by itself, either. -- Töma
“SHOULD” is not “SHALL”, and thus this doesn’t countermand RFC 768’s instruction “ If not used, a value of zero is inserted." So the key question is, when is the source port not used? When a reply is not requested, is my thinking. Is there an application that implements this in UDP? (it’s nonsensical in TCP, which always requires a handshake, after all). I don’t recall one, but I can envision one: sending a one-way notification that requires no acknowledgement. Given that IP is designed to be extensible to support innovation, who’s to say that there won’t eventually be (if there isn’t already) an application that happens to follow the standard-declared mandate “If not used, a value of zero is inserted"? Should this application be randomly crippled (by inconsistent filtering) for simply following the rules? I know some say there is a security risk to zero-sourced UDP, but it seems to me that risk is only due to incorrect IP stack code. Zero-sourced UDP should be in everyone’s regression tests to verify non-dangerous behavior, since it’s an edge case specifically noticed by the standard. I think filtering zero-sourced UDP flies in the face of fundamental Internet interoperability. -mel On Aug 25, 2020, at 8:06 AM, Douglas Fischer <fischerdouglas@gmail.com> wrote: Sorry! sed 's/"I can think"/"I can't think"/g' Em ter., 25 de ago. de 2020 às 09:16, Töma Gavrichenkov <ximaera@gmail.com<mailto:ximaera@gmail.com>> escreveu: Peace, On Tue, Aug 25, 2020, 2:14 PM Douglas Fischer <fischerdouglas@gmail.com<mailto:fischerdouglas@gmail.com>> I can think of a genuine use of it. I'm curious which one. With Berkeley sockets there's technically no way to bind(2) to this port without some amount of kernel patching applied, and the system cannot allocate it by itself, either. -- Töma -- Douglas Fernando Fischer Engº de Controle e Automação
On Tue, Aug 25, 2020 at 8:36 AM Mel Beckman <mel@beckman.org> wrote:
There are many applications that send UDP streams that don't expect a reply. Here's one I worked on at previous $DAYJOB: https://github.com/yahoo/UDPing It emits a stream of UDP packets to a measurement box, which collects the data and reports statistics on it. No replies to the UDP probes are sent. But there's another, more common application that many people on this list use every day, and indeed was likely the initial trigger for this thread: netflow collection. Your routers emit UDP data streams, destined for a netflow collector box; no reply is expected (and indeed, no reply is desired; the router is busy enough *sending* the netflow stream, trying to process replies would just be another burden on the CPU). [...]
Indeed. There are existing applications where the source port of unidirectional UDP streams is not used, as no replies are expected, and may be left as zero. Matt
On Tue, Aug 25, 2020 at 4:15 AM Douglas Fischer <fischerdouglas@gmail.com> wrote:
a) Should an ISP block that Kind of traffic?
Hi Douglas, Generally speaking the answer is NO, You should not presume that your understanding of your customers' data traffic is sufficiently complete or correct to make blocking decisions for them. There are some major exceptions to this rule: 1. If your customer has directed you to apply your expertise and make blocking decisions for you. 2. For commodity dynamic-IP (residential) accounts only, there is a small set of "attractive nuisance" ports which it's reasonable to exclude from your service offering. Generally email server to server (port 25) and the historically poorly secured MS Windows LAN ports (135-139, 445, and 1900). It's fair to tell these customers that (A) they don't want to use those ports and (B) if they do want to use those ports, buy the SOHO offering. 3. For low-dollar virtual server products it's not unreasonable to block the same ports by default and for the same reasons, as long as you're prepared to promptly remove the blocks upon request.
b) Should a Transit Provider block that Kind of traffic?
Preemptively? Never. If I found my business transit provider was doing this, I'd treat it as a breach of contract. As for port 0 specifically, it doesn't really fit the attractive nuisance mold. It's about as harmless (or harmful) as any random TCP port. It doesn't particularly have a history of doing harm. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
Agree, but there are less invasive options as well like rate limiting or comb rate-limiting (i.e. rate-limiter per address range).
Agree, but again one can still do proactive rate limit based on historical data (to address the hit and run type of attacks -that exploit the reactive application of filters). adam
On 25 Aug 2020, at 18:13, Douglas Fischer <fischerdouglas@gmail.com> wrote:
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.
Are you certain that the UDP packets exhibit port 0, or is this flow telemetry reporting non-initial fragments as port 0 (they don’t actually have ports). -------------------------------------------- Roland Dobbins <roland.dobbins@netscout.com>
participants (13)
-
adamv0025@netconsultings.com
-
Bjørn Mork
-
Dobbins, Roland
-
Douglas Fischer
-
Job Snijders
-
Jon Lewis
-
K. Scott Helms
-
Matthew Petach
-
Mel Beckman
-
Mike Hammett
-
Pim van Stam
-
Töma Gavrichenkov
-
William Herrin