Subject: [tsvwg] Fwd: UDP source ports for HTTP/3 and QUIC

From: Mark Nottingham <[email-masked]>
Date: Mon, 19 Jul 2021 15:58:21 +1000

Hi TSVWG,

I started a conversation on the HTTP and QUIC mailing lists regarding the somewhat common practice of server-side blocking of UDP source ports that can be used for reflection attacks; see below.

Doing so interacts poorly with QUIC and HTTP/3, because it not only requires a new connection to be established (thereby increasing latency), but many implementations also take it as a sign that UDP is blocked on that particular network path, so they don't attempt to use QUIC for some time afterwards to that particular host -- effectively downgrading.

We seem to have some agreement there that documenting this is a good idea, but that putting it in an RFC doesn't make a lot of sense,[1] because (unfortunately) the list of such protocols is likely to grow.

So, a registry might do the trick. Rather than spinning up a purpose-built registry, I was wondering whether we could write add a column to the Service Name and Transport Protocol Port Number Registry, something along the lines of 'Potential Reflection Vector'.

What do folks here think about that?

Cheers,

P.S. Please CC me on responses, as I'm not subscribed.

1. However, see <https://github.com/quicwg/ops-drafts/pull/392>

> Begin forwarded message:
> 
> From: Mark Nottingham <[email-masked]>
> Subject: UDP source ports for HTTP/3 and QUIC
> Date: 15 July 2021 at 10:20:39 am AEST
> To: HTTP Working Group <[email-masked]>, IETF QUIC WG <[email-masked]>
> Resent-From: [email-masked]
> Archived-At: <https://www.w3.org/mid/[email-masked]>
> 
> [ bringing this up on both lists because it's not yet clear what the right scope is ]
> 
> It's not uncommon for servers to block certain UDP source ports to avoid being overwhelmed by certain reflection attacks. In particular:
> 
> * 53 - DNS
> * 123 - NTP
> * 1900 - SSDP
> * 5353 - mDNS
> * 11211 - memcached
> 
> ... among other candidates.
> 
> See, eg., <https://blog.cloudflare.com/reflections-on-reflections/>. This isn't done to avoid protocol vulnerabilities as such -- it's to avoid volumetric attacks (usually DDoS). 
> 
> If a client chooses source ports from the ephemeral port range, this shouldn't be an issue. However, some implementations (or deployments) extend the source port range "downwards" to avoid exhaustion:
> 
> * On Linux, it's pretty common to tune to extend the ephemeral port range, e.g., <https://ma.ttias.be/linux-increase-ip_local_port_range-tcp-port-range/>
> 
> * On some versions of Windows, ports as low as 1025 are used: <https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements>
> 
> * FreeBSD has used ports as low as 1024 in the past; their documentation is... confused right now. <https://github.com/freebsd/freebsd-src/blob/373ffc62c158e52cde86a5b934ab4a51307f9f2e/sys/netinet/in.h#L272> (I don't run a FreeBSD box to check this)
> 
> * NAT and CGNAT are a thing. <https://www.rfc-editor.org/rfc/rfc4787.html#section-4.2.1> recommends that source ports in the range 1024-65535 be reassigned within that range, which can cause collisions. 
> 
> Overall, the chance of collision (i.e., a client or a NAT choosing a blocked source port) is quite low, but at Internet scale it'll happen, leading to the client needing to open a new connection, thereby adding perceived latency. 
> 
> At a minimum, it seems like a good thing for client and NAT developers to be aware that some ports are likely to be blocked, so that they can avoid them if they care about perceived performance. This e-mail might be enough for that immediate purpose.
> 
> My question is whether there's a need for more coordination -- e.g., a very short RFC outlining such ports, to help bring this to folks' attention (especially in the NAT crowd)?
> 
> Cheers,
> 
> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Joseph Touch <[email-masked]>
Date: Mon, 19 Jul 2021 20:15:25 -0700

Hi, Mark,

All ports are permitted as *source* ports. They are not assigned by IANA nor do any have special meaning, AFAICT.

Port values have meaning most specifically in socket pairs; they are assigned/reserved by IANA and have meaning for a RFC793-style socket ONLY when there is a corresponding RFC793-style listen listen that allows the source port to float AND when there is no more specific binding to a socket pair.

This suggests we should neither create a registry nor document this approach, to avoid either giving the impression of endorsing this behavior.

At best, we should document why this behavior is incorrect and should be avoided.

Joe

(NB: I’m referring to RFC793 sockets and listens, not how Unix ior other OSes implement these)

> On Jul 18, 2021, at 10:58 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Hi TSVWG,
> 
> 1. However, see <https://github.com/quicwg/ops-drafts/pull/392 <https://github.com/quicwg/ops-drafts/pull/392>>
> 
> 
>> Begin forwarded message:
>> 
>> From: Mark Nottingham <[email-masked] <mailto:[email-masked]>>
>> To: HTTP Working Group <[email-masked] <mailto:[email-masked]>>, IETF QUIC WG <[email-masked] <mailto:[email-masked]>>
>> Resent-From: [email-masked] <mailto:[email-masked]>
>> Archived-At: <https://www.w3.org/mid/[email-masked] <https://www.w3.org/mid/[email-masked]>>
>> 
>> See, eg., <https://blog.cloudflare.com/reflections-on-reflections/ <https://blog.cloudflare.com/reflections-on-reflections/>>. This isn't done to avoid protocol vulnerabilities as such -- it's to avoid volumetric attacks (usually DDoS). 
>> 
>> * On Linux, it's pretty common to tune to extend the ephemeral port range, e.g., <https://ma.ttias.be/linux-increase-ip_local_port_range-tcp-port-range/ <https://ma.ttias.be/linux-increase-ip_local_port_range-tcp-port-range/>>
>> 
>> * On some versions of Windows, ports as low as 1025 are used: <https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements <https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements>>
>> 
>> * FreeBSD has used ports as low as 1024 in the past; their documentation is... confused right now. <https://github.com/freebsd/freebsd-src/blob/373ffc62c158e52cde86a5b934ab4a51307f9f2e/sys/netinet/in.h#L272 <https://github.com/freebsd/freebsd-src/blob/373ffc62c158e52cde86a5b934ab4a51307f9f2e/sys/netinet/in.h#L272>> (I don't run a FreeBSD box to check this)
>> 
>> * NAT and CGNAT are a thing. <https://www.rfc-editor.org/rfc/rfc4787.html#section-4.2.1 <https://www.rfc-editor.org/rfc/rfc4787.html#section-4.2.1>> recommends that source ports in the range 1024-65535 be reassigned within that range, which can cause collisions. 
>> 
>> Mark Nottingham   https://www.mnot.net/ <https://www.mnot.net/>
>> 
>> 
> 
> --
> Mark Nottingham   https://www.mnot.net/ <https://www.mnot.net/>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 20 Jul 2021 13:43:22 +1000

Hi Joe,

> On 20 Jul 2021, at 1:15 pm, Joseph Touch <[email-masked]> wrote:
> 
> Hi, Mark,
> 

And yet, we have text like this in RFC5905:

> dstport: UDP port number of the client, ordinarily the NTP port
   number PORT (123) assigned by the IANA.  This becomes the source port
   number in packets sent from this association.

and this in RFC6762:

> A compliant Multicast DNS querier, which implements the rules
   specified in this document, MUST send its Multicast DNS queries from
   UDP source port 5353 (the well-known port assigned to mDNS)

> This suggests we should neither create a registry nor document this approach, to avoid either giving the impression of endorsing this behavior.

I don't follow. 

> At best, we should document why this behavior is incorrect and should be avoided.

Based upon the preliminary discussions we've had on the QUIC list, I don't think there's consensus to do that.

---

From: Joseph Touch <[email-masked]>
Date: Mon, 19 Jul 2021 21:10:05 -0700

Hi, Mark,

> On Jul 19, 2021, at 8:43 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Hi Joe,
> 

This is consistent with my definition above. See notably the definition for srcport, which is 123 only in symmetric mode (which makes sense - both sides can receive requests).

>   UDP source port 5353 (the well-known port assigned to mDNS)

It is sending from the port on which it listens, as noted in the remainder of that paragraph:
   , and MUST
   listen for Multicast DNS replies sent to UDP destination port 5353 at
   the mDNS link-local multicast address (224.0.0.251 and/or its IPv6
   equivalent FF02::FB).

I.e., it is sending from a server. 

> Based upon the preliminary discussions we've had on the QUIC list, I don't think there's consensus to do that.

Well, there’s no consensus on reserving ports as source ports UNLESS that is the port on which the service listens. I.e., IANA ports are defined as listening ports and are thus used in packets emitted from that listener.

There should be no prohibition on using any port number for source unless a listen exists on that port. There’s no precedence for that decision and no registry where those values would be indicated. 

Joe

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Tue, 20 Jul 2021 07:10:22 -0700 (PDT)

Hello Joe, Mark, etc,

  I have to support Joe's possition here, there have never been
this restriction placed on source address ports by the IETF or IANA,
even though most implementations do impose them.

  It would, in my opinion, be a mistake to try and impose this now.

Regards,
Rod Grimes

> Well, there?s no consensus on reserving ports as source ports UNLESS that is the port on which the service listens. I.e., IANA ports are defined as listening ports and are thus used in packets emitted from that listener.
> 
> There should be no prohibition on using any port number for source unless a listen exists on that port. There?s no precedence for that decision and no registry where those values would be indicated. 
> 
> Joe
-- 
Rod Grimes                                                 [email-masked]

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 20 Jul 2021 15:39:20 +0100

This is just a short note to say that I think this topic **IS** in the 
scope of tsvwg.

IETF transport protocols do utilise source ports in various ways, 
(RFC6437; RFC6438; RFC8086; etc) e.g.:

- as a part of IP fragmentation processing in the net and at endpoints;
- can be used a part of forwarding, QoS classification; and tunnel 
processing;
- as a part of load balancing ( ECMP etc);
- randomised src ports as a method of mitigating off-path data insertion 
attack at receivers;
etc.

Some protocols have specified the src port as a part of their spec.  
Some relevent BCPs are RFC8085; RFC6056. I'd expect recommendations to 
on-path devices to *NOT* be specific to QUIC, and devices don't know 
which traffic is QUIC; Endpoints at the transport also might not know 
which traffic is QUIC.

Please do discuss the use of source ports here on the tsvwg list, 
especially if there is new thinking on how source ports of QUIC should 
be used and/or should be managed.

Best wishes,

Gorry Fairhurst
(as a TSVWG Chair)

On 20/07/2021 05:10, Joseph Touch wrote:
> Hi, Mark,
>
>> On Jul 19, 2021, at 8:43 PM, Mark Nottingham <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Joe,
>>
>>> On 20 Jul 2021, at 1:15 pm, Joseph Touch <[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>
>>> Hi, Mark,
>>>
>>> All ports are permitted as *source* ports. They are not assigned by 
>>> IANA nor do any have special meaning, AFAICT.
>>>
>>> Port values have meaning most specifically in socket pairs; they are 
>>> assigned/reserved by IANA and have meaning for a RFC793-style socket 
>>> ONLY when there is a corresponding RFC793-style listen listen that 
>>> allows the source port to float AND when there is no more specific 
>>> binding to a socket pair.
>>
> This is consistent with my definition above. See notably the 
> definition for srcport, which is 123 only in symmetric mode (which 
> makes sense - both sides can receive requests).
>
>> and this in RFC6762:
>>
>>> This suggests we should neither create a registry nor document this 
>>> approach, to avoid either giving the impression of endorsing this 
>>> behavior.
>>
>> I don't follow.
>>
>> Based upon the preliminary discussions we've had on the QUIC list, I 
>> don't think there's consensus to do that.
>
> Well, there’s no consensus on reserving ports as source ports UNLESS 
> that is the port on which the service listens. I.e., IANA ports are 
> defined as listening ports and are thus used in packets emitted from 
> that listener.
>
> There should be no prohibition on using any port number for source 
> unless a listen exists on that port. There’s no precedence for that 
> decision and no registry where those values would be indicated.
>
> Joe

---

From: "Holland, Jake" <[email-masked]>
Date: Tue, 20 Jul 2021 14:59:58 +0000

From: Joseph Touch <[email-masked]>
> Date: Mon,2021-07-19 at 9:10 PM
> Well, there’s no consensus on reserving ports as source ports
> UNLESS that is the port on which the service listens. I.e.,
> IANA ports are defined as listening ports and are thus used
> in packets emitted from that listener.

From reading the links in the original message, I didn't think
the idea here was to reserve source ports, exactly.

As I understand the proposal, it's to say "these source ports
happen to match common attack targets that are listening ports
for other protocols, and thus commonly get special handling to
help avoid reflection attacks against those servers".

> There should be no prohibition on using any port number for
> source unless a listen exists on that port.

As I understood it, it's not a prohibition on using those ports,
it's a warning that if you use them, many servers are likely to
block you and likely to continue to do so until further notice
(at least until they have a better answer deployed).

> There’s no precedence for that decision and no registry where
> those values would be indicated. 

The proposal here is to create such a registry.

Of course we don't need precedent to do something that's a good
idea, but the burden of proof is lower if there's some sense in
which there's good precedents showing how doing something like
it in the past has helped things.

I would argue there's plenty of such examples for both
"document how the internet works in practice" (especially when
it has diverged from a design from 30+ years ago that didn't
anticipate modern security issues like reflection attacks) and
for "create a registry to list things that can help people
avoid unpleasant surprises".

My main reservation here is that I'm not sure I understand why
the listening ports are special--a volumetric reflection attack
using servers for amplification would be just as effective with
random source ports as long as it can fill the pipes for the
victim's IP, wouldn't it?

I thought the real problem is that protocol design needs to
avoid generating more traffic than was sent to them before the
server has proved 2-way connectivity to someone who requested
it?  I don't quite get how blocking source ports can fill that
hole.

But with that said, it's interesting that people are doing this,
and if it's the best operational fix for *some* problem, it seems
worth documenting to me, if only selfishly so I can understand
where it's helpful.

-Jake

---

From: "Black, David" <[email-masked]>
Date: Tue, 20 Jul 2021 19:02:38 +0000

Explaining as an individual, not WG chair ... TL;DR - +1 on Jake's comments, his understanding matches mine.

Providing some more detail ...

> help avoid reflection attacks against those servers".

+1 - this is about documenting "running code" that discards traffic that uses one of those UDP source ports.

> The proposal here is to create such a registry.

I definitely agree that a new registry is wanted/warranted, and I agree with Joe's objections to adding this information to the existing registry for ports.

Creating the new registry would require an RFC that lays out the rules for adding a port to the new registry.  I support that approach as I think there ought to be IETF consensus on what the criteria are for adding a port to that new registry.

... and responding to a question from Jake ...

> victim's IP, wouldn't it?

The attacks of concern are 3rd party amplification attacks that are launched by an attacker sending small requests to a plethora of "foo" servers with the victim's IP address used as the source IP for the requests.  The "foo" servers have amplification properties in that a small request results in a large response, and the resulting plethora of large responses inundates the victim.

The "foo" servers of relevance to this discussion use a fixed value for the UDP source port in their (large) responses, hence a source port filtering rule that discards matching traffic blocks this sort of attack.  If something other than a "foo" server uses that UDP source port, its traffic is at risk of getting discarded, so the purpose of the registry is to warn against use of UDP source ports that risk this sort of traffic discard.

Thanks, --David

-----Original Message-----
From: tsvwg <[email-masked]> On Behalf Of Holland, Jake
Sent: Tuesday, July 20, 2021 11:00 AM
To: Joseph Touch; Mark Nottingham
Cc: [email-masked]
Subject: Re: [tsvwg] UDP source ports for HTTP/3 and QUIC

[EXTERNAL EMAIL] 

-Jake

---

From: Joseph Touch <[email-masked]>
Date: Wed, 21 Jul 2021 21:56:56 -0700

Hi, David,

> On Jul 20, 2021, at 12:02 PM, Black, David <[email-masked]> wrote:
> 

There’s a hazard with this viewpoint, IMO.

It’s like observing people driving on flat tires and thinking the road is bumpy.

There are two solutions: 
	- document existing practice and describe how road engineers can redesign roads to avoid the problem
	- document that driving on flat tires is incorrect and explain what it impacts

I agree with documenting the problem as a problem, but not as a practice. The latter viewpoint endorses it, which then means we all have to accommodate that behavior.

> I definitely agree that a new registry is wanted/warranted,

I have no problem making a list of ports that people MISTAKENLY attribute to attacks.

However, those who assume that a packet is bad simply because it uses one of these source ports is ITSELF incorrect. Just because it works when you’re under this attack, doesn’t mean it is safe to do when you’re not.

Let’s please not endorse incorrect conclusions that source port has this sort of meaning.

Joe

---

From: "Black, David" <[email-masked]>
Date: Thu, 22 Jul 2021 15:05:31 +0000

Hi Joe,

Let's start from a couple of aspects where we're in rough agreement:

  *   "… agree with documenting the problem as a problem, but not as a practice." &
  *   " … no problem making a list of ports that people ... attribute to attacks."

Someone ought to "Send Draft!" (credit to Randy Bush) that contains an explanation of the problem, text to create the new IANA registry that lists the ports plus some discussion of what can usefully be done.  That draft's text on implications and recommendations (what can usefully be done) can then be discussed in detail to get to precise text that is acceptable to all (e.g., what to do about the view that attribution to attacks in the second bullet may be mistaken).

Does that sound reasonable?

Thanks, --David

From: Joseph Touch <[email-masked]>
Sent: Thursday, July 22, 2021 12:57 AM
To: Black, David
Cc: Holland, Jake; Mark Nottingham; [email-masked]
Subject: Re: [tsvwg] UDP source ports for HTTP/3 and QUIC

[EXTERNAL EMAIL]
Hi, David,

On Jul 20, 2021, at 12:02 PM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:

There are two solutions:

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 22 Jul 2021 16:45:53 +0100

I'm still misisng some context about the use case why a QUIC client 
would wishes to use a source port outside the ephmeral range.

Althoughit was always possible to use all ports as source port, that use 
does not come without pain. And QUIC multiplexes data, so  what's the 
use case for using the lower-numbered source ports?

Gorry

On 22/07/2021 16:05, Black, David wrote:
> Someone ought to "Send Draft!" (credit to Randy Bush) that contains an 
> explanation of the problem, text to create the new IANA registry that 
> lists the ports plus some discussion of what can usefully be done. 
>  That draft's text on implications and recommendations (what can 
> usefully be done) can then be discussed in detail to get to precise 
> text that is acceptable to all (e.g., what to do about the view that 
> attribution to attacks in the second bullet may be mistaken).
>
> *From:* Joseph Touch <[email-masked]>
> *Sent:* Thursday, July 22, 2021 12:57 AM
> *To:* Black, David
> *Cc:* Holland, Jake; Mark Nottingham; [email-masked]
> *Subject:* Re: [tsvwg] UDP source ports for HTTP/3 and QUIC
>
> [EXTERNAL EMAIL]
>
> Hi, David,
>
>
>
>     Explaining as an individual, not WG chair ... TL;DR - +1 on Jake's
>     comments, his understanding matches mine.
>
>     +1 - this is about documenting "running code" that discards
>     traffic that uses one of those UDP source ports.
>
> I agree with documenting the problem as a problem, but not as a 
> practice. The latter viewpoint endorses it, which then means we all 
> have to accommodate that behavior.
>
>
>
> However, those who assume that a packet is bad simply because it uses 
> one of these source ports is ITSELF incorrect. Just because it works 
> when you’re under this attack, doesn’t mean it is safe to do when 
> you’re not.
>

---

From: "Black, David" <[email-masked]>
Date: Thu, 22 Jul 2021 18:10:25 +0000

Dell Customer Communication - Confidential

Hi Gorry,

Thanks, --David

From: Gorry Fairhurst <[email-masked]>
Sent: Thursday, July 22, 2021 11:46 AM
To: Black, David; Joseph Touch
Cc: Mark Nottingham; [email-masked]
Subject: Re: [tsvwg] UDP source ports for HTTP/3 and QUIC

[EXTERNAL EMAIL]

I'm still misisng some context about the use case why a QUIC client would wishes to use a source port outside the ephmeral range.

Although it was always possible to use all ports as source port, that use does not come without pain. And QUIC multiplexes data, so  what's the use case for using the lower-numbered source ports?

Gorry

  1.  "... agree with documenting the problem as a problem, but not as a practice." &
  2.  " ... no problem making a list of ports that people ... attribute to attacks."

Thanks, --David

From: Joseph Touch <[email-masked]><mailto:[email-masked]>
Sent: Thursday, July 22, 2021 12:57 AM
To: Black, David
Cc: Holland, Jake; Mark Nottingham; [email-masked]<mailto:[email-masked]>
Subject: Re: [tsvwg] UDP source ports for HTTP/3 and QUIC

[EXTERNAL EMAIL]
Hi, David,

There's a hazard with this viewpoint, IMO.

It's like observing people driving on flat tires and thinking the road is bumpy.

There are two solutions:

There's no precedence for that decision and no registry where
those values would be indicated.

However, those who assume that a packet is bad simply because it uses one of these source ports is ITSELF incorrect. Just because it works when you're under this attack, doesn't mean it is safe to do when you're not.

Let's please not endorse incorrect conclusions that source port has this sort of meaning.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 22 Jul 2021 22:14:34 +0100

On 22/07/2021 19:10, Black, David wrote:
> Quoting from the original message that Mark forwarded 
> (https://mailarchive.ietf.org/arch/msg/tsvwg/7Fbxa5NryyUzJSWesNFbAx6hs3U/ 
> <https://mailarchive.ietf.org/arch/msg/tsvwg/7Fbxa5NryyUzJSWesNFbAx6hs3U/> 
> - scroll down past Mark's initial remarks to TSVWG):
>
> > If a client chooses source ports from the ephemeral port range, this 
> shouldn't be an issue. However, some implementations (or deployments) 
> extend the source port range "downwards" to avoid exhaustion:
>
> Thanks, --David
>
I haven't quite yet understood this use case, I suspect I must have 
missed something:

Am I understanding this about a client choosing source ports, and this 
client runs out of ephemeral ports (at least within the time it can 
reuse closed ports). I can see that servers can have lots of clients, 
but what is the use-case for a QUIC client to have that many open UDP 
ports?

Gorry

> *From:* Gorry Fairhurst <[email-masked]>
> *Sent:* Thursday, July 22, 2021 11:46 AM
> *To:* Black, David; Joseph Touch
> *Cc:* Mark Nottingham; [email-masked]
> Althoughit was always possible to use all ports as source port, that 
> use does not come without pain. And QUIC multiplexes data, so  what's 
> the use case for using the lower-numbered source ports?
>
> Gorry
>
>      1. "… agree with documenting the problem as a problem, but not as
>         a practice." &
>      2. " … no problem making a list of ports that people ...
>         attribute to attacks."
>
>     Someone ought to "Send Draft!" (credit to Randy Bush) that
>     contains an explanation of the problem, text to create the new
>     IANA registry that lists the ports plus some discussion of what
>     can usefully be done.  That draft's text on implications and
>     recommendations (what can usefully be done) can then be discussed
>     in detail to get to precise text that is acceptable to all (e.g.,
>     what to do about the view that attribution to attacks in the
>     second bullet may be mistaken).
>
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>
>         On Jul 20, 2021, at 12:02 PM, Black, David
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Explaining as an individual, not WG chair ... TL;DR - +1 on
>         Jake's comments, his understanding matches mine.
>
>     practice. The latter viewpoint endorses it, which then means we
>     all have to accommodate that behavior.
>
>
>
>     However, those who assume that a packet is bad simply because it
>     uses one of these source ports is ITSELF incorrect. Just because
>     it works when you’re under this attack, doesn’t mean it is safe to
>     do when you’re not.
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 23 Jul 2021 09:21:06 +1000

Hi Gorry,

> On 23 Jul 2021, at 7:14 am, Gorry Fairhurst <[email-masked]> wrote:
> 
> Am I understanding this about a client choosing source ports, and this client runs out of ephemeral ports (at least within the time it can reuse closed ports). I can see that servers can have lots of clients, but what is the use-case for a QUIC client to have that many open UDP ports? 

Please see my original mail in its entirety. There are two scenarios of note:

1) A client implementation asks the OS for a port and uses whatever it's given. Because of the port allocation practices of some implementations, the chosen port can be one of those we're talking about (although that's mostly for those > 1024). While AFAIK some implementations will try to allocate an ephemeral port number first (in the IETF definition), some will not, AIUI.

2) A client is behind a NAT/CGNAT that chooses a different source port, again within one of these ranges.

Cheers,

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 23 Jul 2021 03:01:34 +0100

> 2) A client is behind a NAT/CGNAT that chooses a different source port, again within one of these ranges.

Thanks Mark

- sorry for making you say this again, I was thrown by the context of QUIC.

So, probably for (2) I think RFC4787 (BCP: 127), Section 4.2.is the 
relevant reference, and that current NATs have different policies, .....

I think I now understand the use-case.

Gorry

---

From: Joseph Touch <[email-masked]>
Date: Thu, 22 Jul 2021 20:26:18 -0700

> On Jul 22, 2021, at 8:05 AM, Black, David <[email-masked]> wrote:
> 
> Hi Joe,
>  
> "… agree with documenting the problem as a problem, but not as a practice." &
> " … no problem making a list of ports that people ... attribute to attacks."

This is the core Issue though. So we have a problem where people generate spoofed traffic.

And some patterns of that traffic can be identified by how they use source ports.

So we document that this happens. That’s fine.

But then we make a list of the ports that have been abused this way. That step is problematic. It serves to endorse what is, in essence, squatting. Even though source ports are not assigned, it says “hey, they now own these”.

I know that’s not what you will say, but that’s what will happen.

And that, in essence, is what I object to.

I would welcome some sort of suggestions of what could be done that doesn’t end this way, but can’t imagine one.

Joe

---

From: "Black, David" <[email-masked]>
Date: Fri, 23 Jul 2021 16:05:30 +0000

