Re: [MMUSIC] [mmusic-udptl-dtls-01] Establishment direction of DTLS session

[Christer Holmberg <[e-mail]>]

Hi Albrecht,

The direction of the SIP session establishment and the DTLS session establishment are NOT tightly coupled. The draft enables the Answerer to select whether it wants to act as DTLS client or DTLS server.

Section 3.1 states:

.... The
offerer MUST assign the SDP setup attribute with setup:actpass
value, and MUST be prepared to receive a DTLS client_hello message
before it receives the SDP answer. The answerer MUST assign the
SDP setup attribute with either setup:active value or
setup:passive value. The answerer SHOULD assign the SDP setup
attribute with the setup:active value. Whichever party is active
MUST initiate a DTLS handshake by sending a ClientHello over each
flow (host/port quartet).

The same rules apply for DTLS-SRTP (see Section 5 of RFC5763). In fact, we base the procedure on that RFC.

BFCP-over-DTLS (draft-ietf-bfcpbis-rfc4582bis) also refers to the DTLS-SRTP procedures for DTLS server determination.

Regards,

Christer





-----Original Message-----
From: Schwarz, Albrecht (Albrecht) [mailto:[e-mail]] 
Sent: 18. syyskuuta 2013 18:28
To: Christer Holmberg
Cc: [e-mail]
Subject: [mmusic-udptl-dtls-01] Establishment direction of DTLS session

The T.38 endpoint could be located in a terminal (= T.38 IAF) or in a gateway, leading to three possible scenarios of 
a) T - T
b) T -GW
c) GW-GW

I'd like to scope on scenario (b) due to its asymmetry of user- and network-side located T.38 endpoints.

Christer,
I thought that the two directions of
1) SIP session establishment and
2) DTLS session establishment
should be NOT tightly coupled (as currently supposed to be in clause 3.1)?
The ietf draft should offer the flexibility in decoupling both establishment directions.

E.g., there might be the demand to limit DTLS session establishment in T-to-GW direction (and apply rather the reverse direction) due ClientHello associated security threats, resource requests in terms of memory, ...

In my opinion:
the IETF should allow the flexibility,
other SDOs could still profile/limit this capability.

Best regards,
Albrecht

PS
We had a similar discussion with TLS, there NAT traversal (NAT-T) aspects could influence TLS session establishment direction. However, I guess that NAT-T is minor for DTLS/UDP.