Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?
On Tue, 25 Aug 2020 12:40:43 +0000 Pim van Stam <pim@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
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
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 thought would be transit providers should not block it because it is not invalid to use, simply not recommended. On Tue, Aug 25, 2020 at 8:54 AM John Kristoff <jtk@depaul.edu> wrote:
On Tue, 25 Aug 2020 12:40:43 +0000 Pim van Stam <pim@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
participants (2)
-
John Kristoff
-
Tom Beecher