Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field

From: "Elwell, John" <[email-masked]>
Date: Wed, 01 Apr 2009 11:33:44 +0100

I would like service providers to chip in here. Suppose I use service
providers to establish a call between two enterprises. Enterprise A uses
SP A for all external traffic, and enterprise B uses SP B for all
external traffic. We then have a path:

	Enterprise A -> SP A -> SP B -> Enterprise B.

What I would like to know is whether SP A and/or SP B would have reason
to change the SDP (also other aspects of the SIP request, but just stick
to SDP for now). If they need to change it, then what drives this need
to change the SDP: NAT traversal, topology hiding, media steering, ....?

If SPs think they have no reason to change SDP in such situations, then
this part of the problem is solved. However, I very much doubt that is
the case.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Cullen Jennings
> Sent: 01 April 2009 02:24
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]; Francois Audet
> Subject: Re: [Sip] francois' comments and why RFC4474 not 
> used in the field
> 
> 
> In all of section 8, the only reason I find of why things are 
> changed is
> 
> "For media steering purposes, B2BUAs in intermediate domains need to  
> modify the IP address c-lines and the port in m-lines."
> Even this one line leaves me confused about what intermediate 
> domains  
> are in the deployment cases where this happens and if we are talking  
> about email style address or e.164 style addresses. What an 
> example is  
> of a deployment where things like this happen and why the 
> middle (not  
> the end domains) do the media steering. When I ask this of example  
> people give me, if often turns out what is really wanted is 
> not media  
> steering but the middle to be able to hide the fact that they 
> actually  
> delivered the call to a third provider for PSTN termination.
> 
> Pretend 4474 does not even exist for a minute. I don't think it is  
> unrealizable of me to ask what the problem is we are trying 
> to solve.  
> Saying 4474 is does not solve the problem may or may not be true but  
> we are unlikely to have a good conversation about about what 
> we should  
> do until we understand what we are trying to accomplish.
> 
> 
> On Mar 31, 2009, at 7:00 PM, DRAGE, Keith (Keith) wrote:
> 
> > Cullen wrote:
> >
> > > The thing I keep asking is can we make a list of reason why
> > > SDP and headers get changes and in what scenarios they do
> > > this. I think it will be hard to sort how to fix this without
> > > being clear what needs to be fixed.
> > >
> >
> > Isn't that the function of the text that was placed in section 8 of
> >
> > 
> http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03
> >
> > If it is not, then what do you think is missing.
> >
> > regards
> >
> > Keith
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of Cullen Jennings
> > > Sent: Tuesday, March 31, 2009 11:32 PM
> > > To: Jiri Kuthan
> > > Cc: [email-masked]; Francois Audet
> > > Subject: Re: [Sip] francois' comments and why RFC4474 not
> > > used in the field
> > >
> > >
> > > On Mar 28, 2009, at 2:02 PM, Jiri Kuthan wrote:
> > >
> > > >
> > > > I'm worried this is only a wishful thinking. While
> > > perfectly logical,
> > > > still even in such constrained setups some bizzar ALGs do in my
> > > > experience appear in the middle, change SDP and make thus
> > > the identity
> > > > worthless.
> > >
> > > The thing I keep asking is can we make a list of reason why
> > > SDP and headers get changes and in what scenarios they do
> > > this. I think it will be hard to sort how to fix this without
> > > being clear what needs to be fixed.
> > >
> > > For example, one of the things we might want to say is
> > > something like:
> > > the Phone is behind a NAT and connects to it's proxy /
> > > registrar for its' domain. That proxy/b2bua whatever mucks
> > > with IP/ports in the SDP for NAT traversal. Then we could ask
> > > if 4474 is broken in this case or not and what might be a
> > > good way of solving the problem of having UAs behind NATs.
> > >
> > > Cullen <in my individual contributor role>
> > >
> > > _______________________________________________
> > > Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol Use
> > > [email-masked] for questions on current sip
> > > Use [email-masked] 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 [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Wed, 01 Apr 2009 14:09:11 +0000

John,

In my experience, service providers (such as the one I work for)
sometimes change the SDP in situations like this, and sometimes don't.
It depends on whether the service providers' VoIP infrastructure is in
the public Internet address space, or a private address space (e.g.,
MPLS/BGP -based VPN).  Use of the latter configuration requires NAT and
SIP ALG functionality "at the edge".  In the diagram below there is an
"edge" everywhere you draw an arrow.  Typically the devices that
implement the NAT and SIP ALG functions do other things, like topology
hiding and steering the media to a device that will then monitor
("police") its arrival rate.

Alternatively, if the SP's infrastructure is in the public address
space, you typically don't see NAT / SIP ALG or topology hiding or media
steering.  You may (often do) still see "border devices" doing things
like traffic aggregation and policy based routing.

In either case, it's not uncommon that the border elements modify other
aspects of the SIP signaling for reasons of interoperability.  For
example it's sometimes [believed to be] necessary to modify response
codes due to differing implementations - e.g., to break an
infinite-retry loop.

tim

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 1 Apr 2009 16:23:27 +0200

In that scenario you have probably passed 6 SBC's :-)

    Enterprise A (SBC1) -> (SBC2) SP A (SBC3)->(SBC4) SP B (SBC5)-> (SBC6)
Enterprise B.

/Hans Erik van Elburg

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 1 Apr 2009 09:06:07 -0600

> this part of the problem is solved. However, I very much doubt that is

I think this is exactly the right sort of question to be asking (and  
we all agree they have reasons they are currently changing the SDP,  
what we need to get at is why).

I think we also need to know about situations like

           UA A -> SP A -> SP B -> UA B.
          Enterprise A -> SP A -> SP B -> SP C -> Enterprise B.

And reasons SP B would change it. We also need to understand for each  
use case if it is an E.164 number or email style name. We need to deal  
with the cases where one of both of the ends is the PSTN not an  
enterprise. We also need to understand the trust relationships between  
the various entities. By that I mean things like "Enterprise B is  
willing to trust SP C (who it pays) will not misroute it calls". Or  
that UA A trust SP A not to give A's AOR to someone else.

Then we need to go through use case and figure out which requirements  
derive the modification of key headers or bodies and which use cases  
happen in real deployments and which ones are purely hypothetical.  
They type of reasons for modification of headers/SDP that have been  
raised in past include things like topology hiding, media steering,  
nat traversal, and protocol repair.

Next we need to work on what the problem is. This includes things like  
"I want to know who's phone I will be talking to if I answer this  
ringing call so I can decide if I answer the call" or "I want to know  
who's phone I am talking to at the other end so I can decide what I  
might say", or "I want to be able to reject all calls at 2am that are  
not from a phone that is listed in my personal address book". I'm not  
proposing any of these are the right problem statement - I'm just  
trying to give examples of they type of statement that if we agreed on  
it would help us make progress.

We have proven over and ever again that without understanding what  
problem we are trying to fix, we don't get very far. Saying that the  
problem is "4474 does not work", does not help in the slightest. That  
may or may not be true but it is not the problem - it's a statement  
about if 4474 as a technology helps solve some unspecified problem or  
not.

I have been advocating for years now that the discussion about if 4474  
works for problem X or not is not going to get far without some  
agreement on what the various values of X are.

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 1 Apr 2009 10:12:24 -0500

This is the wrong question to ask.

If an Enteprise does NOT want a service provider to "muck around" with
it's media, it will pick a service provider that does not, or use
4474 to ensure it doesn't happen.

I would expect that smaller Enteprises (SMB/SME) might be 
comfortable with a service provider that "adds value" by 
mucking around with its media. Presumably for NAT/Firewall traversal
reasons, willingness to be tapped into by the authorities, etc. 

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Wednesday, April 01, 2009 03:34
> To: Cullen Jennings; DRAGE, Keith (Keith)
> Cc: [email-masked]; Audet, Francois (SC100:3055)
> Subject: RE: [Sip] francois' comments and why RFC4474 not 
> used in the field
> 
> I would like service providers to chip in here. Suppose I use 
> service providers to establish a call between two 
> enterprises. Enterprise A uses SP A for all external traffic, 
> and enterprise B uses SP B for all external traffic. We then 
> have a path:
> 
> What I would like to know is whether SP A and/or SP B would 
> have reason to change the SDP (also other aspects of the SIP 
> request, but just stick to SDP for now). If they need to 
> change it, then what drives this need to change the SDP: NAT 
> traversal, topology hiding, media steering, ....?
> 
> If SPs think they have no reason to change SDP in such 
> situations, then this part of the problem is solved. However, 
> I very much doubt that is the case.
> 
> John
> 
> 
> Behalf Of 
> > Cullen Jennings
> used in the 
> > field
> > In all of section 8, the only reason I find of why things 
> are changed 
> > is
> > 
> > Even this one line leaves me confused about what 
> intermediate domains 
> > steering but the middle to be able to hide the fact that 
> they actually 
> > we are unlikely to have a good conversation about about 
> what we should 
> > > > The thing I keep asking is can we make a list of reason why SDP 
> > > > and headers get changes and in what scenarios they do this. I 
> > > > think it will be hard to sort how to fix this without 
> being clear 
> > > > what needs to be fixed.
> > > >
> > >
> > > > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > > > Of Cullen Jennings
> > > > Subject: Re: [Sip] francois' comments and why RFC4474 
> not used in 
> > > > the field
> > > >
> > > >
> > > > The thing I keep asking is can we make a list of reason why SDP 
> > > > and headers get changes and in what scenarios they do this. I 
> > > > think it will be hard to sort how to fix this without 
> being clear 
> > > > what needs to be fixed.
> > > >
> something 
> > > > like:
> registrar 
> > > > for its' domain. That proxy/b2bua whatever mucks with 
> IP/ports in 
> > > > the SDP for NAT traversal. Then we could ask if 4474 is 
> broken in 
> > > > this case or not and what might be a good way of solving the 
> > > > problem of having UAs behind NATs.
> > > >
> > > > [email-masked] for questions on 
> current sip Use 
> > > > [email-masked] for new developments on the
> > application of sip
> > > >
> > 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 1 Apr 2009 09:30:49 -0600

On Apr 1, 2009, at 12:52 AM, Dean Willis wrote:

>
> On Mar 31, 2009, at 5:31 PM, Cullen Jennings wrote:
>
>>
>>> I'm worried this is only a wishful thinking. While perfectly
>>> logical, still even in such constrained setups some bizzar
>>> ALGs do in my experience appear in the middle, change SDP
>>> and make thus the identity worthless.
>>
>> The thing I keep asking is can we make a list of reason why SDP and  
>> headers get changes and in what scenarios they do this. I think it  
>> will be hard to sort how to fix this without being clear what needs  
>> to be fixed.
>>
>> For example, one of the things we might want to say is something  
>> like: the Phone is behind a NAT and connects to it's proxy /  
>> registrar for its' domain. That proxy/b2bua whatever mucks with IP/ 
>> ports in the SDP for NAT traversal. Then we could ask if 4474 is  
>> broken in this case or not and what might be a good way of solving  
>> the problem of having UAs behind NATs.
>>
>
> You seem to be trying to construct an argument for "why 4474 isn't  
> broken" based on being able to transform every use case where RFC  
> 4474 breaks to one where it doesn't, generally by mandating a  
> different approach to solving problems (TURN vs, SDP fixup, for  
> example). You seem to expect this to prove that RFC 4474 is fine as- 
> is, needing no modification to its A/M signing.

No Dean. I am trying to get to what is the problem - and what I see  
happening is several people trying to transform that into Jon and  
Cullen are blocking work in this space which is not at all true - I  
would love to see some progress in this space.

>
>
> It might be useful to counter this with "If RFC 4474 isn't broken,  
> why isn't it being deployed?"

It's not needed in the bulk of todays deployments. Deployments using  
email stye addresses are directly connecting often with mutual TLS or  
an equivalently bound VPN. When enterprise B gets a call from [email-masked] 
  and it came over a TLS connection that had a certificate of a.com,  
well you get something that meets B's authorization needs with just  
that. For deployments using E.164 style addresses - they are pretty  
much all capable of connecting in and out of the PSTN and there is no  
interest in a security properties greater than what PSTN provides as  
that is acceptable for most these users. This can easily be  
accomplished with PAI and a transitive trust model. In fact, many of  
these deployments have SP A talking to SP B talking to SP C and B  
explicitly wants to hide that they used SP C instead of terminating  
the call themselves. B needs to make it look like to A like B  
terminated the call into the PSTN vs handing it to C. These sort of  
deployments require B to look to A like the end not the middle.

> I expect that the answer is "because users currently expect to  
> correct their topological issues using SBCs instead of the tools  
> that work with 4474. You might not think they have legitimate  
> reasons for doing it this way, but the fact remains -- that's how  
> they do it.

You expect it might be one thing - fair enough, other disagree. What I  
am suggesting will be the best way to make progress is to find out  
what they do and what needs caused them to do it. Sure, for any  
problem, there will be multiple ways to skin the cat. You are accusing  
me of saying that the only way people are allowed to skin the cat is  
using a potato peeler and that most people probably will not use a  
potato peeler for cats no matter what I want. I am not in the  
slightest telling people they have to use a potato peeler - I'm  
arguing that until we have some common ground on if we are trying to  
peel a cat or potato or both, we are unlikely to make progress on the  
best tool(s) for the job.

> Technically correct or not, ordering this to flow out is likely to  
> give you wet feet.
>
> --
> Dean
>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Wed, 01 Apr 2009 15:54:27 +0000

Cullen,

These are "hotly debated" issues in the service provider community.  I
would hasten to say that nobody has appointed me to speak on that
community's behalf.  So the following views are my own.

You stated:
 
> And reasons SP B would change it.

I think the rationale for SP B changing the SDP is the same as SP A and
C.  It comes down to addressing.  If their VoIP infrastructure is in a
private address space, as it frequently is, then they need NAT and SIP
ALG functionality at the edges of that space.  Other issues such as
topology hiding and media steering, are IMHO secondary in this debate.

More fundamentally I wonder how a path through SP B would ever be
constructed (assuming the arrows above refer to SIP flows).  For sure
you can do this with "policy routing" in SBCs, but using IETF preferred
routing mechanisms (e.g., ENUM, RFC-3263) it's not clear to me what
would motivate such routing.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 1 Apr 2009 10:17:50 -0700

> Behalf Of Hans Erik van Elburg
> Sent: Wednesday, April 01, 2009 7:23 AM
> To: Elwell, John
> Cc: Cullen Jennings; [email-masked]; Francois Audet; DRAGE,Keith (Keith)
>     Enterprise A (SBC1) -> (SBC2) SP A (SBC3)->(SBC4) SP B 
> (SBC5)-> (SBC6) Enterprise B.

And I doubt that every VoIP SP will be meshed with every other VoIP SP.  So in
many situations there will be a transit SP or two along the path.  The PSTN
has transit service providers (my local phone company is not directly
connected with the phone company in Syria or India), and the Internet has
transit service providers (some little ISP in Wyoming is not directly
connected with a little ISP in Switzerland).

-d

> /Hans Erik van Elburg
> 
> 
> 
> On Wed, Apr 1, 2009 at 12:33 PM, Elwell, John 
> <[email-masked]> wrote:
> 
> 
> situations, then
> [mailto:[email-masked]] On
> 	> > > Sip mailing list  
> https://www.ietf.org/mailman/listinfo/sip
> current sip

---

From: Dean Willis <[email-masked]>
Date: Wed, 1 Apr 2009 12:36:22 -0500

> ("police") its arrival rate.

One might argue that we know how to do NAT without ALG -- we use ICE  
to discover candidates for the offer/answer, and the media finds the  
path that works using STUN probes.

Could we use ICE to get to the steering points? Do we really need  
them, or is this just a brute-force way to solve a problem to which  
other tools should have been applied?

Topology-hiding is another question. Does it benefit the Internet  
architecture? Do we need to warp our protocols to allow it?

> like traffic aggregation and policy based routing.

Do we need SDP editing to allow these functions, or is there a cleaner  
way to do it?

> codes due to differing implementations - e.g., to break an

Do such modifications break RFC 4474?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 1 Apr 2009 12:46:45 -0500

> connected with a little ISP in Switzerland).

But the transit ISP should be routing the packets using their source  
and destination IP addresses, not mucking about in the application  
protocol. If some backbone ISP started putting in transparent HTTP  
proxies that diverted Web traffic to alternate sites, we'd have a  
"peasants with torches" scenario.

Same for most of the media-steering cases: The traffic is IP. Route it  
like IP traffic and stop pretending to be a circuit switched phone!

Doing application-sensitive packet routing is a direct path to chaos  
and unmanageable operational complexity.

Or maybe we should have just defined SIP-over-MPLS and left out the  
whole IP middle layer?

--
Dean

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 1 Apr 2009 11:00:19 -0700

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Wednesday, April 01, 2009 10:47 AM
> To: Dan Wing
> Cc: 'Hans Erik van Elburg'; 'Elwell, John'; 'Cullen 
> Jennings'; [email-masked]; 'Francois Audet'; 'DRAGE, Keith (Keith)'
> > And I doubt that every VoIP SP will be meshed with every 
> other VoIP  
> > SP.  So in
> protocol.

The transit SIP provider has every interest in hiding the IP addresses
of their own equipment and of the actual peers.  Otherwise, the peers
may make their own business agreement and circumvent the 'service'
being provided by the transit SIP provider -- or so the argument 
goes.

> If some backbone ISP started putting in transparent HTTP  

Using that analogy, if we were using RFC4474 with HTTPS we would
all have to trust our service providers (Comcast, etc.) to reliably
deliver our credit card and banking information to transit providers
and finally to our bank or catalog ordering company.

> Or maybe we should have just defined SIP-over-MPLS and left out the  

Acme Packet supports routing over MPLS networks.

-d

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 01 Apr 2009 14:38:11 -0400

> being provided by the transit SIP provider -- or so the argument 

If the peers can circumvent the SP and make their own business 
agreement, then perhaps the SP wasn't actually providing a service.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 1 Apr 2009 14:38:42 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
> Willis
> Sent: Wednesday, April 01, 2009 1:47 PM
> 

That's not analogous and you know it, I think.  We're not talking about a transparent inline IP-layer ISP mucking about in the application layer.  You're setting the SIP request URI host portion to your local provider, not the far-end (because you almost never know the far-end domain, and even if you did they won't accept your request directly).  Your SIP request really does almost always reach the local provider identified by that URI domain directly first.  Being authoritative for that domain, they then route your request to another domain, and so on, to reach an entity ultimately identified by a phone number not a hostname.  For another, you know and I know that web-based communication is not like phone communication.  In many ways SIP is much closer to IM or Email than HTTP, except it sometimes also costs money.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 1 Apr 2009 14:38:43 -0400

> Sent: Wednesday, April 01, 2009 1:36 PM
> To: Dwight, Timothy M (Tim)
>

ICE can't find such candidates in some cases, as I've stated before on this mailing list.  The problem is the candidates need to change based on where the call gets routed to.  Not to mention there may never be a single publicly reachable IP used in the media path.

> architecture? Do we need to warp our protocols to allow it?

The question may be more: do we need to make our protocols disallow it?

> Do we need SDP editing to allow these functions, or is there a cleaner

Define "cleaner".  Do you mean simpler, or do you mean more architecturally pure from the IAB's perspective?  The two are probably mutually exclusive.  :)

> Do such modifications break RFC 4474?

Yes, and they've been documented and discussed before, ad nauseam.  Virtually every piece of the message signed by 4474 is mucked with by some device or other, with the exception of the Date header.

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 1 Apr 2009 21:15:01 +0200

>Yes, and they've been documented and discussed before, ad nauseam.
Virtually every piece of the message signed by 4474 
>is mucked with by some device or other, with the exception of the Date
header.

Actually, some SPs don't allow people to make calls from the future, so
if someone is using a future Date header value there may be an SBC which
modifies that also ;)

Regards,

Christer

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 1 Apr 2009 13:14:40 -0700

> agreement, then perhaps the SP wasn't actually providing a service.

There continue to be transit IP providers even though the Internet has been
around for decades, and there continue to be transit PSTN providers even
though the PSTN has been around for generations.

We need an identity architecture that acknowledges transit and works with
transit.

-d

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Wed, 01 Apr 2009 21:40:29 +0000

Dean,

Hadriel has answered most of your questions.  On this point:

> Do we need SDP editing to allow these functions, or is there 
> a cleaner way to do it?

Sorry I wasn't more clear.  These functions don't involve SDP editing.
Traffic aggregation (by which I mean to refer to aggregation of SIP
signaling traffic) is usually done with ROUTE headers or use of the
'maddr' URI parameter, or (most often) through re-targetting in the
border device.  Policy routing is some mechanism internal to the border
device, that it uses to determine how to modify and to where to forward,
the SIP message.

tim

---

From: Dean Willis <[email-masked]>
Date: Thu, 2 Apr 2009 00:46:39 -0500

On Apr 1, 2009, at 1:38 PM, Paul Kyzivat wrote:

>>> But the transit ISP should be routing the packets using their  
>>> source  and destination IP addresses, not mucking about in the  
>>> application  protocol.

And they're afraid the other folks will find out? Hang 'em from the  
yardarm, Captain Bligh. Those fellows are pirates!

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 2 Apr 2009 00:48:17 -0500

On Apr 1, 2009, at 1:38 PM, Hadriel Kaplan wrote:

> That's not analogous and you know it, I think.  We're not talking  
> about a transparent inline IP-layer ISP mucking about in the  
> application layer.

> You're setting the SIP request URI host portion to your local  
> provider, not the far-end (because you almost never know the far-end  
> domain, and even if you did they won't accept your request  
> directly).  Your SIP request really does almost always reach the  
> local provider identified by that URI domain directly first.  Being  
> authoritative for that domain, they then route your request to  
> another domain, and so on, to reach an entity ultimately identified  
> by a phone number not a hostname.  For another, you know and I know  
> that web-based communication is not like phone communication.  In  
> many ways SIP is much closer to IM or Email than HTTP, except it  
> sometimes also costs money.

Dude! This is the INTERNET engineering task force. You want private  
circuit switched networks, see the ITU.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 2 Apr 2009 00:52:55 -0500

> though the PSTN has been around for generations.

Remember, I'm practicing at challenging "the opposition" to help you  
clean up your argument, so don't take this the wrong way . . .

Transit IP providers don't require changing the core protocols so they  
can preserve their business models. I'm hesitant to potentially  
cripple a security mechanism in order to preserve the business model  
of  transit PSTN providers.

Seriously: You want the protocol to change, you have to have a reason  
that makes sense in the context of the Internet. Crazy stuff that  
people are doing in private networks to justify their financial  
exchange doesn't qualify as a reason to change accepted Internet  
architecture.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 2 Apr 2009 00:57:36 -0500

> device, that it uses to determine how to modify and to where to  

Okay. . .

The debate here has been over finding ways to change RFC 474 and/or  
DTLS/SRTP so that the media key fingerprint is preserved, enabling the  
full security of DTLS/SRTP.  Since RFC 4474 signs "the whole SDP", any  
edits done to SDP by a middlebox break the RFC 4474 signature, thereby  
breaking the media key fingerprint protection of RFC 4474 (and thereby  
allowing a MITM on the media). If traffic aggregation and policy based  
routing don't require editing SDP in a proxy, then they don't break  
RFC 4474, and we don't have a problem.

Except we MUST have a problem, because  several folks keep saying we do.

So Cullen et. al. have been pushing us to nail down exactly what the  
problem is (and saying RFC 4474 is broken by SBCs is not an answer; it  
is a symptom).

So what seems to be the problem?

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 2 Apr 2009 07:57:56 +0200

>Seriously: You want the protocol to change, you have to have a reason
that makes sense in the context of the Internet. 
>Crazy stuff that people are doing in private networks to justify their
financial exchange doesn't qualify as a reason to 
>change accepted Internet architecture.

You could say that, but then you will end up where we are now: nobody
implements it :)

Regards,

Christer

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 02 Apr 2009 00:46:02 +0200

Dean Willis wrote:
> 
> On Mar 30, 2009, at 8:03 PM, Jiri Kuthan wrote:
>>
>> There is a timing aspect in favor of placing identity in signaling --
>> I would like to know whose call is ringing before I answer (if I do).
> 
> So, we need identity in signaling, we need identity in media, and we 
> need the two identity expressions to match.

I'm personally happy with having it only in signaling. Should there
be some in media too, I would be in favor of keeping those two
separate -- I'm not a particular fan of protocol dependencies.
That's just not about aesthetic expression -- once a protocol
begins to depend on other protocol, which one possibly does not
need, the cost and adaptability decreases. Single-purpose
things without dependencies have a much sounder chance of
deployment.

-jiri

> 
> That's what we get with RFC 4474 and DTLS/SRTP.
> 
> Why were we trying to change it to protect something else?
> 
> -- 
> Dean
>

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 02 Apr 2009 02:04:08 +0200

Cullen Jennings wrote:
> headers get changes and in what scenarios they do this. I think it will 
> be hard to sort how to fix this without being clear what needs to be fixed.

A short and  probably useless answer is NAT traversal,
transcoding and security (possibly illusive) in the scenarios I know.

The real trouble is that all sorts of SDP rewriting in the field are a rule,
and not rewriting is an exception. It is just so straight-forward to do
for the applications I know. It is widely deployed, and here to stay.
Relying on e2e SDP integrity by the way of TURN seems to me
an alibi at best, if not a hopeless try to reverse history.

Therefore I would choose the opposite way and try to learn what
are the pieces for which we have a compelling need for integrity.
(either way it may be hard to set a demarcation line though).

> 
> For example, one of the things we might want to say is something like: 
> the Phone is behind a NAT and connects to it's proxy / registrar for 
> its' domain. That proxy/b2bua whatever mucks with IP/ports in the SDP 
> for NAT traversal. Then we could ask if 4474 is broken in this case or 
> not and what might be a good way of solving the problem of having UAs 
> behind NATs.

That's the approach we have taken to deal with media relays for sake
of NAT traversal and turned out hard to deploy. I haver considered this
good enough for the particular rather simple scenarios I have been
interested in. SER calculates the message integrity protection for
outbound SDP. Even in such scenarios do ddly ALGs still appear between
signer and verifier, and are difficult to get out (even though they are
evil and shall  not be there in the first place, and are typically
controllable by the same company that controls the SIP server).

I'm therefore seeking protocols that do not require full SDP integrity
along any SIP  path segment. Only this way I think we can achieve
robustness against ALGs, SBCs, evil boxes, grand applications and
what have you, and not limit ourselves to a subset of scnarios
understood today.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 02 Apr 2009 02:27:15 +0200

Cullen Jennings wrote:
> 
> In all of section 8, the only reason I find of why things are changed is
> 

Hi Cullen,

really the trouble is that any list of SDP-mangling scenarios is too
short to capture it. as an example, I think ALGs are "illegitimate"
in that they do provide only an illusion of security and break
things at the same time. Still they do appear withouth what I would
call a "good reason" and break things.

Therefore I would prefer actually something more end-2-end-ish, in that
it is robust in the ends and makes minimum assumptions about network
being nice. That's not an argument for encouraging evil things in the
network. That's just an argument for being able to deal with them.

Does this appear silly? I'm somehow worried I haven't made my point
quite well.

> Even this one line leaves me confused about what intermediate domains 
> about email style address or e.164 style addresses. What an example is 
> of a deployment where things like this happen and why the middle (not 
> people give me, if often turns out what is really wanted is not media 
> steering but the middle to be able to hide the fact that they actually 

My viewpoint is that the case you mention is another element on
a list of scenarios, which we may or may not understand, may or may
not be reasonable, but very likely will appear in the field and
break SDP's integrity.

For my own purposes I would be happy if IP+port+codec were not protected
but I guess that others would fail elsewhere.

> unrealizable of me to ask what the problem is we are trying to solve.

I wish the callee to know caller's identity. (May or may not be what others
are interested in.) The notion of identity is a bit vague -- I'm not 
refering
DNA sort of identity. For mostof the purposes I know a good-enough notion
identity accomodates traceability and change-of-change. Traceability
gives me the ability to call back and fingerpoint ath the caller. 
Cost-of-change
is prohibitive for those who want to make identity worthless by changing
it oon a grand scale. Having DNS in URI IMO accomodates the cost-of-change
requirement, as long as we have certainity caller cannot easily use
someone else's DNS. A non-sip example to me is car license plates.

> Saying 4474 is does not solve the problem may or may not be true but we 
> are unlikely to have a good conversation about about what we should do 
> until we understand what we are trying to accomplish.

I think it does solve my identity problem, but breaks because of the SDP 
thing.

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 02 Apr 2009 02:28:32 +0200

Hi Cullen,

-jiri

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 2 Apr 2009 08:55:11 -0400

> Sent: Thursday, April 02, 2009 1:48 AM
> 

That's odd, I could have sworn the IETF defined MPLS-TE, VPLS, PWE3, BGP/MPLS L3VPNs, tunnel-mode IPsec, SOCKS, and TURN.  Has anyone notified the relevant WG's to notify them they don't belong in the IETF religious sect?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 2 Apr 2009 09:28:08 -0400

