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

From: [email-masked]
Date: Wed, 8 May 2002 13:33:28 +0300

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

Comments?

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: "Dean Willis" <[email-masked]>
Date: Wed, 8 May 2002 11:06:00 -0500

> was present in the request.

I believe this works. 

--
Dean