Subject: [Sip] RE: I-D ACTION:draft-rosenberg-sip-ua-loose-route-00.txt

From: "Francois Audet" <[email-masked]>
Date: Sat, 14 Oct 2006 15:41:55 -0500

Hi Jonathan,

Good job with this draft. Here are some comments on it.

There is one case not mentioned in this draft that I think should be
discussed. It is somewhat similar to your 1-800 number.

It is very common in PSTN to be reachable by more than one phone
numbers.

Of particular importance is the case of Enterprise users who typically
have
both an E.164 Public number and one or more Private corporate numbers
(typically, a "long" corporate-wide number valid in
phone-context=expample.com
and also a "short" number valid in a specific location such as
phone-context=
santaclara.example.com). Similar arrangements also exist in Public
networks
(like your 1-800 example). The difference is that in Enterprises, it is
almost
always the case that multiple numbers are supported.

Seems to me this should be discussed in the draft.

Now, there is some additional complexity to consider here. Typically, a
SIP UA
(such as a SIP phone) will be configured with it's AOR consisting of a
username
and domain name (sip:[email-masked]). It only "knows" of one of that
identity.
That identity could be an alphanumeric username, or it could even look
like a phone
number (typical with low-end SIP phone installations).

The problem is that it is unlikely that these devices will "know" all
the possible
phone numbers assigned to them as this is normally centrally configured.
And a phone
will not normally accept arbitrary requests to URIs it doesn't
understand (otherwise,
a device supporting multiple users wouldn't know which line
appearance/user the request
is targetted to). It could also be bad for SPIT.

I guess the solution to this would be for such an endpoint to rely on
the Route header for
such purpose instead of the Request-URI. This was probably your
intention, but maybe making
it explicit would be useful.

Another suggestion is to add a URI parameter to the example. One of the
main benefits of
this draft is to preserve URI parameters potentially useful for the
target (as we discussed
on the mailing list). A mention of this in the draft would be quite
useful.

Cheers.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, October 13, 2006 12:50 PM
> To: [email-masked]
> Subject: I-D ACTION:draft-rosenberg-sip-ua-loose-route-00.txt
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: Applying Loose Routing to Session 
> Initiation Protocol (SIP) User Agents (UA)
> 	Author(s)	: J. Rosenberg
> 	Filename	: draft-rosenberg-sip-ua-loose-route-00.txt
> 	Pages		: 20
> 	Date		: 2006-10-13
> 	
>    A key part of the behavior of the Session Initiation Protocol (SIP)
>    is that SIP proxies rewrite the Request-URI as a request moves
>    throughout the network.  Over the years, experience has 
> shown this to
>    be problematic.  It makes it difficult to use Request URI 
> for service
>    invocation, complicates emergency services, makes it more 
> complex to
>    support aliases, and so on.  Architecturally, it confounds the
>    concepts of address and route.  This document proposes to 
> change this
>    through a new mechanism called UA loose routing.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo
> se-route-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in 
> the body of 
> the message. 
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then 
> "get draft-rosenberg-sip-ua-loose-route-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE 
> /internet-drafts/draft-rosenberg-sip-ua-loose-route-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

_______________________________________________
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: "Brian Stucker" <[email-masked]>
Date: Mon, 16 Oct 2006 15:25:39 -0500

Jonathan,

Thanks for chronicling the discussion into a draft.

Just to build from Francois' comments (still reading through the entire
draft)...

If the UA is to look at the Route header to get the identity at which it
should accept the the request because the Request-URI could be who knows
what, isn't this confabulating the purposes of the two headers? We'd be
using a routing header for identity purposes.

>From section 4.2, you mention that the exact purpose of the Route header
is to indicate the next hop of the request, but now it would also have
to be the identity at that next hop that you're wishing to be contacted
as well. This assumes, of course, that Francois' concern about the
reliability of the Request-URI value (when you take into account limited
UA behavior) pans out (which I think it will).

