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

Tue Aug 25 15:33:48 UTC 2020

“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 at 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 at gmail.com<mailto:ximaera at gmail.com>> escreveu:
Peace,

On Tue, Aug 25, 2020, 2:14 PM Douglas Fischer <fischerdouglas at gmail.com<mailto:fischerdouglas at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200825/5c2b3a6c/attachment.html>