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

Peter,

This SBC latching is an interesting topic and has come up on some of  
the 3GPP/IETF joint conference calls. I view it as an issue to do with  
middle-box traversal for SIP media and somewhat tangential to DTLS- 
SRTP but that does not change the importance of discussing it.

The part I don't really understand is: Why can the SBC latch for RTP  
No-Op packets but not STUN? If you could provide any more information  
about this question in the context of 3GPP usages, I think that would  
be be helpful in deciding what to do.

Thanks, Cullen


On Sep 23, 2008, at 8:28 AM, 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