Subject: [Sip] [draft-ietf-sip-outbound-07] 5.3. Forwarding Requests

From: [email-masked]
Date: Tue, 06 Mar 2007 15:43:25 +0200

Hi,

  Although you explained in the email 'Re: [Sip] Outbound-07 comments'  
some issues related to '5.3. Forwarding Requests' , I still do not  
understand the logic and scenarios that you intend to cover.

** Q1.

"If the Edge Proxy receives a request where the edge proxy is the host  
in the topmost
Route header field value, and the Route header contains a flow token,  
the proxy compares
the flow in the flow token with the source of the request. If these  
refer to the same
flow, the Edge Proxy removes the Route header and continues processing  
the request."

Where : "the proxy compares the flow in the flow token with the source  
of the request."

Assume that I always use algorithm 2:

1. "the flow in the flow token" is the HMAC of the S array

True?

2. "the source of the request" is the S array

True?

3. "the proxy compares the flow in the flow token with the source of  
the request."

  I understand that we need to decode the flow token and verify that  
the HMAC of the flow identifier is the same as the other part  
containing protocol, Ips and ports (i.e. S array).

  Is this correct?

** Q2.

"Otherwise, if the top-
    most Route header refers to the Edge Proxy and contains a valid flow
    identifier token created by this proxy, the proxy MUST remove the
    Route header and forward the request over the 'logical flow'
    identified by the flow token, that is known to deliver data to the
    specific target UA instance."

Otherwise what statement?

What it is the difference with the former statement :

"If the Edge Proxy receives a request where the edge proxy is the host  
in the topmost
Route header field value, and the Route header contains a flow token,  
the proxy compares
the flow in the flow token with the source of the request."

1. Compare

"Otherwise, if the top-
    most Route header refers to the Edge Proxy "

and

""If the Edge Proxy receives a request where the edge proxy is the  
host in the topmost
Route header field value,"

Both seem to be equivalent.

2. Compare

"and contains a valid flow
    identifier token created by this proxy,"

and

"and the Route header contains a flow token, "

Both seem to be equivalent.

Could you clarify the situation or state this in other words?

** Q3.

The following text is confusing :

"if these refer to the same flow, the Edge Proxy removes the Route
    header and continues processing the request.  Otherwise,..."

What do you mean by " continues processing the request"?
To  continue processing the request as a non sip outbound ("normal") proxy?

  Then the "otherwise" does not provide enough information about  
otherwise what...

Q4.

"If these refer to the same flow, the Edge Proxy removes the Route
    header and continues processing the request. "

  What happen if these not correspond to the same flow?

  For example, 1) in the case someone changed the token, 2) the  
registrar sent an old token, 3) the key  changed due to re-booting.  
Should we return 430 (Flow Failed)?

  Could you add this case in the specification?

Q5.

I can not imagine other situation where "the Edge Proxy receives a  
request where the edge proxy is the host in the topmost Route header  
field value, and the Route header contains a flow token" is NOT going  
to do the following

"the proxy MUST remove the
    Route header and forward the request over the 'logical flow'
    identified by the flow token, that is known to deliver data to the
    specific target UA instance."

  "5.3. Forwarding Requests" is explained in a way that it seems that  
there are other variations.... I can  not understand what you intend  
to consider. An example in some scenario could clarify this issue.

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: Rohan Mahy <[email-masked]>
Date: Tue, 6 Mar 2007 11:34:20 -0800

Hi,

For Question 1 I think an example of Algorithm 2 may be helpful.  I  
will follow up later with answers to your other questions.

I have an edge proxy at 1.2.3.4:5060 and a UA with outbound support  
registering from the public address 5.6.7.8:9999.

transport = UDP (i will use 0x01)
local IP and port is 0x01020304 0x13C4
remote IP and port is 0x05060708 0x270F

S = 0x01 0120304 13C4 05060708 270F

I will use the string "my key is not strong" as the key K

HMAC of S with the key K = 0x5915 581d 9b7f 17a0 d8b1 ade2 5de6 04b0  
5197 a6c9

