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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 7 Aug 2016 03:29:10 +0000

Comments

1)

   A TURN client supporting this STUN usage will add a PMTUD-SUPPORTED
   attribute to the Allocate Request sent to the TURN server.  The TURN
   server can immediately start to send probes to the TURN client on
   reception of an Allocation Request with a PMTUD-SUPPORTED attribute.
   The TURN client will then use the Implicit Mechanism described above
   to send probes.

Comment> The above mechanism can be used by attacks to launch amplification attack (just like in DNS-over-UDP).

2)

   An ICE [RFC5245] client supporting this STUN usage will add a PMTUD-
   SUPPORTED attribute to the Binding Request sent during a connectivity
   check.  The ICE server can immediately start to send probes to the
   ICE client on reception of a Binding Request with a PMTUD-SUPPORTED
   attributed.  Local candidates receiving Binding Request with the
   PMTUD-SUPPORTED flag must not start PMTUD with the remote candidate
   if already done so.  The ICE client will then use the Implicit
   Mechanism described above to send probes.

Comments>
a) What is the need to immediately send probes ?
b) Why not wait until the ICE nomination is complete or until the pair state is changed to Succeeded ?
c) SCTP also has probing discussed in https://tools.ietf.org/html/rfc4821#section-10.2, why can't it be used
   (if media/data channel are multiplexed on the same port) ?
d) If DTLS is used, path discovery can happen after DTLS handshake is complete
   (see https://tools.ietf.org/html/rfc6347#section-4.1.1.1)

3)

   A client MUST NOT send a probe if it does not have knowledge that the
   server supports this specification.  This is done by an external
   mechanism specific to each UDP protocol.  Section 6 describes some of
   this mechanisms.

Comments> What if man-in-middle attacker changes the request to add PMTUD-SUPPORTED ?

4) There are two mechanisms for probing, why can't we have just one ?
     Should both probing mechanisms be implemented ?
     I think a guidance/recommendation section will help select the appropriate probing mechanism.

5) Same comment as above for packet identifier mechanisms.

6) What if the attacker changes the report response from the server ?
    (I think you should mandate authentication/DTLS).

7) The client SHOULD stop retransmitting after 3 missing responses.

comments>
a)Why 3 when STUN uses by 7 by default ?
b)I don't see any discussion on pacing b/w retransmissions.

8) Security considerations needs to discuss threats in the above comments.

9) Section 5.5, Using Checksum as Packet Identifiers

When using checksum as packet identifiers, the client calculate the
checksum for each packet sent over UDP and keep this checksum in an
ordered list.  The server does the same thing and send back this list
in the Report Response.

Comment>

a)       what if the packets arrive out-of-order at the server ?

b)      what is the format of the report response ?

c)       What is the format of the new attributes defined in this document ?

-Tiru