Re: [Sip] Pub request for draft-ietf-sip-dtls-srtp-framework-03

[Henry Sinnreich <hsinnrei at adobe.com>]

> as described now suitable as a media plane security solution for the 3GPP IMS?

What is the media plane, its X and Y dimensions?

Thanks, Henry


On 9/23/08 9:28 AM, "Schneider, Peter (NSN - DE/Munich)"
<peter.schneider at nsn.com> wrote:

> There is maybe one concern with the document in its current form: Is DTLS-SRTP
> as described now suitable as a media plane security solution for the 3GPP IMS?
> 
> A main problem here is the interworking with middleboxes, as described in
> draft-ietf-mmusic-media-path-middleboxes. This draft is mentionened in
> draft-ietf-sip-dtls-srtp-framework-03 in a way that makes me assume that
> following the recommendations of draft-ietf-mmusic-media-path-middleboxes is
> compliant with draft-ietf-sip-dtls-srtp-framework-03. However, ignoring
> draft-ietf-mmusic-media-path-middleboxes is also possible, which would lead to
> a poor interaction with middleboxes. It would be favorable to have the
> recommendations inside draft-ietf-sip-dtls-srtp-framework itself, and to
> emphasize that following theses recommendations will help making DTLS-SRTP
> work in scenarios with middleboxes.
> 
> A specific concern is: If ICE is not used, the passive side (the server in the
> DTLS handshake) must use a STUN connectivity check to open a pinhole (in a
> middlebox). In 3GPP/TISPAN scenarios it is likely that ICE and STUN do not
> work at the managed middleboxes (the SBCs) - such traffic may just be
> discarded. In particular, a STUN connectivity check may NOT trigger latching
> at an SBC. Sending of no-op RTP packets (see [I-D.ietf-avt-rtp-no-op]) however
> will trigger the latching. (Both methods are mentioned in
> draft-ietf-mmusic-media-path-middleboxes at equal ranks, but from the
> 3GPP/TISPAN and SBC interaction perspective, the "wrong" one was selected as
> mandatory in draft-ietf-sip-dtls-srtp-framework-03.)
> 
> Consider this scenario, showing a managed middlebox plus an unmanaged (e.g.
> residential) NAT/FW at the passive side:
> 
> 
>      SIP     +-----------------+     SIP
>   Signaling  |     SIP ALG     |  Signaling
> <----------->+-----------------+<---------------+
>              |   MIDCOM Agent  |                |
>              +-----------------+                |
>                       ^                         |
>        Policy rule(s) | and NAT bindings  +---------+      +----------+
>                       v                   |     +---|----->| Endpoint |
>     Media      +-------------+   Media    | NAT/FW  |      |    P     |
> <------------->|  Middlebox  |<-----------|---------|----->|          |
>                +-------------+            +---------+      +----------+
> 
> 
> The MIDCOM agent will instruct the middlebox to relay the traffic of the
> session. But even after SDP offer and answer have been exchanged, the
> middlebox and MIDCOM agent will not know which IP address the residential
> NAT/FW is going to use for the media session. A STUN connectivity check sent
> by endpoint P would open a pinhole in the residential NAT/FW, but would be
> discarded by the middlebox. An RTP packet however, e.g. a no-op RTP packet,
> would typically cause latching at the middlebox, e.g. make the middlebox take
> the source IP address of the RTP packet as the media address of endpoint P.
> 
> Consequently, at least for 3GPP/TISPAN scenarios, no-op RTP packets should be
> used rather than STUN connectivity checks, and it would be favorable if the
> draft mentioned that, e.g. in the section "Latching Control Without ICE".
> Maybe the best solution is to recommend  the no-op RTP packets for all
> scenarios without ICE.
> 
> Moreover, draft-ietf-mmusic-media-path-middleboxes recommends:
>    - to retry signaling (for key exchange) on the media path in a suitable
> way, if it has failed (REC #3)
>    - to send an SDP answer as soon as possible, for example within a
> provisional SIP response (REC #4)
> Wording reflecting these recommendations should be placed in section 6.7 of
> draft-ietf-sip-dtls-srtp-framework.
> 
> In section 5 of draft-ietf-sip-dtls-srtp-framework, where it is recommended
> for the answerer to take the active role, a hint should be added that in
> middlebox scenarios, where middleboxes block the media path before SDP offer
> and answer have been exchanged (and media before SDP answer will not work
> anyway), the answerer should take the passive role rather then starting a
> DTLS-SRTP handshake that will stall due to a blocking middlebox.
> 
> Peter 
> 
>> -----Ursprüngliche Nachricht-----
>> Von: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] Im
>> Auftrag von ext Dean Willis
>> Gesendet: Dienstag, 23. September 2008 09:28
>> An: iesg-secretary at ietf.org
>> Cc: CULLEN JENNINGS; sip at ietf.org
>> Betreff: [Sip] Pub request for draft-ietf-sip-dtls-srtp-framework-03
>> 
>> We seem to be Done with the DTLS-SRTP Framework!
>> 
>> 
>> Here's the draft writeup for draft-ietf-sip-dtls-srtp-framework-03.
>> Please report any problems (like, maybe I cut-and-pasted the wrong
>> buffer again) to me and to the list. Thanks!
>> 
> ... 
>> 
>> 
>> (1.c) Does the Document Shepherd have concerns that the document
>> needs more review from a particular or broader perspective, e.g.,
>> security, operational complexity, someone familiar with AAA,
>> internationalization or XML?
>> 
>> The reviews appear to be adequate.
>> 
> ...
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip