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

[Gorry Fairhurst <[e-mail]>]

Thanks for this new revision! It indeed answers many of the issues that 
were identified.

I do still see a few things left that the WG should decide upon, and 
hope this helps:
---
The text says this:"A client MUST NOT send a probe if it does not have 
knowledge that the server supports this specification.  This is done 
either by external signalling or by a mechanism specific to the UDP 
protocol to which PMTUD capabilities are added or by one of the 
mechanisms specified in Section 5."
- This looks like a strong requirement without saying why this is a 
"MUST NOT".
- I don't actually understand how this is determined in this spec and 
how this can be extened to other protocols.
---
In section 7:
This section has added a section that is a cross-reference to sections 
in DPLPMTUD. This does seem like a useful addition (and appropriate). 
Currently this doesn’t really seem to me to 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 could be 
helpful tp be explained up front in the intriduction?
---
DPLPMTUD contains guidance on flow control and congestion control. This 
doesn’t describe the implications of probing on flow control control. 
I’m not sure the current text is enough:
 8. Probing and flow control: 
This requirement is out of scope and is not discussed in this document.
- Do probe packets count as credit to an upper layer protocol using this 
method?

  Here are there options: One could be to explain how this is 
done, the easiest mighht be to explain the usage in STUN does not 
require this, or the third: defer to DPLPMTUD saying this applies.
---
“9.  Shared PLPMTU state: This requirement is out of scope and is not 
discussed in this document.”
- Why is 9. out of scope? ... what does the method do with the (PL)PMTU 
value that it discovers? How is this made available to a user of the 
method and is the method cached in way?

- How does the method relate to the cached value of PMTUD at the sender, 
if that is already running on a platform, doesn't this new method mean 
than the PMTU cache and PTB-updates have to be over-ridden, as is the 
case when using DPLPMTUD with other protocol stacks?

- Also is it that the discovered (PL)PMTU value can never be cached by 
another usage of STUN? (I may have misunderstood)

---
Section 7.  Rev-18 also introduces quite a few typos - but I assume a 
spelling checker will find and help correct these.
---

That leaves Section 5:


I still 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. "
- Please see comments made in the previous last call, about this ID not 
defining this for other UDP-based protocols. At the moment it still says 
this ID applies to other uses of UDP (which I did not see explained, nor 
do I think this is needed). To me, much of the spec proposed seems to me 
to rely upon the STUN multiplexing to sepearate the probe packets from 
data, to receive feedback and to introduce padding.
- Please discuss the expected scope of the spec with your WG AD, and 
suggest how to best take section 5 forward.

I'll happilly review a new revision.

---

Gorry


On 14/09/2020 15:27, Felipe Garrido (fegarrid) wrote:
 >
 > Hi Gorry,
 >
 >
 >
 > Have you had a chance to review the latest draft?
 >
 >
 >
 > Thanks,
 >
 > -Felipe
 >
 >
 >
 > From: "Felipe Garrido (fegarrid)" <[e-mail]>
 > Date: Wednesday, August 19, 2020 at 11:24 AM
 > To: Gorry Fairhurst <[e-mail]>, "[e-mail]" 
<[e-mail]>
 > Cc: "[e-mail]" <[e-mail]>
 > Subject: Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt
 >
 >
 >
 > Hi Gorry,
 >
 >
 >
 > Version 18 has been published with the changes mentioned below.  To 
make sure readers are aware, can you add an informative reference to 
stun-pmtud in the tsvwg-datagram-plpmtud draft?
 >
 >
 >
 > Thanks,
 >
 > -Felipe
 >
 >
 >
 > From: Gorry Fairhurst <[e-mail]>
 > Date: Tuesday, August 4, 2020 at 5:05 AM
 > To: "Felipe Garrido (fegarrid)" <[e-mail]>, "[e-mail]" 
<[e-mail]>
 > Cc: "[e-mail]" <[e-mail]>
 > Subject: Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt
 >
 >
 >
 >
 >
 > 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]).
 >
 >
 >
 >         Cheers
 >
 >
 >
 >         Magnus
 >
 >
 >
 >         On Mon, 2020-07-06 at 06:04 -0700, [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]
 >
 >             https://www.ietf.org/mailman/listinfo/i-d-announce
 >
 >             Internet-Draft directories: http://www.ietf.org/shadow.html
 >
 >             or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 >