Thoughts?

Also, the comment at the bottom of section 4.2 about H-I seemed
prejudicial/self-conflicting:

"Thirdly, the history specification is fairly complex and has seen
limited industry adoption. This should never be a reason to not use a
mechanism when its the right choice, but its a consideration that
warrants mentioning."

If something should never be a reason to exclude a mechanism then why is
it a consideration? 

SIP is fairly complex, and given the relative scope of the H-I
mechanism, I'm sure we can find plenty of examples of other mechanisms
proposed within/for SIP that have similar current adoption rates.

Regards,
Brian

> From: Audet, Francois (SC100:3055) 
> Sent: Saturday, October 14, 2006 3:42 PM
> To: [email-masked]; Jonathan Rosenberg
> Subject: [Sip] RE: I-D 
> ACTION:draft-rosenberg-sip-ua-loose-route-00.txt
> 
> Hi Jonathan,
> 
> There is one case not mentioned in this draft that I think 
> should be discussed. It is somewhat similar to your 1-800 number.
> 
> It is very common in PSTN to be reachable by more than one 
> phone numbers.
> 
> Of particular importance is the case of Enterprise users who 
> typically have both an E.164 Public number and one or more 
> Private corporate numbers (typically, a "long" corporate-wide 
> number valid in phone-context=expample.com and also a "short" 
> number valid in a specific location such as phone-context= 
> santaclara.example.com). Similar arrangements also exist in 
> Public networks (like your 1-800 example). The difference is 
> that in Enterprises, it is almost always the case that 
> multiple numbers are supported.
> 
> Now, there is some additional complexity to consider here. 
> Typically, a SIP UA (such as a SIP phone) will be configured 
> with it's AOR consisting of a username and domain name 
> (sip:[email-masked]). It only "knows" of one of that identity.
> That identity could be an alphanumeric username, or it could 
> even look like a phone number (typical with low-end SIP phone 
> installations).
> 
> The problem is that it is unlikely that these devices will 
> "know" all the possible phone numbers assigned to them as 
> this is normally centrally configured.
> And a phone
> will not normally accept arbitrary requests to URIs it 
> doesn't understand (otherwise, a device supporting multiple 
> users wouldn't know which line appearance/user the request is 
> targetted to). It could also be bad for SPIT.
> 
> I guess the solution to this would be for such an endpoint to 
> rely on the Route header for such purpose instead of the 
> Request-URI. This was probably your intention, but maybe 
> making it explicit would be useful.
> 
> Another suggestion is to add a URI parameter to the example. 
> One of the main benefits of this draft is to preserve URI 
> parameters potentially useful for the target (as we discussed 
> on the mailing list). A mention of this in the draft would be 
> quite useful.
> 
> Cheers.
> 
> 
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > 
> > 
> shown this 
> > to
> >    be problematic.  It makes it difficult to use Request URI for 
> > service
> >    invocation, complicates emergency services, makes it 
> more complex 
> > to
> >    concepts of address and route.  This document proposes to change 
> > this
> > logging in, type "cd internet-drafts" and then "get 
> > draft-rosenberg-sip-ua-loose-route-00.txt".
> > 
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Oct 2006 18:22:52 -0400

Thanks for the comments Francois. Responses inline.

> always the case that multiple numbers are supported.

Right. I am familiar with this problem. There are actually a number 
issues in supporting it....

> Seems to me this should be discussed in the draft.

This draft can help answer the question of knowing by which of these you 
were reached, and it would appear in the R-URI. I think thats more or 
less the aliasing problem in Setion 2.1, no? I can certainly mention 
enterprise as another case.

> is targetted to). It could also be bad for SPIT.

You get little protection by checking if you know the R-URI. Spammers 
will just use that URI. What you want is to only accept requests that 
your home proxy decided ought to be delivered to you. Thats done with 
things TLS to your proxy, and only accepting inbound requests over that 
connection.

> it explicit would be useful.

