Subject: [Sipping] Transcoding and route entries

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 12 Mar 2004 13:28:16 +0200

Folks,

during the SIPPING session, I presented the following draft:
http://www.ietf.org/internet-drafts/draft-camarillo-sipping-transc-b2bua-01.txt

We discussed whether or not it is appropriate to use Route headers to 
introduce a B2BUA in the path. The two options are:

A and B are the UAs, and T is the transcoder, which is a B2BUA

-----     -----     -----
| A |-----| T |-----| B |
-----     -----     -----

1) Without using Route

INVITE T
Body: B

2) Using Route

INVITE B
Route T

Reasons for using option 1:

- T is behaving as a conference server, so we should invoke it in the 
same way as we invoke a conference.
- Route headers are intended for proxies, not for B2BUAs.
- If we start using Route headers to invoke B2BUAs, what is the meaning 
of e2e or e2m security? T would be the recipient of the headers in the 
message, but T would not appear in the Request-URI...

Reasons for using option 2:
- sessions with and without transcoder are invoked in the same way.

I would like to hear your opinions. Mine is that we should go for option 1.

Thanks,

Gonzalo

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Fri, 12 Mar 2004 13:28:29 +0100

I prefer option 1.

Cheers

Arnoud

Drs. Arnoud A. T. van Wijk
Viataal
Research & Development
Afdeling RDS
Theerestraat 42
5271 GD Sint-Michielsgestel
The Netherlands. 
Mobile: +31651921948
International text telephone: +31735588408

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gonzalo Camarillo
Sent: vrijdag 12 maart 2004 12:28
To: sipping
Cc: Eric Burger; Henning Schulzrinne; Jonathan Rosemberg; Rohan Mahy; Adam
Roach
Subject: [Sipping] Transcoding and route entries

Folks,

during the SIPPING session, I presented the following draft:
http://www.ietf.org/internet-drafts/draft-camarillo-sipping-transc-b2bua-01.
txt

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

1) Without using Route

INVITE T
Body: B

2) Using Route

INVITE B
Route T

Thanks,

Gonzalo

This communication is confidential and intended solely for the addressee(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If
you believe this message has been sent to you in error, please notify the
sender by replying to this transmission and delete the message without
disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we only
send and receive e-mails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Mar 2004 09:56:08 -0500

Gonzalo - inline.

	Paul

> A and B are the UAs, and T is the transcoder, which is a B2BUA

I vote for option 2.

> same way as we invoke a conference.

It is a stretch to call this a conference server. If you made it one, 
then T would be obligated to support all the things that a conference 
focus does. That is quite a burden to place on a poor transcoder that 
never wants to support more than two legs.

> - Route headers are intended for proxies, not for B2BUAs.

There has never been much work done on defining various specific kinds 
of B2BUAs. But there has always been discussion of various degrees of 
transparency on the part of a B2BUA. There seems to be a continuum, from 
ones that are just barely more than a proxy, to those that are clearly a 
full-blown UA that is the intended destination of the caller.

At least for those that are close to being proxies, the Route header 
seems entirely appropriate. The box is just a waypoint on the path 
between the caller and the intended callee.

I think the question is whether the transcoder is close enough to being 
a proxy for this argument to apply to it. I think so - it clearly isn't 
the caller's intended destination - it is merely a waypoint.

> message, but T would not appear in the Request-URI...

I do agree that security may be an issue here. But it is going to be an 
issue of some sort no matter what. (What happens if B has a whitelist of 
acceptable callers, and A is on the list but T is not?)

If this proves to be a problem, then this architecture for a transcoded 
call may be entirely wrong. What ever happened to the concept of having 
A (or B) act as a B2BUA, bringing in T when needed? As in:

	T ---2----- A ----1------ B
	  ===3=====
	  =========4=============

where 1 and 2 are sip connections that A joining, acting as a B2BUA, 
while 3 and 4 are media sessions that T is joining, acting as a transcoder.

The advantage of this config is that the call between A and B is direct, 
so there is no issue of identifying another party, and no issue of 
authentication or authorization. And presumably T is only brought in 
when it is apparent that it is needed.

> This communication is confidential and intended solely for the 
> addressee(s). Any unauthorized review, use, disclosure or distribution 
> is prohibited. If you believe this message has been sent to you in 
> error, please notify the sender by replying to this transmission and 
> delete the message without disclosing it. Thank you.
> 
> send and receive e-mails on the basis that we are not liable for any 
> such corruption, interception, amendment, tampering or viruses or any 
> consequences thereof.
> 
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 12 Mar 2004 20:29:45 +0200

Paul,

>     T ---2----- A ----1------ B

This approach is documented in the following draft, which will be WGLCed 
shortly. I want this thread to focus on the other draft, though.

http://www.ietf.org/internet-drafts/draft-ietf-sipping-transc-3pcc-00.txt

Thanks,

Gonzalo

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 12 Mar 2004 10:35:12 -0800

Hi Folks,

This decision boils down to a question of semantics.  Does a URI in a  
Route header mean:  1) send through this proxy, or 2) send through this  
service or intermediary ?

