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

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Fri, 28 Oct 2016 01:13:22 +0000

Hi Tiru - 

Thanks for the review.  Sorry for the delayed response but just now getting around to processing your email.  Responses inline...

> On Aug 6, 2016, at 8:29 PM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
> 
> 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).

Yes, you are right.  We have published a new version that addresses this concern by making authentication mandatory for any mechanism that carries the PMTUD-SUPPORTED attribute. Please have a look at the new version to ensure you are satisfied with the approach.
        
> 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 ?

The new version removes all of the ICE text.  We will handle the ICE use-case in a separate draft that we will publish shortly in the ICE WG.

> b) Why not wait until the ICE nomination is complete or until the pair state is changed to Succeeded ?

See above.

> 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) ?

We have made it explicit in the new version that this specification is not meant to replace existing PMTUD mechanisms.  If there is an SCTP use case then the PMTUD mechanism described in Section 10.2 of RFC 4821 can be used.

> 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)

Yes, agreed. This specification is written to be independent of DTLS, so there should no impact to the text.
 
> 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 ?

Any request that contains PMTUD-SUPPORTED is now authenticated (in the new version of this specification).

> 4) There are two mechanisms for probing, why can't we have just one ?

The complete probing mechanism is the one that fully implements RFC 4821.  We added a simple probing mechanism for cases that do not require this complexity.   

>      Should both probing mechanisms be implemented ? 

The new version of the specification states: "Implementations supporting this specification MUST implement the server side of both the Simple Probing mechanism (Section 4.1) and the Complete Probing mechanism (Section 4.2).  Implementations supporting this specification MUST implement the client side of the Complete Probing mechanism.  They MAY implement the client side of the Simple Probing mechanism.”

>      I think a guidance/recommendation section will help select the appropriate probing mechanism.

We added a new section “Overview of Operations” describing the added PMTUD capabilities.  Additionally, we have added clarifying text being very prescriptive about which probing mechanisms are MTI.

>  5) Same comment as above for packet identifier mechanisms.

We intentionally did not provide explicit guidance on which packet identification mechanism to use because it is protocol dependent.  We simply provide two possible packet identification mechanisms to help implementors.

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

Authentication is now mandatory for the report transaction in the complete probing mechanism.

>  7) The client SHOULD stop retransmitting after 3 missing responses.
>  
> comments> 
> a)Why 3 when STUN uses by 7 by default ?

We use 3 simply to get a response faster.  This is similar to some of the discussions happening in the ICE WG about reducing the number of retransmissions for certain usages.

> b)I don't see any discussion on pacing b/w retransmissions.

We use the same pacing as in RFC 5389.  We’ve added text indicating that the initial value for RTO stays at 500 ms.

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

We’ve added related text to the Security Consideration section.

>  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 ?

They certainly can arrive out of order and this will be reflected in the contents of the Report Response. We’ve tried to add clarifying text making this clear.

> b)      what is the format of the report response ?

We have text in there indicating that the server creates a Report Response and adds an IDENTIFIERS attribute that contains the list of all identifiers received so far.  

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

We have added a new section describing the format of the new attributes.

Please review the new version to ensure that all your comments are addressed to your satisfaction.

Cheers,

Gonzalo

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

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Fri, 28 Oct 2016 01:34:55 +0000

Hi Ram - 

Thanks for the review.  Sorry for the delayed response but just now getting around to processing your email.  Responses inline…

> On Aug 7, 2016, at 9:55 PM, Ram Mohan R (rmohanr) <[email-masked]> wrote:
> 
> 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 ?

The authors felt there wasn’t any B2BUA-specifc behavior that needed to be specifically called out as part of this specification. Do you have something specific in mind?  If so, could you propose specific text that we should add?

> 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.

We have responded to Tiru on all his points. Please have a look at that response for more details.

> 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 ?

Yes, authentication is now mandatory for complete probing mechanism.  Also, the ICE usage has been entirely removed from the specification and will be defined in a new separate draft.

> 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 ?

Both simple and complete probing mechanisms are MTI on the server side, so the client that receives the PMTUD-SUPPORTED attribute can initiate either one.

> 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.

This is a good question but the ICE text was intentionally removed from this draft.  We will consider this when defining the ICE PMTUD usage draft.

> 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

Done.

> 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.

The TURN usage has been entirely removed form this draft.  Also, bear in mind that there is no real practical use for a TURN-based PMTUD mechanism because it is not end-to-end.

> 3)Would be good to have ladder diagrams showing the message flows for both
> simple and complete probing mechanisms.

Done. These can be found in the new Overview of Operations section that was added (Section 2).

> 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.

This attribute is only sent in the Report Response so the STUN agents MUST know how to process it.

Cheers,

Gonzalo

> Regards,
> Ram