Our approach tries to use the flow token also in responses: we just
put the flow token in the Via. As mentioned before:
-the UA stores the flow token when it receives a 200 OK after
REGISTER;
So the flow token is stored in the UA's route set?
-then it puts it into every SIP request that is sent over a flow;
So it goes into the Route headers.
-then the edge proxy copies the flow token to the URI part of the
Via
when it composes the Via before to forward the message.
ok
-Later, when the response arrives at the edge proxy, it tries to
decode the flow token in the Via, if it succeeds, it forwards the
response over the flow indicated in the flow token.
yes, looks good to me.
At what moment you generate the "branch flow token"
(for example, when the Via is created?)
yes, that was the idea.
I can not understand completely the idea, from my point of view
it is easier to use the same flow token. Considering that the flow
token considers the reboot, why it could be an advantage to use the
"branch flow token" instead of the flow-token ?
Well that's what I had thought originally (that it is
easier to use the same flow token).
In an earlier e-mail, I had said:
3.
In the Via header's branch parameter, it would encode the required
flow token.
But you challenged that with this problem:
Here is the issue : From were you get the flow token?
(In my previous email I mentioned 2 options... )
So, I'm a bit confused. Is there a problem with using the
flow token in the Via or not? I think the answer is no.
Anyway, the conclusion is this:
"Yes, it is possible for a transaction-stateless proxy
to support the outbound draft".
Regards,
Attila
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 19 November 2007 22:02
To: Attila Sipos
Cc: [email protected]
Subject: RE: [Sip] Can a
transactionstatelessproxysupportOutbounddraft?Ifyes, how will the
response be sentback theUAbehind NAT
Hi,
I feel this would not be a problem for a stateless proxy providing
that it is not just a raw socket descriptor id that is passed to the
registrar. The branch parameter in the Via would need some kind of
hashed/encrypted "reboot count" parameter as well as the socket id.
Then if the edge-proxy rebooted, it would know that the response
coming back is stale. There are many ways to do the
hashing/encryption - you could use a method similar to that used in
the gruu draft Appendix A.2.
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-sip-gruu-
15
.txt
In outbound 10, 5.2. Generating Flow Tokens :
"When the proxy boots it selects a 20-octet crypto
random key called K that only the Edge Proxy knows."
Instead to using the 'reboot count', the approach mentioned in the
draft already considers the case of old flow tokens that can remain
stored in the registrar by using a different key every time the proxy
reboots.
So the Via header's branch parameter would contain encoded information
about:
1. the flow back to the UA (socket id, IP, port) 2. the reboot count
Our approach tries to use the flow token also in responses: we just
put the flow token in the Via. As mentioned before:
-the UA stores the flow token when it receives a 200 OK after
REGISTER;
-then it puts it into every SIP request that is sent over a flow;
-then the edge proxy copies the flow token to the URI part of the Via
when it composes the Via before to forward the message.
-Later, when the response arrives at the edge proxy, it tries to
decode the flow token in the Via, if it succeeds, it forwards the
response over the flow indicated in the flow token.
So my proposal is generating some kind of flow token (but not THE same
"flow token"as used in the REGISTER). So there is the "flow token" as
described in
theoutbound draft and now there is also a "branch flow token" that I
am
?proposing.
Perhaps can be a possible solution but seems complex.
At what moment you generate the "branch flow token" (for example,
when the Via is created?)
I can not understand completely the idea, from my point of view it is
easier to use the same flow token. Considering that the flow token
considers the reboot, why it could be an advantage to use the "branch
flow token" instead of the flow-token ?
Regards,
Sergio
Quoting Attila Sipos <[EMAIL PROTECTED]>:
The problem with the above (separated elements) is that there is
not synchronization about the state of the socket descriptors. As
mentioned
before, if the edge proxy crashes the socket descriptors used
immediately
after reboot could result in delivering messages to different flows.
In my opinion the randomness included in the flow token avoids that
to
happen, since after reboot the flowtoken can not be decoded and/or
find an
existing flow and that cause the return a error response.
Yes, absolutely. And this is a problem with stateful proxies too.
I have agreed with everything you've said.
However, I still think there is a way to do an outbound-compatible
edge proxy with a transaction-stateless/call-stateless proxy.
So I now go back to say something similar to what I said before.
But first, I will refer to something you said in an earlier mail:
Furthermore my registrar should not store socket descriptors due
that if the edge proxy crashes, the registrar could have a number of
descriptor that after the crash belong to other flows.
I feel this would not be a problem for a stateless proxy providing
that it is not just a raw socket descriptor id that is passed to the
registrar. The branch parameter in the Via would need some kind of
hashed/encrypted "reboot count" parameter as well as the socket id.
Then if the edge-proxy rebooted, it would know that the response
coming back is stale. There are many ways to do the
hashing/encryption - you could use a method similar to that used in
the gruu draft Appendix A.2.
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-sip-gruu-
15
.txt
So the Via header's branch parameter would contain encoded information
about:
1. the flow back to the UA (socket id, IP, port) 2. the reboot count
So now I go back to something else you said:
2) generate again the flow token for every request (very bad from
security point of views) and destroys the consistency of the system
since you can send requests for non existing flows. Note that the
draft mentions that the flow and the flow token is only created with
REGISTERs.
So my proposal is generating some kind of flow token (but not THE same
"flow token"
as used in the REGISTER). So there is the "flow token" as described
in the outbound draft and now there is also a "branch flow token" that
I am proposing.
And, as explained before, the information in the "branch flow token"
is used to route responses back to the UA. But the original "flow
token" is never changed.
The original "flow token" would still be used when forwarding requests
to the UA because the Edge Proxy (in your diagram) would've added it
to the Path. So requests to the UA would still work.
Now I'm not sure about the security aspects.
What security problems could there be with "branch flow token" idea?
Regards,
Attila
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 16 November 2007 15:53
To: Attila Sipos
Subject: RE: [Sip] Can a transaction
statelessproxysupportOutbounddraft?Ifyes, how will the response be
sent back theUAbehind NAT
I am starting to see the problems.
If I understand correctly, your scenario is this...
REGISTRAR--------PROXY----------NAT---------SIP UA
Can you confirm?
more specifically my scenario is
REGISTRAR/PROXY--------EDGEPROXY----------NAT---------SIP UA
where PROXY is a traditional SIP proxy
And, since you were talking about scalability, you might also have
REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA
is this right?
About scalability I was thinking about
/EDGEPROXY1\
REGISTRAR/PROXY-------- ----------NAT---------SIP UA
\EDGEPROXY2/
So that the UA has flows to EDGEPROXY1 and EDGEPROXY2.
I have no experience with registrars, I guess that in your case you
have a REGISTRAR/EDGEPROXY in the same process (or group of processes)
and not REGISTRAR--------EDGEPROXY (linked by other means).
The problem with the above (separated elements) is that there is not
synchronization about the state of the socket descriptors. As
mentioned before, if the edge proxy crashes the socket descriptors
used immediately after reboot could result in delivering messages to
different flows.
In my opinion the randomness included in the flow token avoids that
to happen, since after reboot the flowtoken can not be decoded and/or
find an existing flow and that cause the return a error response.
Then another entry in the registrar binding will be used, i.e. other
flow token. If you have a second edge proxy (that does not crashed at
the same time that the first one :) and the flow token belongs to the
second edge proxy, the message will reach the UA over a flow
previously established to the second edge proxy.
BR
Sergio
Quoting Attila Sipos <[EMAIL PROTECTED]>:
3.
In the Via header's branch parameter, it would encode the
required
flow token.
Here is the issue : From were you get the flow token?
(In my previous email I mentioned 2 options... )
OK I'm starting to see your problem.
The registration record stores the flow token (obviously)
It seems that you are integrating the edge proxy and registrar in
the
same code, right?
yes, that's it.
And the socket id for the flow would be stored as well (for
Can you confirm that you call socket id to the socket/file
descriptor
of the connection?
yes.
connection-oriented
protocols). So if you received a request on that socket, you could
match that up to one of the registration records and hence, one of
the
flow tokens.
Good approach. I assume that you have available the socket
descriptor
in the registrar, so basically you consider storing the socket
descriptor
(number) in the registrar tables. Then perhaps using a flow token
it
is not
necessary since you have available in the socket descriptor all the
information
that describes a flow (TCP case).
That's true. I might not need the flow tokens.
I hope I have explained how the flow token might be mapped to the
socket.
Yes if my comments above make sense..
I can now see that my idea wouldn't work for UDP.
Now for UDP perhaps you can consider storing the socket descriptor
for
UDP and the IP and port for the flow from the NAT.
yes, that would work I think.
Furthermore my registrar should not store socket descriptors due
that
if the edge proxy crashes, the registrar could have a number of
descriptor
that after the crash belong to other flows.
I generate the flow token with REGISTER and send it to the
registrar (other node). The approach works as the draft says for
incoming
requests
(to the Calle). Now when the Callee sends requests, and the
requests
are
sent over the flow, the responses of that request reach first the
edge
proxy
and it can not forward them to the Callee over the flow, because
these responses don't have the flow token (and the flow token is
not
stored
in
the edge proxy)...
I am starting to see the problems.
If I understand correctly, your scenario is this...
REGISTRAR--------PROXY----------NAT---------SIP UA
Can you confirm?
And, since you were talking about scalability, you might also have
REGISTRAR--------PROXY--------PROXY----------NAT---------SIP UA
is this right?
But what if you used the gruu in the contact to match up with the
gruu
of a registration? Then the registration record tells tells you
about
the flow token. That would work wouldn't it?
I have not background with gruu. Could you recommend what could I
read about it?
Sorry, I didn't mean gruu, I was mixing up my drafts!
I was just looking for a unique identifier for the UA which is the
sip.instance from the outbound draft (not gruu).
Regards,
Attila
