Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-udptl-dtls-04

From: Christer Holmberg <[email-masked]>
Date: Sat, 1 Feb 2014 14:31:37 +0000

Hi,

Based on the review comments by Adam G and Ari K, I've submitted a new version (-04) of the udptl-dtls draft.

Regards,

Christer

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 11 Feb 2014 17:43:30 -0500

Hi Christer

I took a look at the latest draft and I have some comments:

- The Offer/Answer sections could use a bit more work. We try to have 
the following sub-sections with relevant procedures called out (in line 
with RFC 3264):
1) Generating the Initial Offer
2) Generating the Answer
3) Offerer Processing of the Answer
4) Modify the Session
and I'd much prefer the same here.

- Related to offer/answer, I find it underspecified in terms of things 
that are (or are not) at the session versus media-level. It should be 
more explicit here.

- NAT Traversal Without ICE
I'm not sure I follow this section. If the passive party is behind a NAT 
and then sends a STUN request to the active party in order to create a 
NAT binding, then the active party won't know the external NAT address 
and hence its ClientHello message won't get through (unless you are 
saying that it needs to look for such unauthenticated STUN messages and 
then start sending packet to their source address, at which point we are 
headed down a slippery slope on security implications, reinventing or 
ICE, or both).

- Backwards compatibility/interoperability considerations with vanilla 
UDPTL implementations; how do you negotiate successfully ?

I have a couple of nits that I'll send to you off-line as well.

Thanks

-- Flemming

On 2/1/14, 9:31 AM, Christer Holmberg wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Feb 2014 11:40:30 +0000

Hi,

I'll get back to your comment regarding SDP Offer/Answer procedures later.

> I'm not sure I follow this section. If the passive party is behind a NAT and then sends a STUN request to the active party 
> in order to create a NAT binding, then the active party won't know the external NAT address and hence its ClientHello 
> message won't get through (unless you are saying that it needs to look for such unauthenticated STUN messages and 
> then start sending packet to their source address, at which point we are headed down a slippery slope on security implications, reinventing or ICE, or both).

This part is re-used from RFC 5763, as part of the Middlebox Interaction section, so I assume the idea is that the STUN messages are terminated by an SBC (5763 talks about latching).

However, my suggestion would be to remove section 4.2.2 completely. We need 4.2.1 and 4.2.3, which are related to ICE. Then, whatever other mechanisms people may use to do NAT traversal, are out of the scope.

------------------

> - Backwards compatibility/interoperability considerations with vanilla UDPTL implementations; how do you negotiate successfully ?

The draft defines a mechanism to negotiate a secure fax channel. If one endpoint doesn't support it, there will be no successful negotiation, and no secure fax channel. 

However, I guess I can add some informative text, saying that if the user is ok to have a non-secure fax channel in case of failure, it can send a new offer with non-secure fax. Or, it can use CapNeg.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Feb 2014 14:46:40 +0000

Hi Flemming,

>- The Offer/Answer sections could use a bit more work. We try to have the following sub-sections with relevant procedures called out (in line with RFC 3264):
>- Related to offer/answer, I find it underspecified in terms of things that are (or are not) at the session versus media-level. It should be more explicit here.

It did require some restructuring, but I was able to keep most of the text (with some clarifications).

Something like (Note that the compatibility with UDPTL over UDP will be covered in Section 5):

----------------

3.  Secure Channel

   The UDPTL over DTLS media stream is negotiated using the SDP offer/
   answer mechanism [RFC3264].

   DTLS is used as specified in [RFC6347].  Once the DTLS handshake is
   successfully completed (in order to prevent facsimile data from being
   transmitted insecurely), the UDPTL packets SHALL be transported in
   DTLS record layer "application_data" packets.

4.  SDP Offerer/Answerer Procedures

4.1.  General

   The offerer and answerer MUST create an SDP media description ("m="
   line) for each UDPTL over DTLS media stream, and MUST assign a UDP/
   TLS/UDPTL value to the "proto" field of the "m=" line.  The
   procedures in this section apply to such "m=" line.

   In negotiation of a UDPTL over DTLS media stream, the following SDP
   attbibutes are used:

   o  The SDP attributes defined for UDPTL over UDP, as described in
      [ITU.T38.2010]; and
   o  The SDP attributes, defined in [RFC4145] and [RFC4572], as
      described in this section.

   The offerer and answerer MUST NOT use the SDP connection attribute
   [RFC4145].

   In order to negotiate the TLS roles for the UDPTL over DTLS transport
   connection, the offerer and answerer MUST use the SDP setup attribute
   [RFC4145].

   If an endpoint supports, and is willing to use, a cipher suite with
   an associated certificate, it MUST include an SDP fingerprint
   attribute [RFC4572].

   If a cipher suite with an associated certificate is selected during
   the DTLS handshake, the certificate received during the DTLS
   handshake MUST match the fingerprint received in the SDP fingerprint
   attribute.  If the fingerprint does not match the hashed certificate,
   then the endpoint MUST tear down the media session immediately.  Note
   that it is permissible to wait until the other side's fingerprint has
   been received before establishing the connection; however, this may
   have undesirable latency effects.

4.2.  SDP Offerer Procedures

   The offerer SHOULD assign the SDP setup attribute with a
   setup:actpass value.  Alternatively, the offerer MAY assign the SDP
   setup attribute with a setup:active value or setup:passive value.
   The offerer MUST NOT assign an SDP setup attribute with a
   setup:holdconn value.

   If the offerer assigns the SDP setup attribute with a setup:actpass
   value or setup:passive value, the offerer MUST be prepared to receive
   a DTLS client_hello message before it receives the SDP answer.

   When the offerer receives the associated answer, if the offerer ends
   up being active it MUST initiate a DTLS handshake by sending a
   ClientHello message on the negotiated media stream, towards the IP
   address and port of the answerer.

4.3.  SDP Answerer Procedures

   If the answerer accepts the offered UDPTL over DTLS transport
   connection, in the associated answer the answerer MUST assign an SDP
   setup attribute with either a setup:active value or setup:passive
   value, according to the procedures in [RFC4145].  The answerer MUST
   NOT assign an SDP setup attribute with a setup:holdconn value.

   If the answerer assigns a setup:active value, the answerer MUST
   initiate a DTLS handshake by sending a ClientHello message on the
   negotiated media stream, towards the IP address and port of the
   offerer.

----------------

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 12 Feb 2014 10:10:30 -0500

> This part is re-used from RFC 5763, as part of the Middlebox Interaction section, so I assume the idea is that the STUN messages are terminated by an SBC (5763 talks about latching).
Ok - the draft doesn't say that and in general we don't recommend 
latching since it introduces various security issues (see the latching 
draft for more on all of this).

> However, my suggestion would be to remove section 4.2.2 completely. We need 4.2.1 and 4.2.3, which are related to ICE. Then, whatever other mechanisms people may use to do NAT traversal, are out of…
I would agree with that.

Sounds good.

Thanks

-- Flemming

> .