RE: [Sip] sips: upgrading allowed or not

["Hadriel Kaplan" <[e-mail]>]

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