Subject: [Ntp] Details of the fragmentation attacks against NTP and port randomization

From: Watson Ladd <[email-masked]>
Date: Mon, 3 Jun 2019 11:24:25 -0700

Dear all,

The debate over client port randomization is missing an important
fact: off-path attacks against NTP are not prevented by the origin
timestamp due to the OS handling of fragmentation. In
http://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf we see that sending
a properly crafted IP fragment can selectively overwrite NTP packets,
thus allowing an attacker to modify received data without overwriting
the origin timestamp. I would recommend we adopt port randomization
to handle this problem.

Sincerely,
Watson Ladd

---

From: Danny Mayer <[email-masked]>
Date: Mon, 3 Jun 2019 23:09:50 -0400

> the origin timestamp. I would recommend we adopt port randomization

Actually if you read Section VI you will see that the last sentence of
that section states that they do not consider it to be a sufficient defense.

Danny

---

From: Watson Ladd <[email-masked]>
Date: Mon, 3 Jun 2019 20:16:35 -0700

> that section states that they do not consider it to be a sufficient defense.

I concur. Sadly we don't have anything better until we see NTS deployment.
>
> Danny
>
>
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 4 Jun 2019 09:39:03 +0300

> that section states that they do not consider it to be a sufficient defense.

Wasn't Your argument that the timestamp was enough to mitigate off-path
attacks?

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Danny Mayer <[email-masked]>
Date: Tue, 4 Jun 2019 22:41:16 -0400

> Wasn't Your argument that the timestamp was enough to mitigate off-path
Yes and no. The draft you wrote requires using random ports to avoid
off-path attacks. The paper demonstrates that for at least some O/S's an
off-path fragmentation attack succeeds regardless of the port number.
This is at a layer below NTP. So randomizing the ports doesn't matter
for this attack according to the paper. The proper way to deal with this
fragmentation attack is to fix the underlying O/S behavior as has
already been done for most of them. The NTP basic payload is only 48
bytes so there is no reason to allow fragmentation in the first place.

If you can't attack that way then your off-path attacker cannot guess
the origin timestamp which is a 64-bit quantity. Furthermore the
attacker doesn't know the server being used by the NTP client so the IP
address of that server will be invalid as well. The client should have
enough information to ignore the packet.

So RFC6056 doesn't really apply as a mandate. You can certainly ask to
update draft-ietf-ntp-bcp to recommend randomizing the port for outgoing
queries. In any case RFC6056 is about randomizing ports and is not
really a security document. If it were then it would have made a very
basic recommendation concerning the port: if you have received your
response and it is valid then close the port immediately and the next
time you want to make a new request open a new random port to perform
the request. That way the off-path attacker will have no way of knowing
what the new port number will be.

In the case of NTP you don't want to trust a single server, The draft
NTP BCP recommends at least 3 different servers and preferably 4 to
allow for the loss of one server. See section 3.2. If you are really
concerned about security you should arrange with your server providers
to include either a MAC at the end of the packet or use the new NTS
security mechanism to validate and secure the packets returned. If you
are concerned about attacks you should be employing firewalls anyway.
Lastly you can get yourself a GPS unit and use that to get your clock
information. For the really paranoid, get an atomic clock!

Danny

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Wed, 5 Jun 2019 10:45:14 +0800

> On Jun 5, 2019, at 10:41 AM, Danny Mayer <[email-masked]> wrote:
> 
> Furthermore the attacker doesn't know the server being used by the NTP client so the IP address of that server will be invalid as well. 

This doesn’t seem right. There are much much less NTP servers in the world than there are clients. Even an attacker wildly guessing will have a limited scope of guessing (versus “every possible IP”).

Ask

---

From: Warner Losh <[email-masked]>
Date: Tue, 4 Jun 2019 20:53:03 -0600

On Tue, Jun 4, 2019, 8:45 PM Ask Bjørn Hansen <[email-masked]> wrote:

> Furthermore the attacker doesn't know the server being used by the NTP
> client so the IP address of that server will be invalid as well.
>
>
> This doesn’t seem right. There are much much less NTP servers in the world
> than there are clients. Even an attacker wildly guessing will have a
> limited scope of guessing (versus “every possible IP”).
>

Also, the time isn't a random 64 bit number, also limiting the domain to
search, no?

Warner

---

From: Tony Finch <[email-masked]>
Date: Wed, 5 Jun 2019 12:44:07 +0100

> Also, the time isn't a random 64 bit number, also limiting the domain to

It is if you use OpenNTPD or chrony

https://chrony.tuxfamily.org/comparison.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Isle of Man: South or southwest 3 to 5. Slight, occasionally moderate.
Showers. Good, occasionally moderate.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 5 Jun 2019 07:40:13 -0700

On Tue, Jun 4, 2019 at 7:41 PM Danny Mayer <[email-masked]> wrote:
> Yes and no. The draft you wrote requires using random ports to avoid off-path attacks. The paper demonstrates that for at least some O/S's an off-path fragmentation attack succeeds regardless of the port number. This is at a layer below NTP. So randomizing the ports doesn't matter for this attack according to the paper. The proper way to deal with this fragmentation attack is to fix the underlying O/S behavior as has already been done for most of them. The NTP basic payload is only 48 bytes so there is no reason to allow fragmentation in the first place.

>From the paper: "Our measurements(Section VI-G) confirm that there are
ten of thousands of NTP servers in the wild that do this." Clearly
tens of thousands of servers are fragmenting below minimum MTU in
response to PMTUD messages.

>
> If you can't attack that way then your off-path attacker cannot guess the origin timestamp which is a 64-bit quantity. Furthermore the attacker doesn't know the server being used by the NTP client so the IP address of that server will be invalid as well. The client should have enough information to ignore the packet.
>
> So RFC6056 doesn't really apply as a mandate. You can certainly ask to update draft-ietf-ntp-bcp to recommend randomizing the port for outgoing queries. In any case RFC6056 is about randomizing ports and is not really a security document. If it were then it would have made a very basic recommendation concerning the port: if you have received your response and it is valid then close the port immediately and the next time you want to make a new request open a new random port to perform the request. That way the off-path attacker will have no way of knowing what the new port number will be.
>
> In the case of NTP you don't want to trust a single server, The draft NTP BCP recommends at least 3 different servers and preferably 4 to allow for the loss of one server. See section 3.2. If you are really concerned about security you should arrange with your server providers to include either a MAC at the end of the packet or use the new NTS security mechanism to validate and secure the packets returned. If you are concerned about attacks you should be employing firewalls anyway. Lastly you can get yourself a GPS unit and use that to get your clock information. For the really paranoid, get an atomic clock!

I find this level of opposition (it doesn't close all the barriers so
why bother) remarkable. Why not randomize the ports? Doing so would
also simplify dos protection: src=123 is a problem. I agree we should
all move to NTS.

---

From: "Majdi S. Abbas" <[email-masked]>
Date: Wed, 5 Jun 2019 12:09:52 -0400

On Wed, Jun 05, 2019 at 10:45:14AM +0800, Ask Bjørn Hansen wrote:
> This doesn’t seem right. There are much much less NTP servers in the 
> world than there are clients. Even an attacker wildly guessing will 
> have a limited scope of guessing (versus “every possible IP”).

	You're still going to have to guess the entire set of servers
the client is using, get them to accept small fragmented packets, with
an invalid of zero checksum...and do this for a minimum of 8 poll 
intervals in order to fool the discipline filters.  So you have to 
correctly predict the timing, and try to send additional fragments...
while the host is still processing the UDP frame.

	This does not appear to be anything but a very theoretical 
attack at this point -- does anyone have a proof of concept?

	Additionally: Can anyone think of a reason an implementation
should accept an additional fragment if the MF bit was not set in the
first packet?  (Particularly an overlapping fragment, when we are not
expecting any fragments at all?)

	And does that behavior exist in the wild?

	Thanks,

	--msa

---

From: Danny Mayer <[email-masked]>
Date: Wed, 5 Jun 2019 14:35:42 -0400

> response to PMTUD messages.

Yes and those O/S's clearly need to be fixed. Fix the underlying problem
and it will be fixed for more than just NTP.

> also simplify dos protection: src=123 is a problem. I agree we should

The opposition is due to the fact that randomizing the ports doesn't
solve the underlying security issue. If I'm an attacker off-path and can
get to the target system, I can just run nmap and find out all of the
open ports leaving just a few ports to check. Randomizing ports by
itself solves nothing here.

What is really needed is a draft to improve the security of unprotected
NTP servers. NTS helps but will take a long time before many servers are
using it so getting NTS rolled out should be on everyone's list.

Danny

---

