RE: [Sip] sips: upgrading allowed or not

["Francois Audet" <[e-mail]>]

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