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

["Schneider, Peter (NSN - DE/Munich)" <[e-mail]>]

No smiley in the question, so: The media plane is just the set of all media paths. Shown as the line at the bottom of the SIP trapezoid, e.g. in Figure 1 in draft-ietf-sip-dtls-srtp-framework-03.txt .

The media plane security solution to be specified by 3GPP will comprise cryptographic procotocols for securing the media (like SRTP) as well as a key management protocol (or more than one). Because of the middlebox considerations 3GPP currently focusses on key management protocols that do not use the media path.

A 3GPP technical report on this (work in progress) can be found at
http://www.3gpp.org/ftp/Specs/archive/33_series/33.828/33828-081.zip

Peter

> -----Ursprüngliche Nachricht-----
> Von: ext Henry Sinnreich [mailto:[e-mail]] 
> Gesendet: Dienstag, 23. September 2008 23:13
> An: Schneider, Peter (NSN - DE/Munich); ext Dean Willis; 
> Tschofenig, Hannes (NSN - FI/Espoo); Jason Fischl; [e-mail]
> Cc: Cullen Jennings; [e-mail]
> Betreff: Re: [Sip] Pub request for 
> draft-ietf-sip-dtls-srtp-framework-03
> 
> > 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)"
> <[e-mail]> 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: [e-mail] [mailto:[e-mail]] Im
> >> Auftrag von ext Dean Willis
> >> Gesendet: Dienstag, 23. September 2008 09:28
> >> An: [e-mail]
> >> Cc: CULLEN JENNINGS; [e-mail]
> >> 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 [e-mail] for questions on current sip
> > Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip