>> I don't know how to answer where the flow token should be stored in >>the UA. I did not studied about the UA details.
rfc 3327 talks about the Path header as a way for REGISTRARs to work out the path back to a UA. It also says that the UA can check the Path header to make sure that undesirable proxies don't insert themselves in the route. The Path, like Record-Route, is reflected back so this can be stored by the UA. There is nowhere I know which says the UA must store it but it would seem useful to do so. >>>> 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. >> >> I think that NO if we do as we propose. >> >> And Yes, it is a problem if we limit only to the draft because the >>draft does not say anything explicitly about >>1) In the UA: storing the flow-token in the UA >>2) In the UA: putting the flow token in the Route header if the flow >>is used for outgoing requests >>3) In the Ed.proxy : copying the flow token to the Via header. I agree, you need to do extra things (more than what the draft specified) but this is fine. All the proposed actions are transparent to the UA's below and transparent to the proxies above. So it cannot break anything. >> One problem that I see generating the flow token at any time is >>about the proxy rebooting; it will generate a flow token for a non >>existent flow (although this issue is for discussing hours, because >>depending on the implementation and protocols one can argue that if >>the edge proxy rebooted, the UAC can no longer use the flow because it >>disappeared.). I don't think there's much you can do. Except realise that the flow token is stale since the proxy rebooted. One would have to wait for the flow to get re-established to get successful routing. >>Anyway the most important characteristic of our >>approach is that the edge proxy can know that what arrives comes from >>an outbound flow and then have a criteria to determine that the Via >>header must have a flow token. Nevertheless I recognize that the >>discussion is not complete. The edge proxy must have some kind of >>mapping between the flow-tokens and socket descriptors that we did not >>discuss.. I thought we did discuss that the mapping is effectively stored in the flow token. >> After all these discussions we should remember that in fact the >>draft does not discusses about using a flow for outbound requests; and >>that a UAC can always avoid using the flow for outgoing requests just >>by using the traditional approach (the UAC is behind the NAT and is >>free to form any number of connections independent of outbound flows) Yes. The UAC could send a request without using the flow. I wonder how often this happens. This discussion has certainly raised lots of questions. Regards, Attila ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tue 20/11/2007 18:14 To: Attila Sipos Cc: [email protected] Subject: RE: [Sip] Can atransactionstatelessproxysupportOutbounddraft?Ifyes, how will the responsebe sentback theUAbehind NAT >>> 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? I don't know how to answer where the flow token should be stored in the UA. I did not studied about the UA details. We consider that the Edge Proxy is stateless but UACs are stateful. We assume that in an UAC every flow will be associated to a transaction and the transaction can store the flow token. We did not research about the UAC storing the flow token; so any comments about feasibility are welcome. > >>> -then it puts it into every SIP request that is sent over a flow; > > So it goes into the Route headers. Yes > 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. I think that NO if we do as we propose. And Yes, it is a problem if we limit only to the draft because the draft does not say anything explicitly about 1) In the UA: storing the flow-token in the UA 2) In the UA: putting the flow token in the Route header if the flow is used for outgoing requests 3) In the Ed.proxy : copying the flow token to the Via header. This is the approach we propose. It could be suggested that since the origin IP and port and so on are known in the Edge Proxy, the flow token can be generated at any time when request arrives. I don't know way we did not discuss this option before (our approach was storing the flow token in the UA and your approach was retrieving it from the registrar). One problem that I see generating the flow token at any time is about the proxy rebooting; it will generate a flow token for a non existent flow (although this issue is for discussing hours, because depending on the implementation and protocols one can argue that if the edge proxy rebooted, the UAC can no longer use the flow because it disappeared.). Anyway the most important characteristic of our approach is that the edge proxy can know that what arrives comes from an outbound flow and then have a criteria to determine that the Via header must have a flow token. Nevertheless I recognize that the discussion is not complete. The edge proxy must have some kind of mapping between the flow-tokens and socket descriptors that we did not discuss... we sent to publish an abstract proposing a solution at application level about this issue. After all these discussions we should remember that in fact the draft does not discusses about using a flow for outbound requests; and that a UAC can always avoid using the flow for outgoing requests just by using the traditional approach (the UAC is behind the NAT and is free to form any number of connections independent of outbound flows) Sergio Quoting Attila Sipos <[EMAIL PROTECTED]>: >>> 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 >>> >> >> >> > > > >
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
