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

From: "Felipe Garrido (fegarrid)" <[email-masked]>
Date: Thu, 14 Nov 2019 09:04:33 +0000

Hi Eric,

Responses to your COMMENTS are in-line along with some additional requests for information to address some of them. Most are addressed in the latest draft -14.

Thanks,
-Felipe

From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Subject: [tram] Eric Rescorla's No Objection on draft-ietf-tram-stun-pmtud-10: (with COMMENT)
Date: September 27, 2018 at 12:19:43 AM EDT
To: "The IESG" <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, Gonzalo Camarillo <[email-masked]<mailto:[email-masked]>>

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.

[FG] In discussing with the other authors, we’re unsure of which method you are referring to. Can you provide clarity on this COMMENT?

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.

[FG] Working with the other authors to determine how best to update this section. Will provide updated text in the next drft.

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.

[FG] The PMTUD mechanism is meant to be used by any UDP-based protocol.

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

[FG] Updated to match RFC 4821.

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.

[FG] yes, this would require the server to take reverse roles and act as a client to measure PMTU.

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.

[FG] updated text in the latest draft.

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?

[FG] updated the text in the latest draft.

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?

[FG] updated the text in the latest draft

_______________________________________________
tram mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tram