Subject: RE: [Sipping] Re: draft-sinnreich-sipdev-req-06.txt

From: "Francois Audet" <[email-masked]>
Date: Thu, 19 May 2005 12:56:02 -0400

Good, I think we are essentially on the same page.

See minor embedded comment below.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Thursday, May 19, 2005 06:26
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'Christian Stredicke'; 'Johnston, Alan'; [email-masked]'
> Subject: Re: [Sipping] Re: draft-sinnreich-sipdev-req-06.txt
> 
> I guess I wasn't clear enough. I think I agree with you. I was only 
> postulating an *example* of a device where those were the only two 
> addresses where it expects to receive requests.
> 
> I agree that a device could have addresses which it has not 
> *registered*, but which it has made available to callers in some way. 
> (E.g. as contact addresses in INVITEs.)
> 
> I was struggling for a way to explain this, and to word a 
> requirement. I 
> think the revised requirement captured it reasonably.
> 
> > Also, you could have device that accept any request 
> regadless of the 
> > user name (which is I believe whate the majority of 
> single-user device 
> > do today).
> 
> That is the part te draft is trying to put limits on. I 
> understand the 
> security implications to an operator of a managed device, and 
> so I have 
> no objection to the attempt to have a configurable option to restrict 
> this behavior.

Right. I would expect it to be something like that. 

> Lets try to explain this again:
> 
> - a device of the sort we are discussing normally has no addresses
>    that are externally known a priori
> 
> - callers normally learn the addresses at which the device can be
>    reached because it actively makes those addresses known. This may
>    be via registration of a uri, or by including a uri
>    in some other sip message that it sends. (The URIs could also
>    be published using other protocols.)

Or they can be configured in the location server. In this particular
case, unless the phone "accepts everything", it is important that the
phone be also made aware of its valid aliases (either through manual 
configuration, or other mechanisms).

Maybe that is a trivial subset of your "protocol" example.

> - callers are expected to contact the device using one of the URIs
>    the device has exposed without altering the URI in any way.

Yes.

> - the device *ought* to know the set of URIs it has exposed.

Right. Otherwise it has to accept everyting which is definitively
not optimal for security unless you really trust your proxy. There
are environments where this is feasible.

> - if the device receives requests at a URI other than one it has
>    exposed, that request should probably be considered inappropriate.
> 
> It is this last bullet that they were trying to place a 
> requirement on. 
> Namely to make an option that when set requires the device to detect 
> this inappropriate usage and report it as an error.
> 
> My only concern with this was that I thought the proposed 
> wording could 
> also be read to include a setting that required the device to 
> accept the 
> inappropriate request as valid. I don't think a device should ever be 
> required to do that.

My take is that we should actually make this requirement (but it should
NOT be the default setting).

In controlled environments, say, in an enterprise where you only accept
requests from a valid proxy, it may be operationally much simpler to
use your phones that way than to synchronize the URIs on the phones. This
may even be the case in Service provider scenarios especially if the 
proxies that can be supported by the phone are restricted.

Somehow, I believe that device manufacturers need to understand this
to decide what they need to provide in their phones, depending on the
market they wish to sell into.

So to me, the explanation is more important than the "requirement".
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP