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

[K. Scott Helms]

Nick,

Data on blocking inbound TCP or the kinds of gear that mistakenly
labels UDP fragments as DST port 0?

Scott Helms


On Wed, Aug 26, 2020 at 9:00 AM Nick Hilliard  wrote:
>
> K. Scott Helms wrote on 26/08/2020 13:55:
> > To be clear, UDP port 0 is not and probably shouldn't be blocked
> > because some network gear and reporting tools may mistake a fragmented
> > UDP PDU for port 0.  That's an implementation error, but one that may
> > be common enough to create issues for users.
> do you have data on this?
>
> Nick
>

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

[Nick Hilliard]

K. Scott Helms wrote on 26/08/2020 13:55:

To be clear, UDP port 0 is not and probably shouldn't be blocked
because some network gear and reporting tools may mistake a fragmented
UDP PDU for port 0.  That's an implementation error, but one that may
be common enough to create issues for users.

do you have data on this?

Nick

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

[K. Scott Helms]

To be clear, UDP port 0 is not and probably shouldn't be blocked
because some network gear and reporting tools may mistake a fragmented
UDP PDU for port 0.  That's an implementation error, but one that may
be common enough to create issues for users.  Blocking inbound TCP
port 0 is something that I've personally done in dozens of ISP
networks over more than a decade without a single reported issue.

Scott Helms


On Tue, Aug 25, 2020 at 7:39 PM narhiro  wrote:
>
>
> > "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
> >
> >
> >
> >>> On Tue, Aug 25, 2020 at 8:17 AM Job Snijders  wrote:
> >>>
>  On Tue, Aug 25, 2020 at 07:27:33AM -0400, K. Scott Helms wrote:
> >>> 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
> >>
> >> 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.
> >>> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
> >>
> >> What about UDP IP fragmentation?
> >>
> >> Kind regards,
> >>
> >> Job

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

[Bjørn Mork]

What problem are you trying to solve?


Bjørn

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

[Matthew Petach]

On Tue, Aug 25, 2020 at 8:36 AM Mel Beckman  wrote:

> “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

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

[K. Scott Helms]

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


On Tue, Aug 25, 2020 at 8:46 AM Job Snijders  wrote:
>
> On Tue, Aug 25, 2020 at 08:27:24AM -0400, K. Scott Helms wrote:
> > 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

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

[Dobbins, Roland]

> On 25 Aug 2020, at 18:13, Douglas Fischer  wrote:
> 
> 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.

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


Roland Dobbins 

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

[adamv0025]

> William Herrin
> Sent: Tuesday, August 25, 2020 4:20 PM
> 
> On Tue, Aug 25, 2020 at 4:15 AM Douglas Fischer
>  wrote:
> > 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

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

[Mel Beckman]

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

On Tue, Aug 25, 2020, 2:14 PM Douglas Fischer 
mailto:fischerdoug...@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

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

[William Herrin]

On Tue, Aug 25, 2020 at 4:15 AM Douglas Fischer
 wrote:
> 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



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

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

[Douglas Fischer]

Sorry!

sed 's/"I can think"/"I can't think"/g'

Em ter., 25 de ago. de 2020 às 09:16, Töma Gavrichenkov 
escreveu:

> Peace,
>
> On Tue, Aug 25, 2020, 2:14 PM Douglas Fischer 
>
>> 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

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

[Tom Beecher]

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 
> ]; 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 
> ]).
>
>
>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  wrote:

> On Tue, 25 Aug 2020 12:40:43 +
> Pim van Stam  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
>

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

[John Kristoff]

On Tue, 25 Aug 2020 12:40:43 +
Pim van Stam  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

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

[Töma Gavrichenkov]

Peace,

On Tue, Aug 25, 2020, 3:43 PM Pim van Stam  wrote:

> I think in general you can say that problems with UDP port 0 are in fact
> fragments. Ohter opinions on this?
>

Either that, or dumb DDoS packet generators.

--
Töma

>

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

[Job Snijders]

On Tue, Aug 25, 2020 at 08:27:24AM -0400, K. Scott Helms wrote:
> 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

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

[Pim van Stam]

> On 25 Aug 2020, at 14:27, K. Scott Helms  wrote:
> 
> 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



> 
> 
> Scott Helms
> 
> Scott Helms
> 
> 
> 
> On Tue, Aug 25, 2020 at 8:17 AM Job Snijders  wrote:
>> 
>> On Tue, Aug 25, 2020 at 07:27:33AM -0400, K. Scott Helms wrote:
>>> 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
>> 
>> 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.
>>> 
>>> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
>> 
>> What about UDP IP fragmentation?
>> 
>> Kind regards,
>> 
>> Job

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

[Mike Hammett]

TCP vs. UDP. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "K. Scott Helms"  
To: "Job Snijders"  
Cc: "NANOG list"  
Sent: Tuesday, August 25, 2020 7:27:24 AM 
Subject: Re: TCP and UDP Port 0 - Should an ISP or ITP Block it? 

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 



On Tue, Aug 25, 2020 at 8:17 AM Job Snijders  wrote: 
> 
> On Tue, Aug 25, 2020 at 07:27:33AM -0400, K. Scott Helms wrote: 
> > 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 
> 
> 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. 
> > 
> > https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
> >  
> 
> What about UDP IP fragmentation? 
> 
> Kind regards, 
> 
> Job 

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

[K. Scott Helms]

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



On Tue, Aug 25, 2020 at 8:17 AM Job Snijders  wrote:
>
> On Tue, Aug 25, 2020 at 07:27:33AM -0400, K. Scott Helms wrote:
> > 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
>
> 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.
> >
> > https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
>
> What about UDP IP fragmentation?
>
> Kind regards,
>
> Job

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

[Töma Gavrichenkov]

Peace,

On Tue, Aug 25, 2020, 3:14 PM Jon Lewis  wrote:

> 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.
>

Oh yes, if you don't reassemble fragments on your equipment then please
please do not filter anything.

--
Töma

>

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

[Job Snijders]

On Tue, Aug 25, 2020 at 07:27:33AM -0400, K. Scott Helms wrote:
> 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

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.
> 
> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

What about UDP IP fragmentation?

Kind regards,

Job

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

[Töma Gavrichenkov]

Peace,

On Tue, Aug 25, 2020, 2:14 PM Douglas Fischer 

> 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

>

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

[Jon Lewis]

On Tue, 25 Aug 2020, Douglas Fischer wrote:


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?


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


--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

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

[K. Scott Helms]

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


Scott Helms



On Tue, Aug 25, 2020 at 7:16 AM Douglas Fischer 
wrote:

> 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 Fernando Fischer
> Engº de Controle e Automação
>