[tram] Tsvart telechat review of draft-ietf-tram-stun-pmtud-10

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Sat, 29 September 2018 11:58 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tram@ietf.org
Delivered-To: tram@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75065130E08; Sat, 29 Sep 2018 04:58:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
To: <tsv-art@ietf.org>
Cc: tram@ietf.org, ietf@ietf.org, draft-ietf-tram-stun-pmtud.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153822231441.18786.6724250628334789955@ietfa.amsl.com>
Date: Sat, 29 Sep 2018 04:58:34 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/Iif8Bs4WEOTJ5F1hOMhaofEz_wU>
Subject: [tram] Tsvart telechat review of draft-ietf-tram-stun-pmtud-10
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Sep 2018 11:58:34 -0000

Reviewer: Gorry Fairhurst
Review result: On the Right Track


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?


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.


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.


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

The abbreviation for the specified method is PLPMTUD (see

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

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


I have a protocol question. Section 2 states:
/ which increase in size until transactions timeout, indicating that the Path
MTU has been
- 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.


- The cited registry does not exist. Is this:

- 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

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)