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

[Fernando Gont <[e-mail]>]

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


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



> 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