Subject: [tram] Review of draft-ietf-tram-stun-pmtud-02

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 8 Aug 2016 04:55:08 +0000

Here is my review of draft-ietf-tram-stun-pmtud draft.

Comments:

1)What is behavior of middle boxes like B2BUAs (that may be media aware
relay or simple media relay as described in section 4 of
https://tools.ietf.org/html/rfc7584)
 when handling pathMTUD STUN messages ?

2) I also agree to some of the security concerns raised by Tiru in the
list. Especially on how we can avoid/detect when some one is using the
mechanism described in this draft for mechanism  to launch amplification
attack or man-in-the-middle attacks.

3)Section 4,5 says server MUST NOT authenticate/challenge client. Why is
authentication not recommended here ? If path MTUD is being used between
ICE peers, or a STUN client/Server they are likely to have shared secret
already (short-term or long-term credentials). Should we not use the
existing STUN authentication procedures here as well ?

4) Section 6 talks about different mechanisms for indicating support for
supporting the pmtud described in this document by means of having
PMTUD-SUPPORTED attribute in STUN/TURN messages. How does the
server/client know it is using simple or complete probe mechanisms ? Is it
only by looking at the sequence of messages ?

5)Would pmtud probes be done only once when the 5-tuple for sending data
is setup (as part of ICE checks, TURN) ? Or would the probes done
periodically during a session ? If done periodically it would be good to
add how this would interact with Consent freshness STUN messages.

Minor comments:
1) Would be good to refer the RFC (rfc5780) that defines the STUN PADDING
attribute as you are using that in this document

2)Section 6.2 should be applicable for any STUN client (not for only TURN
client) interacting with STUN server. In case of TURN client/server it
will be indicated in ALLOCATE request as mentioned in draft. In case of
STUN client/Server it will be BindRequest from client to Server.
3)Would be good to have ladder diagrams showing the message flows for both
simple and complete probing mechanisms.

4)Why is IDENTIFIERS STUN attribute made as comprehensive-required stun
attribute ? That would require all STUN agents to process that attribute
and cannot safely ignore if it does not understand.

Regards,
Ram