Subject: [Sipping] Re: Transcoding and route entries

From: William Marshall <[email-masked]>
Date: Tue, 16 Mar 2004 12:17:02 -0500 (EST)

A transcoder is really a "man in the middle" and it is "attacking" 
the signaling and media stream.  So if the endpoints really
desire secure signaling and/or media, then one of them needs to
handle the transcoding issue by themselves.  We then end up with a
connection like this, with possibly two separate SIP sessions:
     A <=====> B [<===> T]
I believe there are already adequate mechanisms built into SIP and
lots of other protocols to implement this case.

And if the originator of the call knows that it will need a transcoder,
it can force one.  Just place the call to the transcoder, and have it
place a call to the destination.  There already are mechanisms to
enable this, like the conference server.  Security is explicitely 
end-to-end, with the transcoder being two of the (4) ends.
     A <====> T <====> B

The more interesting case is when the Transcoder really is a "man
in the middle", and when it is allowed (and intended) to attack the
signaling/media, and when it is inserted by a proxy without the
explicit request of either endpoint.  From the service-provider
point of view, of course we want to make connections and not just
tell people why they can't (e.g. no compatible codecs).

Since option #2 (back in Gonzalo's original email that started this
thread) is the one that is consistent with proxy rules, I favor that
choice - use the Route header.

Bill Marshall
[email-masked]

-----original message-----
From: Rohan Mahy <[email-masked]>
Date: Mon, 15 Mar 2004 09:15:23 -0800
To: Gonzalo Camarillo <[email-masked]>
Cc: Eric Burger <[email-masked]>, Rohan Mahy <[email-masked]>,
   Jonathan Rosemberg <[email-masked]>,
   Adam Roach <[email-masked]>,
   Henning Schulzrinne <[email-masked]>, sipping <[email-masked]>
Subject: [Sipping] Re: Transcoding and route entries

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

> Rohan,
>
>> 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.
>
> 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 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.
>
>
> 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.

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 
> approach was right, this would be a prefectly acceptable behavior.

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.

> 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.

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"

> 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.

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

> Thanks,
> Gonzalo

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Mar 2004 11:51:50 -0500

I'm with Bill on this. I also raised the issue of this other topology 
earlier, but it was blown off as being out of scope for this discussion.

But I think Bill has enunciated the difference better.

1)if the UA knows that a transcoder is needed
   (either a prior, or because it has received some
   policy on the subject, or because an attempt
   without failed) then all the needed mechanisms
   are there for it to involve a transcoder in
   the call with no security issues.

   if the UA doesn't know that a transcoder is needed,
   and a proxy decides it is, the proxy can throw
   it back to the UA, turning it back into this case.

2)If it doesn't want to do that, then the call
   topology being discussed in this thread is a
   possibility. But it will only work in certain
   restricted cases. If the proxy can tell that
   the case applies, go ahead. And in this set
   of circumstances, adding a Route header is
   a good solution.

I'm not convinced there is any good reason to standardize (2). It seems 
to be a hack with limited applicability. People will probably do it even 
if it isn't standardized. That seems like a good way to leave it.

	Paul