One of the important things to consider when there is a difference of  
philosophy or opinion regarding semantics, is to consider if any harm  
comes from either of the choices.  In this case, I can come up with no  
technical reason that using a Route header is harmful.

Another key question is if there is any precedent.  Again, the two  
proposals both have some precedent. Conference bridges do not use the  
Route header (the analogy of approach 1), but folks have been using  
Route headers to direct SIP requests through B2BUAs for session border  
control (gasp), policy control, P-CSCFs, etc.. for some time now (the  
analogy of approach 2).  I can even dig up some old mail when we  
encouraged 3GPP to use a loose-route for one of their many B2BUAs  
instead of defining some piece of new mechanism.  Taking this a step  
further, we've been talking about how *proxies* can use session policy  
to meet logging requirements.  I think this is very similar to  
transcoding, since some entity operating on behalf of both  
intermediaries (transcoder and logging proxy) need to see the media.

Finally there is the question of using existing mechanism vs. inventing  
new mechanism.  If the existing mechanism fits, I see no reason to  
define new mechanism unless a more general approach to other problems  
is achievable with the new mechanism.  Nobody is proposing using the  
new mechanism proposed in (1) to do anything else.  Also, the  
conference bridge analogy breaks IMO since conference bridges do not  
use this new mechanism to indicate the other participants in the  
conference.

In summary, I prefer option 2 (use the Route header).  The approach  
causes no harm, has precedent for existing usage, and requires no new  
special-purpose mechanism.

thanks,
-rohan

On Mar 12, 2004, at 3:28 AM, Gonzalo Camarillo wrote:

> - If we start using Route headers to invoke B2BUAs, what is the  
> meaning of e2e or e2m security? T would be the recipient of the  
> headers in the message, but T would not appear in the Request-URI...
>
> interruption, unauthorized amendment, tampering and viruses, and we  
> only send and receive e-mails on the basis that we are not liable for  
> any such corruption, interception, amendment, tampering or viruses or  
> any consequences thereof.
>

---

From: Tim Melanchuk <[email-masked]>
Date: Fri, 12 Mar 2004 11:07:13 -0800

i agree with rohan and prefer using route headers. a transcoding
service seems much more akin to a relay along the path than it
does a conference which is more a destination unto itself. if
this can be achieved without (imho) inappropriately bending
existing mechanism, it is preferable to new mechanism.

timm

Rohan Mahy wrote:
>> addressee(s). Any unauthorized review, use, disclosure or 
>> distribution  is prohibited. If you believe this message has been sent 
>> to you in  error, please notify the sender by replying to this 
>> transmission and  delete the message without disclosing it. Thank you.
>>

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Fri, 12 Mar 2004 22:31:16 +0100

I prefer 2.

In most cases you would think: "I want to call B."
Then, either you, yourself add "through the
transcoding service T", or that is added
automatically because of some analysis of
preferences registered by A and B.

Gunnar
-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
[email-masked]
--------------------------------------------

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Tim Melanchuk
> Sent: Friday, March 12, 2004 8:07 PM
> To: Rohan Mahy
> Cc: Gonzalo Camarillo; Eric Burger;
> Jonathan Rosemberg; Adam Roach;
> Henning Schulzrinne; sipping
> Subject: Re: [Sipping] Re: Transcoding
> and route entries
>
>
> http://www.ietf.org/internet-drafts/draf
> t-camarillo-sipping-transc-
> >> b2bua-01.txt
> >>
> >> I would like to hear your opinions.
> Mine is that we should go for
> >> option 1.
> >>
> >> Thanks,
> >>
> >> Gonzalo
> >>
> >>
> > Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping

_______________________________________________
Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the
application of SIP
Use [email-masked] for questions
on current sip
Use [email-masked] for new developments of core SIP

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 12 Mar 2004 13:31:25 -0800

On Mar 12, 2004, at 1:18 PM, Volker Hilt wrote:

> Rohan,
>>  Route header mean:  1) send through this proxy, or 2) send through 
>> this  service or intermediary ?
>>  philosophy or opinion regarding semantics, is to consider if any 
>> harm  comes from either of the choices.  In this case, I can come up 
>> with no  technical reason that using a Route header is harmful.
> An issue might be that a UA is free to do whatever it wants with the 
> remaining Route header values in a message (i.e. if the service wasn't 
> the last Route header entry). This is in contrast to a proxy, for 
> which Route header processing is well defined. Thus, a UAC would not 
> know if all entities in the Route header will actually be visited.

Hi Volker,

This is a good point. Since we are defining a transcoder role, I think 
it is appropriate for us to provide normative guidance on what you 
should do with other pre-loaded Routes.  If we go with proposal (1), we 
need to embed the post-transcoder routes in the target URI:

INVITE T
Route: a1, a2
Real-Target: B?Route=b1,b2

If we go with proposal (2) we put all the waypoints in the Route header 
and make it clear that the transcoder sends the new request routed 
through the remaining waypoints:

INVITE B
Route: a1, a2, T, b1, b2

thanks,
-rohan

>> [...] Taking this a step  further, we've been talking about how 
>> *proxies* can use session policy  to meet logging requirements.  I 
>> think this is very similar to
> I believe the difference is that these entities are still proxies and 
> not B2BUAs. Thus, there is no change in the semantics of the Route 
> header.
>
> Thanks,
>
> Volker

---

From: Volker Hilt <[email-masked]>
Date: Fri, 12 Mar 2004 17:50:37 -0500

Rohan Mahy wrote:
> should do with other pre-loaded Routes.  

Yes, true. A mechanism has to be defined no matter which alternative is 
chosen.

> If we go with proposal (1), we 
What I like about the first option is that it seems to be cleaner since 
it separates service specific functionality from general SIP headers.

The second approach requires the definition of B2BUA procedures for a 
header targeted at proxies. However, an advantage of this approach 
certainly is that it does not require support for extensions from endpoints.

Thanks,

Volker

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 13 Mar 2004 12:29:32 +0200

Rohan,

> technical reason that using a Route header is harmful.

I do consider using Route harmful, in the sense that, in many 
situations, it will simply not work. After talking about this I will 
state my "philosophical" concerns as well.

SIP is designed so that the UAC needs to know who the UAS in order to 
work. For example, the UAC uses the public key of the UAS to encrypt the 
content encryption key and to integrity protect parts of the message. 
So, any SIP entity different than the destination UAS will not be able 
to process the request correctly (or at all).

When there is a B2BUA in the path, the destination UAS for the request 
is the B2BUA. This means that the UAC MUST know that the B2BUA will be 
in the path in order to act accordingly (e.g, use the B2BUA's public key 
to integrity protect the request).

The problem with Route is that it can be added by proxies. That is, any 
proxy in the path can use loose routing and insert a number of Route 
entries, some of which, if we go for the Route approach, may be B2BUAs. 
This clearly does not work, because these B2BUAs will not be able to 
process the request... so, we need a way to invoke B2BUAs that can only 
be used by the UAC... this calls for a different mechanism than Route.

That much about why I consider Route harmful. Regarding more 
"phylosophical" arguments, when I see a SIP request, I understand which 
entity is the destination (i.e., the Request-URI), and which pieces of 
information are intended to that entity (e.g., the session description). 
If we go for the Route approach, it will be impossible to figure out, by 
inspecting a message, which entity will process which parts of the 
message, and which is the final destination of the *request*. This can 
soon become a debugging nightmare.

Additionally, recall our liaison statement to 3GPP, complaining that the 
P-CSCF sends a BYE if the terminal loses coverage... if the Route 
approach was right, this would be a prefectly acceptable behavior.

Moreover, if we look at REFER, the destination of the REFER request is 
encoded in the request-URI, and the URI of the Refer-target is encoded 
somewhere else (i.e., Refer-To header). Using Route here does not seem 
appropriate either.

In brief, what the Route approach tries to do is to send application 
data to an application server using a header that happens to have a 
syntax that allows to place URIs in it. Having a different mechanism 
with the right semantics would avoid a lot of confusion, in my opinion.

Thanks,

Gonzalo

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Sun, 14 Mar 2004 09:11:36 +0100

One important function using transcoding is indeed a relay.
Where an interpreter will transcode a voice call into for example text when
the receiving user is deaf and needs text to understand the speech.
(and text to speech).

Greetz

Arnoud

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tim Melanchuk
Sent: vrijdag 12 maart 2004 20:07
To: Rohan Mahy
Cc: Gonzalo Camarillo; Eric Burger; Jonathan Rosemberg; Adam Roach; Henning
Schulzrinne; sipping
Subject: Re: [Sipping] Re: Transcoding and route entries

timm

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Sun, 14 Mar 2004 09:16:54 +0100

Can we be sure that there is no proxy on the route that may change the route
header in a way that the original route information and URI is lost?

If we can be sure that this is not going to happen, that the route header
with the URI will not change in the signalling path. Then I change my choice
into number 2 instead of 1.

