| 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. 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. 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. 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:
This is a lengthy discussion, and as Mirja should have been reminding me (yes, it’s of course your fault Mirja), I am remiss in writing up a draft about this. My suggestion is that you drop the topic of TCP/UDP port numbers, except to perhaps suggest that some consideration is needed about their utility versus the risks, and that this needs to be further explored. No need to otherwise hold up this good work. When we get around to that document, we can update again RFC 3552 but also RFC 6335. IMHO we can do a lot better on improving privacy and resilience wrt discovery. Eliot
|
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