I hadn't considered this case. I had in mind at least the IMS model 
where the UA does actually know its aliases. But anyway I think there is 
a difference between how to authorize accepting a request and how to 
know to where the request was sent. Per above receiving a request over 
the TLS connection to your proxy is a much better authorization tool 
than examining the topmost Route header field.

> on the mailing list). A mention of this in the draft would be quite

OK, will do.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Oct 2006 18:28:04 -0400

> using a routing header for identity purposes.

See my response to Francois; I don't think thats what you want. If the 
UA wants to authorize an incoming request it uses a real security technique.

That said, I don't actually see anything wrong with using a Route haeder 
field for determining how to process a request. Thats already what 
proxies do and have been doing since the dawn of SIP.

> UA behavior) pans out (which I think it will).

I'm not sure I follow. With proxies, the Route header field identifies 
the next hop. WIth the introduction of loose routing in RFC3261, when 
received at that hop, it examines the URI, checks that it is 'its own', 
and proceeds if it is. I am merely extending that exact processing to 
UA. That doesn't mean that Route becomes an identity header akin to 
P-A-ID. It would mean that a UA would check that the Route haeder field 
matches its registered contact, if it wants. Though its not clear to me 
what security benefits are derived from that check in the absence of tls 
I must say.

> If something should never be a reason to exclude a mechanism then why is

I was putting all of the cards on the table. I'm happy to remove this 
since claerly I was iffy on this as a reason myself. I have other 
concerns about history-info and they are there also in teh document.

Note that I'm not in fact proposing to get rid of H-I at all. I'm merely 
trying to frame when it is used (retargeting) vs. when its not (routing).

-Jonathan R.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 16 Oct 2006 18:20:35 -0500

Thanks. 

See below.

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Monday, October 16, 2006 3:23 PM
> To: Audet, Francois (SC100:3055)
> Cc: [email-masked]
> Subject: [Sip] Re: I-D 
> should be 
> > have both an E.164 Public number and one or more Private corporate 
> > numbers (typically, a "long" corporate-wide number valid in 
> > phone-context=expample.com and also a "short" number valid in a 
> > specific location such as phone-context= santaclara.example.com). 
> > Similar arrangements also exist in Public networks (like your 1-800 
> > example). The difference is that in Enterprises, it is 
> almost always 
> > the case that multiple numbers are supported.
> 
> Right. I am familiar with this problem. There are actually a 
> number issues in supporting it....

I'm thinking that your draft actually helps with this problem.

> This draft can help answer the question of knowing by which 
> of these you were reached, and it would appear in the R-URI. 
> I think thats more or less the aliasing problem in Setion 
> 2.1, no? I can certainly mention enterprise as another case.

Well, maybe I guess. I've never tought of these phone numbers
as AOR really, because they are not associated with registration.

Phone numbers can result in different devices/users being addressed
completely independently of registration. Proxies may have rules
that routes calls to +1-555-1212 to different AORs (e.g., agents) based
on time of day, load balancing, or any other criteria.

Also, I do not expect that the devices themselves would be aware of
their
own phone numbers. It's something that is managed elsewhere.

That's why I tought it was more analogous to your section 2.7 on 
Freephone numbers.

What I'd like to see is either an expansion of section 2.7 to cover
phone numbers in general, including enterprise numbering plan as per my
example, or maybe a section 2.8 on it. As you prefer. 

> Typically, a
> "know" all

I'm more concerned about the following simple case:

- A device has 2 (or more) users logged in (on different line
appearances). 

- When it gets an incoming request, it needs to be able to figure out
  which of the users the call is destined to.

- Because of this, that device can not just "blindly" accept calls to 
  arbitrary AORs that it doesn't understand. With the current
procedures, it
  must look at the Request-URI. With your draft, it would be the Route
header
  instead. Your draft would allow that device to know not only which
user the
  call is destined to, but also how it was addressed. That's one of the
reason 
  I like it.

> than examining the topmost Route header field.

