Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?

[Tom Beecher <beecher () beecher cc>]

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 () 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