Greetz

Arnoud

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gunnar Hellstrom
Sent: vrijdag 12 maart 2004 22:31
To: Tim Melanchuk; Rohan Mahy
Cc: Gonzalo Camarillo; Eric Burger; Jonathan Rosemberg; Adam Roach; Henning
Schulzrinne; sipping
Subject: RE: [Sipping] Re: Transcoding and route entries

I prefer 2.

Gunnar

application of SIP

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Sun, 14 Mar 2004 09:21:44 +0100

Gonzalo,
You voiced my concern in a much more detailed way. :-)
So, it boils down to:
What happens to the route header and the information in it during any SIP
call?
And is it still understandable which information is relevant for the
transcoding service and which is for other services like security,
authorization etc. (not to mention weird proxies that replace the entirely
route header to hide internal network routing).

Greetz

Arnoud

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gonzalo Camarillo
Sent: zaterdag 13 maart 2004 11:30
To: Rohan Mahy
Cc: Eric Burger; Jonathan Rosemberg; Adam Roach; Henning Schulzrinne;
sipping
Subject: [Sipping] Re: Transcoding and route entries

Rohan,

Thanks,

Gonzalo

---

From: Dean Willis <[email-masked]>
Date: Mon, 15 Mar 2004 10:08:51 -0600

> service or intermediary ?

Clearly, it means 1), as a meaning of 2) would tend to melt-down any 
end-to-end protections being applied.

Today's occasional usage of route-thru-B2BUAs is not a general model -- 
users of this approach are just "getting lucky" in that the end-to-end 
behaviors that would be affected are not being used in their current 
environment.

--
Dean

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 15 Mar 2004 09:15:23 -0800

Hi Gonzalo,

On Mar 13, 2004, at 2:29 AM, Gonzalo Camarillo wrote:

> work. For example, the UAC uses the public key of the UAS to encrypt 
> the content encryption key and to integrity protect parts of the 
> message. So, any SIP entity different than the destination UAS will 
> not be able to process the request correctly (or at all).
>
> in the path in order to act accordingly (e.g, use the B2BUA's public 
> key to integrity protect the request).

The transcoder is an intermediary which wants to apply session policy 
to offers and answers.  It should be able hand its session description 
to the far end using either the redirect or piggyback model (the 
transcoder doesn't care). The UAS can verify the integrity of the 
various bits of the message (this bit came from the UAC, this bit from 
the transcoder) and make an authorization decision (do I cooperate with 
this intermediary).  Either the transcoder is operating on behalf of 
the UAC (in a verifiable way), or the transcoder is operating on behalf 
of the UAS (in a verifiable way), or the UAS should refuse to 
cooperate.

Note, that we still have a similar authorization/correlation problem if 
you don't use Route.

> The problem with Route is that it can be added by proxies. That is, 
> any proxy in the path can use loose routing and insert a number of 
> Route entries, some of which, if we go for the Route approach, may be 
> B2BUAs. This clearly does not work, because these B2BUAs will not be 
> able to process the request...

This is in common use today.  I don't understand why these B2BUAs won't 
be able to process the request?  We are defining a transcoding role 
which happens to be a B2BUA.  We are not defining the behavior of all 
B2BUAs.  In general, if some intermediary manipulates Route headers, it 
needs to follow the rules for Route headers in RFC 3261.

> so, we need a way to invoke B2BUAs that can only be used by the UAC... 
> this calls for a different mechanism than Route.
>
>
> "phylosophical" arguments, when I see a SIP request, I understand 
> which entity is the destination (i.e., the Request-URI), and which 
> pieces of information are intended to that entity (e.g., the session 
> description). If we go for the Route approach, it will be impossible 
> to figure out, by inspecting a message, which entity will process 
> which parts of the message, and which is the final destination of the 
> *request*. This can soon become a debugging nightmare.

The final destination is the Request-URI.  Yes, it is impossible to 
know which entity will process which part.  I consider this a feature 
similar to the SIP feature that you don't know if the next hop is the 
last hop or not.

> Additionally, recall our liaison statement to 3GPP, complaining that 
> the P-CSCF sends a BYE if the terminal loses coverage... if the Route 

No, because the P-CSCF sending the BYE is assuming authoritative 
control over the UAs CSeq space, and making no attempt to provide the 
UAs with credentials with which to authorize the BYE.

> somewhere else (i.e., Refer-To header). Using Route here does not seem 

The REFER comparison is a stretch in my book, because the Refer-To URI 
typically has a different method, and can even be non-SIP.  In the 
transcoding case, we still want an INVITE on "both sides", and the only 
reason we can't INVITE directly is because of media or codec 
incompatibility.

Thinking about this again from the perspective of session policies, I 
consider transcoding a logical extension of "let me propose this new 
session description to you"

> with the right semantics would avoid a lot of confusion, in my 

I think we will continue to disagree on this point, but that's probably 
a good sign that this topic is worth discussing.  ;-)

thanks,
-rohan

---

From: Volker Hilt <[email-masked]>
Date: Mon, 15 Mar 2004 18:59:22 -0500

Rohan,

> The transcoder is an intermediary which wants to apply session policy to 
> offers and answers.  It should be able hand its session description to 
> the far end using either the redirect or piggyback model (the transcoder 
> doesn't care). The UAS can verify the integrity of the various bits of 
> the message (this bit came from the UAC, this bit from the transcoder) 
> and make an authorization decision (do I cooperate with this 
> intermediary).  Either the transcoder is operating on behalf of the UAC 
> (in a verifiable way), or the transcoder is operating on behalf of the 
> UAS (in a verifiable way), or the UAS should refuse to cooperate.
> 
How would this authorization be done with a B2BUA-based intermediary 
that is added to the Route?

If a policy-enabled proxy is used, policies are clearly identifiable as 
such and UAs are able to authenticate the originator of policies and 
authorize their use. If a B2BUA-based transcoding service is explicitly 
addressed in the SIP message, end-to-end security can be used between 
the UAs and the transcoding service. Both UAs would know that this 
service is involved.

If a B2BUA-based transcoding service is added to the Route header, the 
situation seems to be different. If no security is used, it would be 
hard for the UAs to detect that this service has modified the SDP 
announcement. If security is used between the endpoints (i.e. the two 
UAs) the transcoding service will not work. In this case, the UAC would 
have to have the implicit knowledge that one of the entries in the Route 
header is actually a B2BUA. But then, the UAC could as well directly 
address this entity making the relationship explicit.

Thanks,

Volker

---

From: Kumiko Ono <[email-masked]>
Date: Tue, 16 Mar 2004 13:40:01 +0900

Gonzalo, Rohan and Volker,

>>> key to integrity protect the request).

As you pointed out, both cases require a mechanism that the UAC know if 
the transcoder is needed in the path. The UAC must know the B2BUA's 
public key to encrypt the content-encryption-key for confidentiality, 
but not for integrity protection. The UAC must know its own private key 
to protect integrity of the request. (correction in above example)

>address this entity making the relationship explicit.

I think that it would be hard for the UAs to detect that intermediaries 
had modified the SDP in *both* cases, if no security is used.

I agree on the point that proposal 1 is appropriate with the SIP design 
policy. However, proposal 1 is to make it ambiguous for the UAS(B) to 
know the real originator. Also this is to make it ambiguous for the UAC
(A) to know whether the request is properly sent to the real target.  We 
need a SIP header to specify redirected identity (=the real originator) 
besides the real target. Also, we need a mechanism to authenticate the 
redirected identity in the request and the real target in the response. 
AIB could be useful.

In proposal 2, it is hard for the UAS to know if the transcoder (B2BUA) 
exists in the path. I don't know if the UAS needs to know that using the 
SIP headers. If the UAS receives some data with signature of the 
transcoder instead of signature of the UAC, the UAS could know that the 
transcoder handled the data. If the UAS receives some data without any 
signature, the UAS could know that there was some possibility of 
modification.

Thanks,

Kumiko

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 17 Mar 2004 14:11:12 +0200

Rohan,

session policies does not introduce B2BUAs in the path. A session policy 
could consist of telling a UA "by the way, if you want this session to 
be established, you should use that B2BUA". The way the B2BUA is invoked 
by the UA is outside the scope of session policies... and this is 
exactly what we are discussing here.

As I said in my previous mail, when a UA is invoking a B2BUA, the UA 
needs to use the public keys of the B2BUA. Otherwise, nothing works. And 
since Route can be inserted by any proxy, every time a proxy inserts a 
B2BUA in the path, the B2BUA will not be able to do anything with the 
request, because it cannot decrypt it (or check its integrity).

And if the one inserting the B2BUA in a Route header is the UA, then the 
request would carry a session description that is not intended to the 
entity identified by the Request-URI. It would be intended to an entity 
that is identified by one of the multiple Route headers that the request 
may carry... which Route header? No idea, because by inspecting the 
message it is impossible to see who is the intended recipient of the
session description.

 > The final destination is the Request-URI.

Maybe of the service, but not of the request, which is the one that 
needs to be protected using crytography.

 >  Yes, it is impossible to know
 > which entity will process which part.  I consider this a feature similar
 > to the SIP feature that you don't know if the next hop is the last hop
 > or not.

