Re: [Ntp] Benjamin Kaduk's Yes on draft-ietf-ntp-port-randomization-06: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Fernando!

On Wed, Jun 02, 2021 at 03:40:03AM -0300, Fernando Gont wrote:
> Hi, Ben,
> 
> Thanks a lot for your feedback!  In-line....
> 
> On 1/6/21 21:24, Benjamin Kaduk via Datatracker wrote:
> [....]
> > There's a few places where we say things like "the choice of whether to
> > randomize the ephemeral port number on a per-request or a
> > per-association basis is left to the implementation, and should consider
> > the possible effects on path selection along with its possible impact on
> > time measurement."  But the main specific consideration that we mention
> > is that in ECMP and similar situations, randomizing per-request can
> > cause problems; in particular, I don't remember seeing anything that
> > would be an argument in favor of randomizing on a per-request basis.  So
> > the current guidance (entirely up to the implementation) doesn't seem to
> > match up very well with what we say about the two choices.  I think I'm
> > missing (in the text, that is) some aspect about how randomizing the
> > port on a per-request basis provides more robust defence against
> > off-path attacks than only randomizing per-association.
> 
> How about:
> 
> Randomizing the ephemeral port number on a per-request basis will better 
> mitigate off-path/blind attacks, particularly if the socket/port is 
> closed after each request/response exchange, as recommended above. The 
> choice of whether to randomize the ephemeral port number on a 
> per-request or a per-association basis is left to the implementation, 
> and should consider the possible effects on path selection along with 
> its possible impact on time measurement.
> ?

Thanks, that puts some picture of both the "pro" and "con" sides into the
reader's mind.

> 
> > 
> > Section 3.3
> > 
> >     inspecting the source and destination port numbers.  Implementation
> >     of port randomization for non-symmetrical modes allows for simple
> >     differentiation of NTP requests and responses, and for the
> >     enforcement of security policies that may be valuable for the
> >     mitigation of DDoS attacks, when all NTP clients in a given network
> >     employ port randomization.
> > 
> > I guess the details of what those security policies might look like are
> > properly out of scope for this document ... but the potential
> > consequences of such policies on clients that don't employ port
> > randomization might be in scope for us.
> 
> The issue here is that it won be possible to easily tell request and 
> responses. SO if you meant to filter requests, then youĺl have to filter 
> both requests and responses, or nothing at all.

Makes sense.  I leave it to you as to whether it merits a mention in the
document.

The rest all looks good, and thanks for it,

Ben

> 
> 
> > Section 4
> > 
> > Just an observation (no need to change anything), but we seem to be
> > going from three lines of content in the original to 30 lines of content
> > in the new version.  If it was actually applied and viewed in context in
> > the manner of inline errata, the new text might feel a bit out of place.
> 
> FWIW, Section 4 clarifies which text from RFC5095 should be interpreted 
> differently. However, I don't think this text should be rendered with 
> inline errata, as that would miss most of the background/implications 
> that e.g. is expected to influence the decision on whether to randomize 
> on a per-request or per-association basis.
> 
> 
> 
> > NITS
> > 
> > Abstract
> > 
> >     number.  However, in the case of NTP modes where the use of a well-
> >     known port is not required, employing such well-known port
> >     unnecessarily increases the ability of attackers to perform blind/
> >     off-path attacks.  This document formally updates RFC5905,
> > 
> > "increases" has some implicit baseline, which is typically "the current
> > state prior to this document" (which is not the right baseline for this
> > case).  I'd suggest just "unnecessarily enables blind/off-path attacks",
> > or maybe a variant with "facilitates" rather than "enables".
> > (Similarly for the Introduction, twice.)
> 
> Good point!  -- I've used "facilitates"
> 
> 
> > 
> > Section 7
> > 
> >     known for a long time now.  However, the NTP specification has
> >     traditionally followed a pattern of employing common settings and
> >     code even when not strictly necessary, which at times has resulted in
> >     negative security and privacy implications (see e.g.
> > 
> > It seems unusual for the NTP *specification* to employ common *code*.
> 
> I guess "algorithm" might have been a better term -- but still the text 
> wouldn't add much. So I've just s/and code//.
> 
> 
> 
> 
> >     This issue has been tracked by US-CERT with VU#597821, and has been
> >     assigned CVE-2019-11331.
> > 
> > I failed to find anything under us-cert.gov that referenced "VU#597821"
> > or even just "597821".
> 
> Good grief! No idea what happened to it. -- So I've tweaked the text 
> such that we only keep the CVE reference:
> 
>     This issue has been assigned CVE-2019-11331 [VULN-REPORT].
> 
> where:
> 
>     [VULN-REPORT]
>                The MITRE Corporation, "CVE-2019-11331", April 2019,
>                <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-
>                2019-11331>.
> 
> Thanks!
> 
> Regards,
> -- 
> Fernando Gont
> e-mail: [e-mail] || [e-mail]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
>