RE: [Sip] sips: upgrading allowed or not

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

 


> 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

Correct. There is no way to make it work in real life.

I mean, if you want to ugrade there is a way to do it that
does work: you Redirect instead of retargeting.

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

Huh? Legacy-3261 proxies doing upgrades? I've never seen such a
think, and I'd argue that it would be broken anyways if it did.


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

We could leave it in there for "theoretical" legacy 3261 proxies doing
upgrades, but I think it will just encourage people to do evil (and it
will still break things).

Note that there was no SIPS in 2543, so it wouldn't apply there.

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