Not at all. When I generate a session description, place it in my 
INVITE, and send it to sip:[email-masked], I know that I have to 
encrypt it using your public key. So, I know that the entity processing 
the session description will belong to Rohan. So, I know exactly who wil 
process my SDP.

In brief: using Route headers for invoking B2BUAs does not work as soon 
as security is used, and the messages would be everything but explicit 
about who needs to process what (i.e., systems would be very difficult 
to debug).

If we went ahead solve these problems, we would be creating a mechanism 
or a set of mechanisms that are so far away from the current Route 
header that would be better implemented as a different mechanism.

Gonzalo

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Mar 2004 14:03:08 -0500

inline.

Gonzalo Camarillo wrote:

> Rohan,
> 
> session policies does not introduce B2BUAs in the path. A session
> policy could consist of telling a UA "by the way, if you want this
> session to be established, you should use that B2BUA". The way the
> B2BUA is invoked by the UA is outside the scope of session
> policies... and this is exactly what we are discussing here.
> 
>  needs to use the public keys of the B2BUA. Otherwise, nothing works.
> And since Route can be inserted by any proxy, every time a proxy
> inserts a B2BUA in the path, the B2BUA will not be able to do
> anything with the request, because it cannot decrypt it (or check its
> integrity).

This problem exists even for proxies. COnsider that I call you, Gonzalo,
so that I insert a body encrypted with your public key. You are not
around, so your calls are forwarded to Rohan. My INVITE goes only
through proxies, and arrives at Rohan's PC with a body encrypted with
the key of someone else.

One other point to make - the cat is way out of the bag on this one.
AFAIK, the Isc interface in 3gpp uses loose route headers to identify
applications. Those applications can be b2bua, proxy, or whatever. The
interface doesnt change based on that.

I do see the philosophical argument about Route being intended for
proxies, however. I think Paul hit the nail on the head when he said:

> There has never been much work done on defining various specific
> kinds of B2BUAs. But there has always been discussion of various
> degrees of transparency on the part of a B2BUA. There seems to be a
> continuum, from ones that are just barely more than a proxy, to those
> that are clearly a full-blown UA that is the intended destination of
> the caller.
> 
> I think the question is whether the transcoder is close enough to
> being a proxy for this argument to apply to it. I think so - it
> clearly isn't the caller's intended destination - it is merely a
> waypoint.

If you look at it this way, though, the real defining characteristic of 
a proxy vs. a b2bua is its inability to initiate requests and its 
inability to modify the bodies of the request. A transcoder violates the 
second of these, and that is the source of the security concerns raised 
by Gonzalo.

Clearly on the fence,

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Dean Willis <[email-masked]>
Date: Wed, 17 Mar 2004 15:31:31 -0600

> interface doesnt change based on that.

Only "sortof, kinda." The fact that this breaks e2e protections is known 
and provided for within the limited trust model (P-Asserted-Identity) of 
3GPP. Any B2BUAs thus invoked are also required to have a high-level of 
feature transparency, although that transparency does not necessarily 
include end-to-end protection.

This limited use within a restricted architecture having known 
interoperability limitations doesn't establish Routing: to B2BUA 
intermediaries as a general case. It's more in the nature of a tricky 
kludge that works sometimes, if one is very careful or very lucky.

--
Dean

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 18 Mar 2004 12:48:23 +0200

Jonathan,

> through proxies, and arrives at Rohan's PC with a body encrypted with

Yes, this is actually the other side of the problem I was describing. 
When a SIP UAC creates a request applying end-to-end encryption to its 
SDP, it needs to know which entities are acting as a UAS (a B2BUA is a 
UAS for the UAC) and which entities are acting as a proxy. The entity 
that acts as a UAS goes into the Request-URI, and its public key is used 
to encrypt the SDP. The entities that act as proxies go into the Route 
headers, and do not have access to the SDP.

Now, if one of the entities that is supposed to act as a proxy (i.e., an 
entity in a Route header) decides to act as a UAS, nothing works, 
because that entity does not have access to the SDP. This is the problem 
I was talking about in my previous mails.