The flow token is therefore the base 64 encoding of [ HMAC(S,K) +  S ] =
WRVYHZt/F6DYsa3iXeYEsFGXpskBASAwE8QFBgcIJw8=

(Note that the text is misleading and needs to be clarified.  The  
flow token is 44 octets on the wire, although it can be represented  
in 32 octets on the proxy before it is base 64 encoded)

On Mar 6, 2007, at 5:43 AM, [email-masked] wrote:
>
> Hi,
>
>
>  Although you explained in the email 'Re: [Sip] Outbound-07  
> comments' some issues related to '5.3. Forwarding Requests' , I  
> still do not understand the logic and scenarios that you intend to  
> cover.
>
>
> ** Q1.
>
> "If the Edge Proxy receives a request where the edge proxy is the  
> host in the topmost
> Route header field value, and the Route header contains a flow  
> token, the proxy compares
> flow, the Edge Proxy removes the Route header and continues  
> processing the request."
>
> Where : "the proxy compares the flow in the flow token with the  
> source of the request."
>

no, the flow in the flow token is the UDP flow from 5.6.7.8:9999 to  
1.2.3.4:5060.

The proxy removes the base64 encoding from the flow token and takes  
the last 13 octets to get S again, computes HMAC(S,K), and verifies  
that this matches the first 20 octets in the flow token.

> 2. "the source of the request" is the S array

no.  the source of the (just received) SIP request is the IP address,  
port, and transport over which that new request (not the original  
register request) was received.  The proxy compares the source  
address from S with the source address of the new request.

> 3. "the proxy compares the flow in the flow token with the source  
> of the request."
>

yes

thanks,
-rohan

> "If the Edge Proxy receives a request where the edge proxy is the  
> host in the topmost
> Route header field value, and the Route header contains a flow  
> token, the proxy compares
> request where the edge proxy is the host in the topmost Route  
> header field value, and the Route header contains a flow token" is  
> NOT going to do the following
>
>  "5.3. Forwarding Requests" is explained in a way that it seems  
> that there are other variations.... I can  not understand what you  
> intend to consider. An example in some scenario could clarify this  
> issue.
>
>
> Regards
>
> Sergio
>
>
>
>

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 11 Mar 2007 16:35:10 +0100

On Mar 6, 2007, at 8:34 PM, Rohan Mahy wrote:

> HMAC of S with the key K = 0x5915 581d 9b7f 17a0 d8b1 ade2 5de6  
> 04b0 5197 a6c9
>
>> the flow in the flow token with the source of the request. If  
>> these refer to the same
> no.  the source of the (just received) SIP request is the IP  
> address, port, and transport over which that new request (not the  
> original register request) was received.  The proxy compares the  
> source address from S with the source address of the new request.
>
>>  I understand that we need to decode the flow token and verify  
>> that the HMAC of the flow identifier is the same as the other part  

Lets walk through the whole first paragraph of Section 5.3:

> When an Edge Proxy receives a request, it applies normal routing  
> procedures with the following addition. If the Edge Proxy receives  
> a request where the edge proxy is the host in the topmost Route  
> header field value, and the Route header contains a flow token, the  
> proxy compares the flow in the flow token with the source of the  
> request.

OK so far?  The Edge Proxy compares the flow in the flow token (the  
source of the register) with the source of the newly received request

> If these refer to the same flow, the Edge Proxy removes the Route  
> header and continues processing the request.

In other words if the request is already coming over the same flow  
that registered, continue forwarding it because it is an "outgoing"  
request from the UA instance that caused the flow token to be created.

> Otherwise, if the top-most Route header refers to the Edge Proxy  
> and contains a valid flow identifier token created by this proxy,  
> the proxy MUST remove the Route header and forward the request over  
> the 'logical flow' identified by the flow token, that is known to  
> deliver data to the specific target UA instance.

If the request is coming from some *other* UA instance, forward it  
over the flow to the UA that caused the flow token to be created.

> For connection-oriented transports, if the flow no longer exists  
> the proxy SHOULD send a 430 (Flow Failed) response to the request.

>> To  continue processing the request as a non sip outbound  

yes.

>>  Then the "otherwise" does not provide enough information about  

In English, "otherwise" usually is in this form:

	If (statement A) {do something}.  Otherwise {do something different}.

Still, the text is not especially easy to read.  If you can come up  
with a clearer way to express this paragraph, I'll be happy to  
consider it.

>> registrar sent an old token, 3) the key  changed due to re- 
>> booting. Should we return 430 (Flow Failed)?
>>
>> issue

A ---- EP1  ---- P1 ----  P2 ---- EP2 --- B

User Agent A registers through EP1 to P1.
User Agent B registers through EP2 to P2.

A establishes a session with B.  Once the route set is established, A  
has to send its requests toward B through EP1.  Since the Route for  
EP1 has to be the same for A as it is for B, EP1 needs a way to  
distinguish between traffic from A going somewhere else (in this case  
B), instead of inbound traffic.

I hope this clarifies things a bit.
thanks,
-rohan

---

From: [email-masked]
Date: Mon, 12 Mar 2007 15:34:37 +0200

Hi,

  Thank  you for your comments.
  I add some new comments below.

> In other words if the request is already coming over the same flow that
> registered, continue forwarding it because it is an "outgoing" request
> from the UA instance that caused the flow token to be created.
>
> If the request is coming from some *other* UA instance, forward it over
> the flow to the UA that caused the flow token to be created.
>

In other words, I understand that we check if the request is  
"outgoing" or "ingoing".

True?

> with a clearer way to express this paragraph, I'll be happy to consider
> it.
>

Original text
{
Otherwise, if the top-most Route header refers to the Edge Proxy and  
contains a valid
flow identifier token created by this proxy, the proxy MUST remove the  
Route header and
forward the request over the 'logical flow' identified by the flow  
token, that is known
to deliver data to the specific target UA instance.
}

Since you re-state "if the top-most Route header refers to the Edge  
Proxy and contains a valid flow identifier token created by this  
proxy," I am lost with the "otherwise". Otherwise could be:

-Otherwise it is not a request.

-Otherwise the Route header does not contain a flowtoken

-Otherwise these do not refer to the same flow

I think that you mean "Otherwise these do not refer to the same flow"

True?

  If it is true, I find easier to read instead the following,

Original text:
{
    If these refer to the same flow, the Edge Proxy removes the Route
    header and continues processing the request.  Otherwise, if the top-
    most Route header refers to the Edge Proxy and contains a valid flow
    identifier token created by this proxy, the proxy MUST remove the
    Route header and forward the request over the 'logical flow'
    identified by the flow token, that is known to deliver data to the
    specific target UA instance.  For connection-oriented transports, if
    the flow no longer exists the proxy SHOULD send a 430 (Flow Failed)
    response to the request.
}

the following text:

New text, Suggestion :
{

    If these refer to the same flow it means that the request is
    coming from a user agent that established a flow to the Edge Proxy
    (a flow that was created previously in "outgoing direction").
    In this case the Edge Proxy removes the Route header and continues
    processing the request without introducing (no) new considerations
    related to the proxy behavior.

    Otherwise, if the flow in the flow token and the source of the request
    do not refer to the same flow, it means that the request is coming
    from a user agent that intends to reach another user agent through a
    flow ("ingoing direction").
    In this case the proxy MUST remove the Route header and forward the
    request over the 'logical flow' identified by the flow token, that
    is known to deliver data to the specific target UA instance.
}

  Where "outgoing" and "ingoing" refer to the following scenario

UAC--------------Edge PX----------------Other PX / Registrar..

     outgoing--->
     <---ingoing

Also I wrote the following flow chart. Could you verify if it is correct?

                .-------------.
                | New request |
                .-------------.
                       |
    .----------------------------------------.
    |      edge proxy is the host in the     |
    |    topmost Route header field value?   |
    |                 AND                    |--.
    | the Route header contains a flow token |  |NO
    .----------------------------------------.  |
                       |                        |
                       | YES               What to do?
                       |
                       V
    .----------------------------------------.
    | the proxy compares                     |
    | the flow in the flow token             |
    | with the source of the request         |--.
    | Are these equal?                       |  |NO
    .----------------------------------------.  |
                       |                        |
                       | YES                    |
                       | Outgoing case          |
                       V                        |
    .----------------------------------------.  |
    | Edge Proxy removes the Route header    |  |
    |  and continues processing the request  |  |
    .----------------------------------------.  |
                       |                        |
                       |                        |
                       V                        |
    .----------------------------------------.  |
    | Proxy continues processing the request |  |
    .----------------------------------------.  |
                       .                        |
                       .                        |
                                               /
                                              /
                                             /
                                            /
                                           /
                            Ingoing case  /
                                         /
                                        /
    .----------------------------------------.
    | Edge Proxy removes the Route header    |
    |  and continues processing the request  |
    | and forwards the request over the      |
    | 'logical flow' identified by the flow  |
    | token                                  |
    .----------------------------------------.

Regards

Sergio

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 12 Mar 2007 18:02:08 +0100

On Mar 12, 2007, at 2:34 PM, [email-masked] wrote:
>>> procedures with the following addition. If the Edge Proxy  
>>> receives  a request where the edge proxy is the host in the  
>>> topmost Route  header field value, and the Route header contains  
>>> a flow token, the  proxy compares the flow in the flow token with  
>>> the source of the  request.
>>
>>> If these refer to the same flow, the Edge Proxy removes the  
>>> Route  header and continues processing the request.
>>
>> that
>>> and contains a valid flow identifier token created by this  
>>> proxy,  the proxy MUST remove the Route header and forward the  
>>> request over  the 'logical flow' identified by the flow token,  
>>> that is known to  deliver data to the specific target UA instance.
>>
>> over

yes.

>> consider
> and contains a valid
> flow identifier token created by this proxy, the proxy MUST remove  
> the Route header and

Thank you.  I plan to use your wording with some minor modifications.

> UAC--------------Edge PX----------------Other PX / Registrar..

I understood you perfectly, but so you are aware, the opposite of  
"outgoing" is "incoming".

> Also I wrote the following flow chart. Could you verify if it is  

The flow chart is correct.  Under "what to do", the proxy does  
whatever it did before outbound existed.  ;-)

thanks,
-rohan

---

From: [email-masked]
Date: Tue, 13 Mar 2007 14:28:02 +0200

Hi,

> Thank you.  I plan to use your wording with some minor modifications.

Ok.

Thank you for your answers.

Now let me ask the following

** Q1.

>>> source of the register) with the source of the newly received request

  About "the  proxy compares the flow in the flow token with the  
source of the  request.", let me mention the steps that could be  
followed to make this comparison and indirectly verify if I am  
understanding what you propose. ( Assume that I am using algorithm 2 ):

1. From the received flowtoken I take the flow identifier (IP address,  
port, and transport combination) and decode base64. Then I get "back"  
the S array.

2. From S array I retrieve IP address and port and compare it with the  
IP address and port of the newly received request (these are obtained  
from the transport layer used to receive the newly received request).

  Is the above correct? (Assume that the transport protocol is the  
same and it is not included in the comparison).

** Q2.

  In section '5.2.  Generating Flow Tokens' you say

{
Algorithm 2:  When the proxy boots it selects a 20-octet crypto
       random key called K that only the Edge Proxy knows.  A byte array,
       called S, is formed that contains the following information about
       the flow the request was received on:  an enumeration indicating
       the protocol, the local IP address and port, the remote IP address
       and port.  The HMAC of S is computed using the key K and the HMAC-
       SHA1-80 algorithm, as defined in [11].  The concatenation of the
       HMAC and S are base64 encoded, as defined in [12], and used as the
       flow identifier.  When using IPv4 addresses, this will result in a
       32-octet identifier.
}

  Note: "an enumeration indicating
       the protocol, the local IP address and port, the remote IP address
       and port."

1) Where "local IP address and port" are the IP address and port of  
the edge proxy?

If, 'yes', then why should we consider the "local IP address and port"  
in every flow token if these are constant and do not introduce new  
information to identify different flows?
Note that the IP address or domain of the edge proxy is included in  
the Path header, so in case that we have several proxies the proxy "in  
charge" will be reached regardless of the flow token content. I can  
not imagine an scenario where including these in the flowtoken will  
introduce some advantage.

