Subject: [tram] WGLC: draft-ietf-tram-stun-dtls-02

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 6 May 2014 09:07:57 +0200

Folks,

we are starting a Working Group Last Call (WGLC) on the following draft:

http://datatracker.ietf.org/doc/draft-ietf-tram-stun-dtls/

This WGLC will end on May 21st. Please, send your comments to this list.

Thanks,

Gonzalo

---

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 20 May 2014 14:53:29 +0000

Marc, Gonzalo,

I did a review of your draft and, though the draft is in good shape, 
I came across some points which were not clear to me.

Section 3 DTLS as Transport for STUN
   ...
   STUN over DTLS MUST, at a minimum,
   support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support
   TLS_RSA_WITH_AES_128_CBC_SHA.  

The first MUST is qualified with "at a minimum".
Should that indicate that the second MUST is not really a MUST? 
If not, then you might want to remove "at a minimum".
If yes, use RECOMMENDED for TLS_RSA_WITH_AES_128_CBC_SHA.

The STUN over TLS default cipher suite was TLS_RSA_WITH_AES_128_CBC_SHA. 
Are both cipher suites above meant as addition to the TLS default or as a replacement?
I propose to clarify either with
"In addition to TLS_RSA_WITH_AES_128_CBC_SHA, which is the default cipher suite for STUN over TLS, STUN over DTLS implementation MUST support ."
or
"Instead of TLS_RSA_WITH_AES_128_CBC_SHA, which is the default cipher suite for STUN over TLS, STUN over DTLS implementation MUST support ."

Section 4. STUN Usages
The link in "[RFC5389] Section 7.2 ." points to section 7.2 of this draft. 
Similar links in the draft point directly to the relevant RFC. 
You may want to change this link accordingly.

Section 4.1 NAT Discovery Usage
   ...
   Regardless, this usage is rarely used by itself, since TURN [RFC5766]
   is generally mandatory to use with ICE [RFC5245], and TURN provides
   the same NAT Discovery feature as part of an Allocation creation.  In
   fact, with ICE, the NAT Discovery usage is only used when there is no
   longer any resource available for new Allocations in the TURN server.

TURN support is not mandated in RFC5245, it is only at SHOULD strength. 
See http://tools.ietf.org/html/rfc5245#section-4.1.1.2.  
The easiest fix is probably to remove that whole paragraph.

4.2. Connectivity Check Usage
.. 
This usage MUST NOT be used with a STUN URI.
It is not obvious to me what is meant here. 
Do you want say that connectivity checks MUST NOT be sent over DTLS?
MUST NOT is maybe a bit strong, but I would not object violently.

4.3. Media Keep-Alive Usage
   The media keep-alive (described in Section 20 of [RFC5245]) runs
   inside an RTP or RTCP session, so it is already protected if the RTP
   or RTCP session is also protected (i.e., SRTP/SRTCP).  Adding DTLS
   inside the SRTP/SRTCP session would add overhead, with minimal
   security benefit.

   This usage MUST NOT be used with a STUN URI.

I think the first sentence is a bit misleading. Media keep alive is separate from the RTP or SRTP session. 
The STUN Binding indications are just multiplexed on the same port as (S)RTP/(S)RTCP. 
Sending the STUN Binding indication in DTLS records would however change how this multiplexing is done, and as stated, would add overhead and initially some delay. 
Again I can't parse "This usage MUST NOT be used with a STUN URI." 
Do you mean "STUN Binding indications MUST NOT be sent over DTLS"?

4.4. SIP Keep-Alive Usage
.
   This usage MUST NOT be used with a STUN URI.
As above it is not clear to me what is meant.

Kind Regards/mit freundlichen Grüßen
Thomas Stach

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> Sent: Dienstag, 6. Mai 2014 09:08
> To: [email-masked]
> Subject: [tram] WGLC: draft-ietf-tram-stun-dtls-02
> 
> Folks,
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 26 May 2014 09:26:36 +0300

Hi Thomas,

thanks for your comments. The authors will revise the draft in order to
address them.

Cheers,

Gonzalo

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 30 May 2014 10:32:46 -0600

Hi Thomas,

Thank you for the review, and sorry for the delay in responding.  Please
see my answers inline.

> If yes, use RECOMMENDED for TLS_RSA_WITH_AES_128_CBC_SHA.

I think that the intent was "at a minimum both of them", but I agree
that the text is confusing.  Fixed in the new version.

> Are both cipher suites above meant as addition to the TLS default or as a replacement?

The latter.

> "Instead of TLS_RSA_WITH_AES_128_CBC_SHA, which is the default cipher suite for STUN over TLS, STUN over DTLS implementation MUST support ."

Text added.

> You may want to change this link accordingly.

I suppose that this is an artifact of the HTMLization of the I-D but as
editors we do not have any control on this, as far as I know.

> The easiest fix is probably to remove that whole paragraph.

"mandatory" here meant "it is a disservice to your customers to not use
TURN" more than "the IETF forces you to use TURN".  I replaced "since
TURN is generally mandatory to use" by "since using TURN with ICE is
generally indispensable".

> MUST NOT is maybe a bit strong, but I would not object violently.

No it means that STUN URI must not be used with this usage, so we do not
have to specify how STUN URI are to be interpreted in this context.

Changed the text to: "STUN URIs are not used with this usage."

> The STUN Binding indications are just multiplexed on the same port as (S)RTP/(S)RTCP. 

Yes, you are right.  I shorten the sentence to "The media keep-alive
(described in Section 10 of [RFC5245]) runs alongside an RTP or RTCP
session."

> Sending the STUN Binding indication in DTLS records would however change how this multiplexing is done, and as stated, would add overhead and initially some delay. 

RFC 5764 already permits that kind of multiplexing but it also forbids
using application_data records, so a non-srtp additional session would
have to be negotiated, at the cost of additional delay.

So the new text says that:

"It is possible to send the media
 keep-alive packets inside a separately negotiated non-srtp DTLS
 session if DTLS-SRTP [RFC5764] is used, but that would add overhead,
 with minimal security benefit."

> Do you mean "STUN Binding indications MUST NOT be sent over DTLS"?

See above.

> As above it is not clear to me what is meant.

See above.

-- 
Marc Petit-Huguenin
Developer  |  Jive Communications, Inc.
Jive.com  |  [email-masked]