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
