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
> > be
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
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
What problem are you trying to solve?
Bjørn
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 ther
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:
>
> 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 te
> 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' da
“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
nonse
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
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
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 provid
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
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
>
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 ind
> 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 fragmenta
4 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
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 wit
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 UD
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
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
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 genui
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 gen
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 w
24 matches
Mail list logo