> Sent: Thursday, April 02, 2009 1:47 AM
>

I don't think they hide them to avoid circumvention - at least not in the general case.  I've heard that argument a few times, but not often.  Providers already know who the origination and termination providers are (they're identified in the NPAC/LERG/etc.), but they just can't reasonably peer direct with everyone.  There's a demand/need for transit providers mostly because phone calls cost money, are nationally regulated, users/law-enforcement expect traceability, and there's a need for identity (ironically).  

Anytime money is involved, for example, it means you need a business relationship to handle billing arrangements, and providers clearly can't scale to have a business relationship with every other provider/domain/Enterprise on the planet.  Heck, even in the PSTN right now, SMS messages between very large mobile providers in the same country go through a middleman, purely because the middleman acts as the arbiter for billing.

I'm not saying some transits don't fear circumvention - IP transits feared it too when BGP first came out and advertised AS paths - I'm just saying it's not the only, or even a primary, reason for SDP changing in transits.  There are really a lot of reasons the media gets steered through transit providers.  The first one is probably: because that's what is being billed/paid-for.  You yourself, Dean, have said many times that one shouldn't bill on signaling, but rather bill on media.  So providers sort of do that - they bill on the signaling, but they open/close gates on the media to enforce that billing.  Then of course they also like to measure the QoS of the media (and sometimes make call routing decisions based on it even), monitor that there actually is media and that the call didn't just mysteriously fail, etc.

If phone calls were free for everyone, had no regulation, etc., then I would expect transit providers to not steer media. (I would in fact expect no transit providers period, ultimately)  If there's no value in something, then there's nothing to protect/monitor/troubleshoot/hide/arbitrate/provide-service-for. 

-hadriel
p.s. and not all transits do change SDP, and some only change SDP in certain circumstances (like for transcoding).

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 02 Apr 2009 13:59:46 +0000

Dean, 

> So what seems to be the problem?

I think first of all that we're suffering from a long email thread that
has been snipped a few times, hence we've lost some of the context.

Previously I said there are 2 basic ways that VoIP interconnections are
designed:

  1) media pinned at each network border
  2) media not pinned at the borders

The above text refers to case #2.  If media is not pinned (by which I
mean "steered" to a specific point of network ingress), the things that
the border elements do don't seem to break RFC 4474.  I am happy to hear
that.

So the problem seems isolated to interconnect designs involving pinning
the media.  

And the question becomes, why do operators do that?  Again speaking only
based on my own experience, the rationale is related to the transit
service provided to the media.  If the media is going to be carried (and
in practice prioritized) by the transit operator, that operator will
generally want to measure and/or police its arrival rate.  Sometimes
this is per microflow, other times it is applied to the aggregate; that
depends on the SLA.  Either way, these (and L3 encapsulation and QoS
marking) are functions provided by the device to which the media is
"steered" by fiddling with the SDP.

I am (in general, operators are) aware that just because a transit
operator touches the signaling does not mean it needs to be or should be
in the media path.  But there are possible designs (e.g., a series of
private IP networks) where it may be viewed as desirable.  Equally,
there are designs (e.g., a group of operators sharing a common IP
network) where media pinning is unnecessary (*).  Ergo both design
approaches exist.

It may be tempting to wish this problem away by "outlawing" interconnect
designs involving pinning the media; but IMHO that would be wishful
thinking.

(*) this is a simplified argument.  In practice SDP manipulation may be
required
    even in the "multiple operators sharing a common IP network"
scenario; e.g.,
    to support Lawful Intercept.

Tim

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 02 Apr 2009 07:13:16 -0700

Hadriel,

>If phone calls were free for everyone, had no regulation, etc., then I would
expect transit providers to not steer media.
>(I would in fact expect no transit providers period, ultimately)

Fortunately this is already happening as you may know if you have to make
international voice calls using your own SIP box, Skype or any other.
You can also see this acknowledged in the trade press.

>If there's no value in something, then there's nothing to
protect/monitor/troubleshoot/hide/arbitrate/provide-service-for.
You have said it here in a nutshell IMO.

The Google Mlab tools are just the beginning so far to insure there are no
devices mucking with packets e2e.
http://www.measurementlab.net/measurement-lab-tools
The genie is out of the bottle and more tools will likely be made available
by other organizations to protect Internet users.

Henry

On 4/2/09 6:28 AM, "Hadriel Kaplan" <[email-masked]> wrote:

> I don't think they hide them to avoid circumvention - at least not in the
> general case.  I've heard that argument a few times, but not often.  Providers
> already know who the origination and termination providers are (they're
> identified in the NPAC/LERG/etc.), but they just can't reasonably peer direct
> with everyone.  There's a demand/need for transit providers mostly because
> phone calls cost money, are nationally regulated, users/law-enforcement expect
> traceability, and there's a need for identity (ironically).
> 
> Anytime money is involved, for example, it means you need a business
> relationship to handle billing arrangements, and providers clearly can't scale
> to have a business relationship with every other provider/domain/Enterprise on
> the planet.  Heck, even in the PSTN right now, SMS messages between very large
> mobile providers in the same country go through a middleman, purely because
> the middleman acts as the arbiter for billing.
> 
> I'm not saying some transits don't fear circumvention - IP transits feared it
> too when BGP first came out and advertised AS paths - I'm just saying it's not
> the only, or even a primary, reason for SDP changing in transits.  There are
> really a lot of reasons the media gets steered through transit providers.  The
> first one is probably: because that's what is being billed/paid-for.  You
> yourself, Dean, have said many times that one shouldn't bill on signaling, but
> rather bill on media.  So providers sort of do that - they bill on the
> signaling, but they open/close gates on the media to enforce that billing.
> Then of course they also like to measure the QoS of the media (and sometimes
> make call routing decisions based on it even), monitor that there actually is
> media and that the call didn't just mysteriously fail, etc.
> 
> If phone calls were free for everyone, had no regulation, etc., then I would
> expect transit providers to not steer media. (I would in fact expect no
> transit providers period, ultimately)  If there's no value in something, then
> there's nothing to
> protect/monitor/troubleshoot/hide/arbitrate/provide-service-for.
> 
> -hadriel

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 02 Apr 2009 07:35:50 -0700

Sorry for the error of not attributing the MLab Tools to the large
International community involved in this initiative.
http://www.measurementlab.net/who

The fact that most are from academia is a reminder who first built out the
global Internet.
Even more encouraging is the fact of having so many CS students cherish it
and most likely working to defend it.
No doubt, enlightened service providers are also comparing their diminishing
voice revenue with the growing revenue from Internet access, fixed and
mobile.

Yes, exactly

Henry

====================================

Hadriel,

Henry

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 2 Apr 2009 10:38:30 -0500

> So Cullen et. al. have been pushing us to nail down exactly 
> what the problem is (and saying RFC 4474 is broken by SBCs is 
> not an answer; it is a symptom).
> 

The problem is that people seem to prefer changing the SDP than
using TURN, because it is easier and more convenient.

And what draft-wing-sip-identity-media does is show how and 4474-like
mechanism that doesn't protect the IP address can be used in
conjunction with DTLS-SRTP, to provide an adequate level of security.

So, I'll repeat the question from a previous email: what's wrong with 
draft-wing-sip-identity-media???

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 2 Apr 2009 08:48:05 -0700

> exchange doesn't qualify as a reason to change accepted Internet  

Here is an Internet architecture with SIP transit service providers.  The
bubble in the middle is "The Internet", enterprises are on the left and the
four service providers are on the right:

Enterprise A ---- { -------- } --+
                  {          }    \
                  {          }     { SP-A }
                  {          }    /
                  {   +----- } --+
                  {   |      }
                  {   +----- } --+
                  {          }    \
                  {          }     { transit-A }
                  {          }    /
                  {   +----- } --+
                  {   |      }
                  {   +----- } --+
                  {          }    \
                  {          }     { transit-B }
                  {          }    /
                  {   +----- } --+
                  {   |      }
                  {   +----- } --+
                  {          }    \
                  {          }     { SP-B }
                  {          }    /
Enterprise B ---- { -------- } --+        

And it should be realized that call forwarding turns any SP into a transit
provider.

-d

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 02 Apr 2009 20:06:09 +0100

Cullen,

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 01 April 2009 16:06
> To: Elwell, John
> Cc: DRAGE, Keith (Keith); [email-masked]; Francois Audet
> > providers to establish a call between two enterprises. 
> Enterprise A  
> > uses
[JRE] Yes.

> that UA A trust SP A not to give A's AOR to someone else.
[JRE] Yes, but my contention has already been that I will trust SP A (my
local SP) to identify a user in SP A's domain, but not to identify a
user in some other domain - for that latter case I would trust that
other domain (subject to a valid certificate, of course). I would trust
an assertion from Amazon.com, but might not trust an assertion from
SP.net that I am talking (perhaps through other SPs) with Amazon.com.

I suppose in either case transitive trust is involved. In the one case
(by trusting Amazon.com) I am really trusting the CA to assert that it
is Amazon.com, whereas in the other case I am trusting my SP to assert
that it is Amazon.com. The web way of doing things is to trust a CA
rather than to trust an intermediary.

> nat traversal, and protocol repair.
[JRE] Some of this is already discussed in the e2e-identity-important
draft. People are adding further information about real deployments on
this thread.

> it would help us make progress.
[JRE] I thought a lot of this was covered in e2e-identity-important.
Maybe its not said in the right way.

> about if 4474 as a technology helps solve some unspecified 
[JRE]The e2e-identity-important draft does not just say "4474 does not
work" but looks at use cases, looks at what they are trying to achieve,
and also looks at things that get changed by intermediaries, thereby
limiting possible solutions.

> agreement on what the various values of X are.
[JRE] I know. But I can't seem to find a way of expressing X that works
for people.

Let's try this. Suppose I receive a call from Amazon.com. I want to know
that it is from Amazon.com, because my white list will accept calls from
Amazon.com and also, when Amazon.com is displayed, I am prepared to
interrupt whatever I am doing to answer a call from Amazon.com. I might
give an appropriate greeting and I might be prepared to divulge
sensitive information to the caller if I know it is Amazon.com. I might
even be interested to know the particular caller from Amazon.com, but
not necessarily. If I just see that the call is from my SP, or from some
other SP that happens to be in the call path, that means nothing to me.
My device can't do effective white list filtering, I can't do effective
filtering, I can't answer with an appropriate greeting, I can't know
whether it is safe to divulge sensitive information during the call.

Furthermore, it is not sufficient just to be told it is from Amazon.com.
I require authentication based on a trust anchor, which could a
well-known CA, or some other certificate I already have in my store by
some out-of-band means.

This is the problem I am trying to solve. It is also a problem that RFC
4474 is designed to solve, but depending on the number and behaviour of
intermediaries, very often RFC 4474 will not solve it.

John

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 02 Apr 2009 20:15:51 +0100

Hans Erik,
 
Yes, except that SBC1 and SBC6 might not matter if the authentication
and verification services are collocated with them.
 
John

________________________________

	From: Hans Erik van Elburg [mailto:[email-masked]] 
	Sent: 01 April 2009 15:23
	To: Elwell, John
	Cc: Cullen Jennings; DRAGE, Keith (Keith); [email-masked];
Francois Audet
	Subject: Re: [Sip] francois' comments and why RFC4474 not used
in the field

	
	/Hans Erik van Elburg

		I would like service providers to chip in here. Suppose
I use service
		providers to establish a call between two enterprises.
Enterprise A uses
		SP A for all external traffic, and enterprise B uses SP
B for all
		external traffic. We then have a path:

		What I would like to know is whether SP A and/or SP B
would have reason
		to change the SDP (also other aspects of the SIP
request, but just stick
		to SDP for now). If they need to change it, then what
drives this need
		to change the SDP: NAT traversal, topology hiding, media
steering, ....?
		
		If SPs think they have no reason to change SDP in such
situations, then
		this part of the problem is solved. However, I very much
doubt that is
		the case.
		
		John

		> Subject: Re: [Sip] francois' comments and why RFC4474
not
		> Even this one line leaves me confused about what
intermediate
current sip
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 [email-masked] for questions on
current sip
		Use [email-masked] for new developments on the
application of sip

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 2 Apr 2009 15:50:40 -0600

> (either way it may be hard to set a demarcation line though).

Sure, I'd be very happy to see some good work on that direction if  
people felt that would get us closer.

---

From: Dean Willis <[email-masked]>
Date: Thu, 2 Apr 2009 22:49:32 -0500

On Apr 1, 2009, at 5:46 PM, Jiri Kuthan wrote:

>> So, we need identity in signaling, we need identity in media, and  
>> we need the two identity expressions to match.
>

So you're okay with knowing who dialed you, but not knowing who you  
are actually talking to?

Personally, I want something that at least correlates the signaling  
and media streams.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 2 Apr 2009 22:55:26 -0500

On Apr 2, 2009, at 8:28 AM, Hadriel Kaplan wrote:

>
> p.s. and not all transits do change SDP, and some only change SDP in  
> certain circumstances (like for transcoding).
>

Well we certainly can't expect transcoding to be compatible with e2e  
crypto.

So are there any legitimate use cases for requiring that the protocol  
supports MITM rewriting of SDP?

Having a transit provider that, for unknown reasons changes SDP is  
still not an adequate justification.

Perhaps is lots of calls started failing because they endpoints detect  
that a MITM attack on their signaling/media has occurred, and did so  
in a way that makes that failure evident to the MITM, then we'd see  
fewer MITMs making that mistake.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 2 Apr 2009 22:59:26 -0500

>    to support Lawful Intercept.

The IETF has chosen not to  to design our protocols to enable lawful  
intercept, in large part because any design that enables lawful  
intercept also enables unlawful intercept, and one countries lawful  
intercept may be a another's espionage. See RFC 1984.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 2 Apr 2009 23:01:51 -0500

> draft-wing-sip-identity-media???

If I understand the argument, extending the d-w-s-i-m approach to non- 
DTLS media legitimizes the obfuscation of the one media identifier we  
do have -- the IP address. Some people seem to find this unacceptable.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 3 Apr 2009 00:40:59 -0400

> Sent: Thursday, April 02, 2009 11:55 PM
> 

Nope, and why I do not include that function as being compatible with it.  I do think some form of signaling caller-id may be useful in that case, but clearly media identity is not possible short of speaking in pig-latin.

> supports MITM rewriting of SDP?