2) Where " the remote IP address and port." I understand that these  
are the destination for the REGISTER (e.g Registrar).

True?

  If it is true, then several UACs could have the same destination  
(same Registrar) and we are not introducing new information in  the  
token to distinguish a unique flow.
  I understand that the main reason to include these in the flowtoken  
to compare later with the IP address and port of the newly received  
request as it is mentioned in Q1 above.

  How about replacing the following ?

Original text:
{
       an enumeration indicating
       the protocol, the local IP address and port, the remote IP address
       and port.
}

by

Suggested text/idea:
{
       an enumeration indicating
       the protocol; the source IP address and port (after any  
possible NAT, i.e. the IP address and port retrieved from the  
transport layer that carries the received REGISTER), the remote IP  
address
       and port.
}

Regards,

Sergio

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 13 Mar 2007 13:43:40 +0100

Hi,

On Mar 13, 2007, at 1:28 PM, [email-masked] wrote:
> ** Q1.
>
>>>>> When an Edge Proxy receives a request, it applies normal  
>>>>> routing   procedures with the following addition. If the Edge  
>>>>> Proxy  receives  a request where the edge proxy is the host in  
>>>>> the  topmost Route  header field value, and the Route header  
>>>>> contains  a flow token, the  proxy compares the flow in the  
>>>>> flow token with  the source of the  request.
>>>>
> 1. From the received flowtoken I take the flow identifier (IP  
> address, port, and transport combination) and decode base64. Then I  
> get "back" the S array.
>
> 2. From S array I retrieve IP address and port and compare it with  
> the IP address and port of the newly received request (these are  
> obtained from the transport layer used to receive the newly  
> received request).
>

Yes

> 1) Where "local IP address and port" are the IP address and port of  

Yes

> If, 'yes', then why should we consider the "local IP address and  
> port" in every flow token if these are constant and do not  
> introduce new information to identify different flows?
> the Path header, so in case that we have several proxies the proxy  
> "in charge" will be reached regardless of the flow token content. I  
> can not imagine an scenario where including these in the flowtoken  
> will introduce some advantage.

If the edge proxy has multiple interfaces or supports multiple  
ports / transport protocols, this can be an issue.
> are the destination for the REGISTER (e.g Registrar).

No, this is the address and port of the UA.

thanks,
-rohan

>  I understand that the main reason to include these in the  
> flowtoken to compare later with the IP address and port of the  
> newly received request as it is mentioned in Q1 above.
>
>

---

From: [email-masked]
Date: Thu, 15 Mar 2007 19:25:33 +0200

Hi,

>>    2) Where " the remote IP address and port." I understand that   
>> these are the destination for the REGISTER (e.g Registrar).

> No, this is the address and port of the UA.

   In my opinion it could be easy to understand something like

Original text
{
   the remote IP address and port.
}

Suggestion
{
   remote IP address and port of the user agent that is sending the  
REGISTER (or creating the flow)
}

   Also it could be good if you mention that these (IP address and port
) are the "public" IP address and port (i.e. the IP address and port
after a possible NAT).

Sergio

---

From: [email-masked]
Date: Fri, 23 Mar 2007 14:30:59 +0200

Comment:

About section '5.3.  Forwarding Requests' :

  I understand that here you try to describe in a formal way a  
procedure to identify if the flow is arriving from the flow or from  
somewhere else.

  I agree that this method it is OK for connectionless protocols. Now,  
in connection oriented protocols we will have to maintain a  
connection; then we can easily recognize  the source of a message  
merely if it arrives through this connection (connected flow already  
established between the edge proxy and a UAC) or not.

  So, for connection oriented protocols the method that you propose to  
check the origin of the message could be optional depending on the  
implementation approach.

  For example I am considering an implementation where every flow has  
a dedicated TCP connection for every UAC, and I manage the connections  
(flows) independently. Then, when something arrives from a certain  
connection (flow) I know that it is from the UAC that connected  
before, so I do not need to verify something that I know..

Regrads,
Sergio.