> 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