> And some patterns of that traffic can be identified by how they use source ports.

In the cases of interest for this discussion, the source ports are real not spoofed.

> But then we make a list of the ports that have been abused this way. That step is problematic. It serves to endorse what is, in essence, squatting. Even though source ports are not assigned, it say…

Nope, that's not what's going on, please go back and reread Mark's original message which contains examples of services that can cause this problem with non-squatting use of registered ports (https://mailarchive.ietf.org/arch/msg/tsvwg/7Fbxa5NryyUzJSWesNFbAx6hs3U/).

To belabor an example that needs to be understood – NTP servers can be used in DDoS amplification attacks where it is the responses from the NTP servers that use the *IANA-registered port 123 (for NTP) as a source port, consistent with  the purpose for which it is registered* that DDoS the victim because the NTP requests from the attacker *spoofed the victim's IP address, not the port*.

There is no port squatting involved in the examples that Mark used.
> I would welcome some sort of suggestions of what could be done that doesn’t end this way, but can’t imagine one.

Writing an RFC to create the IANA registry forces this issue (whether or not the registry includes ports that are being squatted upon) to be resolved before any list gets any official imprimatur, as the rules/procedures for populating and maintain an IANA registry have to be approved in the RFC before IANA will do anything.

Thanks, --David

From: Joseph Touch <[email-masked]>
Sent: Thursday, July 22, 2021 11:26 PM
To: Black, David
Cc: Mark Nottingham; [email-masked]
Subject: Re: [tsvwg] UDP source ports for HTTP/3 and QUIC