From: Hal Murray <[email-masked]>
Date: Wed, 05 Jun 2019 14:57:10 -0700

[email-masked] said:
> The opposition is due to the fact that randomizing the ports doesn't solve
> the underlying security issue. If I'm an attacker off-path and can get to the
> target system, I can just run nmap and find out all of the open ports leaving
> just a few ports to check. Randomizing ports by itself solves nothing here. 

There is an important idea that isn't specified in "randomization".  When does 
the randomization happen?

Case A: When a client decides to use IP Address a.b.c.d as a server, open a 
socket.

Case B: When a client decides to send a packet to IP Address a.b.c.d, open a 
socket.  When the response arrives (or timeout) close the socket.

nmap will find Case A type systems.  It has a small chance of finding systems 
using Case B.

-- 
These are my opinions.  I hate spam.

---

From: Danny Mayer <[email-masked]>
Date: Wed, 5 Jun 2019 19:13:07 -0400

> nmap will find Case A type systems.  It has a small chance of finding systems 
Yes, if you are smart you would want case B. Thar's what I am
advocating. I think I put that in my message.

Danny

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 6 Jun 2019 09:21:55 +0200

> socket.  When the response arrives (or timeout) close the socket.

The socket should be "connected" to the server. That is, for packets
coming from different addresses the port should behave as closed
(respond with ICMP).

> nmap will find Case A type systems.  It has a small chance of finding systems 

The timeout needs to be at least few seconds. Would that be short enough
to not allow off-path attackers to find the open port if it wasn't
connected? I'm not sure if all systems have rate limits for ICMP
messages.

-- 
Miroslav Lichvar

---

From: Fernando Gont <[email-masked]>
Date: Fri, 7 Jun 2019 13:53:22 +0300

On 5/6/19 05:41, Danny Mayer wrote:
> off-path attacks.

No.

The draft we wrote says employing predictable identifiers is a bad
practice that has been known for over 20 years. We have been on this
road so many times. You just don't use predictable IDs.

Using them leads to trouble, with no benefit. Using random port numbers
helps mitigate such trouble.

> The paper demonstrates that for at least some O/S's an

The IPv4 minimum MTU is 68 bytes. Anything longer than that may need to
be fragmented.

> address of that server will be invalid as well. 

In many-many cases, the possible NTP servers are known. We have been
dicussiing this sort of thing *for ages* in the transport area. See e.g.
RFC5927

> So RFC6056 doesn't really apply as a mandate.

It's a BCP from the *transport area* about how to employ ephemeral port
numbers. I can't see what's the rationale to ignore such advice.

> You can certainly ask to
> queries.

Yes. That's what our draft does.

> In any case RFC6056 is about randomizing ports and is not

The document provides advice for all transport protocols. What you
describe only applies for connection-less protocols, where the app-layer
only does occasional packets exchanges.

> allow for the loss of one server.

You keep mixing things up.

There's a lot of things you may want to do (and probably should!) at the
app layer. This document is concerned with what you do at the *transport
layer*. Any good practices at the app layer don't rule out good
practices at the transport layer.

You keep arguing that you want to keep a very bad practice, because
somehow you are doing something else that you thing will relieve you
from the possible pain of the bad practice.

Our draft argues: bad practices are bad practices. Do the right thing.

>  See section 3.2. If you are really

I guess with the same line of reasoning you could argue that if you're
really concerned about security, you wouldn't keep the servers connected
to the Internet?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 7 Jun 2019 13:56:34 +0300

On 5/6/19 05:45, Ask Bjørn Hansen wrote:
> 
> 
>> On Jun 5, 2019, at 10:41 AM, Danny Mayer <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
> world than there are clients. Even an attacker wildly guessing will have
> a limited scope of guessing (versus “every possible IP”).

Indeed, this is plain wrong. e.g. see the analysis in RFC5927 and RFC4953.

Not only we seem to be ignoring the advice in this area (RFC6056), but
we also seem to be ignoring 5+ years of work on the transport area on
these topics.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 7 Jun 2019 14:01:23 +0300

>> On 6/3/19 2:24 PM, Watson Ladd wrote:
[....]
> also simplify dos protection: src=123 is a problem. I agree we should

I find remarkable, too. I found the same sort of opposition ("I don't
want to fix my implementation) when we solved:

* TCP ISN: RFC6528
* IPv6 Frag IDs: RFC7739
* Transport ports: RFC6056
* IPv6 IIDs: RFC7217/RFC8064

It's simple: Do *not* use predictable IDs.

Thanks,

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 7 Jun 2019 12:50:50 +0000

>    It's simple: Do *not* use predictable IDs.
  
+1

---

From: Danny Mayer <[email-masked]>
Date: Mon, 10 Jun 2019 19:25:44 -0400

> Indeed, this is plain wrong. e.g. see the analysis in RFC5927 and RFC4953.
Actually he is right. Not all NTP clients are also servers. It has
nothing to do with whether or not to randomize the source port.

Danny

---

From: Watson Ladd <[email-masked]>
Date: Mon, 10 Jun 2019 18:24:53 -0700

> nothing to do with whether or not to randomize the source port.

Who is right about what? I am confused and I dont think I'm the only one.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Jun 2019 04:44:06 +0300

> nothing to do with whether or not to randomize the source port.

If you know the target client, you know its IP address.
You may guess address of the NTP server -- for many systems, they employ
one of the addresses they get from a domain name.
And if the implementation uses 123 for both the src and dst port, you do
not need to guess the port.

This is a similar analysis to what we did over 10 years ago in RFC5927
and RFC4953.

Thanks,

---

From: Danny Mayer <[email-masked]>
Date: Tue, 11 Jun 2019 18:33:55 -0400

>> Yes and no. The draft you wrote requires using random ports to avoid
Actually that's exactly what it says. See the abstract of your own draft.
> road so many times. You just don't use predictable IDs.
You do this of off-path attackers.
> helps mitigate such trouble.
No always which why your RFC is a BCP. What needs to be clarified is
when it is wise to do so and when not to do so and what are the
consequences if you do so. You cannot make proposals without including them.
> The IPv4 minimum MTU is 68 bytes. Anything longer than that may need to
Yes, and when you add the UDP envelope and the IP envelope to the NTP
Payload you have 78 bytes (if I did the addition correctly). If there
were way to avoid fragmentation I'd recommend doing so particularly for
NTP packets as they are time-sensitive, separate from this fragmentation
attack. A fragmented, reassembled NTP packet is likely to be thrown out
anyway since it is likely to be outside the limits of the error budget,
jitter, and other acceptability requirements.
> numbers. I can't see what's the rationale to ignore such advice.
It's advice and you need to examine consequences in both directions
before you recommend this.
> Yes. That's what our draft does.
No, it actually obsoletes RFC5905! You should be updating the NTP BCP
since you seemed to have missed the draft review.
> only does occasional packets exchanges.
And falls short of proper advise on what to do when the port is not in
use. NTP *is* a connectionless protocol and that's what this WG is
dealing with.
> practices at the transport layer.
Yes, but you need to consider the consequences of what you do at each
layer, you cannot do this in a vacuum. You seem to ignore the whole in
preference of the detail. It's the whole you need to deal with.
> from the possible pain of the bad practice.
Not at all. If the circumstances are right then you should do it.
> Our draft argues: bad practices are bad practices. Do the right thing.
Reminds me of Theresa May's statement: "Brexit means Brexit" which
really means nothing at all. Doing the right thing involves more than
just saying that.
> really concerned about security, you wouldn't keep the servers connected

No I'm saying use proper security where possible or close the port when
not using it and open it on a new port when you need it again. *That* is
good practice yet nowhere in RFC6056 does it say that.

Danny

---

From: Warner Losh <[email-masked]>
Date: Tue, 11 Jun 2019 20:26:29 -0600

Can we please keep it technical rather than launch into personal attacks?
You can make your points without the vitriol and nastiness.

Warner

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Jun 2019 16:35:38 +0300

Hello, Danny,

> Actually that's exactly what it says. See the abstract of your own draft.

It's a mitigation. It is not meant to be *the only* mitigation.

> You do this of off-path attackers.

?

> consequences if you do so. You cannot make proposals without including them.

Could you please tell me the advantages of using the flawed scheme (src
port=123)?

> attack. 

That's layer 3, where port randomization is layer 4. I'm fine with any
smarts you want to do at any other layers... but that's exactly the
point: what you do at other layers has nothing to do with port
randomization, which happens at layer-4.

> before you recommend this.

Indeed, and hopefully the next rev will expand on this.

May I ask, once again:
* What are the befenits of src=123?

