TCP and UDP Port 0 - Should an ISP or ITP Block it?
Tom Beecher
beecher at beecher.cc
Tue Aug 25 13:02:18 UTC 2020
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.
On Tue, Aug 25, 2020 at 8:54 AM John Kristoff <jtk at depaul.edu> wrote:
> On Tue, 25 Aug 2020 12:40:43 +0000
> Pim van Stam <pim at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200825/1c775714/attachment.html>
More information about the NANOG
mailing list