RE: [Sip] sips: upgrading allowed or not

["Samir Srivastava" <[e-mail]>]

Hi Hadriel,

Sorry I am still catching up this thread.

My understanding was that this document will just state what SIPS
provides as per 3261 .
Nothing to modify the behaviour of 3261. Looks like, we are patching it
for STANDARDS track doc.

Let us stop worrying more about upgrade etc, till we see at one place
(in the next version of cipher-suites) ugliness of the SIPS and the need
for the clear defintion of secure protocols etc, and then decide do we
need to spend cycles on this stuff. 

BTW, there is no SIPS in 2543. I don't recollect which bis got it added.
Here legacy should mean 3261 only, if SIPS doesn't get deprecated, and
we start working on 3261 bis etc...

Thx
Samir

>-----Original Message-----
>From: Hadriel Kaplan [mailto:[e-mail]] 
>Sent: Wednesday, March 28, 2007 3:59 PM
>To: Audet, Francois (SC100:3055); 'Jonathan Rosenberg'; 'IETF SIP List'
>Subject: RE: [Sip] sips: upgrading allowed or not
>
>Hmmm... then I think I did miss your point.
>Your point then is to remove the upgrade scenario from the 
>draft, and any attempt to make it work, and instead disallow 
>it - and thus any legacy-3261 proxy in the path still doing it 
>will be found out if it breaks things, and subsequently fixed 
>to not do so?
>
>So my only point to that then is that it won't mean you can 
>remove section
>4.1 of your draft (though it should be reworded I guess) - 
>because a sips request arriving at a UAS is still not known to 
>have started as sips, because it may have crossed an upgrading 
>legacy-3261/2543 proxy en route.
>
>-hadriel
>
>
>> -----Original Message-----
>> From: Francois Audet [mailto:[e-mail]]
>> Sent: Tuesday, March 27, 2007 8:18 PM
>> To: Hadriel Kaplan; Jonathan Rosenberg; IETF SIP List
>> Subject: RE: [Sip] sips: upgrading allowed or not
>> 
>> I'm not sure I follow your point...
>> 
>> If you "upgrade", you will know soon enough because things 
>will start 
>> breaking, and you'll get customer complaints. This 
>"breaking" part is 
>> the reason why I want to deprecate upgrades.
>> 
>> As for the "checks", it seems to me that using SIPS as a "check" is 
>> not a good idea (at least on it's own) as it is very weak. To me, 
>> that's one of the possible topic for "Furture work in 
>specification". 
>> I think this section on checks is misleading and it 
>contradicts other 
>> parts of the document that explain that SIPS is not an 
>indication that 
>> the request was indeed forwarded over TLS on each hop.
>> 
>> If people think we need a indication of end-to-end security (of of 
>> security on each hop), then bring it in. That's what I tought people 
>> wanted to talk about in Prague...
>> 
>> 
>> > -----Original Message-----
>> > From: Hadriel Kaplan [mailto:[e-mail]]
>> > Sent: Tuesday, March 27, 2007 17:03
>> > To: Audet, Francois (SC100:3055); 'Jonathan Rosenberg'; 'IETF SIP 
>> > List'
>> > Subject: RE: [Sip] sips: upgrading allowed or not
>> >
>> > I also agree upgrading should not be allowed to make life simpler, 
>> > but my concern is isn't it too late?
>> >
>> > I mean how many 3261-compliant boxes out there will retarget 
>> > upgrade?  So if sips suddenly becomes a (more) popular thing, how 
>> > would the UAS know if the request traversed a 3261-only 
>proxy which 
>> > upgraded, vs. traversed this newer proposal proxies only?
>> >
>> > It will have to do the checks no matter what, no?  And the bad 
>> > scenario of sips contact can still occur. (or maybe I missed the 
>> > point) But at least if you specify NOT to do it and why in your 
>> > draft then it will help proxy makers avoid the sips 
>contact issue.  
>> > So it still has some value.
>> >
>> > -hadriel
>> >
>> >
>> > > -----Original Message-----
>> > > From: Francois Audet [mailto:[e-mail]]
>> > > Sent: Tuesday, March 27, 2007 3:36 PM
>> > > To: Jonathan Rosenberg; IETF SIP List
>> > > Subject: RE: [Sip] sips: upgrading allowed or not
>> > >
>> > > I agree with Jonathan's proposal.
>> > >
>> > > Here is a slighly different perspective on it however. I'll keep 
>> > > rethorical arguments out of it, and stick to protocol.
>> > >
>> > > - Disallowing re-targeting "upgrades" from SIP to SIPS 
>by a proxy 
>> > > would be
>> > >   a normative change to RFC 3261. Section 26.4.4 
>describes it (3rd 
>> > > paragraph
>> > >   on p. 250). That is just an observation.
>> > >
>> > > - The fact that it is currently allowed means that the UAS
>> > receiving
>> > > the request
>> > >   has to go through some fairly esoteric logic to "guess" if the 
>> > > request was
>> > >   sent securily on each hop or not. This is described in
>> > paragraph 4
>> > > of p. 250,
>> > >   and section 4.1 of draft-ietf-sip-sips-02 also describes it, 
>> > > with some modifications.
>> > >   Those procedures are extremely cludgy and non-deterministic. 
>> > > They are also misleading
>> > >   for the UAS, and inconsistent with the use of SIPS and SIP as 
>> > > described in this draft
>> > >   (i.e., for the other scenarios of forwarding and retargeting). 
>> > > In all other instances,
>> > >   the idea is that when a request is forwarded/retargeted,
>> > the scheme
>> > > is preserve.
>> > >   I'd really like to get rid of section 4.1.
>> > >
>> > > 	- Jonathan Peterson was proposing that the UAS inspect
>> > the To header
>> > > to see if
>> > >         the request was initially targeted at SIPS. This is
>> > a subset
>> > > of the procedures
>> > >         of 4.1/draft-ietf-sip-sips and of RFC 3261 (they 
>add stuff 
>> > > like looking at
>> > >         Via and other fields).
>> > >
>> > > - This "upgrading" also forces the use of the double
>> > Record-Route in
>> > > section 4.2
>> > >   of draft-ietf-sip-sips-02. Since we agreed to deprecate
>> > the last hop
>> > > exception
>> > >   for downgrading, the SIPS-to-SIP Record-Route scenario will be 
>> > > removed from the
>> > >   -03 version. Removing the "upgrade" scenario would also
>> > remove the
>> > > double
>> > >   Record-Route for the SIP-to-SIPS, and the net-net is that
>> > the whole
>> > > section
>> > >   4.2 could be removed.
>> > >
>> > > - Because of rules described in RFC 3261, if a UAS receives an 
>> > > incoming request with a
>> > >   SIPS Request-URI, it MUST use a SIPS contact. This is a
>> > big problem
>> > > for the sender
>> > >   of the initial request that initiated the dialog if that
>> > UAC did not
>> > > support SIPS.
>> > >   If Record-Routing is not used, it will just plainly not work. 
>> > > The UAC will not be
>> > >   able to send further requests (like BYE for example). If 
>> > > Record-Route is used, it
>> > >   might work (or it might not). The reason it might not
>> > work is that
>> > > there is possible
>> > >   that the UAC might "choke" on the SIPS URI in the Contact
>> > (because
>> > > it doesn't understand
>> > >   how to parse it).
>> > >
>> > > 	- We have corrected to types of problems everywhere
>> > else in this
>> > > draft. There was
>> > > 	  quite a few of them in previous versions. This is the
>> > only one
>> > > remaining.
>> > >
>> > > - Note that it would still be possible to "upgrade" by 
>sending SIP 
>> > > over TLS. In fact, I would
>> > >   argue that we need to put a requirement to do so when there is 
>> > > already a TLS connection
>> > >   opened with the target (as would be the case if Outbound
>> > was used,
>> > > and the registration was
>> > >   done over TLS).
>> > >
>> > > In summary, I favor deprecating the "retargeting upgrade"
>> > scenario for
>> > > the following reasons:
>> > >
>> > > - It greatly simplifies the draft, eliminating sections 4.1 and 
>> > > 4.2 completely.
>> > >
>> > > - It is much less confusing for the far end.
>> > >
>> > > - It avoids some nasty protocol level problems that 
>"break" things.
>> > >
>> > > - You can still use TLS for transport for delivering to
>> > that last hop.
>> > >
>> > > > -----Original Message-----
>> > > > From: Jonathan Rosenberg [mailto:[e-mail]]
>> > > > Sent: Tuesday, March 27, 2007 06:40
>> > > > To: IETF SIP List
>> > > > Subject: [Sip] sips: upgrading allowed or not
>> > > >
>> > > > During the Prague IETF, I shared some opinions on what 
>I thought 
>> > > > sips needs to look like and why, and wanted to take 
>these to the 
>> > > > list.
>> > > >
>> > > > Firstly, what is the point of sips? What does it bring 
>a network 
>> > > > that it can't get with TLS on some hops, as needed?
>> > > > The answer is that certain security benefits are afforded
>> > if we can
>> > > > assure that every single hop from UAC to UAS was TLS
>> > protected, and
>> > > > that furthermore, this fact can be definitively known by the 
>> > > > UAC, UAS, and all proxies along the way. If we make the
>> > assumption that
>> > > > the UA's trust their proxies (please don't question the
>> > assumption
>> > > > in this thread), then SIPS provides you some very nice 
>security 
>> > > > properties - confidentiality and integrity from all 
>non-trusted 
>> > > > entities. We use this property all over our specs to
>> > secure various
>> > > > extensions.
>> > > >
>> > > > Given that, sips is broken if it doesn't provide that
>> > service (tls
>> > > > on each hop with knowledge of such by all entities). FOr this 
>> > > > reason, I think we need to eliminate the last hop exception 
>> > > > (uncontroversial I think), but furthermore, I believe
>> > this extends
>> > > > to retargeting as well.
>> > > > I think we clearly need to disallow retargeting or
>> > downgrading from
>> > > > a sips URI to a sip URI. I think that was also largely 
>> > > > non-controversial.
>> > > > However, I also want to disallow upgrading or retargeting
>> > from sip
>> > > > to sips. On this, there was some disagreement.
>> > > >
>> > > > The challenge Jon gave me at the mike was this. As 
>long as a UAC 
>> > > > inserts a sips URI into the To field and R-URI field when
>> > it emits a
>> > > > sips request, does not the presence of a sips URI in the
>> > TO field,
>> > > > and receipt over a TLS connection, assure that the request was 
>> > > > delivered over TLS at each hop? Had the request been sent
>> > originally
>> > > > to a sip URI and then upgraded, the TO field would not 
>have been 
>> > > > sips, but rather sip.
>> > > >
>> > > > I believe Jon is correct, however I still think it is 
>not a good 
>> > > > idea.
>> > > > My rationale is:
>> > > >
>> > > > 1. if upgrades are disallowed, redirecting from sip to sips 
>> > > > works much better. Such a redirection would necesarily have to
>> > go all the
>> > > > way to the UAC. If we allow upgrades, a proxy in the middle 
>> > > > could recurse and upgrade. In that case, if the reason for the
>> > redirection
>> > > > was that the UAS *wanted* TLS on each hop, recursing in
>> > the middle
>> > > > would destroy that possibility.
>> > > >
>> > > > 2. The architectural principle behind the first issue, more 
>> > > > generally, is that the meaning of sips is *SECURE ON EACH
>> > HOP FROM
>> > > > UAC TO UAS*. To me, this is fundamentally at odds with
>> > any notion of
>> > > > upgrade or downgrade.
>> > > >
>> > > > 3. Things become simpler if we forbid upgrades. We can
>> > eliminate the
>> > > > text on double-record routing sinec a proxy would never
>> > be sip/sips
>> > > > converting. I think it also just generally makes overall
>> > processing
>> > > > easier. SIPS means one thing and one thing only and 
>its terribly 
>> > > > clear what it means.
>> > > >
>> > > > As such, I stand by my argument that we should forbid upgrades.
>> > > >
>> > > > -JOnathan R.
>> > > >
>> > > > --
>> > > > Jonathan D. Rosenberg, Ph.D.                   600 
>Lanidex Plaza
>> > > > Cisco Fellow                                   Parsippany, NJ
>> > > > 07054-2711
>> > > > Cisco Systems
>> > > > [e-mail]                              FAX:
>> > [phone]
>> > > > http://www.jdrosen.net                         PHONE:
>> > [phone]
>> > > > http://www.cisco.com
>> > > >
>> > > > _______________________________________________
>> > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> > > > This list is for NEW development of the core SIP Protocol Use 
>> > > > [e-mail] for questions on current sip 
>> > > > Use [e-mail] 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 
>> > > [e-mail] for questions on 
>current sip Use 
>> > > [e-mail] 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 
>[e-mail] for questions on current sip 
>Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip