[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Pub request for draft-ietf-sip-dtls-srtp-framework-03
No smiley in the question, so: The media plane is just the set of all media paths. Shown as the line at the bottom of the SIP trapezoid, e.g. in Figure 1 in draft-ietf-sip-dtls-srtp-framework-03.txt .
The media plane security solution to be specified by 3GPP will comprise cryptographic procotocols for securing the media (like SRTP) as well as a key management protocol (or more than one). Because of the middlebox considerations 3GPP currently focusses on key management protocols that do not use the media path.
A 3GPP technical report on this (work in progress) can bFrom sip-bounces at ietf.org Wed Sep 24 01:41:09 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 0F5613A6D4C;
Wed, 24 Sep 2008 01:41:09 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 39DE13A6D66
for <sip at core3.amsl.com>; Wed, 24 Sep 2008 01:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.372
X-Spam-Level:
X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=0.772,
BAYES_00=-2.599, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id BwiEOL+tlFpX for <sip at core3.amsl.com>;
Wed, 24 Sep 2008 01:41:02 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net
[217.115.75.233])
by core3.amsl.com (Postfix) with ESMTP id 6EFD93A6D67
for <sip at ietf.org>; Wed, 24 Sep 2008 01:41:01 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55])
by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id
m8O8f0Vr025213
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verifyúIL);
Wed, 24 Sep 2008 10:41:00 +0200
Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35])
by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP
id m8O8ex1N019582; Wed, 24 Sep 2008 10:41:00 +0200
Received: from DEMUEXC006.nsn-intra.net ([10.150.128.103]) by
demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);
Wed, 24 Sep 2008 10:40:59 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 24 Sep 2008 10:41:01 +0200
Message-ID: <085BE88FD18EE94085EB8960172CA35901005B9C at DEMUEXC006.nsn-intra.net>
In-Reply-To: <C4FEC5F0.886C%hsinnrei at adobe.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] Pub request for draft-ietf-sip-dtls-srtp-framework-03
Thread-Index: AckdTgnYoAlFa5S2SWSKYxnUx9goqAABLz1AABuUOC4AFx8VAA=References: <085BE88FD18EE94085EB8960172CA35901005A00 at DEMUEXC006.nsn-intra.net>
<C4FEC5F0.886C%hsinnrei at adobe.com>
From: "Schneider, Peter (NSN - DE/Munich)" <peter.schneider at nsn.com>
To: "ext Henry Sinnreich" <hsinnrei at adobe.com>
X-OriginalArrivalTime: 24 Sep 2008 08:40:59.0924 (UTC)
FILETIME=[451FDD40:01C91E21]
X-purgate: clean
X-purgate: This mail is considered clean
X-purgate-type: clean
X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net
X-purgate-ID: 151667::080924104100-728D1BB0-D582DF52/0-0/0-15
X-purgate-size: 7447/0
Cc: sip at ietf.org
Subject: Re: [Sip] Pub request for draft-ietf-sip-dtls-srtp-framework-03
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
No smiley in the question, so: The media plane is just the set of all media paths. Shown as the line at the bottom of the SIP trapezoid, e.g. in Figure 1 in draft-ietf-sip-dtls-srtp-framework-03.txt .
The media plane security solution to be specified by 3GPP will comprise cryptographic procotocols for securing the media (like SRTP) as well as a key management protocol (or more than one). Because of the middlebox considerations 3GPP currently focusses on key management protocols that do not use the media path.
A 3GPP technical report on this (work in progress) can be found e found at
http://www.3gpp.org/ftp/Specs/archive/33_series/33.828/33828-081.zip
Peter
> -----Ursprüngliche Nachricht-----
> Von: ext Henry Sinnreich [mailto:hsinnrei at adobe.com]
> Gesendet: Dienstag, 23. September 2008 23:13
> An: Schneider, Peter (NSN - DE/Munich); ext Dean Willis;
> Tschofenig, Hannes (NSN - FI/Espoo); Jason Fischl; ekr at rtfm.com
> Cc: Cullen Jennings; sip at ietf.org
> Betreff: Re: [Sip] Pub request for
> draft-ietf-sip-dtls-srtp-framework-03
>
> > as described now suitable as a media plane security
> solution for the 3GPP IMS?
>
> What is the media plane, its X and Y dimensions?
>
> Thanks, Henry
>
>
> On 9/23/08 9:28 AM, "Schneider, Peter (NSN - DE/Munich)"
> <peter.schneider at nsn.com> 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.
> >
> > Consequentlyat
http://www.3gpp.org/ftp/Specs/archive/33_series/33.828/33828-081.zip
Peter
> -----Ursprüngliche Nachricht-----
> Von: ext Henry Sinnreich [mailto:hsinnrei at adobe.com]
> Gesendet: Dienstag, 23. September 2008 23:13
> An: Schneider, Peter (NSN - DE/Munich); ext Dean Willis;
> Tschofenig, Hannes (NSN - FI/Espoo); Jason Fischl; ekr at rtfm.com
> Cc: Cullen Jennings; sip at ietf.org
> Betreff: Re: [Sip] Pub request for
> draft-ietf-sip-dtls-srtp-framework-03
>
> > as described now suitable as a media plane security
> solution for the 3GPP IMS?
>
> What is the media plane, its X and Y dimensions?
>
> Thanks, Henry
>
>
> On 9/23/08 9:28 AM, "Schneider, Peter (NSN - DE/Munich)"
> <peter.schneider at nsn.com> 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 lea, 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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] Im
> >> Auftrag von ext Dean Willis
> >> Gesendet: Dienstag, 23. September 2008 09:28
> >> An: iesg-secretary at ietf.org
> >> Cc: CULLEN JENNINGS; sip at ietf.org
> >> 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 sip-implementors at cs.columbia.edu for questions on current sip
> > Use sipping at ietf.org for new developments on the application of sip
>
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
st 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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] Im
> >> Auftrag von ext Dean Willis
> >> Gesendet: Dienstag, 23. September 2008 09:28
> >> An: iesg-secretary at ietf.org
> >> Cc: CULLEN JENNINGS; sip at ietf.org
> >> 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 sip-implementors at cs.columbia.edu for questions on current sip
> > Use sipping at ietf.org for new developments on the application of sip
>
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip