Subject: RE: [Sip] The Problem with PRACK

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 9 Mar 2006 01:18:57 -0600

We can do for SIPS only.

Thx
Samir 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, March 08, 2006 7:29 PM
To: Audet, Francois [SC100:3055:EXCH]
Cc: IETF SIP List
Subject: Re: [Sip] The Problem with PRACK

Francois Audet wrote:
> I'm ok with the suggestion to deprecate using PRACK for Offer/Answer. 
> 
> While we are at it, why not go for deprecating the use PRACK 
> altogether when TCP transport is used?

Explain to me again how you would know that reliable transport is used
end to end?

	Paul

> On Mar 8, 2006, at 15:51 , Rohan Mahy wrote:
> 
>> Hi,
>>
>> A things about PRACK come immediately to mind that are a pain to
>> implement:
>>
>> 1) The UAS has to queue provisionals until it receives a PRACK for 
>> the first provisional.  This is due to RSeq starting at an arbitrary 
>> value instead of just starting at 1.  This is probably the simplest 
>> to fix, by just requiring the UAC to always start with a RSeq of 1.
>>
>> 2) Multiple unacknowledged provisionals can be in flight at the same 
>> time.  We could potentially eliminate this requirement by 
>> acknowledging the current status instead of the whole history.  In 
>> other words, when the UAS sends a new reliable provisional, it 
>> decides which (if any) of the previously sent provisionals are still 
>> relevant and sends all of them (as sipfrags or something) as a single

>> reliable request.
>>
>> 3) If you "answer" and want to deliver a 200 OK, you have to queue it

>> and wait if you are waiting for a PRACK to an offer or answer. 
>> Keeping track of when you can send the 200 would be easier if we did 
>> something like I recommend in #2.
>>
>> 4) Even for an acknowledged provisional, you still have to retransmit

>> approximately every minute (I forget exactly) to prevent old proxies 
>> from deleting state for your transaction.  This is one of those minor

>> annoyances that is *almost* operationally irrelevant, and unlikely to

>> not get coded.  My proposal for simplification is to retransmit the 
>> latest reliable provisional in exactly the same way that the UAS 
>> retransmits unreliable provisionals.  Who cares if there is an extra 
>> message or two for a call with 1 minute + post-answer delay?
>>
>> 5) I would deprecate the PRACK/200 (PRACK) offer/answer exchange.  I 
>> talked Jonathan into this, and I've been sorry I did ever since.  My 
>> apologies to everyone for making a bad decision.
>>
>> Hope this helps.
>> thanks,
>> -rohan
>>
>> On 3/7/06, *Jonathan Rosenberg* <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     At the last IETF, there was a lot of discussion and argument
around
>>     PRACK. The spark of this debate was the ICE specification, which
had
>>     words in it requiring the usage of PRACK and UPDATE in order to
work
>>     with early media. There was strong pushback from many
implementors
>>     that
>>     anything requiring PRACK is unacceptable. Rohan put up a slide
(IIRC)
>>     that showed the state machine in his implementation resulting
from
>>     PRACK, and it was not pretty.
>>
>>     So, I'd like to discuss exactly what IS the problem with PRACK?
There
>>     are really two pieces of state machinery in play here. One piece
>>     is the
>>     complication that PRACK introduces into the offer/answer model.
With
>>     PRACK, you can now get a final answer in the 18x, and then send a
new
>>     offer in UPDATE, or even in PRACK itself. Another piece is the
state
>>     machinery with the retransmissions itself - correlating the PRACK
>>     with a
>>     particular reliable provisional response and causing it to stop.
>>
>>     In a chat with Flemming today, he suggested in interested remedy
>>     to our
>>     PRACK dilemma. Why not revise PRACK so that you can't send an
offer or
>>     answer with it; it has no impact on the set of allowed O/A
exchanges
>>     defined by RFC 3261. I'm not sure if that would consequently
break the
>>     preconditions mechanism, but maybe there are some kind of
offer/answer
>>     limitations that would simplify things.
>>
>>     So, this is one idea. I'd like for people who have complained
about
>>     PRACK implementations to speak up and indicate what exactly makes
>>     it so
>>     complicated for them.
>>
>>     Thanks,
>>     Jonathan R.
>>     --
>>     Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>>     Cisco Fellow                                   Parsippany, NJ
>>     07054-2711
>>     Cisco Systems
>>     [email-masked]
>>     <mailto:[email-masked]>                              FAX:  
>>     (973) 952-5050
>>     http://www.jdrosen.net                         PHONE: (973)
952-5000
>>     http://www.cisco.com
>>
>>     _______________________________________________
>>     Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>     <https://www1.ietf.org/mailman/listinfo/sip>
>>     This list is for NEW development of the core SIP Protocol
>>     Use [email-masked]
>>     <mailto:[email-masked]> for questions on
current sip
>>     Use [email-masked] <mailto:[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] 
>> <mailto:[email-masked]> for questions on current 
>> sip Use [email-masked] <mailto:[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

_______________________________________________
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: Thu, 9 Mar 2006 13:17:20 -0600

On Mar 9, 2006, at 1:18 AM, Samir Srivastava wrote:

> Paul said:

Nope. sips only assures TLS as far as the proxy servicing the AOR.  
Now I suppose that once your dialog is established and you have a  
SIPS Contact: you have stronger assurances, but this isn't nailed  
down as that SIPS: contact could actually be a GRUU.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 12 Mar 2006 12:28:29 -0800

SIPS does not imply TCP. For example SIPS can be sent over IPSEC protected
connections.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 13 Mar 2006 08:50:53 -0600

Cullen Jennings wrote:
> SIPS does not imply TCP. For example SIPS can be sent over IPSEC
> protected connections.

Cullen: I am curious -- Will it be valid to specify a sips URI
over UDP if IPSec is employed beneath (i.e., don't use DTLS, but
only upgrade the scheme to sips because of IPSec)?

To me, the use of sips has been associated with a transport;
i.e., rfc3261 probably assumes that a sips URI without a
transport parameter applies to TCP only.  Supporting sips over
SCTP would mean inserting a "transport=sctp" parameter, and once
DTLS becomes an RFC, one could also use "transport=udp".

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Mon, 13 Mar 2006 08:14:40 -0800

It's been pointed to me that I was just plan wrong on the statement below.
IPSEC is not allowed to be used for a SIPS URI when trying to reach the
domain in the target.

Sorry, Cullen

---

From: Dean Willis <[email-masked]>
Date: Mon, 13 Mar 2006 12:27:10 -0600

> IPSEC is not allowed to be used for a SIPS URI when trying to reach  

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.

This was established in 3261 at my insistence (over the objections of  
Jon, who hates it) because I had a use case with a SIPS AOR-serving  
proxy on the same LAN as my UDP-only SIP phone, and I wanted to be  
able to protect the "open internet" signaling path with sips.

So, sips still doesn't assure you end-to-end TCP. Or security, for  
that matter.

This also has implications for congestion control and the sending of  
large messages. You may recall a draft a few years ago that tried to  
establish assured end-to-end- transit using congestion-controlled  
links, so that we could send larger MESSAGE requests. The approach  
generated little traction, because people were thinking that SIP/UDP  
would be vastly more efficient than SIP/TCP, and the "wireless  
market" was dominating our discussion, and there was widespread  
superstition that TCP just wouldn't work in a wireless environment.

Now we've realized that SIP requests themselves (not counting MESSAGE  
bodies) are starting to exceed the UDP single-packet limit. This,  
combined with the the advent of DTLS, better knowledge about TCP  
usage (people understand select/poll)  and the broader acceptance in  
wireline applications might result in an opportunity to rethink some  
things here.

Personally, I'm in favor of simply deprecating SIP/UDP (and forking,  
but I can't say that).

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 13 Mar 2006 22:24:44 -0800

> AOR. The AOR to Contact vector could be UDP/IPSEC, or even just plain

I think we have a gathering amount of evidence that we want to update this
regardless of UDP or PRACK. 

) by vtg-um-e2k4.sj21ad.cisco.com
	([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; 
	Tue, 14 Mar 2006 06:24:44 +0000
Date: Mon, 13 Mar 2006 22:24:44 -0800
Subject: Re: [Sip] The Problem with PRACK
From: Cullen Jennings <[email-masked]>
To: Dean Willis <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Francois Audet <[email-masked]>,
	Paul H Kyzivat <[email-masked]>

> AOR. The AOR to Contact vector could be UDP/IPSEC, or even just plain

I think we have a gathering amount of evidence that we want to update this
regardless of UDP or PRACK.

---

From: Dean Willis <[email-masked]>
Date: Tue, 14 Mar 2006 01:07:39 -0600

> 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

---

From: Aki Niemi <[email-masked]>
Date: Tue, 14 Mar 2006 12:22:25 +0200

ext Dean Willis wrote:
> 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.

I agree with you here. But there seems to be quite considerable pushback
in this community towards HTTP connect. After all, this wasn't an option
even for MSRP, and there backwards compatibility wasn't an issue, as it
most definitely is here.

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

Yup. There are of course folks that think hop-by-hop is a good thing,
because it potentially enables secure media while letting LI boxes
recover the session keys. Except if something like DTLS with public key
authentication is used, instead of, say, the PSK ciphersuites.

Cheers,
Aki