Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt

[Gorry Fairhurst <[e-mail]>]

On 03/08/2020 14:39, Felipe Garrido (fegarrid) wrote:
>
> Hi Gorry,
>
> Thank you for the comments. Responses are in-line.
>
> Thanks,
>
> -Felipe
>
> *From: *tram <[e-mail]> on behalf of Gorry Fairhurst 
> <[e-mail]>
> *Date: *Tuesday, July 14, 2020 at 9:24 AM
> *To: *"[e-mail]" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *[tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt
>
> I had a look at draft-ietf-tram-stun-pmtud-17 with respect to the last 
> comments, and saw some changes and I have a few comments. These 
> comments are sent to the TRAM mailing list,
>
> Gorry
>
> ---
>
> Section 2 does not discuss the frequency of the probe. This is a 
> congestion control case, and the method needs to assert some 
> guidance/requirements on the probing. Do probe packets count against 
> cwnd when using this method?
>
> In section 4.1.
> I think this is misleading, and not a feature of the simple method:
> “   Note: Routers can be configured to clear the DF bit or ignore the DF
>    bit which can be difficult or impossible to detect if reassembly
>    occurs prior to receiving the packet, rendering PLPMTUD inaccurate.
> “
> - I wouldn’t call this inaccurate? If the path contains a link-layer 
> (or tunnel or anything) that fragments and reassembles - then the path 
> MTU is whatever size that assembly is performed to. It has always been 
> this way, if links fragment and reassemble, IP uses the reassembled size.
>
> --
> Updated the Note as follows.
>
> “   Note: Routers can be configured to clear the DF bit or ignore the DF
>    bit which can be difficult or impossible to detect if reassembly
>    occurs prior to receiving the packet.”
>
>
Sure. I'd actually suggest /might be configured/ to /can be 
configured/... I'm not sure any RFC should do this according to the spec.
>
> In section 4.2.2.  Receiving an ICMP Packet
> This ID currently recommends “ Validation SHOULD be performed on the ICMP
>    packet as specified in [RFC8085].”
> - Since this is a method above UDP, I think this implicitly also 
> checks the UDP port information, hence this recommendation actually is 
> an unavoidable consequence when using a normal stack - if you have one 
> that forwards ICMP to the socket.
>
> This becomes a requirement (or is always true) in dplpmtud:
> - “Any received PTB message MUST be validated before it is used to 
> update the PLPMTU discovery information”.
> - Should this be a requirement in this spec, to avoid off-path attack?
>
> -- 
> I agree. Updating to,
>
> “ Validation MUST be performed on the ICMP  packet as specified in 
> [RFC8085].”
>
OK, or refer to the DPLPMTUD Spec - where the details are explain?
>
>
> In section 4.2.5
> “It could have been possible to use the checksum generated in the UDP
>    checksum for this, but this value is generally not accessible to
>    applications.  Also, sometimes the checksum is not calculated or is
>    off-loaded to network hardware.“
> - I do not agree this could be used (even if the checksum was returned 
> to user space), and think it suggests something that isn’t possible. 
> The UDP checksum includes the pseudo header information, including the 
> ports. Wouldn’t this make the method very fragile in the face of NAPT?
>
> --
> Removing this paragraph in its entirety.
>
Thanks
>
> In section 5:
> I don’t yet see changes in this version to section 5.
> “The PMTUD mechanism described in this document is intended to be used
>    by any UDP-based protocols that do not have built-in PMTUD
>    capabilities, irrespective of whether those UDP-based protocols are
>    STUN-based or not.  So the manner in which a specific protocol
>    discovers that it is safe to send PMTUD probes is largely dependent
>    on the details of that specific protocol, with the exception of the
>    Implicit Mechanism described below, which applies to any protocol."
>
> - Please see comments made in the previous last call.
>
> --
> Can you be more specific on what comments were not addressed?
>
> In section 7:
>
> This has added a section that is a cross-reference of which sections 
> contain information that relates to DPLPMTUD.
>
> I see a mapping of requirements in section 7.1 to refer to the 
> described method  with STUN. This seems like a useful addition (and 
> appropriate). Currently this doesn’t really have enough detail to 
> clearly see how the two sets of text relate, one might have to read 
> both to figure out the details, and if that’s the case, maybe it 
> should be explained up front. That could be helpful.
>
> --
> agreed. Can you provide the additional text that would satisfy your 
> comment?
>
> However, this does not resolve the last call questions raised about 
> the method, and it seems to require someone to read both documents, 
> which really  isn't that easy.
>
> --
> The addition of Section 7 does require that both drafts be read. As 
> such, we’re moving I-D.ietf-tsvwg-datagram-plpmtud to a normative 
> reference.
>
>
That sounds good.


> Section 7.1.  Probe loss recovery -  I think understand that the 
> probes themselves do not need to be recovered, but the text in section 
> 7.1 does not quite say this.
> --
> Agreed. Updating to the following
> Probe loss recovery: This requirement is fulfilled by requiring that 
> the PADDING bits MUST be set to zero as discussed in Section 4.1.1 and 
> Section 4.2.1 of this document. No retransmission is required as there 
> is no user data being transmitted in the probe.
>
>
/being/is being/
>
> Section 7.1. Section 7 doesn’t describe the implications of probing on 
> flow control control. I’m not sure the current text is enough:
> - Do probe packets count as credit to an upper layer protocol using 
> this method?
>
> ---
> Can you provide additional clarification on the request?
>
DPLPMTUD contains guidance on flow control and congestion control (added 
during the WGLC),see (10) in section 3.
>
> *---*
>
I hope this helps,

Gorry

> On 06/07/2020 15:02, Magnus Westerlund wrote:
>
>     Hi,
>
>     Gorry did have feedback on this document, and they have done some attempt
>
>     to define a DPLPMTUD mapping for their mechanism. I looked at it briefly and
>
>     think it is horrible terse with just requirements to combine sections. Which
>
>     unfortunately requires one to sit and cross reference the two documents.
>
>     I would appreciate any feedback from any of you have and if there appear some
>
>     glaring  failures or problems with things they declare out of scope etc.
>
>     Privately or publicly to the TRAM mailing list ([e-mail]  <mailto:[e-mail]>).
>
>     Cheers
>
>     Magnus
>
>     On Mon, 2020-07-06 at 06:04 -0700,[e-mail]  <mailto:[e-mail]>  wrote:
>
>         A New Internet-Draft is available from the on-line Internet-Drafts
>
>         directories.
>
>         This draft is a work item of the TURN Revised and Modernized WG of the IETF.
>
>                  Title           : Packetization Layer Path MTU Discovery (PLMTUD) For
>
>         UDP Transports Using Session Traversal Utilities for NAT (STUN)
>
>                  Authors         : Marc Petit-Huguenin
>
>                                    Gonzalo Salgueiro
>
>                                    Felipe Garrido
>
>             Filename        : draft-ietf-tram-stun-pmtud-17.txt
>
>             Pages           : 23
>
>             Date            : 2020-07-06
>
>         Abstract:
>
>             The datagram exchanged between two Internet endpoints have to go
>
>             through a series of physical and virtual links that may have
>
>             different limits on the upper size of the datagram they can transmit
>
>             without fragmentation.  Because fragmentation is considered harmful,
>
>             most transports and protocols are designed with a mechanism that
>
>             permits dynamic measurement of the maximum size of a datagram.  This
>
>             mechanism is called Packetization Layer Path MTU Discovery (PLPMTUD).
>
>             But the UDP transport and some of the protocols that use UDP were
>
>             designed without that feature.  The Session Traversal Utilities for
>
>             NAT (STUN) Usage described in this document permits retrofitting an
>
>             existing UDP-based protocol with such a feature.  Similarly, a new
>
>             UDP-based protocol could simply reuse the mechanism described in this
>
>             document.
>
>         The IETF datatracker status page for this draft is:
>
>         https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/
>
>         There are also htmlized versions available at:
>
>         https://tools.ietf.org/html/draft-ietf-tram-stun-pmtud-17
>
>         https://datatracker.ietf.org/doc/html/draft-ietf-tram-stun-pmtud-17
>
>         A diff from the previous version is available at:
>
>         https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-pmtud-17
>
>         Please note that it may take a couple of minutes from the time of submission
>
>         until the htmlized version and diff are available at tools.ietf.org.
>
>         Internet-Drafts are also available by anonymous FTP at:
>
>         ftp://ftp.ietf.org/internet-drafts/
>
>         _______________________________________________
>
>         I-D-Announce mailing list
>
>         [e-mail]  <mailto:[e-mail]>
>
>         https://www.ietf.org/mailman/listinfo/i-d-announce
>
>         Internet-Draft directories:http://www.ietf.org/shadow.html
>
>         orftp://ftp.ietf.org/ietf/1shadow-sites.txt
>