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
