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

Peter, just wanted to ACK that I got this message and I will treat it  
as a IETF LC comment - we can work with folks to resolve the issue.

Cullen <in my AD role>

On Sep 23, 2008, at 7:28 , Schneider, Peter (NSN - DE/Munich) 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