The same way, if the entity that is supposed to act as a UAS (the one in 
the Reques-URI) decides suddently to act as a proxy instead (in your 
example, Gonzalo's UA proxied the request to Rohan), nothing works 
either, because the new entity that will act as a UAS (i.e., Rohan's UA) 
will not be able to access the SDP of the message.

So, the general issue is that, for end-to-end protection to work, the 
UAC needs to know, before hand, which entities are acting as UAs and 
which entities are acting as proxies. Entities cannot change roles once 
the request has been generated.

Consequently, mixing B2BUAs and proxies in the same header (Route) does 
not seem the right thing to do, since the behavior of the UAC will be 
completely different depending on which entity performs which role.

> interface doesnt change based on that.

As Dean pointed out, the 3gpp model only works because they do not use 
end-to-end security. Add end-to-end security to 3gpp, and a bunch of 
things will break; this is only one of them.

> proxies, however.

In addition to the technical reasons above, I also believe that the 
intention of Route headers has always been to contain proxy entries.

Thanks,

Gonzalo

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Thu, 18 Mar 2004 14:01:49 +0200

Hi,

Inline.

ext Gonzalo Camarillo wrote:
<snip />

> same way as we invoke a conference.

I guess you're saying that the transcoder is a special type of ad-hoc 
conference. In the generic case, A would call a conference-factory, and 
include a dial-out list in the body of the INVITE. In the transcoder 
scenario, this dial-out list would only contain B.

What if A wants to transcode *and* set up an ad-hoc conference as above? 
That clearly won't work with option #1, since you would need to include 
two dial-out lists - one that only has the conference-factory, and 
another one that includes the final dial-out list. But it would work 
with option #2.

Based on the ability to combine services better, I'd vote for option #2.

Cheers,
Aki

Disclaimer: philosphically I haven't made up my mind yet. ;)

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 18 Mar 2004 15:00:20 +0200

Aki,

invoking B2BUAs in a cascade fashion can be done with the ad-hoc 
conference approach as well. You only need to escape characters... and 
if we want the messages to look nicer (less escaping) we can create a 
special place where you put all the B2BUAs you want to have in the path.

Nevertheless, using Route for B2BUAs does not work for the reasons I 
have stated previously, and we need a new mechanism.

It is not very useful that people state "I like the Route approach" 
without addressing the technical concerns being raised...

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: "Niemi Aki (Nokia-M/Espoo)" <[email-masked]>
Date: Thu, 18 Mar 2004 15:42:16 +0200

> special place where you put all the B2BUAs you want to have in the path.

Hmm.. so the URI in the 1st list also needs a cid: reference to a 
another list, a bodypart delivered as part of the original message? To 
me this sounds more complicated than escaping a few characters, but I 
guess it could work...

> without addressing the technical concerns being raised...

Well, I was about to address your concerns after raising a technical 
concern of my own.

Cheers,
Aki

>> conference. In the generic case, A would call a conference-factory, 
>> and include a dial-out list in the body of the INVITE. In the 
>> transcoder scenario, this dial-out list would only contain B.
>>
>> What if A wants to transcode *and* set up an ad-hoc conference as 
>> above? That clearly won't work with option #1, since you would need to 
>> include two dial-out lists - one that only has the conference-factory, 
>> and another one that includes the final dial-out list. But it would 
>> work with option #2.
>>

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 18 Mar 2004 10:21:25 -0500

On Mar 15, 2004, at 3:59 PM, Volker Hilt wrote:

> Rohan,
>
>>> SIP is designed so that the UAC needs to know who the UAS in order 
>>> to work. For example, the UAC uses the public key of the UAS to 
>>> encrypt the content encryption key and to integrity protect parts of 
>>> the message. So, any SIP entity different than the destination UAS 
>>> will not be able to process the request correctly (or at all).
>>>
>>> When there is a B2BUA in the path, the destination UAS for the 
>>> request is the B2BUA. This means that the UAC MUST know that the 
>>> B2BUA will be in the path in order to act accordingly (e.g, use the 
>>> B2BUA's public key to integrity protect the request).
>> to offers and answers.  It should be able hand its session 
>> description to the far end using either the redirect or piggyback 
>> model (the transcoder doesn't care). The UAS can verify the integrity 
>> of the various bits of the message (this bit came from the UAC, this 
>> bit from the transcoder) and make an authorization decision (do I 
>> cooperate with this intermediary).  Either the transcoder is 
>> operating on behalf of the UAC (in a verifiable way), or the 
>> transcoder is operating on behalf of the UAS (in a verifiable way), 
>> or the UAS should refuse to cooperate.
>> Note, that we still have a similar authorization/correlation problem 
>> if you don't use Route.

Case 1: transcoder added on behalf of originating user A

1. A INVITEs B with Route: T
2. T responds with an alternate offer (signed by T) that A can use
3. A resends INVITE B Route T including both offers
4. T forwards the INVITE to B
5. B authorizes the new session description as inserted on behalf of 
the UAC
6. B responds with a 2xx and its offer to the revised answer provided 
by T
7. T tacks on its alternate answer (signed by T)
8. A authorizes and uses the alternate answer

Case 2: transcoder added on behalf of receiving user B

1: A INVITEs B with Route: T
2. T tacks on an alternate offer (signed by T) that A can use instead 
of A's offer
3. B authorizes the new sdp came from T on its behalf
4. B responds with a 2xx and it offer to T's revised answer
5. T tacks on it alternative answer (signed by T)

> If a policy-enabled proxy is used, policies are clearly identifiable 
> as such and UAs are able to authenticate the originator of policies 
> and authorize their use. If a B2BUA-based transcoding service is 
> explicitly addressed in the SIP message, end-to-end security can be 
> used between the UAs and the transcoding service. Both UAs would know 
> that this service is involved.

This property is still attainable even if the the B2BUA is expressed as 
a Route.

> announcement.

Without integrity, neither method provides authentication.

> If security is used between the endpoints (i.e. the two UAs) the 
> transcoding service will not work. In this case, the UAC would have to 
> have the implicit knowledge that one of the entries in the Route 

Just an observation, you are making the relationship with the B2BUA 
explicit, but now the relationship with the real target is implicit.

thanks,
-rohan

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 18 Mar 2004 12:43:24 -0500

If the UAC wants to encrypt the payload and still make it available to 
both the UAS and one or more entities identified in preloaded Route 
headers, the obvious strategy would seem to be to place multiple 
versions of the body, encrypted with different entities' public keys, in 
a multipart body. I'm not sure if this could be made to work with 
S/MIME, though.

Anders

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 18 Mar 2004 20:07:50 +0200

Anders,

if you want to make the *same* information available to several 
entities, you can encrypt the content encryption (symmetric) key under 
different public keys. This yields a much smaller message.

In any case, the problem we want to resolve is not how to implement 
end-to-middle security. The problem we are dealing with is where it is 
best to place the URIs of the B2BUAs.

Thanks,
Gonzalo

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 18 Mar 2004 13:26:31 -0500

> best to place the URIs of the B2BUAs.

Yes, but one of your arguments was that "The entities that act as 
proxies go into the Route headers, and do not have access to the SDP." 
What I'm saying is that, AFAICT, this doesn't have to be the case.

Anders

>> versions of the body, encrypted with different entities' public keys, 
>> in a multipart body. I'm not sure if this could be made to work with 
>> S/MIME, though.
>>
>> Anders
>>
> 
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 18 Mar 2004 20:36:25 +0200

Hi,

> What I'm saying is that, AFAICT, this doesn't have to be the case.

No, that was not my argument. I said that if the UAC knows that an entry 
in the Route header is a proxy, the UA could take the necessary actions 
to make it work. Nevertheless, proxies in the path can and do insert new 
(loose) Route entries. So, if a proxy inserts a Route entry that 
corresponds to a B2BUA, the UAC will not have a chance to do anything. I 
conclude that since Route has this property, we do not want to use 
Route. We need an extension to resolve this... it may be a new 
mechanism, or it may be a Route extension... but stating that Route 
"just works", which is supposed to be the advantage of using Route, is 
not true.

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Mar 2004 17:47:17 -0500

Rohan,

I want to clarify what you are proposing here.

When you say "T responds with an alternate offer" or "T tacks on an 
alternate offer", are you suggesting that T insert the old offer and the 
alternate offer in a multipart/alternative body?

That is an interesting idea. But I think we would need some enhancements 
to the offer/answer model to support that. Currently we have rules about 
how the offer relates to the answer. With this extension, there need to 
be rules for how an alternative offer relates to the original offer, and 
on how the recipient interprets a single answer to alternative offers, 
especially since the recipient may not have seen the alternatives.

But mostly I think this is silly. If the UAC knows about the transcoder, 
then it should be between the transcoder and the UAS. If the UAS knows 
about the transcoder then *it* should be between the UAC and the 
transcoder. It is only when neither the UAC nor the UAS know about the 
transcoder that it needs to be between them. That can't work unless 
there is no security, or at least the transcoder has the credentials to 
act as the UAS.

	Paul

Rohan Mahy wrote:
> 5. B authorizes the new session description as inserted on behalf of the 
> UAC
> 6. B responds with a 2xx and its offer to the revised answer provided by T
> 2. T tacks on an alternate offer (signed by T) that A can use instead of 
> A's offer

---

From: Volker Hilt <[email-masked]>
Date: Fri, 12 Mar 2004 16:18:35 -0500

Rohan,
An issue might be that a UA is free to do whatever it wants with the 
remaining Route header values in a message (i.e. if the service wasn't 
the last Route header entry). This is in contrast to a proxy, for which 
Route header processing is well defined. Thus, a UAC would not know if 
all entities in the Route header will actually be visited.

> [...] Taking this a step  
I believe the difference is that these entities are still proxies and 
not B2BUAs. Thus, there is no change in the semantics of the Route header.

Thanks,

Volker