Subject: [dispatch] FW: Re: New I-D: draft-dawes-dispatch-mediasec-parameter-01

From: "Dawes, Peter, VF-Group" <[email-masked]>
Date: Tue, 15 Jun 2010 13:38:04 +0200

Hi,
I have submitted a revised draft on media plane security on the first
hop to include more background on motivation, add SDP to the examples,
and indicate that the entity on the edge of the network is a B2BUA not a
proxy. 

https://datatracker.ietf.org/doc/draft-dawes-dispatch-mediasec-parameter
/

I have copied the revised motivations clause below. 

Regards,
Peter

1.1.  Motivations

1.1.1.  Access Network Protection

   Some access technologies protect the data passed over them by
   default, for example many cellular wireless accesses, but some do
   not, for example WLAN.  For accesses with no protection, it is useful
   for the media controlled by SIP signalling to be protected by default
   because of vulnerability to eavesdropping.  It is currently possible
   for a UA to request protection of the media plane end-to-end by
   including the crypto attribute in SDP at session setup.  This does
   not guarantee protection however, because it relies on support of
   encryption by the called UA, or by another entity in the path taken
   by the media.  In some cases, the session will originate in an access
   that protects the media and terminate in one that does not, meaning
   that media is protected in all but some hops of its path.  In cases
   where the same provider supplies the user equipment and provides the
   IP access, the IP access technology that the UA will use is
   predictable and the media is vulnerable only as far as the core
   network.  In such cases, the user equipment it is possible to protect
   the media plane by encrypting at the UA and decrypting at the edge of
   the core network, and for the user agent that originates or
   terminates the session to expect the edge of the core network to be
   capable of encrypting and decrypting media.  This document describes
   this case of first-hop protection, which is typically provided by
   default to a user agent.  Both media and signalling must pass through
   the entity at the edge of the core network, which must therefore be a
   back-to-back user agent (B2BUA).

   End to access edge media protection described in this document is not
   a substitute for end-to-end media protection.  A user agent requests
   end-to-access-edge media protection by including a "a=3ge2ae" SDP
   attribute at session setup.  If this attribute is not included, then

Dawes                   Expires December 17, 2010               [Page 4]

Internet-Draft          Media Security Parameter               June 2010

   end-to-end protection is expected by the user agent and protection
   MUST NOT fall back to end-to-access-edge protection.

1.1.2.  DTLS-SRTP

   DTLS-SRTP is described in RFC 5763 [8], which shows the basic message
   flow in Figure 1.  The DTLS handshake takes place when Bob receives
   the initial INVITE request.  Alice uses the source IP address of the
   DTLS "hello" message (3) as the destination address for "hello"
   message (4) even though Bob does not provide a contact address until
   the 200 OK message (8).

                           Alice            Proxies             Bob
                |(1) INVITE       |                  |
                |---------------->|                  |
                |                 |(2) INVITE        |
                |                 |----------------->|
                |                 |(3) hello         |
                |<-----------------------------------|
                |(4) hello        |                  |
                |----------------------------------->|
                |                 |(5) finished      |
                |<-----------------------------------|
                |                 |(6) media         |
                |<-----------------------------------|
                |(7) finished     |                  |
                |----------------------------------->|
                |                 |(8)  200 OK       |
                |                 |<-----------------|
                |(9)  200 OK      |                  |
                |<----------------|                  |
                |                 |(10) media        |
                |<---------------------------------->|
                |(11) ACK         |                  |
                |----------------------------------->|

      Message (1):  INVITE Alice -> Proxy

            Figure 1: Security capability exchange message flow

   In some networks, media packets are blocked between Alice and Bob
   until Alice receives the 200 (OK) message 9, which blocks the DTLS
   handshake until after Alice receives message (9).  Media will not be
   successfully exchanged unless the DTLS handshake is re-attempted
   after message (9) 200 OK.  Even if the handshake is re-attempted, the

Dawes                   Expires December 17, 2010               [Page 5]

Internet-Draft          Media Security Parameter               June 2010

   media will be clipped until the handshake is complete.

1.1.3.  SDP Capability Negotiation

   SDP capability negotiation is described in
   draft-ietf-mmusic-sdp-capability-negotiation [9] and describes
   sending multiple potential SDP combinations as an offer, such that a
   user agent can offer a choice of media security alternatives in the
   body of an initial INVITE request.  However, the caller UA has no
   prior knowledge of whether media plane security setup will succeed
   and in many cases it will fail or cause a lengthy delay while the
   user agent re-attempts, for example using a different IP access
   network.

1.1.4.  Motivations for RFC 3329

   RFC3329 describes why security is needed to protect SIP signalling
   from man-in-the-middle attacks, and to accomodate the expected wide
   variation in security mechanism support by SIP entities.  The media
   plane requires similar protection and exchange of security
   capabilities, for example to prevent eavesdropping in environments
   such as public wireless access networks that have no inherent
   security.  For the media plane security mechanism defined by this
   document, the cryptographic key is in plain text in SDP, therefore
   signalling SHOULD be protected e.g. using the security mechanism
   negotiation described by RFC 3329 [1]