Subject: [Sip] One big concern with outbound-05

From: "Fredrik Thulin" <[email-masked]>
Date: Mon, 30 Oct 2006 12:40:55 +0100

Hi

While I am generally very much in favour of draft-Outbound, I have one 
big concern with it. I also have some other questions/comments after 
thoroughly reading version 05, but I will separate them from this first 
big concern and send them in another e-mail.

My concern is that you, in your attempts to make sure outbound works 
with several layers of NATs/SIP stateful packet inspecting firewalls, 
you actually _break_ some otherwise perfectly fine resilient SIP network 
designs. Consider the following example in which every entity except the 
UA has a globally reachable IP address :

               ep1.isp.net       (ep1.sip-p.net)
    UA --NAT--            ------- ep.sip-p.net -- Authoritative proxy /
               ep2.isp.net       (ep2.sip-p.net)      registrar

The user agent has been provisioned with two Outbound URLs, 
sip:ep1.isp.net;keepalive=stun and sip:ep2.isp.net;keepalive=stun. The 
SIP service provider sip-p.net has two edge proxys of it's own, which 
the NAPTR records for sip-p.net directs all incoming traffic for 
sip-p.net to.

Now, the UA opens one flow to ep1.isp.net, and one flow to ep2.isp.net. 
These are Outbound flows, so STUN keepalives are used to keep the 
connections alive etc. UA sends one REGISTER over it's first flow, and 
one over it's second. ep1.isp.net and ep2.isp.net resolve the NAPTR 
records for sip-p.net, find that there are two hosts to which requests 
can be sent, and by coincidence both choose to send the REGISTER to 
ep1.sip-p.net. The REGISTERs contain Path headers, according to 
Outbound-05, so that requests sent towards the UA will travel in the 
reverse direction of the REGISTER, but on the exact same flows, for all 
the hops between the Authroitative proxy and the UA.

Now, the registrar for sip-p.net has two bindings with the same 
instance-id, but different reg-id's, but both of these depend on the 
flow from ep1.sip-p.net to the registrar being alive! If ep1.sip-p.net 
goes down, then the authoritative proxy has no way of reaching the UA 
_because of restrictions introduced by Outbound_. If Outbound permitted, 
the UA could still be reached because both ep1.isp.net and ep2.isp.net 
is globally reachable.

I STRONGLY object to the principle in Outbound that when a request is 
received destined for the UA, the proxys on the way MUST use the very 
same connection on every hop. On the last hop (between ep1/ep2.isp.net 
and the UA), naturally the same flow has to be used, but not for example 
between the EP's of isp.net and sip-p.net! It is not at all unreasonable 
that practically all SIP servers have global connectivity, even though 
clearly it was not reasonable to expect all user agents to have one.

I'm going to stop now before this e-mail gets too long for anyone to 
read on an IETF mailing list, but if anyone have a question about 
anything I've written above, then please ask and I will try to clarify.

/Fredrik

_______________________________________________
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: "Fredrik Thulin" <[email-masked]>
Date: Mon, 30 Oct 2006 14:38:30 +0100

Fredrik Thulin <[email-masked]> wrote:
...
> and the UA), naturally the same flow has to be used, but not for
> example between the EP's of isp.net and sip-p.net! It is not at all
> unreasonable that practically all SIP servers have global
> connectivity, even though clearly it was not reasonable to expect all
> user agents to have one.

I think I will have to take all of this back. When going through my 
print out of the draft with comments in the margins, to write about the 
other questions/comments I had I think I realize that you actually 
_have_ loosened the rules in outbound-05 to not demand proxys with 
global reachability to use the very same flow.

Can I just verify this by asking if the following scenario would work 
with Outbound-05?

The UA sets up one Outbound flow to ep1.isp.net, and one to ep2.isp.net. 
It sends a REGISTER on both flows, and when these reach the 
Authoritative proxy / registrar they look like this :

Request #1 :

REGISTER sip:sip-p.net
Via: SIP/2.0/TCP ep1.isp.net;branch=...
Via: SIP/2.0/TCP ep1.sip-p.net;branch=...
Path: <sip:[email-masked];ob>
From: <...>
...

Request #2 :

REGISTER sip:sip-p.net
Via: SIP/2.0/TCP ep2.isp.net;branch=...
Via: SIP/2.0/TCP ep1.sip-p.net;branch=...
Path: <sip:[email-masked];ob>
From: <...>
...

So the edge proxys of sip-p.net didn't add any Path headers, because 
they knew that ep1.isp.net was globally reachable, and the Authoritative 
proxy didn't add itself to the Path vector before storing the location 
binding?

If this is how it would work, then I am totally happy with it.

/Fredrik

---

From: "Rohan Mahy" <[email-masked]>
Date: Mon, 30 Oct 2006 08:05:07 -0800

Hi Fredrik,

Yes, the scenario you described will work.

thanks,
-rohan

---

From: "Fredrik Thulin" <[email-masked]>
Date: Mon, 30 Oct 2006 17:13:50 +0100

> Yes, the scenario you described will work.

Thanks - then I'm very happy with the current Outbound.

Just to double check, it will work without requests forwarded from the 
Authoritative proxy, towards the UA, going through the edge proxy of 
sip-p.net?

I mean, ep1.sip-p.net won't add itself to the Path of the REGISTER, 
since it knows that the Authoritative proxy can reach ep1/ep2.isp.net 
directly?

Thanks again

/Fredrik

---

From: "Rohan Mahy" <[email-masked]>
Date: Mon, 30 Oct 2006 12:36:42 -0700

Exactly.

thx,
-r

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 30 Oct 2006 21:04:38 +0100

Hi,

I don't think you can assume that the sip-p.net proxies won't add Path
headers. Path is used for other purposes than outbound, so there may be
many non-outbound related reasons why proxies add Path.

For example, in IMS the P-CSCF could be the edge proxy, but then you can
have other intermediate nodes between the P-CSCF and home S-CSCF
(registrar) that insert Path.

Regards,

Christer

> -----Original Message-----
> From: Fredrik Thulin [mailto:[email-masked]] 
> Sent: 30. lokakuuta 2006 15:39
> To: [email-masked]
> Subject: Re: [Sip] One big concern with outbound-05
> 
> I think I will have to take all of this back. When going 
> through my print out of the draft with comments in the 
> margins, to write about the other questions/comments I had I 
> think I realize that you actually _have_ loosened the rules 
> in outbound-05 to not demand proxys with global reachability 
> to use the very same flow.
> 
> Can I just verify this by asking if the following scenario 
> would work with Outbound-05?
> 
>

---

From: "Fredrik Thulin" <[email-masked]>
Date: Mon, 30 Oct 2006 22:23:55 +0100

Christer Holmberg (JO/LMF) <[email-masked]> wrote:
> headers. Path is used for other purposes than outbound, so there may
> be many non-outbound related reasons why proxies add Path.
>
> For example, in IMS the P-CSCF could be the edge proxy, but then you
> can have other intermediate nodes between the P-CSCF and home S-CSCF

My concern was only with not having more proxys than necessary adding 
themselves to the Path vector.

I do however see the problem you are talking about with Outbound 
effectively being disabled if there is some other proxy on the way 
between the UA and the registrar that adds itself to the Path vector for 
some non-Outbound reason, and not including the ;ob parameter since it 
doesn't know about Outbound. In that case, reachability from the 
Authoritative proxy / registrar to the UA won't be guaranteed.

Changing it to what you suggest, only demand the edge proxy closest to 
the UA to support Outbound, would of course (at least slightly) reduce 
the chance of reachability from the Authoritative proxy / registrar to 
the UA, but at least until now I haven't been able to come to any other 
conclusion than that it would probably work often enough (because the 
edge proxys closest to the UA probably will have global reachability)... 
I am looking forward to Rohan's response to this.

When thinking about this I came up with another question :

What if there are NATs between a series of edge proxys between the UA 
and the Authoritative proxy / registrar - who is going to keep those 
connections alive? The UA will keep it's connection to the first edge 
proxy alive using STUN keepalives, but who is going to make sure that 
the flows between the edge proxys are still alive?

/Fredrik

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 30 Oct 2006 22:36:34 +0100

Hi, 

>>headers. Path is used for other purposes than outbound, so 
>>there may be many non-outbound related reasons why proxies add Path.
>>
>>For example, in IMS the P-CSCF could be the edge proxy, but 
>>then you can have other intermediate nodes between the P-CSCF and home
S-CSCF
>My concern was only with not having more proxys than 
>necessary adding themselves to the Path vector.

I understand. But, we can still not make any assumptions on that issue.

For example, in an IMS roaming scenario you could have 3 entities adding
a path header: the visited P-CSCF (edge proxy), a visited IBCF, and a
home IBCF.
 
>I do however see the problem you are talking about with 
>Outbound effectively being disabled if there is some other 
>proxy on the way between the UA and the registrar that adds 
>itself to the Path vector for some non-Outbound reason, and 
>not including the ;ob parameter since it doesn't know about 
>Outbound. In that case, reachability from the Authoritative 
>proxy / registrar to the UA won't be guaranteed.
> 
>Changing it to what you suggest, only demand the edge proxy 
>closest to the UA to support Outbound, would of course (at 
>least slightly) reduce the chance of reachability from the 
>Authoritative proxy / registrar to the UA, but at least until 
>now I haven't been able to come to any other conclusion than 
>that it would probably work often enough (because the edge 
>proxys closest to the UA probably will have global reachability)... 
 
Me too :)

>What if there are NATs between a series of edge proxys 
>between the UA and the Authoritative proxy / registrar - who 
>is going to keep those connections alive? The UA will keep 
>it's connection to the first edge proxy alive using STUN 
>keepalives, but who is going to make sure that the flows 
>between the edge proxys are still alive?

I think the assumption is that the non-controllable NAT(s) will only be
located in the "access network", between the UA and the edge proxy. At
least tha.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeeoB-0002xI-Cm
	for [email-masked]; Mon, 30 Oct 2006 16:36:48 -0500
Content-class: urn:content-classes:message
Subject: RE: [Sip] One big concern with outbound-05
Date: Mon, 30 Oct 2006 22:36:34 +0100
From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
To: "Fredrik Thulin" <[email-masked]>,
	<[email-masked]>
Cc: 

Hi, 

>>headers. Path is used for other purposes than outbound, so 
>>there may be many non-outbound related reasons why proxies add Path.
>>
>>For example, in IMS the P-CSCF could be the edge proxy, but 
>>then you can have other intermediate nodes between the P-CSCF and home
S-CSCF
>My concern was only with not having more proxys than 
>necessary adding themselves to the Path vector.

I understand. But, we can still not make any assumptions on that issue.

For example, in an IMS roaming scenario you could have 3 entities adding
a path header: the visited P-CSCF (edge proxy), a visited IBCF, and a
home IBCF.
 
>I do however see the problem you are talking about with 
>Outbound effectively being disabled if there is some other 
>proxy on the way between the UA and the registrar that adds 
>itself to the Path vector for some non-Outbound reason, and 
>not including the ;ob parameter since it doesn't know about 
>Outbound. In that case, reachability from the Authoritative 
>proxy / registrar to the UA won't be guaranteed.
> 
>Changing it to what you suggest, only demand the edge proxy 
>closest to the UA to support Outbound, would of course (at 
>least slightly) reduce the chance of reachability from the 
>Authoritative proxy / registrar to the UA, but at least until 
>now I haven't been able to come to any other conclusion than 
>that it would probably work often enough (because the edge 
>proxys closest to the UA probably will have global reachability)... 
 
Me too :)

>What if there are NATs between a series of edge proxys 
>between the UA and the Authoritative proxy / registrar - who 
>is going to keep those connections alive? The UA will keep 
>it's connection to the first edge proxy alive using STUN 
>keepalives, but who is going to make sure that the flows 
>between the edge proxys are still alive?

I think the assumption is that the non-controllable NAT(s) will only be
located in the "access network", between the UA and the edge proxy. At
least that is the assumption in IMS.

I am not sure I understand the concept of multiple edge proxies in the
flow path, but that is a separate issue...

Regards,

Christer

t is the assumption in IMS.

I am not sure I understand the concept of multiple edge proxies in the
flow path, but that is a separate issue...

Regards,

Christer

---

From: "Rohan Mahy" <[email-masked]>
Date: Tue, 31 Oct 2006 10:22:46 -0800

Hi,

Comments inline.

> a path header: the visited P-CSCF (edge proxy), a visited IBCF, and a

My point to Fredrik is that none of these additional intermediaries
NEED to add a Path header for the purposes of outbound.  If they WANT
to add a Path header for some other reason, that is the choice of the
network provider.

> >I am looking forward to Rohan's response to this.

Perhaps I am going too far in trying to insure connectivity back to
the UA.  Today there are some networks that don't require a border
signaling element and some that do.  The assumption that the border
element for foo.com can reach any edge proxy for foo.com pre-dates
outbound, but it is kind of brittle.

The current outbound draft provides a more reliable assurance of
working connectivity, but at the price of requiring more devices in
the path to understand outbound.

> least that is the assumption in IMS.

We ruled this out of scope for the current outbound draft.  There are
still folks who want to address this as future work though.

thanks,
-rohan

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 31 Oct 2006 20:12:06 +0100

Hi Rohan, 

>>>between the UA and the registrar that adds itself to the Path vector 
>>>for some non-Outbound reason, and not including the ;ob parameter 
>>>since it doesn't know about Outbound. In that case, 
>>>reachability from the Authoritative proxy / registrar to the UA won't
be guaranteed.
>>>
>>>Changing it to what you suggest, only demand the edge proxy closest 
>>>to the UA to support Outbound, would of course (at least slightly) 
>>>reduce the chance of reachability from the Authoritative proxy / 
>>>registrar to the UA, but at least until now I haven't been able to 
>>>come to any other conclusion than that it would probably work often 
>>>enough (because the edge proxys closest to the UA probably will have 
>>>global reachability)...
>Perhaps I am going too far in trying to insure connectivity 
>back to the UA.  Today there are some networks that don't 
>require a border signaling element and some that do.  The 
>assumption that the border element for foo.com can reach any 
>edge proxy for foo.com pre-dates outbound, but it is kind of brittle.
> 
>The current outbound draft provides a more reliable assurance 
>of working connectivity, but at the price of requiring more 
>devices in the path to understand outbound.

I strongly don't think we should have that requirement. It should be
possible to use outbound if only the edge proxy and registrar support
outbound.

We can of course add some text talking about the advantages of all
proxies supporting outbound, but I don't think we should mandate it.

Regards,

Christer