[tram] Eric Rescorla's No Objection on draft-ietf-tram-stun-pmtud-10: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-tram-stun-pmtud-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4528



IMPORTANT
S 4.2.6.
>      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.
>   
>   4.2.6.  Using Sequence Numbers as Packet Identifiers

I don't understand how as an endpoint I know which method I use.


S 4.2.6.
>   
>   4.2.6.  Using Sequence Numbers as Packet Identifiers
>   
>      When using sequence numbers, a small header similar to the TURN
>      ChannelData header is added in front of all packets that are not a
>      STUN Probe Indication or Request.  The sequence number is

how would this interact with ICE, where you send Binding Indidcations.

COMMENTS
S 2.
>      Probing mechanism (as described in Section 4.2).  The selection of
>      which Probing Mechanism to use is dependent on performance and
>      security and complexity trade-offs.
>   
>      If the Simple Probing mechanism is chosen, then the Client initiates
>      Probe transactions, as shown in Figure 1, which increase in size

Why does this use probe and not binding-request? Then you wouldn't
have a constraint on knowing the other side supported it.


S 2.
>      security and complexity trade-offs.
>   
>      If the Simple Probing mechanism is chosen, then the Client initiates
>      Probe transactions, as shown in Figure 1, which increase in size
>      until transactions timeout, indicating that the Path MTU has been
>      exceeded.  It then uses that information to update the Path MTU.

Most of the MTU mechanisms I know of start big and go small.

See, for instance: https://tools.ietf.org/html/rfc4821#section-7.2


S 4.1.2.
>      [RFC5389].
>   
>      The server then creates a Probe Response.  The server MUST add the
>      FINGERPRINT attribute so the STUN messages are disambiguated from the
>      other protocol packets.  The server then sends the response to the
>      client.

I note that this doesn't let you measure PMTU in the opposite
direction.


S 4.1.3.
>      client.
>   
>   4.1.3.  Receiving a Probe Response
>   
>      A client receiving a Probe Response MUST process it as specified in
>      [RFC5389].  If a response is received this is interpreted as a Probe

5389 doesn't describe Probe, so you should lay out what this means.


S 6.2.
>   
>   6.2.  PMTUD-SUPPORTED
>   
>      The PMTUD-SUPPORTED attribute indicates that its sender supports this
>      specification.  This attribute has no value part and thus the
>      attribute length field is 0.

When is this useful? Only when you want to use simple probing?


S 7.
>      The Simple Probing mechanism may be used without authentication
>      because this usage by itself cannot trigger an amplification attack
>      as the Probe Response is smaller than the Probe Request.  An
>      unauthenticated Simple Probing mechanism cannot be used in
>      conjunction with the Implicit Probing Support Signaling mechanism in
>      order to prevent amplification attacks.

I don't understand this last sentence. It can't be used? Doesn't the
previous sentence imply you can?