Well, yes, TLS is much better, I agree, but it doesn't mean that it
should
be broken.

The multi-user terminal is an example.

Another one is in the event of a device shutting down without properly 
un-registering, it is possible that another device would be assigned the
old IP address. This could result in calls (or IM) being directed to the
wrong device/user. I've seen it...
 
> > on the mailing list). A mention of this in the draft would be quite

Thanks.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Oct 2006 21:09:38 -0400

inline.

> as AOR really, because they are not associated with registration.

Fair enough, but they are AOR in that they are identities by which 
someone can reach me. Aliases for the AOR would be another way to think 
about them.

> own phone numbers. It's something that is managed elsewhere.

Again it depends on the system in use.

> example, or maybe a section 2.8 on it. As you prefer. 

OK, I'll work something in.

>   instead.

Well it'd be both in this case. Presumably each user has a different AOR 
so those appaer in the R-URI.

> Your draft would allow that device to know not only which
> user the

Right, it gives you both pieces of information, so you can use whichever 
you like.

> wrong device/user. I've seen it...

OK, fair point.

-Jonathan R.

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 17 Oct 2006 15:45:40 -0500

> Sent: Monday, October 16, 2006 5:28 PM
> To: Stucker, Brian (RICH1:AR00)
> Cc: Audet, Francois (SC100:3055); [email-masked]
> Subject: Re: [Sip] RE: I-D 
> > Just to build from Francois' comments (still reading through the 
> > entire draft)...
> > 
> > If the UA is to look at the Route header to get the 
> identity at which 
> > it should accept the the request because the Request-URI 
> could be who 
> > knows what, isn't this confabulating the purposes of the 
> two headers? 
> > We'd be using a routing header for identity purposes.
> 
> See my response to Francois; I don't think thats what you 
> want. If the UA wants to authorize an incoming request it 
> uses a real security technique.
> 
> That said, I don't actually see anything wrong with using a 
> Route haeder field for determining how to process a request. 
> Thats already what proxies do and have been doing since the 
> dawn of SIP.

Fair enough. It was more of a textual/self-consistiency comment about
the draft text as it stands.
 
> > to be the identity at that next hop that you're wishing to be 
> > contacted as well. This assumes, of course, that Francois' concern 
> > about the reliability of the Request-URI value (when you take into 
> > account limited UA behavior) pans out (which I think it will).
> 
> I'm not sure I follow. With proxies, the Route header field 
> identifies the next hop. WIth the introduction of loose 
> routing in RFC3261, when received at that hop, it examines 
> the URI, checks that it is 'its own', and proceeds if it is. 
> I am merely extending that exact processing to UA. That 
> doesn't mean that Route becomes an identity header akin to 
> P-A-ID. It would mean that a UA would check that the Route 
> haeder field matches its registered contact, if it wants. 
> Though its not clear to me what security benefits are derived 
> from that check in the absence of tls I must say.

I agree. That's a better way of putting it I guess.

> > If something should never be a reason to exclude a 
> mechanism then why 
> > is it a consideration?
> 
> I was putting all of the cards on the table. I'm happy to 
> remove this since claerly I was iffy on this as a reason 
> myself. I have other concerns about history-info and they are 
> there also in teh document.
> 
> Note that I'm not in fact proposing to get rid of H-I at all. 
> I'm merely trying to frame when it is used (retargeting) vs. 
> when its not (routing).

If you consider the H-I insertion to only to apply to the last hop to
the UA (as you are doing with the Route header) I don't see the problem.
It's just a choice as to which header type you want to have the UA take
a look at. It's simply storing off the request-URI prior to rewriting it
to the contact value. The advantage in my mind is that H-I is a header
that typically survives to the upper layers of an application built
using SIP. Lower layers may simply strip the route header before the
application gets it because it matches a user/interface on the device.
Does anyone care that we're losing the contact used to reach the device
at the upper layers of an application?

Regards,
Brian