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

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

Cullen,

sorry this took some time, and maybe the answer is not fully satisfactory. I could NOT adduce evidence that middleboxes generally don't latch on a connectivity check as described in the ICE-draft. Rather, it seems that existing implementations can be configured to do so. 

However, in 3GPP/TISPAN it is recommended that terminals, if ICE is not supported, use empty (no payload) RTP packets for maintaining NAT bindings: A reference for this is the document

   3GPP TS 24.229 V8.5.0 (2008-09)
   "IP multimedia call control protocol based on
   Session Initiation Protocol (SIP) and Session
   Description Protocol (SDP)"
   http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-850.zip 

which is valid for TISPAN as well as for 3GPP (from Release 8, to be freezed by the end of this year).

In its (normative) Appendix K5.2.1, the document talks more generally about the keepalive for NAT bindings (i.e. not only for the initial establishing of the binding). It states that ICE should be used, but "In the case where keepalives are required and the other end does not support ICE ..., the UE [user equipment] shall send an empty (no payload) RTP packet with a payload type of 20 as a keepalive ...".

So middleboxes that take this behaviour of user equipment into account will latch on RTP packets. Assuming that the "STUN [I-D.ietf-behave-rfc3489bis] connectivity check" mentioned in the DTLS-SRTP-framework-draft is in fact the connectivity check described in the ICE-draft, middleboxes may let such requests pass and even latch on it, depending on the configuration. (Maybe the framework-draft could use a wording that makes more clear that "Latching control without ICE" still uses a method that is rather described in the ICE-draft than in draft-ietf-behave-rfc3489bis to which the framework-draft refers in the text.)

To conclude: In order to make DTLS-SRTP usable in more scenarios, it (still) seems favorable to me to allow (in the case ICE is not used) the usage of empty RTP packets rather than make the "STUN connectivity check" mandatory if the DTLS handshake stalls.

I feel that my other comments (see my original posting below) are still valid, in particular giving more weight to the recommendations from draft-ietf-mmusic-media-path-middleboxes by placing text reflecting these recommendations into the framework draft.

Peter 

> -----Ursprüngliche Nachricht-----
> Von: ext Cullen Jennings [mailto:[e-mail]] 
> Gesendet: Freitag, 26. September 2008 05:54
> An: Schneider, Peter (NSN - DE/Munich)
> Cc: ext Dean Willis; Hannes Tschofenig; Jason Fischl; Eric 
> Rescorla; SIP List
> Betreff: Re: AW: [Sip] 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: [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