Hello, Eliot,
Thanks a lot for your comments! In-line....
On 11/12/20 05:34, Eliot Lear wrote:
Hi Fernando and others,
This is a pretty good document, and on the whole I applaud your focus on
improving the resiliency of the overall architecture.
Thanks!
I have but one issue.
There is brief mention of TCP ports in the introduction, and a
misstatement in the bullet list referred to on the top of page 3 -
“predictable transport protocol numbers” where I think you mean
transport protocol port numbers.
Indeed! We should fix this. (thanks!)
You refer also to TCP ports in Section
3. You may well be right that there was no security consideration given
initially to these numbers (I don’t know- I wasn’t there). You may also
be right that services can be the subject of various forms of attack
based on these numbers.
However, the document doesn’t really go into enough detail to discuss
the tradeoffs that are necessary around to be helpful in the context of
this registry.
FWIW, in the context of this document, the mention of transport protocol
port numbers (or any other ntransient numeric ID, for instance) is for
illustrative purposes. The discussion of specific I-Ds is in
draft-irtf-pearg-numeric-ids-generation . And, when it comes to
transport protocol port numbers in particular, that document references
RFC6056 (which I co-authored), since it covers all the relevant details.
That is, draft-gont-numeric-ids-sec-considerations focuses on the BCP
stuff to analyze transient numeric IDs in new specs. Whereas
draft-irtf-pearg-numeric-ids-generation analyzes different categories of
transient numeric IDs, and proposes algorithms for each.
In many cases, it would be perfectly fine for clients to
make use of QUIC or HTTPS, and indeed that happens to such an extent
that we can’t easily measure it (a testament to LetsEncrypt, the TLS WG,
and QUIC, I suppose). As a port reviewer, I see two continuing
challenges for implementations:
* Service discovery and autonomic configuration. Put more simply,
plug and pray. A great many of our requests are focused on just
that, requiring a UDP port for multicast and a TCP port to get
through enterprise firewalls.
* Supervisory architectures in which more than one entity may be
responsible for a service. Not everything can run on port 443 in
these instances, and yet the tooling wants to discover those functions.
Please note that when we refer to "transport protocol port numbers",
service ports are excluded from those. (maybe it would be more clear if
we said "transport protocol ephemeral port numbers"?) (since I realize
that "transport protocol port numbers" could also be interpreted as
server-side service ports, too)
[...]
IMHO we can do a *lot* better on improving privacy and resilience wrt
discovery.
Note that we do *not* target service ports. Those ports are not
"transient numeric identifiers", because the server-side port has
overloaded semantics (it identifies the service) -- so it *has* to be a
specific value. Only if, say, a system were using something ala e.g. SRV
records, servers could use "transient numeric identifiers".
(i.e., think of this document as a bcp to have spec authors write down
what the interoperability properties that they need in the transient
numeric IDs they use, do the associated analysis, and then propose an
algorithm for them. e.g., you could say that if we were to specify e.g.
TCP/SCTP today, the spec should include something like what's in RFC6056).
Please let me know if the above clarifies the intent of the document.
Thanks!
Regards,
Fernando
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
