Re: R: R: [Sip] a question about IETF draft location conveyance 09

[Dean Willis <[e-mail]>]

Matt Lepinski wrote:
> James,
> 
> I do believe that the intent of Ted (as well as others in the GEOPRIV
> working group, including myself) is that if a UAC specifies
> "recipient=endpoint" then a compliant proxy will not 'read' the location
> body. In particular, "recipient=endpoint" indicates that a SIP proxy in
> the signaling path does not have permission to store the location (or
> any derived information) for longer than is necessary to forward the SIP
> message and does not have permission to send the location to any third
> party (for any reason including location-based routing) other than the
> next-hop SIP proxy. That is, the intent of "recipient=endpoint" that if
> a call requires location-based routing in order to succeed, then the
> call should fail.

RFC 2119 defines MUST NOT. It says:

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

7. Security Considerations

   These terms are frequently used to specify behavior with security
   implications.  The effects on security of not implementing a MUST or
   SHOULD, or doing something the specification says MUST NOT or SHOULD
   NOT be done may be very subtle. Document authors should take the time
   to elaborate the security implications of not following
   recommendations or requirements as most implementors will not have
   had the benefit of the experience and discussion that produced the
   specification

I can't see any failure of interoperability that results if a proxy
"reads" the location body in violation of the user's preference
described by "recipient=endpoint". I can also see application scenarios
(ex: emergency) where applications can be assured of not operating
unless the proxy violates this prohibition. So we've missed the #6
guidance on "MUST NOT".

Can we justify a "MUST NOT" based on security considerations? Given (as
in emergency) that there are applications in which the application MUST
read the location, I don't think so.

What we really have is guidance that says, in normal operation, proxies
don't include the location in application logic when recipient=endpoint
is specified by the user, because in general this indicator means that
the user is asking the proy to NOT include the location in application
logic by attaching this modifier.

So we're at the level of a "SHOULD NOT", not a "MUST NOT" as described
by RFC 2119. And even then I suspect the discussion of this requirement
needs careful elucidation as to the problems resulting (or likely to
result) if a proxy violates this requirement.

--
Dean



_______________________________________________
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