Subject: RE: [Sip] The Problem with PRACK

From: "Brian Stucker" <[email-masked]>
Date: Tue, 14 Mar 2006 10:54:59 -0600

Based on your proposals below, cryptographically transparent versus redirection:

How would you go about addressing applications like CPL that need to run timers for service logic and thus need to have some level of control over the session (not necessarily what's in the body of the messages, just where they're going) if a redirection model is used?

For example, without mucking about with what's inside the request, triggering off of the request URI of an INVITE to forward to destination A for X seconds and then to destination B. In this example the next hop changes over time for the same request and does not seem possible using redirection. This seems to preclude redirection as a general solution and drive towards requiring a proxy to be cryptographically transparent.

If the proxy is transparent, then how do you go about not precluding deep-packet inspection issues raised by applications such as QoS enforcement, network enforced identity or other services? It seems to me that HTTPS may make a bad model in that I'm unaware of any HTTPS-based application that has a box in the middle that needs to inspect and enforce certain characteristics of the request before it is handled by the final consumer of that request.

This seems to preclude cryptographic transparency as a general solution. 

I'm sure either can be used effectively in many application spaces, but it does not seem that either can be used as a general solution in the protocol itself.

Regards,
Brian

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Tuesday, March 14, 2006 1:08 AM
To: Cullen Jennings
Cc: [email-masked]; Audet, Francois [SC100:3055:EXCH]; Paul H Kyzivat
Subject: Re: [Sip] The Problem with PRACK

On Mar 14, 2006, at 12:24 AM, Cullen Jennings wrote:

> On 3/13/06 10:27 AM, "Dean Willis" <[email-masked]> wrote:
>
>> Right. But, SIPS is only required as far as the proxy serving the
>> AOR. The AOR to Contact vector could be UDP/IPSEC, or even just plain
>> unsecured UDP.
>
> I think we have a gathering amount of evidence that we want to  
> update this
> regardless of UDP or PRACK.

It's true that SIP proxies just don't work "right" with SIPS as it is.

When people first look at the "SIPS is only valid to the serving  
proxy" model they assume that simply changing the requirement to say  
that the proxy-to-UA leg must also be SIPS protected would provide a  
satisfactory answer. It doesn't, and this requires some careful  
thinking.

What security do you mandate on the serving-proxy to UA link? TLS?  
TLS supports many different ciphersuites. What keeps the crypto on  
the SP-UA link from being watered-down? Would other protections like  
IPSEC suffice? How would you end-to-end negotiate the cryptography so  
that the originating UA could believe that the entire chain was  
protected to some minimal level? And how do you offer some level of  
security to an IMS fashion-victim who is always going to be exposed  
to MITM attacks from his own service provider by design?

Personally, I think the only way SIPS really gives us the level of  
protection we have come to expect from HTTPS is if it is used end-to- 
end, either by abandoning proxy-routing in favor of a redirect model,  
or by causing the proxies to be cryptographically transparent as is  
done with HTTPS proxies.

This is an important thing to note: HTTPS proxies do NOT "see inside"  
the HTTPS stream. All they do is pass it along, unchanged, to the  
next hop. It could actually be some other protocol than HTTP, and  
they don't care and can't tell. To-date, we haven't treated SIPS  
proxies that way, and instead presume they have access to the full  
stream, in many cases "write access" so that they can munge various  
header fields about.

--
Dean

_______________________________________________
Sip mailing list  https://www1.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://www1.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: Dean Willis <[email-masked]>
Date: Wed, 15 Mar 2006 16:20:29 -0600

On Mar 14, 2006, at 10:54 AM, Brian Stucker wrote:

> How would you go about addressing applications like CPL that need  
> to run timers for service logic and thus need to have some level of  
> control over the session (not necessarily what's in the body of the  
> messages, just where they're going) if a redirection model is used?
>

My personal view is that any application that is suitable for a  
"proxy" can work with a proxy providing cryptographic transparency.  
If it can't, it's a UA application, not a proxy application. For  
example, stateful forking (which is heavily overused) should be a UA  
(possibly B2BUA,) application, and that UA needs to either be the  
terminal node or be cryptographically visible (from an OPES  
perspective) to the terminal nodes. They NEED to know that it is  
there and is mucking with things.

> For example, without mucking about with what's inside the request,  
> triggering off of the request URI of an INVITE to forward to  
> destination A for X seconds and then to destination B. In this  
> example the next hop changes over time for the same request and  
> does not seem possible using redirection. This seems to preclude  
> redirection as a general solution and drive towards requiring a  
> proxy to be cryptographically transparent.

Only when you REALLY NEED that sort of application (and then you use  
a B2BUA that's cryptoparticipant). It would be much easier to solve  
this in the general case by returning something like a 302 to the  
requestor, where the 302 response contains an ordered contact list  
along with "try" timers so that the caller's node can be responsible  
for its own processing. One could go so far as to return an entire  
CPL to the caller for processing if more than sequence-and-timer  
information is needed.

When do you REALLY NEED that sort of processing in-proxy? Only when  
1) The endpoint is broken and you're doing "in-network protocol  
conversion", 2) you have a privacy constraint. If you have a privacy  
constraint, you need a cryptoparticipant service node that's also  
handling media relay OR you break your privacy constraint on the  
media channel anyhow.

This is in large part why the response-identity problem is so hard to  
solve in general. With SIP as-is, including "proxy retargeting", we  
have NO bounded expectation for where a response might be coming from.

Consider a model, where all nodes are either cryptotransparent, or  
visibly cryptoparticipant:

We initially launch a request to an AOR, targeting the known service  
element (which we might call "proxy" even though it's here acting as  
a UAS) for that AOR. We find this service element using RFC 3262  
resolution or perhaps a P2P overlay mechanism.  We might traverse one  
or more cryptotransparent proxies getting there -- they just don't  
matter to the service. The AOR's serving element responds with a 302.  
We can evaluate the identity of that respondent, because WE KNOW who  
we were expecting to have respond (the service element we discovered  
earlier). We get a new target (the registered contact) in the 302. We  
send a new request to that target, and we can evaluate its identity  
when it responds, because we KNOW who we were expecting to have  
respond (the contact). The unbounded response-identity problem is  
solved.

> If the proxy is transparent, then how do you go about not  
> precluding deep-packet inspection issues raised by applications  
> such as QoS enforcement, network enforced identity or other  
> services? It seems to me that HTTPS may make a bad model in that  
> I'm unaware of any HTTPS-based application that has a box in the  
> middle that needs to inspect and enforce certain characteristics of  
> the request before it is handled by the final consumer of that  
> request.

Duh! The primary goal IS precluding deep-packet inspection attacks.  
Any "service" built on that sort of model is either criminally stupid  
or overtly oppressive. Both are counter to the spirit of the IETF,  
including RFCs 2804 and 3552. We should STOP DESIGNING TO THAT MODEL  
IN THE IETF.

Services might reasonably be be cryptoparticipant, in which case they  
should be visible to the endpoint, which need to actively allow the  
involvement of those services. "Stealth attacks" are things that  
people attacking a system do -- they shouldn't be designed into the  
system.

> This seems to preclude cryptographic transparency as a general  

Clearly we have a different priority list. Go buy a circuit switch if  
you want wires. Oh never mind, I think you already have some ;-) !

--
Dean