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:[EMAIL PROTECTED] > Gesendet: Dienstag, 23. September 2008 23:13 > An: Schneider, Peter (NSN - DE/Munich); ext Dean Willis; > Tschofenig, Hannes (NSN - FI/Espoo); Jason Fischl; [EMAIL PROTECTED] > Cc: Cullen Jennings; [email protected] > 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)" > <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im > >> Auftrag von ext Dean Willis > >> Gesendet: Dienstag, 23. September 2008 09:28 > >> An: [EMAIL PROTECTED] > >> Cc: CULLEN JENNINGS; [email protected] > >> 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 [EMAIL PROTECTED] for questions on current sip > > Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
