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

From: "Dawes, Peter, VF-Group" <[email-masked]>
Date: Thu, 29 Apr 2010 17:21:17 +0200

Hi Paul, Keith,
Thanks for checking the draft. The encryption/decryption of the media
happens at a security gateway controlled by the first-hop proxy, so the
first-hop proxy passes the cryptographic key to this gateway. The
first-hop proxy does not terminate a SIP dialog and initiate a new one,
and I took the term "first-hop proxy" from RFC 3329 which negotiates
security for SIP signalling, so I'm not sure that B2BUA is the correct
term. I agree that this draft differs from RFC 3329 as it involves a
security gateway for the media, and I agree that the gateway needs to be
described in the draft. I also agree that SDP is relevant, so I will add
examples. 

Regards,
Peter

>> So I haven't been able to discern if this is just a matter of the 

>> first hop from the client enforcing a requirement that media security

>> be used between the UAC and UAS, or if there is some expectation that

>> the proxy will in fact control the receipt and encryption/decryption 

>> of the media.

>> That might have been clearer if the examples showed the SDP.

Message: 6

Date: Wed, 28 Apr 2010 13:26:19 -0400

From: Paul Kyzivat <[email-masked]>

Subject: Re: [dispatch] New I-D:

draft-dawes-dispatch-mediasec-parameter-01

To: "DRAGE, Keith (Keith)" <[email-masked]>

Cc: "[email-masked]" <[email-masked]>, "Dawes, Peter, VF-Group"

<[email-masked]>

Message-ID: <[email-masked]>

Content-Type: text/plain; charset=ISO-8859-1; format=flowed

DRAGE, Keith (Keith) wrote:

> The underlying way this works is described in:

> http://www.3gpp.org/ftp/Specs/html-info/33328.htm
<http://www.3gpp.org/ftp/Specs/html-info/33328.htm> 

> Search for "a2ae" for the relevant bits of text.

> The first hop device is in fact a B2BUA with media, where it needs to
implement these procedures. 

This is the key thing I was suspecting.

If it needs to be a B2BUA for this to work, then talking about it as a
proxy is inappropriate.

Thanks,

Paul

> The general use case for these procedures would seem to be where you
have an access technology that is not secure in itself, but needs some
level of security therefore provided. So WLAN uses accessing 3G would
use it, but 3G users would not, because the underlying bearers are
already security protected to an extent.

> I'll leave Peter to discuss how much more introductory material should
be in the document, but this at least will hopefully help you understand
what is happening.

> regards

> Keith

>> -----Original Message-----

>> From: [email-masked]

>> [mailto:[email-masked] <mailto:[email-masked]>
] On Behalf Of Paul Kyzivat

>> Sent: Wednesday, April 28, 2010 2:30 PM

>> To: Dawes, Peter, VF-Group

>> Cc: [email-masked]

>> Subject: Re: [dispatch] New I-D: 

>> draft-dawes-dispatch-mediasec-parameter-01

>> Peter - a question:

>> Dawes, Peter, VF-Group wrote:

>>> Hello All,

>>> An updated draft is available on the topic of providing

>> security for

>>> the media plane between a SIP client and its first-hop proxy

>> (http://www.ietf.org/id/draft-dawes-dispatch-mediasec-paramete
<http://www.ietf.org/id/draft-dawes-dispatch-mediasec-paramete> 

>> r-01.txt).

>>> This draft defines a "mediasec" header field parameter and

>> a "mediasec"

>>> option tag to extend RFC 3329 "Security Mechanism Agreement for the 

>>> Session Initiation Protocol (SIP)" to apply to the media plane.

>> I am confused about the concept of "security for the media plane 

>> between a SIP client and its first-hop proxy".

>> A proxy has no involvement with media. I read through the draft to 

>> understand better, but didn't gain enlightenment there. In fact I 

>> found no mention of proxies at all. However I did find that the 

>> mechanism only applies in cases where there is a single Via header, 

>> which means the server must be one hop removed from the client.

>> So I haven't been able to discern if this is just a matter of the 

>> first hop from the client enforcing a requirement that media security

>> be used between the UAC and UAS, or if there is some expectation that

>> the proxy will in fact control the receipt and encryption/decryption 

>> of the media.

>> That might have been clearer if the examples showed the SDP.

>> Thanks,

>> Paul

>> _______________________________________________

>> dispatch mailing list

>> [email-masked]

>> https://www.ietf.org/mailman/listinfo/dispatch
<https://www.ietf.org/mailman/listinfo/dispatch> 

------------------------------

_______________________________________________

dispatch mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/dispatch
<https://www.ietf.org/mailman/listinfo/dispatch> 

End of dispatch Digest, Vol 13, Issue 23

****************************************

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Apr 2010 11:37:16 -0400

Peter,

> first-hop proxy does not terminate a SIP dialog and initiate a new one,

Does this "first-hop proxy" change the SDP?

That is the key. If it does, then it is not properly a proxy.
If it does not, then no issue.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Apr 2010 12:35:27 -0400

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dawes, Peter, VF-Group
> Sent: Thursday, April 29, 2010 11:21 AM
> 
> Hi Paul, Keith,

Technically it *is* a B2BUA (and an SBC is a B2BUA).  A "Proxy" never modifies SDP, by definition.  Likewise if the "Proxy" does transcoding, or media relay, or IPv6-IPv6 media interworking, etc. - it's a B2BUA, not a "Proxy".  The sec-agree stuff could be done in a real Proxy, because it affected signaling layer only (even then it's debatable, since it removes the option-tag from the Require header).

It'll confuse people to call this next-hop thing a Proxy - we just need to call a spade a spade.  So to be consistent with standard terminology the draft should just call it a B2BUA.

-hadriel