Reviewer: Gorry Fairhurst Review result: On the Right Track Hi, I submitted some comments on draft-ietf-tram-stun-pmtud-10 after the end of Last Call, and this email replaces my personal comments with more detailed feedback, and a more list of comments. These comments are provided as a part of the TSV Area Review Team, paying special attention to transport-related concerns. Please take these as any other IETF last call comments. Summary: This draft says that it specifies Session Traversal Utilities for NAT (STUN) Usage for Path MTU Discovery (PMTUD). The document is one of a group of documents that seek to update PMTU discovery across the Transport and Internet areas. The document describes methods specific to the use with STUN and how this performs MTU reduction. The document is on the right track, but care needs to be taken to ensure that the language and description are consistent other current IETF work, and to improve the description. I think the present document therefore needs some significant editorial work before it clearly expresses the specification and is then ready for publication. I also concerned two methods are suggested, but no rationale appears to be provided about why the WG was unable to converge on a single method for standardisation. Why would an implementor choose to use the simple method? Title I am not sure the pesent title is correct. While the document does define "Discovery of a PMTU using Session Traversal Utilities for NAT (STUN)", I do not think it describes "PMTUD using STUN". I say this, because I see a differentiation between PLPMTUD at the transport and PMTUD at the network. Abstract The current abstract is also rather short on detail, and from this I was not really sure about what the specification. Please consider providing a clear description of why the protocol is useful to the Internet and hence why someone should read this. Introduction I disagree with the following statement, and think the editors need to consider restating this (see below): / The Packetization Layer Path MTU Discovery (PMTUD) specification [RFC4821] describes a method to discover the Path MTU but does not describe a practical protocol to do so with UDP./ - PMTUD is an IP-layer function described in an Internet Area spec, you probably should cite these specs in your introduction (e.g., [RFC1191] and [RFC8201]). The abbreviation for the specified method is PLPMTUD (see http://tools.ietf.org/html/rfc4821). The definition of PLPMTUD for datagram protocols (for which this is one example) is a current work item in TSVWG, and the WG draft on this (draft-ietf-tsvwg-datagram-plpmtud). This ID does not detract from the value of the current spec, but it does supply some of the background to why STUN needs to add a feature to help discover the path MTU. Please consider explaining this and citing draft-ietf-tsvwg-datagram-plpmtud. The second para of the introduction states: / Many UDP-based protocols do not implement the Path MTU discovery mechanism described in [RFC4821]. / I disagree. I do not know of details in RFC4821 that specify a protocol for UDP. In fact, there is no simple way to add PLPMTUD to UDP applications without integrating this with the protocol using UDP. I suggest this needs to be rephrased, because the current text expresses this imprecisely. I think on a related note: draft-ietf-tsvwg-datagram-plpmtud will need to be revised to mention this document. When the current specification is implemented, it does present a standards track protocol that can be used with UDP - there is no reason why an ICMP packet could not be used to set the IP size for fragmenting UDP or any other transport (as in PMTUD), however there are cases where this will not be possible. Please also note that an update to PMTUD was published as RFC 8201 "IPv6 Path MTU Discovery", in July 2017. This also has hints at the problems and challenges of doing PMTUD at the network level. The following statement suggest to me that the specification could be informational or experimental, since the use of the methods proposed is entirely at the discretion of the reader, I'm not really sure what is intended, because there are multiple possibilities suggested in the document: / These protocols can make use of the probing mechanisms described in this document instead of designing their own adhoc extension. / - Now the WG has evaluated the proposal, it would be wide to be clear about the intended status. Please clarify what is intended by: / These probing mechanisms are implemented with Session Traversal Utilities for NAT (STUN), but their usage is not limited to STUN-based protocols./ - I am concerned that this is very open. Perhaps it overlaps with the work done in TSVWG and to me this spec really needs to be much clearer about the applicability it is defining. This sentence needs more clear text: / permits proper operations of UDP-based applications in the network. / - This comment is similar to the above: I'd prefer to see an explanation of what this draft solves, not a general statement that it allows things to be correct. There are references to non-adopted IDs in the introduction. What is the intention of the WG here: [I-D.martinsen-tram-stuntrace] and [I-D.martinsen-tram-turnbandwidthprobe] - it seems weird to endorse these in a standards track document, even if informative. Are these references strictly needed? (If not I suggest removing these references, or instead choosing to cite an adopted item). Specification I have a protocol question. Section 2 states: / which increase in size until transactions timeout, indicating that the Path MTU has been exceeded./ - My first question is where does the reader look to understand the recommendations for the STUN timeout? - I do not see text about the robustness of the method. I therefor also wonder if the working group has thought about whether this is robust to reordering and loss - and how the method would be impacted by reordering of probes (e.g. by alternate paths) and what the impact of loss is on the protocol operation. - I expected some text explaining why the probe packets do not contribute to congestion. This may be taken from other RFCs, but the method clearly sends packets additional to the network traffic that is sent by the transport and this needs to be considered. The UDP Usage Guidelines [RFC8085] may provide some help in describing the impact on congestion. Some RFCs choose to include this text as a part of their security considerations. I'd expect to see more information about what the following text means: /It then uses that information to update the Path MTU. / - Does that mean the updated value is then used by the sender. So does the sender drop packets larger? does it endpoint fragment these as the sender? - Does this mean the host cache in the end system is changed downwards when there is a detected lower PMTU. Is there an API used for this, because this seems to me to raise questions about how to deal with entries for paths - and possible aggregation of information from the same endpoint or not? PLPMTUD has various ways it can be used, and this is not clear in the present text - specifically is this more than black-hole detection or is this the only service? Specifically ... - in other words, does the method increase the PMTU that has been used, or does it simply provide black hole detection? - Does the sender transmit UDP segments larger than the PMTU in the host cache? How is the following done: / A client MUST NOT send a probe if it does not have knowledge that the server supports this specification./ - The above text seems to need more text to verify this is on-path, as per RFC 8201, which points to the need to validate that PTB messages originate on-path which is a specific transport issue. The UDP Usage Guidelines [RFC8085] also provides guidance on what needs to be considered. / If an ICMP packet "Fragmentation needed" is received then this is interpreted as a Probe Failure, as defined in [RFC4821] Section 7.6.2. / - Section 4.2.2 is IPv4 centric, also note the additional requirements in RFC 8201 for processing ICMPv6 PTB messages. / A client MUST NOT send a probe if it does not have knowledge that the server supports this specification. / - However the text in section 5.1 seems very vague about how this is configured. If the document is a PS, then I would have hoped for clearer guidance on signalling or pointers to the specific document sections where this is defined. Section 4.2.6 - I don't understand STUN in detail and this may be answered by referencing other RFCs ..., but I'd like to ask whether the initial value of the sequence number (Sequence number field) need to be randomised, to mitigate opportunities for off-path attack, as in RFC8085, if not please explain why. Section 5.1 describes the methods needed to protect from amplification attack, but does not require any methods. It does not include references to where these methods are specified. Section 5.2 would benefit from a reference to the method for authentication. IANA - The cited registry does not exist. Is this: https://www.iana.org/assignments/stun-parameters/stun-parameters.txt? - It would be helpful for IANA to indicate which pool of method numbers need to be used for "probe" and "response". Security Considerations Finally, I am unsure whether this really does not introduce any specific security considerations beyond those described in [RFC4821]. How does the choice of authentication (optional) impact the security properties of the method? At least, draft-ietf-tsvwg-datagram-plpmtud has a growing list of concerns, I'd like to know if these also apply to this ID? --- Please wait for direction from your document shepherd or AD before posting a new version of the draft. Gorry Fairhurst (on behalf of TSV-ART)