* If you assume there are bad implications of port randomization, which
would be a show stopper for this I-D, why aren't we already suffering
from that trouble in all the scenarios where we have multiple NTP
clients operating behind a NAT?

> since you seemed to have missed the draft review.

There is an error in the I-D, indeed: it should say "Updates", rather
than "Obsoletes". We will fix this.

RFC5905 talks about port number selection. SO it's RFC5905 that should
be updated.

> use. 

It talks about port number *selection*, not *usage*. FOr obvious reasons
it also doesn't answer questions such as "Should my app protocol reuse
the same connection, or use different connections to exchange objects?".
It also doesn't comment on "should i use a 'connected' UDP socket or not?"

> NTP *is* a connectionless protocol and that's what this WG is
> dealing with.

The RFC6056 talks about ephemeral port selection, irrespective of
whether the transport protocol is conenctionless or connection oriented.

> preference of the detail. It's the whole you need to deal with.

The transport area considered that "whole" when it issued its BCP. If
you want to go against such BCP, please provide arguments in that direction.

I'd expect that in the context of the normal scenario of multiple NTP
clients behind NAT devices, you might have a hard time. But please give
it a try.

> Not at all. If the circumstances are right then you should do it.

PLease go and tell the transport area. And while you do it, please
answer the question I asked before, namely:
What are the problems you expect with port randomization, and if they
are such big problems, how you are dealing with them in networks such as
IPv4-based where NATs are already part of the architecture.

> good practice yet nowhere in RFC6056 does it say that.

Because it talks about port number selection, not usage.

Want a similar example: IPv6 address configuration and IID
generation/selection vs IPv6 address usage policies. You are mixing up
two orthogonal things.

Thanks,

---

From: [email-masked]
Date: Thu, 13 Jun 2019 17:06:18 +0200

Hello all,

so far, I have remained largely silent on this thread, mostly because I 
felt I knew too little about the implications of port selection and usage.
But the more of this discussion I witness, the more Fernando's points make 
sense to me on a purely logical, abstract level and I suspect that large 
parts of the discussion have involved mix-ups regarding where the 
burden-of-proof actually lies.

We've established a few things that are (I believe) non-controversial:
1) Always randomizing ports is the default decision, as per a BCP document
2) The default decision as per a BCP document is not mandatory and its 
benefits should be weighed against potential costs/disadvantages
3) Randomizing ports does not immediately solve all possible security 
issues (on all network layers) involving NTP

As I see it, 1) puts the burden-of-proof on anyone arguing not to opt for 
mandating port randomization.
Accepting that, 2) gives a prescription of what such a proof might look 
like: prove that the costs outweigh the benefits.
I guess 3) becomes somewhat relevant here, but logically, "is not a 
perfect solution" basically tells us nothing.
>From my point of view, the combination of 1) - 3) just says: mandate port 
randomization except in cases where there is proof (!) of significant cost 
outweighing its benefits.

Which brings us to the final discussion point, which seems (much) more 
controversial:
4) Randomizing ports might or might not in some cases have significant 
disadvantages

Basically, I think the way forward is pretty clear-cut:
We want a list of concrete scenarios/use cases that pertain to 4) where 
the suspicion is that the costs of randomizing ports outweigh its benefits 
and mandate/recommend port randomization in all other scenarios.
The decision process for each individual scenario that *does* appear on 
said list is complex: come up with actual metrics to quantify both the 
costs and the benefits (avoiding oversimplification specifically by either 
using 4) without proof or fallaciosly mistaking 3) for a showstopper.), 
then do the following.
If the benefits predominate, mandate/recommend port randomization. If the 
costs predominate, formulate a clear rationale for why they do and include 
that in whatever document the proposal eventually affects. If in doubt, 
mandate/recommend port randomization - because 1).
(Just to be clear: from my point of view, there is currently no proof that 
this list is even non-empty.)

Best regards,
Kristof

Von:    "Fernando Gont" <[email-masked]>
An:     "Danny Mayer" <[email-masked]>, [email-masked]
Datum:  13.06.2019 15:36
Betreff:        Re: [Ntp] Details of the fragmentation attacks against NTP 
and port randomization
Gesendet von:   "ntp" <[email-masked]>

Hello, Danny,

?

May I ask, once again:

The transport area considered that "whole" when it issued its BCP. If
you want to go against such BCP, please provide arguments in that 
direction.

Thanks,

---

From: "Gary E. Miller" <[email-masked]>
Date: Thu, 13 Jun 2019 10:00:06 -0700

Yo [email-masked]!

On Thu, 13 Jun 2019 17:06:18 +0200
[email-masked] wrote:

> As I see it, 1) puts the burden-of-proof on anyone arguing not to opt
> for mandating port randomization.

One nit.  As discussed here previously.  Randomizing the NTP port on
each server request degrades the quality of the time received.

Keeping the same random port, per server, for a while, works OK.

> 4) Randomizing ports might or might not in some cases have
> significant disadvantages

See above.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	[email-masked]  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Jun 2019 22:14:12 +0300

On 13/6/19 20:00, Gary E. Miller wrote:
> each server request degrades the quality of the time received.>

*May* degrade. (*) That said, the last revision we posted argued to
randomize the port on a per-association basis

We are considering analyzing the trade-offs, and the document might
eventually argue one way or another. However, the version that has been
discussed so far doesn't suffer from this.

(*) For scenarios where there's no hash-based ECMP, this is not the
case, anyway. And Miroslav has also noted that changing the port number
*intentionally* might actually be of help.

Thanks,

---

From: "Gary E. Miller" <[email-masked]>
Date: Thu, 13 Jun 2019 12:29:29 -0700

Yo Fernando!

On Thu, 13 Jun 2019 22:14:12 +0300
Fernando Gont <[email-masked]> wrote:

> >> As I see it, 1) puts the burden-of-proof on anyone arguing not to
> >> opt for mandating port randomization.  
> > 

PROVEN to degrade.  With a few known mechanisms for that understood.
Many more suspected but as yet undocumented.

> eventually argue one way or another. However, the version that has
> been discussed so far doesn't suffer from this.

But your summary did not mention it.  Just want to make sure the data
point is not lost.

RGDS
GARY

---

From: Fernando Gont <[email-masked]>
Date: Fri, 14 Jun 2019 14:07:29 +0300

Hello, Gary,

> Many more suspected but as yet undocumented.

What I'm saying it: the port number may affect the path in scenarios
where forwarding is somewhat based on the port number. Unless you assume
that every router forwards packets with a hash-based algorithm that
includes the port, then randomization *may* affect the path.

That said, at least in the IPv4 world, you have to learned to live with
this, since the pervasive of NATs means that it may be impossible to
enforce src=PORT (whatever port is), unless e.g. you send requests every
t<30 secs which is a usual NAT timeout for and UDP "flow".

> But your summary did not mention it.

Indeed the last rev didn't mentioned. In all fairness, I think it was
you that raised this (and we already starting working on this on our
working copy) -- those who objected to port randomization didn't raise
this, and even less considered per-association vs per-request
randomization in the objections they voiced.

> Just want to make sure the data point is not lost.

Point taken (and thanks for that!). The next revision will indeed
elaborate on this. We might need a couple of revs for everyone to be
happy -- but well... it's a draft, not an RFC ;-), so we do expect that
the draft evolves and improves overtime.

Based on the discussion above, there should certainly be a section about
whether to randomize on a per-association or a per-request basis. And I
wouldn't mind myself for the default to be "on a per-association basis"
(which an implementation could override "if they know better").

Thanks!

Cheers,

---

From: "Gary E. Miller" <[email-masked]>
Date: Fri, 14 Jun 2019 11:25:22 -0700

Yo Fernando!

On Fri, 14 Jun 2019 14:07:29 +0300
Fernando Gont <[email-masked]> wrote:

> where forwarding is somewhat based on the port number.

Yes.  That is one of a great many scenarios where randomizing the port
per connection degrades the time qulity of the connection.

> Unless you
> assume that every router forwards packets with a hash-based algorithm
> that includes the port, then randomization *may* affect the path.

So you propose one, of many, ways the random port per connection is
bad.  Then sweep all the others under the rug because they are not that
one?  Sloppy thinking.

> That said, at least in the IPv4 world, you have to learned to live
> with this, since the pervasive of NATs means that it may be
> impossible to enforce src=PORT (whatever port is), unless e.g. you
> send requests every t<30 secs which is a usual NAT timeout for and
> UDP "flow".

Yup.  The point of this discussion is finding the best of all the
imperfect options.

> randomization in the objections they voiced.

I read the room differently.  No need to pile on when the data is
obvious.  Save the discussion for the differences.

RGDS
GARY