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

[Gorry Fairhurst <[e-mail]>]

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.

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?

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?

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.

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.

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.

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.

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?

*---*

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
>> orftp://ftp.ietf.org/ietf/1shadow-sites.txt