We already gave you some.  But really the question can just be flipped around: is there a security property of the SDP's IP/port that you feel is important to protect, such that we can't allow it to be changed?  Do you feel an IP:port is an identity, or is somehow actually a secure indicator of anything?  I mean there's plenty of other important things in SIP we're not protecting with 4474 - maybe we should just sign the entire SIP message, just in case.  But we don't, because we know it wouldn't work in the real world, and because most of them have little security value to protect.

SDP is not "the user content", as a mime text attachment in a SIP MESSAGE or email would be.  It is not "the prized possession" from the user.  In particular the indicated IP:port to send IP packets to/from is not.  The IP is not an application nor user identity; and it is spoofable, interceptable, reputable, etc.  You yourself have argued about SIP's dependence on the IP:port in SDP being an architectural shortcoming, and here we are trying to make sure it's cryptographically dependent!  IPsec learned this the hard way when it had to encapsulate itself in UDP due to the pseudoheader and NATs, SIP learned it due to NAT's, a whole host of things may learn it in the v4/v6 transition if it happens (oh, did we mention that as another SDP re-writing case?).  

> fewer MITMs making that mistake.

If calls started failing because of 4474, I'm fairly sure it would be 4474 that would be turned off, not the SDP re-writers.  Because they're not an MITM attack on users or calls - it's a MITM attack on the IETF's principles.  But then again, there's no need to turn 4474 off - it can just be removed by a MITM. 

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 3 Apr 2009 00:57:11 -0400

> Sent: Friday, April 03, 2009 12:02 AM
> 

If you're not using dtls-srtp, you don't have media identity - even with 4474.  You're not losing it, because you didn't have it to begin with.  That's the point I've been trying to make, anyway.  An IP Address is not a media identifier.  It can be easily/trivially spoofed, and it can be less-trivially intercepted.  In that respect, sans dtls-srtp, 4474 is an Emperor with no clothes.  (no knock on 4474, because it never claimed to provide media identity)

For example, see:
http://tools.ietf.org/html/draft-kaplan-sip-baiting-attack-02

-hadriel

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 02 Apr 2009 20:55:36 +0200

Hi Cullen,

I'm not sure I understand all of the sensitivity of the cat skin peeling
business :-). I'm just wondering if there are other folks who consider 
telling
callee who is calling him by demonstrating a traceable not-worthless address
important. And in particular doing so in a robust way that most likely 
survives
ALG/SBC/evil-middlebox traversal (especially being resilient against such
common things as SDP rewrites, whatever today's SIP path topology is).

Or do you think this is not important or we have it or I haven't articulated
the point in a sensible way?

-jiri

Cullen Jennings wrote:
>>> registrar for its' domain. That proxy/b2bua whatever mucks with 
>>> IP/ports in the SDP for NAT traversal. Then we could ask if 4474 is 
>> broken" based on being able to transform every use case where RFC 4474 
>> breaks to one where it doesn't, generally by mandating a different 
>> approach to solving problems (TURN vs, SDP fixup, for example). You 
>> seem to expect this to prove that RFC 4474 is fine as-is, needing no 
>> modification to its A/M signing.
> 
> 
> happening is several people trying to transform that into Jon and Cullen 
> are blocking work in this space which is not at all true - I would love 
> to see some progress in this space.
> 
>>
>>
>> It might be useful to counter this with "If RFC 4474 isn't broken, why 
>> isn't it being deployed?"
> 
> email stye addresses are directly connecting often with mutual TLS or an 
> equivalently bound VPN. When enterprise B gets a call from 
> [email-masked] and it came over a TLS connection that had a certificate of 
> a.com, well you get something that meets B's authorization needs with 
> just that. For deployments using E.164 style addresses - they are pretty 
> that is acceptable for most these users. This can easily be accomplished 
> with PAI and a transitive trust model. In fact, many of these 
> deployments have SP A talking to SP B talking to SP C and B explicitly 
> wants to hide that they used SP C instead of terminating the call 
> themselves. B needs to make it look like to A like B terminated the call 
> into the PSTN vs handing it to C. These sort of deployments require B to 
> look to A like the end not the middle.
> 
>> I expect that the answer is "because users currently expect to correct 
>> their topological issues using SBCs instead of the tools that work 
>> with 4474. You might not think they have legitimate reasons for doing 
>> it this way, but the fact remains -- that's how they do it.
> 
> am suggesting will be the best way to make progress is to find out what 
> they do and what needs caused them to do it. Sure, for any problem, 
> there will be multiple ways to skin the cat. You are accusing me of 
> saying that the only way people are allowed to skin the cat is using a 
> potato peeler and that most people probably will not use a potato peeler 
> for cats no matter what I want. I am not in the slightest telling people 
> they have to use a potato peeler - I'm arguing that until we have some 
> common ground on if we are trying to peel a cat or potato or both, we 
> are unlikely to make progress on the best tool(s) for the job.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Apr 2009 09:50:56 -0400

RFC 4117 shows how to do transcoding in a way that doesn't introduce a 
MiTM. It does put more burden on the endpoints, and it does mean that 
the SPs must allow arbitrary media types to flow between the endpoints, 
but if we wanted real media security that is what we would do.

And of course it only *formally* removes the MiTM. It still depends on 
one end or the other trusting (and vouching for) the transcoding service.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 3 Apr 2009 09:43:56 -0500

On Apr 2, 2009, at 11:40 PM, Hadriel Kaplan wrote:

> We already gave you some.

I believe Cullen and Jon are arguing that no, you haven't -- you have  
just made the same non-examples 50 different ways. I know you want to  
do media-steering and see this as self evident. They want to know why  
media-steering requires SDP editing. I believe they think we need to  
make a more fundamental change to support media-steering instead of  
just hacking on the SDP.

> But really the question can just be flipped around: is there a  
> security property of the SDP's IP/port that you feel is important to  
> protect, such that we can't allow it to be changed?  Do you feel an  
> IP:port is an identity, or is somehow actually a secure indicator of  
> anything?  I mean there's plenty of other important things in SIP  
> we're not protecting with 4474 - maybe we should just sign the  
> entire SIP message, just in case.  But we don't, because we know it  
> wouldn't work in the real world, and because most of them have  
> little security value to protect.
>

Simple rational conservatism says just change something that isn't  
broken. Good enjoying practice says don't change something that  
appears to be broken until you understand the real requirements.  
Medical practice teaches us to treat the cause, not the symptom. Is  
the need to edit SDP a cause or a symptom? To me, it looks like it  
just might be a symptom of a more severe condition.

> If calls started failing because of 4474, I'm fairly sure it would  
> be 4474 that would be turned off, not the SDP re-writers.  Because  
> they're not an MITM attack on users or calls - it's a MITM attack on  
> the IETF's principles.  But then again, there's no need to turn 4474  
> off - it can just be removed by a MITM.

If users start to refuse carrier services because the carrier's SBC- 
riddled architectures can't support the users security requirements,  
carriers will either fix their architectures or go broke.  
Historically, many of them would rather go broke than fix their  
architecture, and I'm okay with that.

--
Dean

---

From: Victor Pascual Ávila <[email-masked]>
Date: Fri, 3 Apr 2009 17:09:43 +0200

> supports MITM rewriting of SDP?

Today, rewriting SDP bodies to convey QoS information to the terminals
might be a valid use case (e.g. "group several flows into a single QoS
reservation flow"). Anyway, one could expect that mechanisms like
draft-ietf-sip-session-policy-framework will become adopted in a near
future.
-- 
Victor Pascual Ávila

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 3 Apr 2009 10:21:56 -0500

Obviously, if you want a transcoding service, then you can't you e2e
security.

> Sent: Thursday, April 02, 2009 20:55
> To: Hadriel Kaplan
> Cc: Paul Kyzivat; 'Cullen Jennings'; [email-masked]; Audet, 
> Francois (SC100:3055); 'DRAGE, Keith (Keith)'; Dan Wing

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 3 Apr 2009 11:50:37 -0400

> From: Victor Pascual Ávila [mailto:[email-masked]]
> Sent: Friday, April 03, 2009 11:10 AM
>
> Anyway, one could expect that mechanisms like

You are refreshingly optimistic. :)

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 3 Apr 2009 08:50:46 -0700

> Nope, and why I do not include that function as being 
> compatible with it.  I do think some form of signaling 
> caller-id may be useful in that case, but clearly media 
> identity is not possible short of speaking in pig-latin.

It is true that we cannot provide edge-to-edge *authenticated* media
through a transcoder when that transcoder is operated by someone other
than an edge.  That is because e2e authenticated media is keyed with
DTLS-SRTP, which we would only trust edge-to-edge.

But we can provide __identity__ over the media path, even with transcoding.

Identity across a transcoder only requires the transcoding function allows the
identity through.  AS AN EXAMPLE, if we used the ICE technique in
http://tools.ietf.org/html/draft-wing-sip-identity-media-02#section-4.3, the
transcoder could permit the ICE messages to pass, unmolested and unmodified,
across the transcoder.  The transcoder would perform its normal transcoding
function with the RTP packets.  I am saying "as an example" because we may not
want to use ICE for this purpose; I have other ideas for how this might be
done which may be more appealing.  

-d

> > So are there any legitimate use cases for requiring that 
> > the protocol supports MITM rewriting of SDP?
> 
> We already gave you some.  But really the question can just 
> be flipped around: is there a security property of the SDP's 
> IP/port that you feel is important to protect, such that we 
> can't allow it to be changed?  Do you feel an IP:port is an 
> identity, or is somehow actually a secure indicator of 
> anything? 
>
> I mean there's plenty of other important things in 
> SIP we're not protecting with 4474 - maybe we should just 
> sign the entire SIP message, just in case.  But we don't, 
> because we know it wouldn't work in the real world, and 
> because most of them have little security value to protect.
> 
> SDP is not "the user content", as a mime text attachment in a 
> SIP MESSAGE or email would be.  It is not "the prized 
> possession" from the user.  In particular the indicated 
> IP:port to send IP packets to/from is not.  The IP is not an 
> application nor user identity; and it is spoofable, 
> interceptable, reputable, etc.  You yourself have argued 
> about SIP's dependence on the IP:port in SDP being an 
> architectural shortcoming, and here we are trying to make 
> sure it's cryptographically dependent!  IPsec learned this 
> the hard way when it had to encapsulate itself in UDP due to 
> the pseudoheader and NATs, SIP learned it due to NAT's, a 
> whole host of things may learn it in the v4/v6 transition if 
> it happens (oh, did we mention that as another SDP re-writing 
> case?).  
>  
> If calls started failing because of 4474, I'm fairly sure it 
> would be 4474 that would be turned off, not the SDP 
> re-writers.  Because they're not an MITM attack on users or 
> calls - it's a MITM attack on the IETF's principles.  But 
> then again, there's no need to turn 4474 off - it can just be 
> removed by a MITM. 
> 
> -hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 3 Apr 2009 11:22:55 -0500

> Sent: Thursday, April 02, 2009 21:02
> To: Audet, Francois (SC100:3055)
> Cc: Dwight, Timothy M (Tim); Cullen Jennings; [email-masked]; 
> DRAGE, Keith (Keith)
> If I understand the argument, extending the d-w-s-i-m 
> approach to non- DTLS media legitimizes the obfuscation of 
> the one media identifier we do have -- the IP address. Some 
> people seem to find this unacceptable.

No, that's not what I'm saying.

I'm saying draft-wing-sip-identity-media WITH DTLS-SRTP.
                                         ^^^^

What's wrong with that approach?

Unless I'm missing something, it does seem to achieve end-to-end
media and identity security.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 3 Apr 2009 10:22:45 -0700

> Behalf Of Dean Willis
> Sent: Thursday, April 02, 2009 8:50 PM
> To: Jiri Kuthan
> Cc: SIP List; Uzelac, Adam
> >>> There is a timing aspect in favor of placing identity in 
> signaling  
> >>> --

All 5 techniques described in 
http://tools.ietf.org/html/draft-wing-sip-identity-media-02#section-4
accomplish that using TLS, DTLS-SRTP, ICE, HIP, or ZRTP -- any of
those choices has different tradeoffs.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 3 Apr 2009 10:24:14 -0700

> Sent: Thursday, April 02, 2009 9:02 PM
> To: Francois Audet
> Cc: Cullen Jennings; [email-masked]; DRAGE,Keith (Keith)
> approach to non- 
> do have -- the IP address. 

Nope, it doesn't.

draft-wing-sip-identity-media uses the media path to prove it is the same
entity as indicated in the SIP signaling path.  Hence the name "SIP Identity
Media".

> Some people seem to find this unacceptable.

It would be objectionable, if SIP Identity Media did that.  It doesn't.

-d

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 3 Apr 2009 12:25:08 -0500

> accomplish that using TLS, DTLS-SRTP, ICE, HIP, or ZRTP -- 
> any of those choices has different tradeoffs.

I'm puzzled by why we would do anything but the DTLS-SRTP (and TLS for TCP traffic).

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 3 Apr 2009 10:44:25 -0700

> (and TLS for TCP traffic).

I also prefer TLS.  RFC4474 doesn't require TLS, so ICE is in the draft to
demonstrate it is possible to have identity even through a translator and have
identity with just RTP (RFC4474 provides identity with just RTP).

However, if we used TLS/DTLS-SRTP for identity it would (a) break transcoding
(as discussed) and (b) require deploying SRTP.  If doubt we are willing to do
(a) and (b).

-d

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 3 Apr 2009 15:47:03 -0500

I'm not sure I agree with the logic.

It seems to me when e2e security of media, then DTS-SRTP (for UDP) and TLS
(for TCP) makes perfect sense.

If we allow transcoding, then I don't see the point in e2e security, since
it obviously is not e2e. I don't understand what ICE gives you in this case.

If we need transcoding, then we might want instead to have a security mechanism with
the transcoder instead.

For example, we could use DTLS-SRTP where Alice is using the 4474-like mechanism,
but the transcoder is using it's own cert (instead of a self-signed one). That
cert's credentials would already be provisioned in Alice's device. That would 
seem like a simple way to do this.

> From: Dan Wing [mailto:[email-masked]] 
> Sent: Friday, April 03, 2009 10:44
> To: Audet, Francois (SC100:3055); 'Dean Willis'; 'Jiri Kuthan'
> Cc: 'SIP List'; 'Uzelac,Adam'
> > I'm puzzled by why we would do anything but the DTLS-SRTP 
> (and TLS for 
> > TCP traffic).
> 
> I also prefer TLS.  RFC4474 doesn't require TLS, so ICE is in 
> the draft to demonstrate it is possible to have identity even 
> through a translator and have identity with just RTP (RFC4474 
> provides identity with just RTP).
> 
> However, if we used TLS/DTLS-SRTP for identity it would (a) 
> break transcoding (as discussed) and (b) require deploying 
> SRTP.  If doubt we are willing to do
> (a) and (b).
> 
> -d
> 
>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 3 Apr 2009 14:10:03 -0700

> From: Francois Audet [mailto:[email-masked]] 
> Sent: Friday, April 03, 2009 1:47 PM
> To: Dan Wing; Dean Willis; Jiri Kuthan
> Cc: SIP List; Uzelac,Adam

I agree that (D)TLS is best, and that it protects from all sorts
of attacks.

> it obviously is not e2e. I don't understand what ICE gives 

The public key challange/response, described in
draft-wing-sip-identity-media-02, provides better identity assurance than
signing IP address and UDP port (as done by RFC4474).  Obviously the media is
still un-encrypted, though, and encrypted media is better than un-encrypted
media.

> If we need transcoding, then we might want instead to have a 
> security mechanism with the transcoder instead.
>

Ignoring SRTP for a moment, the complexities involved there
are asounding.  For example call forwarding and call transfers might
need to invoke, or remove, a translator, in a far-removed service
provider or enterprise (e.g., forwarding your work calls to your 
house).

-d

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 3 Apr 2009 16:14:42 -0500

> Sent: Friday, April 03, 2009 14:10
> draft-wing-sip-identity-media-02, provides better identity 
> assurance than signing IP address and UDP port (as done by 
> RFC4474).  Obviously the media is still un-encrypted, though, 
> and encrypted media is better than un-encrypted media.

I don't understand this. If there is a media transcoder,
then what does this identity assurance mean??? The media
is not protected. Am I missing something?

> > If we need transcoding, then we might want instead to have 
> a security 
> > mechanism with the transcoder instead.
> >
> > For example, we could use DTLS-SRTP where Alice is using 
> the 4474-like 
> > mechanism, but the transcoder is using it's own cert (instead of a 
> > self-signed one). That cert's credentials would already be 
> provisioned 
> > in Alice's device. That would seem like a simple way to do this.
> 
> are asounding.  For example call forwarding and call 
> transfers might need to invoke, or remove, a translator, in a 
> far-removed service provider or enterprise (e.g., forwarding 
> your work calls to your house).

