Subject: [MMUSIC] Draft new version: draft-dtls-sdp-31 [was: Mirja Kühlewind's No Objection on draft-ietf-mmusic-dtls-sdp-30: (with COMMENT)]

From: Christer Holmberg <[email-masked]>
Date: Sat, 7 Oct 2017 11:28:03 +0000

Hi,

Based on Mirja's comments, I've submitted a new version (-31) of draft-dtls-sdp.

The new version implements the following merged GitHub Pull Request:

https://github.com/cdh4u/draft-dtls-sdp/pull/39

Regards,

Christer

-----Original Message-----
From: Mirja Kuehlewind (IETF) [mailto:[email-masked]] 
Sent: 06 October 2017 12:28
To: Christer Holmberg <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-mmusic-dtls-sdp-30: (with COMMENT)

Thanks! Looks good!

Mirja

> Am 06.10.2017 um 11:12 schrieb Christer Holmberg <[email-masked]>:
> 
> Hi Mirja,
> 
> I think Roman earlier did reply to some of your comments, but we 
> forgot to implement the ones that required text modification. Sorry 
> for that. I will include his replies in this reply for convenience.
> 
> Please see inline.
> 
>> ---------------------------------------------------------------------
>> -
>> COMMENT:
>> ---------------------------------------------------------------------
>> -
>> 
>> Thanks for addressing my discuss by simply removing section 7.1!
>> 
>> Old comments:
>> 
>> A couple mostly editorial comments:
>> - Probably a nit: In section 3.2 'must' is used while in section 3.3 
>> 'MUST' is used. I would assume that both sections should probably use 
>> the same.
> 
> Yes. I will fix it.
> 
> ---
> 
>> - in sec 5.1: "Because of
>>  this, if an unordered transport is used for the DTLS association, a  
>> new transport (3-tuple) must be allocated by at least one of the  
>> endpoints so that DTLS packets can be de-multiplexed."
>> Why is this a 3-tuple (instead of a 5-tuple)? I guess you talk about 
>> the source address, source port, transport 3-tuple? May say this more 
>> explicitly.
> 
> Each end point allocates a 3-tuple for connection (transport/address 
> /port). Connections are disambiguated using 5 tuple (transport/source 
> address/source port/destination address/destination port).
> 
> We can make this more explicit.
> 
>   "Because of this, if an unordered transport is used for the DTLS
>    association, a new 3-tuple (transport, address and port) MUST be 
> allocated by at least
>    one of the endpoints so that DTLS packets can be de-multiplexed.²
> 
> 
> Šand:
> 
>   "When an offerer needs to establish a new DTLS association, and if an
>    unordered transport (e.g., UDP) is used, the offerer MUST allocate a
>    new 3-tupleŠ²
> 
> 
> Šand:
> 
>   "When an answerer needs to establish a new DTLS association, if an
>    unordered transport is used, and if the offerer did not allocate a
>    new 3-tuple, the answerer MUST allocate a new 3-tuple for the
>    answer in such a way that it can disambiguate any packets associated
>    with the new DTLS association from any packets associated with any
>    other DTLS association."
> 
> 
> 
> 
>> Also the word of the use transport is confusing to me here because 
>> it's used for the transport protocol as well as for the transport 
>> 'connection' (if a connection-oriented transport protocol is used). 
>> Maybe s/new transport/new flow/? Moreover, there should probably be a 
>> 'MUST' here instead of 'must'!
> 
> I removed ³transport², and simply say 3-tuple, with the 
> transport/address/port clarification on the first occurrence (see above).
> 
> ---
> 
>> - sec 5.2:"In addition, the offerer MUST insert in the  offer an SDP 
>> 'tls-id' attribute with a unique attribute value."
>> Is that a MUST or rather a SHOULD? The rest of the text reads like 
>> this should be a SHOULD.
> 
> <Roman¹s previous reply>
> 
> Implementations compliant with this specification MUST insert tls-id 
> in offers and respond with answer with tls-id if tls-id was present in 
> the offer. This is how end points indicate that they support this 
> specification.
> 
> 
> ---
> 
>> - Shouldn't this document cite RFC6347 normatively, e.g. here (sec 5.3):
>> "... the answerer MUST initiate a DTLS handshake by sending a  DTLS 
>> ClientHello message towards the offerer."
> 
> I will add a reference to RFC6347 to the first occurrence of 'DLTS 
> handshake'.
> 
> ---
> 
>> - I would like to see more discussion about linkability based on the 
>> introduction of the "tls-id" in the security considerations section.
> 
> This comment we actually did address (but forgot to inform you), by 
> adding the following paragraph to the Security Considerations:
> 
>   "This specification does not modify the actual TLS connection setup
>    procedures.  The SDP 'tls-is' attribute as such cannot be used to
>    correlate an SDP Offer/Answer exchange with a TLS connection setup.
>    Thus, this draft does not introduce new security considerations
>    related to correlating an SDP Offer/Answer exchange with a TLS
>    connection setup.²
> 
> 
> ---
> 
> Regards,
> 
> Christer
>