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,
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-port-numbers.xhtml
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).
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.
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.
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.
What about UDP IP fragmentation?
Kind regards,
Job
Peace,
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
TCP vs. UDP.
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.
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
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."
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.
"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.
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
Peace,
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
I was just reading the same thing JTK.
Of course this is followed by RFC8085 / BCP 145 , UDP Usage Guidelines :
5.1 Using UDP Ports
A UDP sender SHOULD NOT use a source port value of zero. A source port number that cannot be easily determined from the address or payload type provides protection at the receiver from data injection attacks by off-path devices. A UDP receiver SHOULD NOT bind to port zero. Applications SHOULD implement receiver port and address checks at the application layer or explicitly request that the operating system filter the received packets to prevent receiving packets with an arbitrary port. This measure is designed to provide additional protection from data injection attacks from an off-path source (where the port values may not be known). Applications SHOULD provide a check that protects from off-path data injection, avoiding an application receiving packets that were created by an unauthorized third party. TCP stacks commonly use a randomized source port to provide this protection [[RFC6056](https://tools.ietf.org/html/rfc6056)]; UDP applications should follow the same technique. Middleboxes and end systems often make assumptions about the system ports or user ports; hence, it is recommended to use randomized ports in the Dynamic and/ or Private Port range. Setting a "randomized" source port also provides greater assurance that reported ICMP errors originate from network systems on the path used by a particular flow. Some UDP applications choose to use a predetermined value for the source port (including some multicast applications), these applications need to therefore employ a different technique. Protection from off-path data attacks can also be provided by randomizing the initial value of another protocol field within the datagram payload, and checking the validity of this field at the receiver (e.g., RTP has random initial sequence number and random media timestamp offsets [[RFC3550](https://tools.ietf.org/html/rfc3550)]).
From the combination of the two, being that the ‘don’t’ is a SHOULD NOT, my thought would be transit providers should not block it because it is not invalid to use, simply not recommended.
Sorry!
sed ‘s/“I can think”/“I can’t think”/g’
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
“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
William Herrin
Sent: Tuesday, August 25, 2020 4:20 PM> 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.
Agree, but there are less invasive options as well like rate limiting or comb rate-limiting (i.e. rate-limiter per address range).
> 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.
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
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).
That's correct, I can only blame my lack of coffee at that point for
the oversight. I went back and looked at where we have this
implemented and it's only TCP.
Scott Helms
“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.
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).
[…]
I think filtering zero-sourced UDP flies in the face of fundamental Internet interoperability.
-mel
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