Well, no, not at all.

The model there would be a model where you would HAVE to anchor the
media at the service provider (probably the first SBC). The encryption
would be between Alice and that.

PS: Don't get me wrong, I'm not saying I like this. I a firm non-believer
in all this transcoding stuff. I'd rather have the end-to-end DTLS-SRTP instead.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 3 Apr 2009 14:32:30 -0700

> is not protected. Am I missing something?

RFC4474 doesn't protect the media, either, yet it provides identity.

Let's pull the two different attacks apart.  There is a difference between
them:

One attack has someone spoof a "From:", and causes the victim to have a
bona-fide conversation with the attacker spoofing the "From:".  Protection
from that attack is achieved with either RFC4474 (and no SDP modifications
between the RFC4474 'authentication service' and 'verifier'), or with the ICE
public-key challange described in draft-wing-sip-identity-media.

However, you are describing a different attack vector, where an attacker waits
for a bona-fide phone call and then sends (and maybe can also also receive)
RTP packets with the victim.  The victim will believe those received RTP
packets are legitimate.  To protect from this attack you need to use SRTP.
RFC4474 cannot provide protection from this attack unless we assume attackers
cannot spoof the source IP address and port of their RTP packets to match the
(signed) SDP.  We know that attackers can spoof their source IP address.
Similarly, the ICE public-key challange described in
draft-wing-sip-identity-media does not protect from this attack vector.

I look at this as part of a normal evolution of technology.  Right now we are
in the everybody-trusts-everyone-else camp where P-A-I and From are relatively
trustable.  This is how email was for about a decade, until that broke down.
Then we will need something better for SIP to protect against spoofed From:,
but something that is still easily deployed.  I suggest that is something
*like* the public-key challange described in draft-wing-sip-identity-media.
Next, if attackers become more creative and deliver RTP to victims (e.g.,
"unsolicited advertising") we will need to use SRTP to protect against that
sort of attack.

> would be between Alice and that.

But if some service provider in the middle needs to drop the call
to <some spiffy codec> which isn't supported by Alice's SP nor by
Bob's SP -- what would that service provider do?  Not deploy that
spiffy new codec, even though it would save them thousands of dollars
a day in satellite bandwidth fees?

> PS: Don't get me wrong, I'm not saying I like this. I a firm 
> non-believer in all this transcoding stuff. I'd rather have the 
> end-to-end DTLS-SRTP instead.

-d

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 3 Apr 2009 16:48:51 -0500

> But if some service provider in the middle needs to drop the 
> call to <some spiffy codec> which isn't supported by Alice's 
> SP nor by Bob's SP -- what would that service provider do?  
> Not deploy that spiffy new codec, even though it would save 
> them thousands of dollars a day in satellite bandwidth fees?

Well, no. You just can't do end-to-end media security in this
case.

I don't understdand at all the claim that if transcoding is 
allowed, there would be any point in doing media security, or
even Secure identity for that matter. I'm just saying if transcoding
or media mucking-around is allowed, then just stick with P-AI.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 3 Apr 2009 14:56:39 -0700

> Well, no. You just can't do end-to-end media security in this

Ok.  Then in that case a way to downgrade to RTP -- which we need
in any event -- would be needed.  

> or media mucking-around is allowed, then just stick with P-AI.

So that the victim (user2) can distinguish between a service provider doing
transcoding for the legimate user1 versus the identity spoofing of user3
(diagram taken from
http://tools.ietf.org/html/draft-elwell-sip-e2e-identity-important-03):

                             user3/UA3
                                  |
                           +------+------+
                           | enterprise3 |
                           +------+------+
                                  |
              +----------+   +----+-----+   +----------+
          +---+ SBC  SBC +---+ SBC  SBC +---+ SBC  SBC +---+
          |   +----------+   +----------+   +----------+   |
          |      ITSP-A         ITSP-B         ITSP-C      |
          |                                                |
   +------+------+                                  +------+------+
   | enterprise1 |                                  | enterprise2 |
   +------+------+                                  +------+------+
          |                                                |
     user1/UA1                                        user2/UA2

-d

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Apr 2009 23:45:30 -0400

> a day in satellite bandwidth fees?

What does a package delivery service provider do if your package doesn't 
fit in its shipping containers?

Does it hack pieces off the package to make it fit?

If it does, do you continue using that service provider?

In my world, I want to be told "that is too big for us to accept. If you 
want us to deliver it for you then you will have to make it smaller." 
Then I can decide if I want that done or not, and how.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Apr 2009 23:55:42 -0400

When I am calling you, if I can discover that transcoding is required to 
establish the call, then I can establish a relationship with a 
transcoding service that I trust. If I use 3pcc to bring the transcoder 
into the call, then my call to you is still from *me*, and I vouch for 
the media source even if it is actually the transcoder. So the 
transcoding scheme can be as secure (or insecure) as any other. That of 
course assumes that the means for setting up the secured media session 
is something that can be set up using 3pcc without my necessarily having 
to relay the media.)

	Thanks,
	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 4 Apr 2009 09:41:08 -0700

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Friday, April 03, 2009 8:56 PM
> To: Dan Wing
> Cc: 'Francois Audet'; 'Dean Willis'; 'Jiri Kuthan'; 'SIP 
> List'; 'Uzelac, Adam'
> When I am calling you, if I can discover that transcoding is 
> required to establish the call,

How would you do that?

-d

> then I can establish a relationship with a

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 04 Apr 2009 17:00:06 -0400

>> required to establish the call,

There are a number of possibilities:

1) I could send an offerless invite, and await an offer from you. Then 
if it isn't something I can do myself I can recruit a transcoder to help.

2) I could send an invite with offer, and the callee could recruit the 
transcoder if needed.

3) I can send an invite with offer, and if you can't handle it, and 
don't have a transcoding alternative, you could send a 18x with an 
answer that refuses the media stream, but mentions the codecs you do 
support.

4) like 3, but use the sdp capability stuff to express the codecs that 
are supported in each direction.

5) I send invite with offer, you reject it with 488 because you can't 
support the codecs offered. The 488 indicates the codecs you do support. 
Then I recruit a transcoder and try the call again, offering somthing I 
expect you will be able to support.

	Thanks,
	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 5 Apr 2009 08:16:55 -0700

Setting up SRTP-only calls and using one or all of those techniques would
certainly be a way to learn how often intermediate transcoders are needed and
cannot be invoked.  Someone should try those techniques against some SIP
peers.  

I suspect even more interoperability issues would be encountered, but I am
only guessing.

-d

> Sent: Saturday, April 04, 2009 2:00 PM
> To: Dan Wing

---

From: Dean Willis <[email-masked]>
Date: Mon, 6 Apr 2009 23:35:13 -0500

> media and identity security.

Yes, but it does so at the expense of weakening RFC 4474 when it is  
used without DTLS.

I believe Jon has said that he wishes to be able to use signaling  
identity without DTLS and considers the presentation of IP addresses  
in the identity signature to be essential. Since you want to change  
RFC 4474 to allow MITM editing of IP address information (thereby  
weakening RFC 4474 protections in Jon's scenario), he doesn't like  
your idea,

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 6 Apr 2009 21:54:39 -0700

> weakening RFC 4474 protections in Jon's scenario), he doesn't like  

I'm saying if you use identity-media, then you MUST use DTLS-SRTP (or  
at least the handshake part if you don't need actual encryptio, or a  
NULL encryption).

That way it doesn't weaken anything. Also, nothing prevents anybody  
from using classic 4474 if you want to prevent nasty SBCs from mucking  
around with SDP: I can see enterprises doingbso between them.

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 07 Apr 2009 07:26:14 +0200

> I'm puzzled by why we would do anything but the DTLS-SRTP (and TLS for TCP traffic).

perhaps because zrtp does not require identity which fails to get to
recepient because of SDP changes?

-jiri

---

From: Jon Peterson <[email-masked]>
Date: Wed, 08 Apr 2009 19:10:53 -0700

I think I've said in the past that the IP address and port remain relevant
because their soundness is a necessary condition for the delivery of media,
and by extension the employment of mechanisms like DTLS-SRTP. If we remove
the IP address and port from the protection domain of rendezvous layer
security entirely, then either an MITM or a cut-and-paste attacker could
exploit those SDP lines to deny service, for example, in a manner that will
not be detected by the recipient until they find their media goes AWOL.
That's basically why I think the alteration of those lines should be a
detectable condition in the rendezvous layer, and why I've argued we should
have data origin authentication for that information. That doesn't
necessarily mean we need it in the form that RFC4474 currently provides it -
various sorts of patch-and-sign mechanisms would also be fine with me. But
with authentication, if media isn't reaching your interlocutor because it's
drifting out into space, at least you know who told you to aim it there -
which is, I believe, a valuable security property.

Most of my concerns here are really about layer violations, about how many
security functions we can defer to the media layer and how many must reside
in the rendezvous layer in order to meet our requirements. The primitives
that establish and maintain sessions, I believe, require protection in the
rendezvous layer - DTLS-SRTP isn't going to protect you against a forged
BYE, say. If the aggregate security that the system provides does not
prevent an attack that cheap, I think we've accomplished less than we can
and should. I also think that having enough credible information in a SIP
request that a recipient has reasonable grounds to authorize or reject it is
a good general design goal for our security work; provisionally accepting
requests and initiating media (DTLS-SRTP) in order to determine whether or
not the dialog is authorized protects against certain threats, but broadly I
think it doesn't address threats where an attacker/impersonator can
accomplish their goals without ever establishing a session. If we think
about, I suspect we'll find there are actually quite a few of those.

Jon Peterson
NeuStar, Inc.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 09 Apr 2009 08:10:14 +0100

Jon,

> Behalf Of Jon Peterson
> Sent: 09 April 2009 03:11
> To: Francois Audet; Dean Willis
[JRE] If media is encrypted, sending it to the wrong IP address/port,
whilst it will cause the call to fail, will not reveal the information
to the recipient. Of course, if media is not encrypted, that has worse
consequences, but unencrypted media can be eavesdropped by other
mechanisms, or can be spoofed or modified. Knowing who told you which IP
address/port to send to only gives you a certain amount of protection.
We must ensure we do not lower the security available when encryption is
in use (losing the ability to authenticate the user we performed key
agreement with) by clinging on to mechanisms that give some minor
benefit to the unencrypted case.
 
> about, I suspect we'll find there are actually quite a few of those.
[JRE] So this suggests the need for two solutions: one for protecting
the rendez-vous layer and one for protecting the media layer. The
problem is that the mechanism for protecting the rendez-vous layer (RFC
4474) does not work in certain deployment situations, and because we
reuse that for authenticating the media layer (using it to sign the
fingerprint of the certificate used at the media layer) we are unable to
have protection of the media layer in those deployment situations. 

John

---

From: Jon Peterson <[email-masked]>
Date: Thu, 09 Apr 2009 11:49:44 -0700

> benefit to the unencrypted case.

In fairness, I don't think the choice is between signing the IP/port and not
signing the IP/port. It is between signing the entire MIME body as a blob
the auth service does not have to understand, versus selecting a set of
elements (understood here not to include the IP/port) and signing those
exclusively. If we want to understand the benefits of the former approach,
they go a bit beyond protecting the IP/port. Architecturally, signing the
blob results in better future compatibility and better paths to extending
SDP. If the authentication service needs to know what elements in SDP are to
be included in the signature, then the authentication service behavior needs
to change every time that clients start using SDP (or bodies, for that
matter) in new ways.

If someone wakes up tomorrow, invents a new media security model, and
decides there is value in having an indicator in SDP that will let you
correlate the rendezvous layer with media security keying, under the blob
model that indicator can just get stuck in SDP, and the authentication
service does not need to change its behavior in order to sign it. Taking
this to its extreme, while I'm sure no one would stand up to defend SDPng
these days, virtually everyone would say that SDP isn't the ideal tool for
establishing complicated sessions; if we ever do get around to building
something better, the authentication service in the blob signature model
shouldn't need to understand it. This is, again, just a basic SIP layering
architecture we've always followed, intended to maximize the ability of
endpoints to innovate and reduce the brittleness of intermediaries.

Even without looking to the future, I think there's reasonable value in
signing most of the cruft in SDP. For example, as I've mentioned before, I
think it's worth detecting various codec downgrade sorts of attacks. But
speaking to the IP/port again specifically, I maintain that when sending
media doesn't work, it is useful for UAS to ascertain who set the target
IP/port, and if the IP/port shouldn't be tried anyway because they were
inserted by an attacker, I think it's useful for the UAS to know that before
it processes that re-INVITE, or begins altering for that initial INVITE, or
what have you.

>> broadly I

Certainly I agree that RFC4474 interprets "certain deployment situations" as
security violations, and that is a limitation of its approach. I was merely
pointing out that there are also limitations to an approach where we largely
defer security to the media layer; namely, it no longer protects against
classes of attacks that do not intend to establish sessions as such (this
discussion would come around to things like early media and forking, for
example; there are also applicability concerns here with media protocols
other than RTP). If these were the only two possible solutions, they we'd
debate their merits and flaws, pick one, and be done. I at least haven't
given up on the idea that we can draw up some other candidate solutions; the
real bar to doing so seems to me to be disagreement about the problem space.
So for the moment, I am still trying to talk at a pretty high level about
what sorts of qualities are desirable in a solution.

Jon Peterson
NeuStar, Inc.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 9 Apr 2009 14:09:58 -0500

So, at a high level, if we could "sign the blob" à-la-RFC 4474, 
but exclude very specific elements (i.e., the IP:port), and combine
it with DTLS-SRTP (or TLS for non-real time media), in specific 
cases where allowing Media Relays is desireable/necessary, then
we may have a solution, right?

I'm interpreting your email as we should have an opt-out of
integrity protection (carefully used) instead of an opt-in 
(as per the draft-wing-identity-media draft).

> From: Jon Peterson [mailto:[email-masked]] 
> Sent: Thursday, April 09, 2009 11:50
> To: Elwell, John; Audet, Francois (SC100:3055); Dean Willis
> > mechanisms, or can be spoofed or modified. Knowing who told 
> you which 
> > IP address/port to send to only gives you a certain amount 
> of protection.
> > We must ensure we do not lower the security available when 
> encryption 
> > is in use (losing the ability to authenticate the user we performed 
> > key agreement with) by clinging on to mechanisms that give 
> some minor 
> In fairness, I don't think the choice is between signing the 
> IP/port and not signing the IP/port. It is between signing 
> the entire MIME body as a blob the auth service does not have 
> to understand, versus selecting a set of elements (understood 
> here not to include the IP/port) and signing those 
> exclusively. If we want to understand the benefits of the 
> former approach, they go a bit beyond protecting the IP/port. 
> Architecturally, signing the blob results in better future 
> compatibility and better paths to extending SDP. If the 
> authentication service needs to know what elements in SDP are 
> to be included in the signature, then the authentication 
> service behavior needs to change every time that clients 
> start using SDP (or bodies, for that
> matter) in new ways.
> 
> If someone wakes up tomorrow, invents a new media security 
> model, and decides there is value in having an indicator in 
> SDP that will let you correlate the rendezvous layer with 
> media security keying, under the blob model that indicator 
> can just get stuck in SDP, and the authentication service 
> does not need to change its behavior in order to sign it. 
> Taking this to its extreme, while I'm sure no one would stand 
> up to defend SDPng these days, virtually everyone would say 
> that SDP isn't the ideal tool for establishing complicated 
> sessions; if we ever do get around to building something 
> better, the authentication service in the blob signature 
> model shouldn't need to understand it. This is, again, just a 
> basic SIP layering architecture we've always followed, 
> intended to maximize the ability of endpoints to innovate and 
> reduce the brittleness of intermediaries.
> 
> Even without looking to the future, I think there's 
> reasonable value in signing most of the cruft in SDP. For 
> example, as I've mentioned before, I think it's worth 
> detecting various codec downgrade sorts of attacks. But 
> speaking to the IP/port again specifically, I maintain that 
> when sending media doesn't work, it is useful for UAS to 
> ascertain who set the target IP/port, and if the IP/port 
> shouldn't be tried anyway because they were inserted by an 
> attacker, I think it's useful for the UAS to know that before 
> it processes that re-INVITE, or begins altering for that 
> initial INVITE, or what have you.
> 
> >> broadly I
> >> accomplish their goals without ever establishing a session. If we 
> >> think about, I suspect we'll find there are actually quite 
> a few of those.
> > fingerprint of the certificate used at the media layer) we 
> are unable 
> > to have protection of the media layer in those deployment 
> situations.
> 
> Certainly I agree that RFC4474 interprets "certain deployment 
> situations" as security violations, and that is a limitation 
> of its approach. I was merely pointing out that there are 
> also limitations to an approach where we largely defer 
> security to the media layer; namely, it no longer protects 
> against classes of attacks that do not intend to establish 
> sessions as such (this discussion would come around to things 
> like early media and forking, for example; there are also 
> applicability concerns here with media protocols other than 
> RTP). If these were the only two possible solutions, they 
> we'd debate their merits and flaws, pick one, and be done. I 
> at least haven't given up on the idea that we can draw up 
> some other candidate solutions; the real bar to doing so 
> seems to me to be disagreement about the problem space.
> So for the moment, I am still trying to talk at a pretty high 
> level about what sorts of qualities are desirable in a solution.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > John
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 10 Apr 2009 09:03:40 +0100

Francois,

Although an opt-out might be better than an opt-in, I still fear we could end up with complex and not-forward-compatible behaviour at the authentication service and at the verifier. So I do concur with what Jon says. Thinking, for example, of the SDP capability negotiation mechanism that MMUSIC is currently adding. You can have IP addresses and ports hidden in a=lines. If the opt-out mechanism wanted to opt out of these, it would get very messy.

I am more swayed by solutions whereby a copy of the original SDP is conveyed and signed, so you can see what has been changed en route and can decide whether to agree with the changes. A precedent already exists. The To header field URI is a copy of the original Request-URI (ignoring mid-dialog requests for now). RFC 4474 signs the To header field URI (which is not expected to change) and does not sign the Request-URI (which is expected to change). So the verifier or UAS knows for sure where the request was originally targeted and has to use its own judgement as to whether the changed Request-URI is reasonable or not.

John 