[EXTERNAL EMAIL]

On Jul 22, 2021, at 8:05 AM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:

Hi Joe,

Joe

---

From: Joseph Touch <[email-masked]>
Date: Sat, 24 Jul 2021 10:58:03 -0700

Hi, David,

> On Jul 23, 2021, at 9:05 AM, Black, David <[email-masked]> wrote:
> 

Correct me if I’m not tracking:

A- some people send spoofed packets as attacks
B- the packets have one thing in common - use of particular source ports
C- so others have started to filter based on those source ports
D- which means legitimate uses of those ports are now blocked

Assuming that tracks:

(C) has made the leap that “correlation” becomes “cause”, so now it’s not just being under attack, but merely looking at the port that is considered an attack to be blocked

This is no different than the RST attacks on TCP, as follows:

A- some people sent spoofed RSTs all over the sequence space as attacks
B- the packets have one thing in common - being RSTs
C- so there was a proposal to block RSTs not at a single correct location in the receive window
D- which means legitimate transmissions of RSTs are now blocked (and that everyone had to change their TCP, making it more complex).

This is a common IETF fallacy:

A. Some people do X
B. There is a correlation between X and Y (not cause and effect)
C. Others interpret X as bad, leaping from correlation to cause and effect
D. We all have to deal with it (complexity)

We need to stop this at step C and declare THAT the problem.

Joe

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 25 Jul 2021 12:29:27 +1000

> On 25 Jul 2021, at 3:58 am, Joseph Touch <[email-masked]> wrote:
> 
> Hi, David,
> 

No, it's more like

A - some people identify services that allow reflection attacks (often, with a significant amplification factor)
B - those services often use specific source ports

> We need to stop this at step C and declare THAT the problem.

That may be the problem from your perspective, but from the perspective of people operating services on the Internet, it definitely isn't. 

And there is already a precedent of a sort for that view in BCP38:

"""
   Similar attacks have been attempted using UDP and ICMP flooding.
   The former attack (UDP flooding) uses forged packets to try and
   connect the chargen UDP service to the echo UDP service at another
   site.  Systems administrators should NEVER allow UDP packets destined
   for system diagnostic ports from outside of their administrative
   domain to reach their systems.
"""

It may be helpful to get some security and ops area input on this discussion, since it touches both of them pretty directly.

Cheers,

---

From: Joseph Touch <[email-masked]>
Date: Sat, 24 Jul 2021 21:06:56 -0700

Hi, Mark,

> On Jul 24, 2021, at 7:29 PM, Mark Nottingham <[email-masked]> wrote:
> 
> 
> 

Your descriptions are consistent with mine; I’m OK with yours.

It’s the next two that are the issue...

>> D- which means legitimate uses of those ports are now blocked.

>> ..

People care that their traffic is incorrectly being treated as an attack.

Sure, they’ll accept anything the can do to avoid the issue. However, that may not be good for the Internet as it evolves.

>   for system diagnostic ports from outside of their administrativeer 

Agreed; but “designed for” are destination, not source ports. Destination ports indicate both service and socket pair, but source ports are ONLY an indicator of demux. 

We have never registered source ports for a reason - they don’t indicate service. The current error of assuming other meaning to those ports (i.e., that 0 means an attack) is just as bad an idea.

Joe