Subject: [Sip] outbound08 - Handling Responses in Edge proxy / Via vs. Flowtoken

From: [email-masked]
Date: Thu, 19 Apr 2007 17:52:00 +0300

Hi,

  I have a question related to handling Responses that are going to be  
sent over a flow in an Edge proxy.

  In "5.3.  Forwarding Requests (outbound08)" I read that a Request is  
forwarded to a flow using the information retrieved from the flow  
token (and that it is found in the Route-header).

  Now I am considering how is the case for Responses.

  Should we consider the same behavior? i.e. forward a Response over a  
flow using the flowtoken found in the Path-header?

  In 'non-outbound SIP', as far as I understand, Route Header forces  
the routing in Requests, and Via-header forces routing in Responses.

  So... should we avoid any consideration to the information stored in  
the topmost Via-header when proxying a Response? (And instead use the  
information in the flowtoken ?)

  I think that the answers is yes, since the Via could contain a  
private address in the case of a NAT in the middle. Then, shouldn't be  
mentioned the response case in the draft?

Regards,

Sergio

_______________________________________________
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: "Kevin Johns" <[email-masked]>
Date: Thu, 19 Apr 2007 22:19:34 -0600

Sergio,

Outbound expects that rport is used in the via header for routing of
responses (for UDP that is) see the note in section 4.3. Responses are
routed as defined in 3261 for TCP.

Kevin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, April 19, 2007 8:52 AM
To: [email-masked]
Cc: Cullen Jennings; Rohan Mahy
Subject: [Sip] outbound08 - Handling Responses in Edge proxy / Via
vs.Flowtoken

Hi,

  In "5.3.  Forwarding Requests (outbound08)" I read that a Request is
forwarded to a flow using the information retrieved from the flow token
(and that it is found in the Route-header).

  In 'non-outbound SIP', as far as I understand, Route Header forces the
routing in Requests, and Via-header forces routing in Responses.

  I think that the answers is yes, since the Via could contain a private
address in the case of a NAT in the middle. Then, shouldn't be mentioned
the response case in the draft?

Regards,

Sergio

_______________________________________________
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: [email-masked]
Date: Fri, 20 Apr 2007 17:59:22 +0300

Hi,

  Thank you for your answer.

  Perhaps I should emphasize that I am always talking about Edge Proxy  
behavior handling incoming Responses to be forwarded to a UAC over an  
existing flow.

  It seems that your answer is related to handling Responses in the  
UAC, not in the Edge Proxy. Nevertheless I add my comments below:

> responses (for UDP that is) see the note in section 4.3.

  I understand that section 4.3 is for UA behavior.

> Responses are

  Yes, but in the case of forwarding Responses to a flow in an Edge  
Proxy, I understand that the proxy uses the flowtoken information,  
thus discarding any consideration of the Via-header parameters  
(different to 3261 approach).

  So.. shouldn't outbound-08 draft explain the case of Responses  
handled by the Edge Proxy? By common sense I guess that the Response  
should use the destination stated in the flowtoken, but, as  
outbound-08 did not formally specify this case, why I could not avoid  
considering the destination in the Via-header (although it wont work  
with NAT)?

Regards,

Sergio

---

From: "Kevin Johns" <[email-masked]>
Date: Fri, 20 Apr 2007 10:18:58 -0600

Sergio,

Thank you for clarifying your question.

Let me try and provide some more detail, responses are always sent from
the UAS to a UAC and are always routed based on the via header never the
flow token. The flow token is only used for routing of initial requests
from the edge proxy (UAC) to the client (UAS).

Section 4.3 defines the UAC procedures (it is titled sending requests)
and strongly recommends that the UA include the rport in the via header.
When the Edge Proxy gets the INVITE, it will populate the rport
parameter in the UAC inserted via head with the source port in the UDP
header of the received packet. It will also insert the receive parameter
into the same via header entry which contains the source IP address in
the IP header of the received packet. The Edge Proxy then adds its own
via header entry and forwards this INVITE along.

When the edge proxy gets back the response, it will look at the top most
Via header which contains the rport and receive parameter. The Edge
Proxy will then forward the response to the UAC using these parameters
which are routable since they represent the WAN interface of the NAT.
The flow token never comes into play in this case.

This is all defined in RFC 3581 (An Extension to the Session Initiation
Protocol (SIP) for Symmetric Response Routing)

I hope this helps clarify the situation.
Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, April 20, 2007 8:59 AM
To: Kevin Johns
Cc: [email-masked]; Cullen Jennings; Rohan Mahy
Subject: RE: [Sip] outbound08 - Handling Responses in Edge proxy /
Viavs.Flowtoken

Hi,

  It seems that your answer is related to handling Responses in the UAC,

  Yes, but in the case of forwarding Responses to a flow in an Edge
Proxy, I understand that the proxy uses the flowtoken information, thus
discarding any consideration of the Via-header parameters (different to
3261 approach).

  So.. shouldn't outbound-08 draft explain the case of Responses handled
by the Edge Proxy? By common sense I guess that the Response should use
the destination stated in the flowtoken, but, as
outbound-08 did not formally specify this case, why I could not avoid
considering the destination in the Via-header (although it wont work
with NAT)?

Regards,

Sergio

---

From: [email-masked]
Date: Fri, 27 Apr 2007 15:36:10 +0300

Hi,

  We are composing an email with comments about why this issue (to use  
the information in the Via header to handle Responses for Requests  
originated by a UAC) may be not a good approach and bring down several  
good outbound features.

  But before to send our comments, it is important for us to ask the  
authors if they are considering to re-use the flow in a  
non-outbound-required UAC-->UAS Request case. Details are explained  
below.

  Keep in mind that in the comments below we focus our thoughts mainly  
to connection oriented protocols (TCP).

  Let me introduce an example; in the following scenario the UAC  
previously established a flow with the EdgeProxy

      ----flow----
  UAC--------------EdgeProxy----UAS

  Suppose now that the UAC wants to send a Request to the UAS.

  We understand that the purpose of a flow is to reach UAC for a  
Request in the 'opposite direction' (i.e. a request from a UAS to  
UAC). While now we are sending a Request from UAC to UAS.

The question is:

  What are the authors point of view about re-using the flow in a  
non-outbound-required UAC-->UAS Request?

  In other words, is an outbound UAC expected to reuse the  
outbound-flow, or not? ('or not' means : to create another  
'traditional' SIP connection).

  The advantages to re-use a flow in UAC-UAS direction can introduce  
some additional features that can make of outbound a powerful  
mechanism not only to just keep NAT/FW bindings alive to reach a UAC  
but also to : a) increase security (proxying requests and responses at  
the Edge Proxy could be always done using a flowtoken), b) be an  
alternative to RFC 3581.

  We will add more details about the comments above and the advantages  
that outbound can introduce by re-using a flow in any direction  
to/from a UAC. But first we need to know what is the authors position  
about using a flow in the (non-outbound-requiring) UAC-UAS direction.

Regards

Sergio

---

From: "Kevin Johns" <[email-masked]>
Date: Mon, 30 Apr 2007 17:01:02 -0600

Sergio,

Before I respond, I would like to make sure I understand your question,
are you proposing that responses to the client (presumably behind a NAT)
be routed in some way other then the Via header?

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, April 27, 2007 6:36 AM
To: Kevin Johns
Cc: [email-masked]; Cullen Jennings; Rohan Mahy
Subject: RE: [Sip] outbound08 - Handling Responses in Edge proxy
/Viavs.Flowtoken

Hi,

      ----flow----

  We understand that the purpose of a flow is to reach UAC for a Request
in the 'opposite direction' (i.e. a request from a UAS to UAC). While
now we are sending a Request from UAC to UAS.

The question is:

  In other words, is an outbound UAC expected to reuse the
outbound-flow, or not? ('or not' means : to create another 'traditional'
SIP connection).

  The advantages to re-use a flow in UAC-UAS direction can introduce
some additional features that can make of outbound a powerful mechanism
not only to just keep NAT/FW bindings alive to reach a UAC but also to :
a) increase security (proxying requests and responses at the Edge Proxy
could be always done using a flowtoken), b) be an alternative to RFC
3581.

  We will add more details about the comments above and the advantages
that outbound can introduce by re-using a flow in any direction to/from
a UAC. But first we need to know what is the authors position about
using a flow in the (non-outbound-requiring) UAC-UAS direction.

Regards

Sergio

Quoting Kevin Johns <[email-masked]>:

> Let me try and provide some more detail, responses are always sent 
> from the UAS to a UAC and are always routed based on the via header 
> never the flow token. The flow token is only used for routing of 
> initial requests from the edge proxy (UAC) to the client (UAS).
>

> header of the received packet. It will also insert the receive 
> parameter into the same via header entry which contains the source IP 
> address in the IP header of the received packet. The Edge Proxy then 
> adds its own via header entry and forwards this INVITE along.
>
> When the edge proxy gets back the response, it will look at the top 
> most Via header which contains the rport and receive parameter. The 
> Edge Proxy will then forward the response to the UAC using these 
> parameters which are routable since they represent the WAN interface
of the NAT.
> This is all defined in RFC 3581 (An Extension to the Session 
> Initiation Protocol (SIP) for Symmetric Response Routing)
>

---

From: [email-masked]
Date: Tue, 01 May 2007 04:24:06 +0300

Hi,

  Yes, that is one of the proposals and one of the comments that we  
had queued waiting a response to my previous email.

  Note that in my previous email I did not mention yet the 'Responses'  
issue. I just want to be sure what is the authors opinions about  
reusing the flow in a UAS ---> UAS 'Request' and then develop my  
comments. But anyway, I mention below the main idea.

  After knowing the authors opinion, and assuming that they agree with  
the idea to re-use an outbound flow in the UAC---> UAS case, we were  
thinking to propose the following:

1. Always use the flow-token in Requests: i.e. not only use the  
flow-token in the UAS--->UAC case , but also, if a UAC supports  
outbound, consider to reuse optionally or mandatory (to be discussed)   
the flow in the the UAC--->UAS direction. In this case, the UAC must  
keep a copy of the flow-token after successful registration (it can be  
retrieved from the Path-header in the 200 OK).

2. Always use the flow-token in Responses : i.e. when a Request  
crosses a  proxy, and it founds the flow-token in the path header,  
copy it as a URI into the Via-header. Then, when the Response comes  
back to the proxy, use the flow token in the Via-header (if present)  
to forward the response to the destination stated in the flow token  
(instead to use the Via-header rport and received). (This will require  
to store in the flow-token (algorithm 2) the destination IP and port  
of the Registrar/UAS instead of the proxy IP and port. The proxy will  
know how to forward the Response by checking its origin; if origin IP  
and port in transport match origin IP and port in flow-token, then the  
proxy knows that the response comes over the flow and the destination  
is the destination IP and port in the token).

  This behavior could be considered either mandatory or optional in outbound.

Advantages are:
-Security: the proxy could only consider valid flow-tokens before to  
forward a Request (except  REGISTER), thus, only authenticated and  
authorized flows could be allowed to be forwarded.
- Could be used as an alternative to RFC 3581.
- Security (we need to considered if it is really possible): UAC  
location could be anonymous: The registrar and other entities will  
only know a flow-token (only the Edge proxy knows how to decrypt the  
location of UAC).

  Note that the presence of NAT is optional. This scheme will work  
with or without NAT since the flow-token is composed using the origin  
IP and port (and we understand that these are retrieved from the  
transport layer).

Regards,

Sergio