> Sent: 09 April 2009 20:10
> To: Jon Peterson; Elwell, John; Dean Willis
> > > problem is that the mechanism for protecting the 
> rendez-vous layer 
> > > (RFC

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 10 Apr 2009 10:36:19 +0200

But the UAS will mostly receive its own contact address in the Request-URI,
so there is not much to judge there.

/Hans Erik van Elburg

On Fri, Apr 10, 2009 at 10:03 AM, Elwell, John <
[email-masked]> wrote:

> So the verifier or UAS knows for sure where the request was originally
> targeted and has to use its own judgement as to whether the changed
> Request-URI is reasonable or not.
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 10 Apr 2009 10:25:51 -0500

But.... This is unlikely to be backward-compatible, no?

Are you saying that the receiver of the INVITE would get
a multipart MIME, one of them signed with RFC 4474, and the other
with something else?

What I had in mind for "opt-out" was that the signature would
avoid all instances of it's own IP address and port. But yeah,
you are right, this is non-trivial and error-prone.

Using TURN is looking more and more attractive...

> Sent: Friday, April 10, 2009 01:04
> To: Audet, Francois (SC100:3055); Jon Peterson; Dean Willis
> Although an opt-out might be better than an opt-in, I still 
> fear we could end up with complex and not-forward-compatible 
> behaviour at the authentication service and at the verifier. 
> So I do concur with what Jon says. Thinking, for example, of 
> the SDP capability negotiation mechanism that MMUSIC is 
> currently adding. You can have IP addresses and ports hidden 
> in a=lines. If the opt-out mechanism wanted to opt out of 
> these, it would get very messy.
> 
> I am more swayed by solutions whereby a copy of the original 
> SDP is conveyed and signed, so you can see what has been 
> changed en route and can decide whether to agree with the 
> changes. A precedent already exists. The To header field URI 
> is a copy of the original Request-URI (ignoring mid-dialog 
> requests for now). RFC 4474 signs the To header field URI 
> (which is not expected to change) and does not sign the 
> Request-URI (which is expected to change). So the verifier or 
> UAS knows for sure where the request was originally targeted 
> and has to use its own judgement as to whether the changed 
> > So, at a high level, if we could "sign the blob" à-la-RFC 4474, but 
> > exclude very specific elements (i.e., the IP:port), and combine it 
> > with DTLS-SRTP (or TLS for non-real time media), in specific cases 
> > where allowing Media Relays is desireable/necessary, then 
> we may have 
> > a solution, right?
> > 
> integrity 
> > protection (carefully used) instead of an opt-in (as per the 
> > draft-wing-identity-media draft).
> > 
> > 
> > 
> > > Subject: Re: [Sip] francois' comments and why RFC4474 not used in 
> > > the field
> > > 
> > > 
> > > In fairness, I don't think the choice is between signing 
> the IP/port 
> > > and not signing the IP/port. It is between signing the 
> entire MIME 
> > > body as a blob the auth service does not have to 
> understand, versus 
> > > selecting a set of elements (understood here not to include the 
> > > IP/port) and signing those exclusively. If we want to 
> understand the 
> > > benefits of the former approach, they go a bit beyond 
> protecting the 
> > > IP/port.
> > > authentication service needs to know what elements in SDP 
> are to be 
> > > included in the signature, then the authentication 
> service behavior 
> > > needs to change every time that clients start using SDP 
> (or bodies, 
> > > for that
> > > matter) in new ways.
> > > 
> > > If someone wakes up tomorrow, invents a new media security model, 
> > > and decides there is value in having an indicator in SDP 
> that will 
> > > let you correlate the rendezvous layer with media 
> security keying, 
> > > under the blob model that indicator can just get stuck in 
> SDP, and 
> > > the authentication service does not need to change its 
> behavior in 
> > > order to sign it.
> > > Taking this to its extreme, while I'm sure no one would 
> stand up to 
> > > defend SDPng these days, virtually everyone would say 
> that SDP isn't 
> > > the ideal tool for establishing complicated sessions; if 
> we ever do 
> > > get around to building something better, the 
> authentication service 
> > > in the blob signature model shouldn't need to understand it. This 
> > > is, again, just a basic SIP layering architecture we've always 
> > > followed, intended to maximize the ability of endpoints 
> to innovate 
> > > and reduce the brittleness of intermediaries.
> > > 
> reasonable value 
> > > in signing most of the cruft in SDP. For example, as I've 
> mentioned 
> > > before, I think it's worth detecting various codec 
> downgrade sorts 
> > > of attacks. But speaking to the IP/port again specifically, I 
> > > maintain that when sending media doesn't work, it is 
> useful for UAS 
> > > to ascertain who set the target IP/port, and if the IP/port 
> > > shouldn't be tried anyway because they were inserted by 
> an attacker, 
> > > I think it's useful for the UAS to know that before it processes 
> > > that re-INVITE, or begins altering for that initial 
> INVITE, or what 
> > > have you.
> > > 
> > > >> broadly I
> > > situations" as security violations, and that is a 
> limitation of its 
> > > approach. I was merely pointing out that there are also 
> limitations 
> > > to an approach where we largely defer security to the 
> media layer; 
> > > namely, it no longer protects against classes of attacks 
> that do not 
> > > intend to establish sessions as such (this discussion would come 
> > > around to things like early media and forking, for example; there 
> > > are also applicability concerns here with media protocols 
> other than 
> > > RTP). If these were the only two possible solutions, they we'd 
> > > debate their merits and flaws, pick one, and be done. I at least 
> > > haven't given up on the idea that we can draw up some other 
> > > candidate solutions; the real bar to doing so seems to me to be 
> > > disagreement about the problem space.
> > > So for the moment, I am still trying to talk at a pretty 
> high level 
> > > about what sorts of qualities are desirable in a solution.
> > > 
> > > Jon Peterson
> > > NeuStar, Inc.
> > > 
> > > > John
> > > 
> > > 
> > 
>

---

From: Jon Peterson <[email-masked]>
Date: Fri, 10 Apr 2009 09:09:38 -0700

At a high level, when an intermediary is going to relay your media, the
intermediary (not the UAC) is the source of the IP/port data that appears in
SDP, and as such, I can accept alternatives to securing that data with a
signature from the originating administrative domain (abstractly, that goes
equally for SBCs and TURN, I suppose). I don't however believe it follows
from this that it just doesn't matter at all who sets the IP/port data in
SDP. I think it does matter, and it matters most when we consider approaches
that defer security checks from the SIP layer to the media layer. For
example, if relatively weak SIP-layer security facilitates cut-and-paste
attacks, then an eavesdropper could listen to INVITEs, forge re-INVITEs with
the same signature but set the IP/port to something unhelpful, and
methodically tear down a target's calls five seconds after they start. So
from my perspective, verifying the origin of IP/port data still has value,
even if the origin of that data is not the originating administrative
domain.

Jon Peterson
NeuStar, Inc.

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 10 Apr 2009 13:37:22 -0500

Yes, this makes sense to me.

The attack is not impersonnation, it's interuption of media.

Verifying the address of the relay seems difficult to me. It could
be in source domain, destination domain, some intermediary. Or there
could even be more than one. Unless we do it hop by hop.

I guess we could have another layer of TLS exchange between the
UA and the intermediary (where instead of a self-signed cert, 
you would actually autenticate your intermediary). Wouldn't do
wonders for backward compatibility however, and I'm not sure
it would be simpler than TURN.

> Sent: Friday, April 10, 2009 09:10
> To: Audet, Francois (SC100:3055); Elwell, John; Dean Willis
> At a high level, when an intermediary is going to relay your 
> media, the intermediary (not the UAC) is the source of the 
> IP/port data that appears in SDP, and as such, I can accept 
> alternatives to securing that data with a signature from the 
> originating administrative domain (abstractly, that goes 
> equally for SBCs and TURN, I suppose). I don't however 
> believe it follows from this that it just doesn't matter at 
> all who sets the IP/port data in SDP. I think it does matter, 
> and it matters most when we consider approaches that defer 
> security checks from the SIP layer to the media layer. For 
> example, if relatively weak SIP-layer security facilitates 
> cut-and-paste attacks, then an eavesdropper could listen to 
> INVITEs, forge re-INVITEs with the same signature but set the 
> IP/port to something unhelpful, and methodically tear down a 
> target's calls five seconds after they start. So from my 
> perspective, verifying the origin of IP/port data still has 
> value, even if the origin of that data is not the originating 
> administrative domain.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> 
> >> and not signing the IP/port. It is between signing the entire MIME 
> >> included in the signature, then the authentication service 
> behavior 
> model, and 
> >> decides there is value in having an indicator in SDP that will let 
> >> you correlate the rendezvous layer with media security 
> keying, under 
> >> the blob model that indicator can just get stuck in SDP, and the 
> >> authentication service does not need to change its 
> behavior in order 
> >> to sign it.
> >> defend SDPng these days, virtually everyone would say that 
> SDP isn't 
> >> in the blob signature model shouldn't need to understand 
> it. This is, 
> >> again, just a basic SIP layering architecture we've always 
> followed, 
> >> intended to maximize the ability of endpoints to innovate 
> and reduce 
> downgrade sorts of 
> >> attacks. But speaking to the IP/port again specifically, I 
> maintain 
> >> that when sending media doesn't work, it is useful for UAS to 
> shouldn't be 
> >> tried anyway because they were inserted by an attacker, I 
> think it's 
> >> useful for the UAS to know that before it processes that 
> re-INVITE, 
> >> or begins altering for that initial INVITE, or what have you.
> >> 
> >>>> broadly I
> >> to an approach where we largely defer security to the media layer; 
> >> around to things like early media and forking, for 
> example; there are 
> >> also applicability concerns here with media protocols other than 
> we'd debate 
> >> their merits and flaws, pick one, and be done. I at least haven't 
> >> given up on the idea that we can draw up some other candidate 
> >> solutions; the real bar to doing so seems to me to be disagreement 
> >> about the problem space.

---

From: Jon Peterson <[email-masked]>
Date: Fri, 10 Apr 2009 12:28:19 -0700

If I may quibble here:

> The attack is not impersonation, it's interruption of media.

The attack relies on impersonation to accomplish interruption of media. The
attacker listens to Alice's INVITE, and then sends a cut-and-pasted
re-INVITE saying "This is Alice again, would you mind sending my media here
instead please." Impersonation is almost always a tool that attackers use to
accomplish some particular goal, even if it's just tricking you into
accepting unwanted communications. I'm not sure I'd say impersonation is an
attack as such, but by preventing it, we prevent whole categories of attacks
and grant ourselves more powers in crafting authorization policies.

Jon Peterson
NeuStar, Inc.

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 10 Apr 2009 15:43:56 -0500

Right, the signalling gets impersonated, but not the media.

So the only practical thing that can be done by the attacker
is interup media. 

> Sent: Friday, April 10, 2009 12:28
> The attack relies on impersonation to accomplish interruption 
> of media. The attacker listens to Alice's INVITE, and then 
> sends a cut-and-pasted re-INVITE saying "This is Alice again, 
> would you mind sending my media here instead please." 
> Impersonation is almost always a tool that attackers use to 
> accomplish some particular goal, even if it's just tricking 
> you into accepting unwanted communications. I'm not sure I'd 
> say impersonation is an attack as such, but by preventing it, 
> we prevent whole categories of attacks and grant ourselves 
> more powers in crafting authorization policies.

---

From: "Elwell, John" <[email-masked]>
Date: Sat, 11 Apr 2009 13:46:51 +0100

Jon,

So a consequence of what you are saying is that to verify who you are negotiating DTLS-SRTP security with you need one signature, covering the certificate fingerprint and sufficient other stuff to prevent replay, and to verify which intermediary told you the IP address and port to send media to you need a second signature. Correct?

John

> Sent: 10 April 2009 17:10
> To: Francois Audet; Elwell, John; Dean Willis
> media, the
> believe it follows
> cut-and-paste

---

From: "Elwell, John" <[email-masked]>
Date: Sat, 11 Apr 2009 13:49:27 +0100

Technically you are correct, of course, but in many practical situations
the UAS implicitly knows the final target AoR based on the contact URI
received in the Request-URI. Also with the proposed change to
History-Info it would receive an explicit indication. I don't think this
impacts my argument.
 
John

	From: Hans Erik van Elburg [mailto:[email-masked]] 
	Sent: 10 April 2009 09:36
	To: Elwell, John
	Cc: Francois Audet; Jon Peterson; Dean Willis; Cullen Jennings;
[email-masked]; DRAGE, Keith (Keith)
	Subject: Re: [Sip] francois' comments and why RFC4474 not used
in the field

	But the UAS will mostly receive its own contact address in the
Request-URI, so there is not much to judge there. 
	
	/Hans Erik van Elburg

	On Fri, Apr 10, 2009 at 10:03 AM, Elwell, John
<[email-masked]> wrote:

		So the verifier or UAS knows for sure where the request
was originally targeted and has to use its own judgement as to whether
the changed Request-URI is reasonable or not.

---

From: Anthony D Pike <[email-masked]>
Date: Mon, 13 Apr 2009 09:15:58 -0400

hi Francios,

Surely if you correlate the signallng with the initial media stream from the endpoint as Jonathan mentioned in his original email a couple of weeks ago then you will know that that there has been a problem and you would not pick up the call and you might report the call to the appropriate authorities who could then trace the call potentailly.

Quite how this correlation takes place is not 100% clear to me as yet, but I'm thinking on it.

Tony

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. •

[email-masked] wrote: -----

To: "Jon Peterson" <[email-masked]>, "Elwell, John" <[email-masked]>, "Dean Willis" <[email-masked]>
From: "Francois Audet" <[email-masked]>
Sent by: [email-masked]
Date: 04/10/2009 04:43PM
cc: Cullen Jennings <[email-masked]>, [email-masked], "DRAGE, Keith \(Keith\)" <[email-masked]>
Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 13 Apr 2009 11:02:54 -0500

I agree.
 
I think the issue Jon is pointing out is that one could interrupt the media stream.

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Anthony D Pike
	Sent: Monday, April 13, 2009 06:16
	To: Audet, Francois (SC100:3055)
	Cc: Cullen Jennings; Jon Peterson; [email-masked]; DRAGE, Keith (Keith); Dean Willis
	Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field

	hi Francios,

	Tony

---

From: Anthony D Pike <[email-masked]>
Date: Mon, 13 Apr 2009 12:10:32 -0400

Hi

interruptions in a media stream may occur naturally in the network for many reasons!

My point was to emphasize that if you don't correlate signalling with the original media stream(s) from the calling user, then the called user cannot truely authenticate the caller. This should be a requirement? How to correlate the signalling with the media streams is TBD.

Tony

-----"Audet, Francois (SC100:3055)" <[email-masked]> wrote: -----

To: Anthony D Pike/ESI/CSC@CSC
From: "Audet, Francois (SC100:3055)" <[email-masked]>
Date: 04/13/2009 12:02PM
cc: "Cullen Jennings" <[email-masked]>, "Jon Peterson" <[email-masked]>, <[email-masked]>, "DRAGE, Keith (Keith)" <[email-masked]>, "Dean Willis" <[email-masked]>
Subject: RE: [Sip] francois' comments and why RFC4474 not used in the field

I agree.

hi Francios,

Tony

[email-masked] wrote: -----

> From: Jon Peterson [ mailto:[email-masked] ]

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 13 Apr 2009 11:12:18 -0500

I agree.

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Anthony D Pike
	Sent: Monday, April 13, 2009 09:11
	To: Audet, Francois (SC100:3055)
	Cc: Cullen Jennings; [email-masked]; DRAGE,Keith (Keith); Jon Peterson; Dean Willis
	Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field

	Hi

	Tony

---

From: Jon Peterson <[email-masked]>
Date: Mon, 13 Apr 2009 10:18:47 -0700

I am saying that there solutions that have those properties that would be
satisfactory from my perspective, yes, but certainly not that a solution
must exhibit these properties. Obviously something like using TURN and
having the originating administrative domain sign the IP/port generated by
the intermediary is also fine with me, for example.

Jon Peterson
NeuStar, Inc.

On 4/11/09 5:46 AM, "Elwell, John" <[email-masked]>
wrote:

> Jon,
> 
> So a consequence of what you are saying is that to verify who you are
> negotiating DTLS-SRTP security with you need one signature, covering the
> certificate fingerprint and sufficient other stuff to prevent replay, and to
> verify which intermediary told you the IP address and port to send media to
> you need a second signature. Correct?
> 
> John

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 13 Apr 2009 10:38:50 -0700

> Sent: Friday, April 10, 2009 12:28 PM
> of media. The
> instead please."

The 'Alice again' attacker would need to prove Alice's identity which 
the attacker cannot accomplish (unless the attacker knows Alice's 
private key).  This is true of RFC4474 and 
draft-fischer-sip-e2e-sec-media and draft-wing-sip-identity-media.
All three of those require the attacker to sign SIP headers and,
in the case of the two I-D's, the attacker has to also perform
a handshake proving possession of Alice's private key.

I don't see the new attack that you are seeing.

-d

---

From: Anthony D Pike <[email-masked]>
Date: Mon, 13 Apr 2009 13:52:38 -0400

+1

[email-masked] wrote: -----

To: "'Jon Peterson'" <[email-masked]>, "'Francois Audet'" <[email-masked]>, "'Elwell, John'" <[email-masked]>, "'Dean Willis'" <[email-masked]>
From: "Dan Wing" <[email-masked]>
Sent by: [email-masked]
Date: 04/13/2009 01:38PM
cc: "'Cullen Jennings'" <[email-masked]>, [email-masked], "'DRAGE, Keith \(Keith\)'" <[email-masked]>
Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field

-d

---

From: Jon Peterson <[email-masked]>
Date: Mon, 13 Apr 2009 11:20:04 -0700

I don't think I'm describing any novel attack here, and really I am trying
to speak more to higher-level requirements than the properties of any
specific proposal, but I'd like to understand what our disconnect is. I'm
talking about an attack that is purely in the signaling layer, so I'm not
sure in what sense Alice has a private key applicable to that layer (unless
she is acting as her own authentication service, say). "This is Alice again"
here means that, for example, the re-INVITE is a clever cut-and-paste attack
that appears to have a valid signature to verifier. The decision about where
media is sent is always something negotiated in the rendezvous layer; if the
rendezvous layer is persuaded to send media somewhere unhelpful, no amount
of media layer security will prevent this disruption.

The only thing this attack is meant to illustrate is why it does matter who
sets the IP/port. I've gathered that some people in the discussion reject
the notion that there are any threats related to the setting the IP/port in
the signaling layer, so I'm trying to provide an example.

Jon Peterson
NeuStar, Inc.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 13 Apr 2009 11:38:01 -0700

> Sent: Monday, April 13, 2009 11:20 AM
> To: Dan Wing; 'Francois Audet'; 'Elwell, John'; Dean Willis
> Cc: Cullen Jennings; [email-masked]; 'DRAGE,Keith (Keith)'
> specific proposal, but I'd like to understand what our 
> disconnect is.

I believe there is consensus that cut-and-paste attacks need
to be prevented.  You continue to raise that point, so I can
only assume that you believe there is a lack of consensus on
that point.

> I'm

That is because, ** in conjunction with media-path validation **
(which is the important point), the attack is prevented.

-d

---

From: Dean Willis <[email-masked]>
Date: Mon, 13 Apr 2009 14:20:15 -0500

> (which is the important point), the attack is prevented.

Well, the attack is not so much "prevented"  as it is "detected". It  
is detectable when the media-path validation fails.

But though detectable, the attack is not attributable. You may know  
that an attack has occurred, but you don't know whether it was enabled  
by modification of the media or by modification of the signaling.

If you had the original signed signaling and could see that the  
signaling had been altered, then you might reasonably suspect that the  
attacker was on the signaling path. Without this, all you know is that  
somebody tweened your media somehow.

Now, is this really useful if the original signed media description  
(SDP) has been replaced by new signed SDP? Not really; as we then  
would not be able to decide whether the attack was a compromised  
intermediary authentication server or a a direct attack on the media.

So a model wherein no intermediary replaces and resigns the SDP is  
preferred, as it allows the media to always match the signaling,  
thereby reducing the uncertainty. We don't have such a model yet  
AFAIK, as outbound, STUN, and relays give us only two steering points,  
and I've heard it claimed we need more. I might argue that this  
problem is due to the separation of signaling and media, which I hold  
to be one of the prime "complicators" in this whole house of cards.  
But it might well be possible to extend the relay-discovery model of  
ICE to be able to express an entire graph of candidate sequences,  
including n-relay paths. On the otehr hand, I find it difficult to  
propose such a mechanism that would be backward compatible with the  
SIP devices I currently use, and if we have to breal backward  
compatibility, I'd just as soon do it cleanly and on a large scale.

--
Dean

---

From: Jon Peterson <[email-masked]>
Date: Mon, 13 Apr 2009 12:22:04 -0700

> (which is the important point), the attack is prevented.

You're talking about a solution here; I'm really trying to establish that
there's a problem. The two are not mutually exclusively - ideally we will
have both a problem and a solution. I am however uncertain that we have a
common understanding of the problem.

I'm not sure I know what you mean by media-path validation, here, but I do
think that there are many important attacks against SIP that accomplish
their aims without ever establishing a media session. These include
signaling-layer attacks that would, for example, tear down the media
associated with an existing call. I have a hard time seeing how anything we
do at the media layer is salient to that - again, just speaking to high
level examples, if you accept a forged BYE request, that will presumably
convince you to tear down a call regardless of anything that media-layer
security has established. I've argued a similar requirement exists to
prevent a forged re-INVITE that just sets the IP/port to something useless.
When I hear you say that some property of media path prevents this sort of
attack, then I gather we must disagree about the problem, not just the
solution. Can you explain a bit what you mean here by media-path validation
and how it prevents the sorts of attacks I just mentioned?

Jon Peterson
NeuStar, Inc.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 13 Apr 2009 15:45:20 -0700

> Sent: Monday, April 13, 2009 12:22 PM
> level examples, if you accept a forged BYE request,

The BYE would be protected from forgery sufficient to detect a 
forgery, using mechanisms like RFC4474 protects a BYE from 
forgery:  signing enough SIP headers to block a forgery.

> presumably

The media-path validation is useful for INVITEs which establish
media.  

Other methods, which do not establish media -- BYE, MESSAGE, 
etc. -- would receive signatures very similar to what RFC4474
does.  Namely, some certain SIP headers are signed and, if 
present, the body is signed.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 13 Apr 2009 15:53:08 -0700

> Sent: Monday, April 13, 2009 12:20 PM
> To: Dan Wing
> Cc: 'Jon Peterson'; 'Francois Audet'; 'Elwell, John'; 'Cullen 
> Jennings'; [email-masked]; 'DRAGE, Keith (Keith)'

I would be content with identity that worked edge-to-edge, so that
existing devices don't need to change.  Over time those devices can
be upgraded and could do their own proof of identity.  The philosophy
of RFC4474 was similar in that it allows a-device-other-than-the-UA
to create the RFC4474 signature and a-device-other-than-the-UA to 
validate the RFC4474 signagure.

-d

---

From: Adam Roach <[email-masked]>
Date: Mon, 13 Apr 2009 19:50:28 -0500

> present, the body is signed.

You're proposing signing the entire body of MESSAGE requests?

But what if some intermediary, for policy reasons, wants to change the 
contents of a MESSAGE -- say, by redacting selected words the service 
provider feels are inappropriate -- without the consent of either party?

;-)

