Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed?

From: [email-masked]
Date: Wed, 8 May 2002 17:43:39 +0300

Hi Bob!

Fair summary. However, I have a slighly different proposal.
Comments inline

cheers,
 Bernie 

> -----Original Message-----
> From: ext Bob Penfield [mailto:[email-masked]]
> Sent: 08 May, 2002 17:28
> To: Honeisen Bernhard (NET/Helsinki); Khartabil Hisham (NMP/Helsinki);
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path
> needed?
> 
> 
> I think I agree with Bernie's proposal, but let me summarize 
> the normative
> stuff for clarity.
> 
> 1) A UA that is willing to have Path headers inserted by intervening
> elements(proxies) MUST include Supported:path in the REGISTER request.
> 
> 2) An intervening element MUST NOT add a Path header if 
> Supported:path is
> not present.

What about:
2) An intervening element MUST NOT add a Require:path header and SHOULD
   NOT add a Path header if Supported:path is not present.

> 3) An intervening element that adds a Path (only when 
> Supported:path is
> present) SHOULD insert Require:path (if it is not already present) to
> guarantee that registrar supports 'path'.

What about:
3) An intervening element that adds a Path only when Supported:path
   is present) MAY insert Require:path (if it is not already present) to
   guarantee that registrar supports 'path'.

> 4) A registrar that receives a request with Path headers but does not
> include Supported:path MUST ignore the Path headers. If the registrar
> generated an error response in this case, there would be no 
> way for the UA
> to successfully register assuming that element that illegally 
> added the Path
> header would do it on every REGISTER attempt.
> 
> 5) If a UA gets a 420 response to the REGISTER request with
> Unsupported:path, then it SHOULD re-submit the REGISTER without
> Supported:path. This will prevent any intervening element 
> from adding a path
> or a Require:path (given rule 2) allowing the request to succeed at a
> registrar that does not support 'path'.
> 
> cheers,
> (-:bob
> 
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> [email-masked]
> 
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>;
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, May 08, 2002 9:11 AM
> Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path
> needed?
> 
> 
> 
> 
> > -----Original Message-----
> > From: Khartabil Hisham (NMP/Helsinki)
> > Sent: 08 May, 2002 14:39
> > To: Honeisen Bernhard (NET/Helsinki); [email-masked];
> > [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: 
> Require:path
> > needed?
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Honeisen Bernhard (NET/Helsinki)
> > > Sent: Wednesday, May 08, 2002 1:33 PM
> > > To: [email-masked]; [email-masked]
> > > Cc: [email-masked]
> > > Subject: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path
> > > needed?
> > >
> > >
> > > > -----Original Message-----
> > > > From: ext Dean Willis [mailto:[email-masked]]
> > > > Sent: 07 May, 2002 21:47
> > > > To: 'Bob Penfield'
> > > > Cc: [email-masked]; [email-masked]; 
> Honeisen Bernhard
> > > > (NET/Helsinki)
> > > > Subject: RE: WGLC for draft-willis-sip-path-05:
> > Require:path needed?
> > > >
> > > >
> > > > Bob said:
> > > > > Maybe I am missing something, but how do we make sure the
> > > > > registrar can support the Path header? The UA probably does
> > > > > not care, but the intervening proxies probably need to know
> > > > > that the "Path" cannot honored by the registrar. I suppose
> > > > > the proxy could insert Require:path if it saw the
> > > > > Supported:path in the request.
> > > > >
> > > > > I think the spec should say that UAs that want to allow a
> > > > > Path to be inserted MUST add Supported:path to the REGISTER
> > > > > request and that a proxy MUST NOT add a Path header if
> > > > > Supported:path is not present. The proxy inserting a Path
> > > > > header SHOULD add Require:path to guarantee that the
> > > > > registrar supports Path. If the request is rejected with 420,
> > > > > the UA SHOULD resubmit without Supported:path.
> > > >
> > > > I think this works. It does have the side effect that a UA
> > > > that doesn't
> > > > know about Path can't be served by a proxy network that
> > > > requires it even
> > > > though there are no functional changes needed in the UA.
> > >
> > > Do we really want, that the proxies can just insert Paths without
> > > the consent of the user? This is related to the first item
> > > in the Security considerations section.
> > > As the Supported header field can be integrity protected,
> > > the registrar has means, to see, whether the UA really
> > > knows, what is going on with Path.
> > >
> > > Besides this, an implementation of the Path to the UA
> > > seams fairly easy.
> > >
> > >
> > > My proposal is similar as Bob's:
> > >
> > > The registrar ignores any Path header if the Supported:path
> > > is not present in that REGISTER request.
> > >
> > > A proxy, which inserts a Path header and really wants to stay
> > > on the route for incoming calls, inserts also a Require:path
> > > (if not yet present).
> > >
> > > The registrar decides then based on these two headers, what to do:
> > >
> > > - The Require:path has the normal meaning:
> > >   -> send 420 response, if registrar does not understood path
> > >
> > > - If Supported:path is present in the REGISTER request
> > >   --> use path as described in the I/D.
> > >
> > > - If Supported:path is _not_ present in the REGISTER request
> > >   --> _ignore_ any Path,
> > >       regardless of any possible Require:path present
> > >
> > >
> > > The only problem I see lasting is, that proxies could prevent
> > > a user from registering by just inserting a Require:path.
> > > This looks like a more general problem as this can be
> > > done with any option tag.
> > >
> > > Solution:
> > >
> > > -> after a 420 the UA tries to send the request without
> > > Supported:path.
> > >
> > > -> Proxies MUST NOT insert a Require:path, if no Supported:path
> > > was present in the request.
> >
> >
> >
> > Are you suggesting that a proxy must remember requests that
> > it processed earlier?
> 
> No, not at all. Why do you think it has to remember?
> 
> > First you mention that a proxy can insert a path-header
> > without a supported-header (or that is what it sounded like
> > at least).
> 
> If it does, the registrar will ignore any Path header, as
> no Supported:path is present in the REGISTER request in
> question. Such behaviour would allow easier implementation
> of proxies. (But I don't argue, if people think it's better,
> if proxies must not insert any Path stuff, if there is
> no Supported header in the REGISTER request in question.)
> My proposal is just, that the proxy just MUST NOT insert
> any Require:path, if Supported:path was not present.
> 
> > Then you say that if a 420 is returned to TU, a
> 
> TU ???
> 
> > proxy can't insert a path-header in the newly generated
> > request unless a Supported:path is present.
> 
> The proxy makes its decision on whether to insert a
> Require:path based on the presence of the Supported:path .
> 
> > I vote for the supported header to be there from the first
> > REGISTER sent.
> 
> What do you mean here?
> Do you mean, Supported:path present in first REGISTER attempt,
> or do you mean Supported:path present in every REGISTER request?
> 
> cheers,
>  Bernie
> 
> 
> 

_______________________________________________
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: "Bob Penfield" <[email-masked]>
Date: Wed, 8 May 2002 11:20:24 -0400

> <snip>
> <snip>

Given rule 4, any Path header inserted by the proxy will be ignored by the
registrar. I see no reason to make this a SHOULD NOT instead of a MUST NOT.
It all goes back to the "knowledge and consent of the user" requirements.

>    guarantee that registrar supports 'path'.

The only reason you would not include it is if you were sure that the
registrar supported it or you did not care. For an implementation
requirement, I think SHOULD is appropriate. Certainly an implementation can
have a configuration option to prevent the addition of Require:path. Maybe
you could include a recommendation that it be configurable.