/a

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 13 Apr 2009 22:45:50 -0700

> provider feels are inappropriate -- without the consent of 

"file system check" is spelled f-s-c-k.

-d

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Apr 2009 08:21:15 -0400

> provider feels are inappropriate -- without the consent of either party?

Surely nobody would want to do *that*! :-)

Actually it is very believable.

And of course the same would apply to content of an MSRP media stream.

While the technology might not yet be there to do it well, I can imagine 
somebody wanting to impose screening on the content of audio and video 
media streams.

	Paul

---

From: Anthony D Pike <[email-masked]>
Date: Tue, 14 Apr 2009 11:16:54 -0400

This is an interesting case that Adam has brought up, and I'm sure there are many others as well. The approach I had thought of for this type of case is to have a second signature after the radacting has taken place, so the user understands where it was changed and possibly why! The original RFC 4474 signature would NOT be removed. Everytime a modification is done to the Message Request effectively a diff signature with a reason could be added. Unfortunately this is pretty huge burden on the UAS to process all the signatures if it choses to do so.

Tony

[email-masked] wrote: -----

To: "'Adam Roach'" <[email-masked]>
From: "Dan Wing" <[email-masked]>
Sent by: [email-masked]
Date: 04/14/2009 01:45AM
cc: "'Cullen Jennings'" <[email-masked]>, "'Jon Peterson'" <[email-masked]>, [email-masked], "'Francois Audet'" <[email-masked]>, "'DRAGE, Keith \(Keith\)'" <[email-masked]>, "'Dean Willis'" <[email-masked]>
Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 14 Apr 2009 08:52:55 -0700

> From: Anthony D Pike [mailto:[email-masked]] 
> Sent: Tuesday, April 14, 2009 8:17 AM
> To: Dan Wing
> Cc: 'Adam Roach'; 'Cullen Jennings'; 'Jon Peterson'; 
> [email-masked]; 'Francois Audet'; 'DRAGE, Keith (Keith)'; 'Dean Willis'
> This is an interesting case that Adam has brought up, and I'm 
> sure there are many others as well. The approach I had 
> thought of for this type of case is to have a second 
> signature after the radacting has taken place, so the user 
> understands where it was changed and possibly why! The 
> original RFC 4474 signature would NOT be removed. Everytime a 
> modification is done to the Message Request effectively a 
> diff signature with a reason could be added. Unfortunately 
> this is pretty huge burden on the UAS to process all the 
> signatures if it choses to do so.

Worse is the intermediaries would have to generate new public key signatures
over content they are already, presumably, encrypting with TLS (I presume it's
encrypted with TLS because they care about security, which is why they would
be interested in additionally doing signatures over the data, too).

On SIP networks today we have intermediaries modifying SDP in transit.  It's
happening now, on real networks.  I am really interested in preserving
identity over those networks.

Today we do not have intermediaries modifying MESSAGE content in transit, do
we?

-d

> Tony
> 
> This is a PRIVATE message. If you are not the intended 
> recipient, please delete without copying and kindly advise us 
> by e-mail of the mistake in delivery. 
> NOTE: Regardless of content, this e-mail shall not operate to 
> bind CSC to any order or other contract unless pursuant to 
> explicit written agreement or government initiative expressly 
> permitting the use of e-mail for such purpose. . 
> 
> 
> 	cc: "'Cullen Jennings'" <[email-masked]>, "'Jon 
> Peterson'" <[email-masked]>, [email-masked], 
> "'Francois Audet'" <[email-masked]>, "'DRAGE, Keith 
> \(Keith\)'" <[email-masked]>, "'Dean Willis'" 
> <[email-masked]>
> not used in the field
> =

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 14 Apr 2009 12:47:55 -0600

> Today we do not have intermediaries modifying MESSAGE content in  

Yep, systems used by financial traders often add a disclosure message  
to the IM as they leave the site (much like what is done for email).  
Systems that scan for malware in IM often replace "suspicious" content  
with something else. The leading IM compliance systems allow complex  
edits and replacements for compliance reasons.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 14 Apr 2009 11:49:24 -0700

> edits and replacements for compliance reasons.

Those devices are operated by their employer's systems, though.  I
was asking about *transit* providers.

-d

---

From: Adam Roach <[email-masked]>
Date: Tue, 14 Apr 2009 17:22:11 -0500

Anthony D Pike wrote:
>
> This is an interesting case that Adam has brought up, and I'm sure 
> there are many others as well. The approach I had thought of for this 
> type of case is to have a second signature after the radacting has 
> taken place, so the user understands where it was changed and possibly 
> why! The original RFC 4474 signature would NOT be removed. Everytime a 
> modification is done to the Message Request effectively a diff 
> signature with a reason could be added.
>

Yep. And that would work with SDP in INVITES, too.

> Unfortunately this is pretty huge burden on the UAS to process all the 

Not really -- performing three or four crypto operations shouldn't slow 
down a terminal more than a trivial amount. And, of course (as you point 
out), it doesn't *need* to actually process the signatures.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 14 Apr 2009 17:59:07 -0500

[with my individual contributor hat on]

> identity over those networks.

And I have HTTP proxies that I'd love to send RTP through. At some 
point, we've got to realize that certain types of old dogs aren't even 
remotely suited for particularly demanding new tricks -- at least, not 
without software upgrades.

I think it's important to distinguish among three classes of solutions 
in this space:

   1. Identity that works through existing B2BUAs
   2. Identity that might not work through existing B2BUAs, but that
      B2BUAs can be modified to work with
   3. Identity that precludes the presence of B2BUAs

There are clearly approaches that fit into each of these three 
categories. There are a number of people (and I count myself among them) 
who find the security properties of the proposals that fit into #1 to be 
odious. There are also people who clearly find proposals in class #3 
unacceptable for their lack of pragmatism.

Now, there are also a number of people who have historically staked out 
extremist positions that state that only solutions in category #1 (or 
only solutions in category #3) are acceptable, and that neither of the 
other two options could possibly be acceptable. I think we need to 
ignore people arguing from either of these extreme positions, because 
their positions are mutually exclusive, and can never be rectified with 
each other.

At the risk of suggesting compromise, I'll point out that there *is* a 
way to mutually satisfy those people who reject solutions in class #1 
and those people who reject solutions in class #3. I suspect that useful 
progress lies in that direction only.

/a

---

From: Jon Peterson <[email-masked]>
Date: Tue, 14 Apr 2009 16:06:42 -0700

On 4/13/09 3:45 PM, "Dan Wing" <[email-masked]> wrote:

>> I have a hard time seeing how anything we

In so far as there's really any thrust to my argument here, it's that the
situation of an INVITE that an attacker never intends to use to establish a
session is comparable to that of a BYE - one must sign enough of its headers
to detect a forgery to thwart its mischief. The problem is, of course, that
there's no way for the security mechanism to differentiate these sorts of
INVITEs from the "sunny day" session-establishment cases where media-layer
security will eventually be invoked, which makes me question exactly how
much we can reduce the set of INVITE headers we sign.

This doesn't mean I object fundamentally to a two-pronged solution; say,
signing set X of fields for all requests with an SDP body and set Y for all
requests without an SDP body. It just means that in the threat model I'm
considering, I have reservations about making X much smaller than Y.

Jon Peterson
NeuStar, Inc.

>> that will presumably

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 14 Apr 2009 16:10:47 -0700

> From: Adam Roach [mailto:[email-masked]] 
> Sent: Tuesday, April 14, 2009 3:59 PM
> To: Dan Wing
> Cc: 'Anthony D Pike'; 'Cullen Jennings'; 'Jon Peterson'; 
> And I have HTTP proxies that I'd love to send RTP through. At 
> some point, we've got to realize that certain types of old 
> dogs aren't even remotely suited for particularly demanding 
> new tricks -- at least, not without software upgrades.
> 
> I think it's important to distinguish among three classes of 
> solutions in this space:
> 
> 
> 
> 2.	Identity that might not work through existing B2BUAs, 
> but that B2BUAs can be modified to work with
> There are clearly approaches that fit into each of these 
> three categories. There are a number of people (and I count 
> myself among them) who find the security properties of the 
> proposals that fit into #1 to be odious. There are also 
> people who clearly find proposals in class #3 unacceptable 
> for their lack of pragmatism.
>
> Now, there are also a number of people who have historically 
> staked out extremist positions that state that only solutions 
> in category #1 (or only solutions in category #3) are 
> acceptable, and that neither of the other two options could 
> possibly be acceptable. I think we need to ignore people 
> arguing from either of these extreme positions, because their 
> positions are mutually exclusive, and can never be rectified 
> with each other.
> 
> At the risk of suggesting compromise, I'll point out that 
> there *is* a way to mutually satisfy those people who reject 
> solutions in class #1 and those people who reject solutions 
> in class #3. I suspect that useful progress lies in that 
> direction only.

Agreed.  And I also prefer #2.  There have been 3 solutions on
the table that provide e2e identity with small changes to those
B2BUAs (essentially:  permit such-and-such header fields to
pass), and accomplish this without an appreciable CPU impact on 
those intermediaries.  All three of those proposals are in the
#2 category.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 14 Apr 2009 16:33:49 -0700

> Sent: Tuesday, April 14, 2009 4:07 PM

Yes, I agree we need to sign enough headers to prevent an attack.

-d

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 14 Apr 2009 17:46:59 -0600

> was asking about *transit* providers.
Yah, I don't know if some the IM federation groups do that type of  
thing in the middle or if it is all done at the edge.

---

From: Adam Roach <[email-masked]>
Date: Tue, 14 Apr 2009 21:18:18 -0500

Dan Wing wrote:
>> ...
>> ...
>> ...
> Agreed.  And I also prefer #2.

Ah, I misunderstood your earlier statement --  "I am really interested 
in preserving identity over [SIP networks today with intermediaries that 
modify SDP in transit]" -- to mean that the intermediaries were not to 
be modified. So we're really both talking about SIP networks for some 
upcoming tomorrow, not SIP networks today.

Good. I think that leaves a lot of common ground to work with.

/a

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Apr 2009 22:41:17 -0500

I really think the real point is not "preserving existing SBC behavior" or "preserving 4474 behavior".
 
It seems to me the real point that is being made is that perhaps there is a way to have a useful Identity mechanism, even while allowing IP addresses and ports to be modified in transit, provided that there is a sufficient mechanism for allowing (1) the media to integrity protected, (2) the media to be correlated to the identity, and (3) allowing for detection media being "cut".
 
I believe Jon was saying that furthermore, it must be detectable if the IP address and port was modified in transit. I'm not completly clear why it's necessary if all the conditions above are met. Maybe it's part of (3).

	From: Adam Roach [mailto:[email-masked]] 
	Sent: Tuesday, April 14, 2009 19:18
	To: Dan Wing
	Cc: 'Anthony D Pike'; 'Cullen Jennings'; 'Jon Peterson'; [email-masked]; Audet, Francois (SC100:3055); 'DRAGE, Keith (Keith)'; 'Dean Willis'
	Subject: Re: [Sip] francois' comments and why RFC4474 not used in the field

	Ah, I misunderstood your earlier statement --  "I am really interested in preserving identity over [SIP networks today with intermediaries that modify SDP in transit]" -- to mean that the intermediaries were not to be modified. So we're really both talking about SIP networks for some upcoming tomorrow, not SIP networks today.

	/a

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 14 Apr 2009 21:07:15 -0700

> Sent: Tuesday, April 14, 2009 7:18 PM
> To: Dan Wing
> 			On SIP networks today we have 
> intermediaries modifying 
> 		SDP in transit.  It's
> Ah, I misunderstood your earlier statement --  "I am really 
> interested in preserving identity over [SIP networks today 
> with intermediaries that modify SDP in transit]" -- to mean 
> that the intermediaries were not to be modified. So we're 
> really both talking about SIP networks for some upcoming 
> tomorrow, not SIP networks today.

I'm talking about SIP networks that adjust SDP, and which
can be convinced to pass along some additional SIP headers.

I have been told, in the past, that I'm having a pipe dream
when I suggest that.

-d

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 16 Apr 2009 10:00:20 +0100

X could be equal to Y. In each case, the SDP body is excluded. In the
one case the SDP body doesn't exist, in the other it exists but is not
signed.

John

> Sent: 15 April 2009 00:34
> To: 'Jon Peterson'; 'Francois Audet'; Elwell, John; 'Dean Willis'
> Cc: 'Cullen Jennings'; [email-masked]; 'DRAGE,Keith (Keith)'

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 16 Apr 2009 10:00:30 +0100

Adam,
 
Yes, I think #2 might be the way ahead. We need to ensure that any
changes of behaviour that we require from B2BUAs in intermediate domains
is reasonable, in the sense that intermediate domains are not prevented
from doing things they have reasonable grounds for needing to do, and
that the burden on intermediate domains is not excessive (given that the
intermediate domain is not the main beneficiary from e2e identity). For
example, if we believe there is no fundamental reason for intermediate
domains to modify the call-id value, we might require those that do
modify call-id to change their behaviour. However, requiring
intermediate domains to add a signature may or may not be considered too
demanding.

John

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adam Roach
	Sent: 14 April 2009 23:59
	To: Dan Wing
	Cc: 'Cullen Jennings'; 'Jon Peterson'; [email-masked]; 'Francois
Audet'; 'DRAGE,Keith (Keith)'; 'Dean Willis'
	Subject: Re: [Sip] francois' comments and why RFC4474 not used
in the field

	Dan Wing wrote: 

		On SIP networks today we have intermediaries modifying
SDP in transit.  It's
		happening now, on real networks.  I am really interested
in preserving
		identity over those networks.

	And I have HTTP proxies that I'd love to send RTP through. At
some point, we've got to realize that certain types of old dogs aren't
even remotely suited for particularly demanding new tricks -- at least,
not without software upgrades.

	
	Now, there are also a number of people who have historically
staked out extremist positions that state that only solutions in
category #1 (or only solutions in category #3) are acceptable, and that
neither of the other two options could possibly be acceptable. I think
we need to ignore people arguing from either of these extreme positions,
because their positions are mutually exclusive, and can never be
rectified with each other.
	
	At the risk of suggesting compromise, I'll point out that there
*is* a way to mutually satisfy those people who reject solutions in
class #1 and those people who reject solutions in class #3. I suspect
that useful progress lies in that direction only.
	
	/a