Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.txt

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 2 Sep 2014 01:47:49 -0700

I updated the rfc5766-turn-server project code (version 3.2.4.3) to reflect
the changes in the new draft specs version in regard to the Refresh
re-transmission. The coturn project code will be updated later.

Oleg

On Mon, Aug 25, 2014 at 10:32 PM, Oleg Moskalenko <[email-masked]>
wrote:

> I agree with the updates.
>
> The current rfc5766-turn-server and coturn servers are missing only one
> thing from the new specs: the added last paragraph in the section 3.2.2,
> about the REFRESH re-transmission. It will be updated in the next versions.
>
> Oleg
>
>
>
> On Mon, Aug 25, 2014 at 9:43 AM, Prashanth Patil (praspati) <
> [email-masked]> wrote:
>
>> All,
>> We've submitted a revision of the 'Mobility with TURN' draft. The update
>> addresses comments raised by Brandon during IETF-90 regarding TURN client
>> and server behavior when a STUN refresh message carrying MOBILITY-TICKET
>> attribute is lost.
>>
>> Comments welcome.
>>
>> Thanks,
>> Prashanth
>>
>>
>> On 8/25/14 6:26 PM, "[email-masked]" <[email-masked]>
>> wrote:
>>
>> >
>> >A new version of I-D, draft-wing-tram-turn-mobility-01.txt
>> >has been successfully submitted by Prashanth Patil and posted to the
>> >IETF repository.
>> >
>> >Name:          draft-wing-tram-turn-mobility
>> >Revision:      01
>> >Title:         Mobility with TURN
>> >Document date: 2014-08-25
>> >Group:         Individual Submission
>> >Pages:         10
>> >URL:
>> >http://www.ietf.org/internet-drafts/draft-wing-tram-turn-mobility-01.txt
>> >Status:
>> >https://datatracker.ietf.org/doc/draft-wing-tram-turn-mobility/
>> >Htmlized:
>> >http://tools.ietf.org/html/draft-wing-tram-turn-mobility-01
>> >Diff:
>> >http://www.ietf.org/rfcdiff?url2=draft-wing-tram-turn-mobility-01
>> >
>> >Abstract:
>> >   It is desirable to minimize traffic disruption caused by changing IP
>> >   address during a mobility event.  One mechanism to minimize
>> >   disruption is to expose a shorter network path to the mobility event
>> >   so only the local network elements are aware of the changed IP
>> >   address but the remote peer is unaware of the changed IP address.
>> >
>> >   This draft provides such an IP address mobility solution using TURN.
>> >   This is achieved by allowing a client to retain an allocation on the
>> >   TURN server when the IP address of the client changes.
>> >
>> >
>> >
>> >
>> >
>> >Please note that it may take a couple of minutes from the time of
>> >submission
>> >until the htmlized version and diff are available at tools.ietf.org.
>> >
>> >The IETF Secretariat
>> >
>>
>> _______________________________________________
>> tram mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tram
>>
>
>

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 2 Sep 2014 12:36:10 +0000

Thanks for the update, Oleg.

-Prashanth

From: Oleg Moskalenko <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 2, 2014 2:17 PM
To: Prashanth Patil <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.txt

I updated the rfc5766-turn-server project code (version 3.2.4.3) to reflect the changes in the new draft specs version in regard to the Refresh re-transmission. The coturn project code will be updated later.

Oleg

On Mon, Aug 25, 2014 at 10:32 PM, Oleg Moskalenko <[email-masked]<mailto:[email-masked]>> wrote:
I agree with the updates.

The current rfc5766-turn-server and coturn servers are missing only one thing from the new specs: the added last paragraph in the section 3.2.2, about the REFRESH re-transmission. It will be updated in the next versions.

Oleg

On Mon, Aug 25, 2014 at 9:43 AM, Prashanth Patil (praspati) <[email-masked]<mailto:[email-masked]>> wrote:
All,
We've submitted a revision of the 'Mobility with TURN' draft. The update
addresses comments raised by Brandon during IETF-90 regarding TURN client
and server behavior when a STUN refresh message carrying MOBILITY-TICKET
attribute is lost.

Comments welcome.

Thanks,
Prashanth

On 8/25/14 6:26 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
wrote:

>until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
>The IETF Secretariat
>

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

---

From: Brandon Williams <[email-masked]>
Date: Wed, 03 Sep 2014 10:14:51 -0400

I see this new text in the draft.

"To accommodate for loss of Refresh responses, a server must retain
the old STUN MOBILITY-TICKET attribute for a period of at least 30
seconds to be able recognize a retransmission of Refresh request with
the old STUN MOBILITY-TICKET attribute from the client."

Do you mean that the old ticket will be stored along with the new ticket 
in the allocation record? and that a refresh request with a mobility 
ticket that doesn't match the current ticket will have the ticket 
matched against the old ticket? That makes sense to me. I just think it 
would be good to directly state the intended use.

On a separate note, why wouldn't the server just hold onto the old 
ticket until it receives a valid refresh request that contains the new 
ticket? If there are memory space concerns related to the size of the 
ticket, then perhaps the client could immediately send a refresh request 
with new ticket as confirmation that it was received and that the old 
ticket can be discarded.

Regarding construction of the ticket, the draft currently states: "TURN 
server can store system internal data into the ticket that is encrypted 
by a key known only to the TURN server and sends the ticket in the STUN 
MOBILITY-TICKET attribute as part of Allocate success response. The 
ticket is opaque to the client, so the structure is not subject to 
interoperability concerns, and implementations may diverge from this 
format. TURN Allocation state information is encrypted using 128-bit key 
for Advance Encryption Standard (AES) and 256-bit key for HMAC-SHA-256 
for integrity protection."

I think it might be good for the document to be more explicit about the 
minimum content that is required in ticket for it to fulfill its 
purpose. This includes the client-side tuple for the turn allocation 
(required for lookup) and it might need a source of entropy to prevent 
replay of the token, though maybe the MESSAGE-INTEGRITY attribute on the 
STUN message serves that purpose well enough. What else do you envision 
being contained in the token?

--Brandon

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 3 Sep 2014 08:24:44 -0700

see in the text:

On Wed, Sep 3, 2014 at 7:14 AM, Brandon Williams <
[email-masked]> wrote:

> in the allocation record? and that a refresh request with a mobility ticket
> that doesn't match the current ticket will have the ticket matched against
> the old ticket?

No, the meaning is slightly different. For an unreliable protocol, the
client may not receive the refresh response. The client may re-transmit the
REFRESH request from the same network endpoint. And the client will receive
the same refresh response (with the same new ticket inside) because the
server will recognize the refresh request retransmission (because the
server stores the old ticket associated with the TURN session).

On the other hand, if the client sends the REFRESH request (with old
ticket) from a DIFFERENT network endpoint then the client will receive a
sort of "unknown mobile ticket" error because the old ticket has already
been "used" for the session relocation. The old ticket can only be used for
the retransmission purpose. It cannot be used for the session relocation
because it would lead to uncontrolled resource leakage.

> That makes sense to me. I just think it would be good to directly state
> the intended use.
>

I agree that a clarification would be proper.

>
> On a separate note, why wouldn't the server just hold onto the old ticket
> until it receives a valid refresh request that contains the new ticket? If
> there are memory space concerns related to the size of the ticket, then
> perhaps the client could immediately send a refresh request with new ticket
> as confirmation that it was received and that the old ticket can be
> discarded.
>
> server can store system internal data into the ticket that is encrypted by
> a key known only to the TURN server and sends the ticket in the STUN
> MOBILITY-TICKET attribute as part of Allocate success response. The ticket
> is opaque to the client, so the structure is not subject to
> for Advance Encryption Standard (AES) and 256-bit key for HMAC-SHA-256 for
> integrity protection."
>
> minimum content that is required in ticket for it to fulfill its purpose.
> This includes the client-side tuple for the turn allocation (required for
> lookup) and it might need a source of entropy to prevent replay of the
> token, though maybe the MESSAGE-INTEGRITY attribute on the STUN message
> serves that purpose well enough. What else do you envision being contained
> in the token?
>

I do not think that the document must specify what the ticket content is.
The ticket content may be totally opaque and meaningless - that's up to
server what to do about the ticket. The server may store all meaningful
information in its database, and the ticket is just a sequence of random
symbols. For the purpose of this specification, I see no reason why the
ticket content is of any interest.

Thanks
Oleg

---

From: Brandon Williams <[email-masked]>
Date: Wed, 03 Sep 2014 12:26:47 -0400

On 09/03/2014 11:24 AM, Oleg Moskalenko wrote:
> see in the text:
>
>
> On Wed, Sep 3, 2014 at 7:14 AM, Brandon Williams
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Do you mean that the old ticket will be stored along with the new
>     ticket in the allocation record? and that a refresh request with a
>     mobility ticket that doesn't match the current ticket will have the
>     ticket matched against the old ticket?
>
>
> client may not receive the refresh response. The client may re-transmit
> the REFRESH request from the same network endpoint. And the client will
> receive the same refresh response (with the same new ticket inside)
> because the server will recognize the refresh request retransmission
> (because the server stores the old ticket associated with the TURN session).

This sounds like the operation I was talking about.

> been "used" for the session relocation. The old ticket can only be used
> for the retransmission purpose. It cannot be used for the session
> relocation because it would lead to uncontrolled resource leakage.

So you're suggesting that server should not support mobility in this 
case. If that's true, then the document should definitely state that, 
and also make clear why this restriction is important.

>
>     That makes sense to me. I just think it would be good to directly
>     state the intended use.
>
>
>
>     ticket until it receives a valid refresh request that contains the
>     new ticket? If there are memory space concerns related to the size
>     of the ticket, then perhaps the client could immediately send a
>     refresh request with new ticket as confirmation that it was received
>     and that the old ticket can be discarded.
>
>     Regarding construction of the ticket, the draft currently states:
>     "TURN server can store system internal data into the ticket that is
>     encrypted by a key known only to the TURN server and sends the
>     ticket in the STUN MOBILITY-TICKET attribute as part of Allocate
>     success response. The ticket is opaque to the client, so the
>     structure is not subject to interoperability concerns, and
>     implementations may diverge from this format. TURN Allocation state
>     information is encrypted using 128-bit key for Advance Encryption
>     Standard (AES) and 256-bit key for HMAC-SHA-256 for integrity
>     protection."
>
>     I think it might be good for the document to be more explicit about
>     the minimum content that is required in ticket for it to fulfill its
>     (required for lookup) and it might need a source of entropy to
>     prevent replay of the token, though maybe the MESSAGE-INTEGRITY
>     attribute on the STUN message serves that purpose well enough. What
>     else do you envision being contained in the token?
>
>
>
> I do not think that the document must specify what the ticket content
> is. The ticket content may be totally opaque and meaningless - that's up
> to server what to do about the ticket. The server may store all
> meaningful information in its database, and the ticket is just a
> sequence of random symbols. For the purpose of this specification, I see
> no reason why the ticket content is of any interest.

Some examples might be helpful to implementers, especially to help them 
get the security aspects of the token right. For example, if there's no 
source of entropy, then the encrypt and auth results may be problematic. 
Your example of a random series of bytes is fine in this regard, but if 
someone where to do what the spec appears to be suggesting and nothing 
more, that would not be particularly good.

--Brandon

>         On 8/25/14 6:26 PM, "[email-masked]
>         <mailto:[email-masked]>" <[email-masked]
>         <mailto:[email-masked]>>
>         wrote:
>
>
>             A new version of I-D, draft-wing-tram-turn-mobility-__01.txt
>             http://www.ietf.org/internet-__drafts/draft-wing-tram-turn-__mobility-01.txt
>             <http://www.ietf.org/internet-drafts/draft-wing-tram-turn-mobility-01.txt>
>             Status:
>             https://datatracker.ietf.org/__doc/draft-wing-tram-turn-__mobility/
>             <https://datatracker.ietf.org/doc/draft-wing-tram-turn-mobility/>
>             Htmlized:
>             http://tools.ietf.org/html/__draft-wing-tram-turn-mobility-__01
>             <http://tools.ietf.org/html/draft-wing-tram-turn-mobility-01>
>             Diff:
>             http://www.ietf.org/rfcdiff?__url2=draft-wing-tram-turn-__mobility-01
>             <http://www.ietf.org/rfcdiff?url2=draft-wing-tram-turn-mobility-01>
>
>             Abstract:
>             until the htmlized version and diff are available at
>             tools.ietf.org <http://tools.ietf.org>.
>
>             The IETF Secretariat
>
>
>         _________________________________________________
>         tram mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/tram
>         <https://www.ietf.org/mailman/listinfo/tram>
>
>
>     --
>     _________________________________________________
>     tram mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/tram
>     <https://www.ietf.org/mailman/listinfo/tram>
>
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 3 Sep 2014 09:55:56 -0700

> This sounds like the operation I was talking about.

OK

> So you're suggesting that server should not support mobility in this case.
> If that's true, then the document should definitely state that, and also
> make clear why this restriction is important.

Yes, I think that this can be clarified in the document.

> more, that would not be particularly good.

I'd leave that to the implementation completely - we can just impose a
requirement that the token's meaning must be known only to the server. How
it is achieved - by using random string of bytes or by using really good
encryption - let the implementation to decide. I personally think that the
means of hiding information are not relevant in this context because there
are no parties in the information exchange - the information is going from
server to the same server; we do not have to set standards when we do not
have interacting parties. That's up to the server what to do with its own
information. If the server implementation is bad and it cannot hide its own
information - well, then it means that this is a bad program.

Let's not set standards when they do not have a useful purpose.

---

From: Brandon Williams <[email-masked]>
Date: Wed, 03 Sep 2014 13:46:32 -0400

On 09/03/2014 12:55 PM, Oleg Moskalenko wrote:

[snip]

>     Some examples might be helpful to implementers, especially to help
>     them get the security aspects of the token right. For example, if
>     there's no source of entropy, then the encrypt and auth results may
>     be problematic. Your example of a random series of bytes is fine in
>     this regard, but if someone where to do what the spec appears to be
>     suggesting and nothing more, that would not be particularly good.
>
>
> requirement that the token's meaning must be known only to the server.
> How it is achieved - by using random string of bytes or by using really
> good encryption - let the implementation to decide. I personally think
> that the means of hiding information are not relevant in this context
> because there are no parties in the information exchange - the
> information is going from server to the same server; we do not have to
> set standards when we do not have interacting parties. That's up to the
> server what to do with its own information. If the server implementation
> is bad and it cannot hide its own information - well, then it means that
> this is a bad program.
>

The security considerations section of the document currently states 
"TURN server MUST use strong encryption and integrity protection for the 
ticket", so simply using a random string of bytes for the ticket, as you 
seem to be suggesting, is not allowed by the current draft.

I think my primary point is that the security considerations section 
needs more work. It's not enough to just use strong encryption and 
integrity protection algorithms. It's also important to ensure that the 
resulting encrypted token is not easily predictable (and therefore 
easily reusable), which is why a source of entropy is important.

--Brandon

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 3 Sep 2014 11:48:03 -0700

On Wed, Sep 3, 2014 at 10:46 AM, Brandon Williams <
[email-masked]> wrote:

> The security considerations section of the document currently states "TURN
> server MUST use strong encryption and integrity protection for the ticket",
> so simply using a random string of bytes for the ticket, as you seem to be
> suggesting, is not allowed by the current draft.
>

You are not right. A random unique string of bytes, with the right degree
of the entropy, is the ultimate form of encryption - when the information
is hidden so that only the right entity can decrypt it. An encryption
algorithm is useful when a stateless server implementation is used and some
meaningful information is hidden in the ticket. But when the server is
stateful, then a totally random unique bytes can be used - and the server
can keep the information inside it, and the ticket is only a pointer to
that information inside the server - so no information leak is possible.

>
> I think my primary point is that the security considerations section needs
> more work. It's not enough to just use strong encryption and integrity
> protection algorithms. It's also important to ensure that the resulting
> encrypted token is not easily predictable (and therefore easily reusable),
> which is why a source of entropy is important.
>

You are mixing two valid (but different) approaches to tickets. Let's not
create a mess.

If you are using a stateless server, and you are hiding information inside
the ticket, then you have to use the encryption and integrity protection
algorithm of good strengths. Then the entropy is NOT relevant at all in
this case - because there is no randomness in the ticket.

On the other hand, if you are using a stateful server, and no information
is hidden inside the ticket, then indeed the server must use the proper
ticket generation algorithm, so it would be difficult to predict.

I think that the security section must mention these two approaches.

---

From: Brandon Williams <[email-masked]>
Date: Wed, 03 Sep 2014 17:04:23 -0400

On 09/03/2014 02:48 PM, Oleg Moskalenko wrote:
>
>
>
> On Wed, Sep 3, 2014 at 10:46 AM, Brandon Williams
>     "TURN server MUST use strong encryption and integrity protection for
>     the ticket", so simply using a random string of bytes for the
>     ticket, as you seem to be suggesting, is not allowed by the current
>     draft.
>
>
> You are not right. A random unique string of bytes, with the right
> degree of the entropy, is the ultimate form of encryption - when the
> information is hidden so that only the right entity can decrypt it. An
> encryption algorithm is useful when a stateless server implementation is
> used and some meaningful information is hidden in the ticket. But when
> the server is stateful, then a totally random unique bytes can be used -
> and the server can keep the information inside it, and the ticket is
> only a pointer to that information inside the server - so no information
> leak is possible.

The question of whether a random string of bytes can be considered 
encryption has a lot to do with what that random string of bytes gives 
you access to. Providing that there are enough mechanisms in place to 
prevent me from doing anything useful with the random string of bytes 
(e.g. cut off access to a legitimate user by sending the token as if it 
were mine), then I agree with you that it can be considered a form of 
encryption because getting access to the raw token gives me nothing of 
value.

That said, the same argument can be made for a token that contains 
encrypted TURN Allocation state information, in that the encryption only 
prevents you from seeing the state information. If you can get something 
useful simply by knowing the encrypted version of the token then there 
is something wrong with the way the token is being generated.

I think it would be useful for the security considerations section of 
the document to make the argument that the token has no value of its own 
and to highlight the internal requirements of the TURN server 
implementation that ensure this will be true.

>     integrity protection algorithms. It's also important to ensure that
>     the resulting encrypted token is not easily predictable (and
>     therefore easily reusable), which is why a source of entropy is
>     important.
>
>
> You are mixing two valid (but different) approaches to tickets. Let's
> not create a mess.
>
> If you are using a stateless server, and you are hiding information
> inside the ticket, then you have to use the encryption and integrity
> protection algorithm of good strengths. Then the entropy is NOT relevant
> at all in this case - because there is no randomness in the ticket.

I disagree. If there is no source of entropy, then I can learn something 
from the ticket based on its encrypted form. For example, if I can see 
that every connection with the same client-side tuple ends up with 
exactly the same ticket, then I have most likely learned something about 
the unencrypted form of the ticket that will help me to crack the keys 
used to construct the ticket. If the source of entropy is built into the 
algorithm, then you're right that a good algorithm is good enough. 
However, some common encryption algorithms require the user to provide 
such entropy (e.g. via a random initialization vector).

--Brandon

>
> On the other hand, if you are using a stateful server, and no
> information is hidden inside the ticket, then indeed the server must use
> the proper ticket generation algorithm, so it would be difficult to predict.
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 3 Sep 2014 14:29:11 -0700

please see below:

On Wed, Sep 3, 2014 at 2:04 PM, Brandon Williams <
[email-masked]> wrote:

> encryption has a lot to do with what that random string of bytes gives you
> access to. Providing that there are enough mechanisms in place to prevent
> me from doing anything useful with the random string of bytes (e.g. cut off
> access to a legitimate user by sending the token as if it were mine), then
> I agree with you that it can be considered a form of encryption because
> getting access to the raw token gives me nothing of value.
>
> useful simply by knowing the encrypted version of the token then there is
> something wrong with the way the token is being generated.
>
> I think it would be useful for the security considerations section of the
> document to make the argument that the token has no value of its own and to
> highlight the internal requirements of the TURN server implementation that
> ensure this will be true.

The normal user authentication is still in the picture. So if a wrong user
uses the token that was granted to a different legitimate user, then the
request will be rejected and the wrong user (that cannot authenticate
itself as the original user) will not benefit by snooping the token. May be
it is worth mentioning in the security section.

> from the ticket based on its encrypted form. For example, if I can see that
> every connection with the same client-side tuple ends up with exactly the
> same ticket, then I have most likely learned something about the
> unencrypted form of the ticket that will help me to crack the keys used to
> construct the ticket. If the source of entropy is built into the algorithm,
> then you're right that a good algorithm is good enough. However, some
> common encryption algorithms require the user to provide such entropy (e.g.
> via a random initialization vector).
>

That's right, I agree with that part.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 4 Sep 2014 10:37:32 +0000

Oleg Wrote:
I think it would be useful for the security considerations section of the document to make the argument that the token has no value of its own and to highlight the internal requirements of the TURN server implementation that ensure this will be true.

The normal user authentication is still in the picture. So if a wrong user uses the token that was granted to a different legitimate user, then the request will be rejected and the wrong user (that cannot authenticate itself as the original user) will not benefit by snooping the token. May be it is worth mentioning in the security section.

[TR] It’s already discussed in the draft. Section 3.2.2
<snip>
   If the source IP address and port of the Refresh Request is different
   from the stored 5-tuple allocation, the TURN server proceeds with
   MESSAGE-INTEGRITY validation to identify the that it is the same user
   which had previously created the TURN allocation.  If the above
   checks are not successful then server MUST reject the request with a
   441 (Wrong Credentials) error.
</snip>

Brandon Wrote:
I disagree. If there is no source of entropy, then I can learn something from the ticket based on its encrypted form. For example, if I can see that every connection with the same client-side tuple ends up with exactly the same ticket, then I have most likely learned something about the unencrypted form of the ticket that will help me to crack the keys used to construct the ticket. If the source of entropy is built into the algorithm, then you're right that a good algorithm is good enough. However, some common encryption algorithms require the user to provide such entropy (e.g. via a random initialization vector).

[TR] Agreed. We can add a recommendation of constructing the token just like it’s done in http://tools.ietf.org/html/rfc4507#section-4

-Tiru

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Thu, 4 Sep 2014 12:57:16 +0000

>This sounds like the operation I was talking about.

Yes, this is the intention of the text in the draft. Does it need
rewording?

>and also make clear why this restriction is important.

We'll spell this out in the next revision.

>> no reason why the ticket content is of any interest.

I agree. Construction of the ticket and the fact that the server is
stateful or stateless is an implementation detail. The ticket is an opaque
object as far as the client is concerned and is only meaningful to the
server. The standard should hence not dictate the means to
generate/construct this ticket. We could maybe add a recommendation in the
appendix for ticket construction as Tiru suggests in another mail, if that
is useful.

We need text under security considerations that highlights the need for
strong entropy to ensure nothing can be gleaned by looking at the ticket
alone. We'll add text around this in the next revision.

-Prashanth

>><http://www.ietf.org/internet-drafts/draft-wing-tram-turn-mobility-01.txt
>>>
>>             Status:
>>

---

From: Brandon Williams <[email-masked]>
Date: Thu, 04 Sep 2014 09:52:54 -0400

I had one other thought on this one ...

For a large distributed system that selects the relay server for best 
performance, I think that support for redirection via the response to 
the mobility refresh request is important. When the client changes its 
IP address, this will often mean there was a significant change to its 
network geography as well. For example, when moving from a 3G address to 
a wifi address, continuing to use the same relay server will be good for 
short term connection continuity, but could be generally bad for call 
quality. Having the capability to signal that the client should attempt 
to shift its flows to another relay would be beneficial.

This capability could be handled via updated channel bind / permission 
requests using the mechanism from the peer-redirect draft, though 
allowing the redirect in the refresh response itself would be preferable 
I think.

--Brandon

---

From: Brandon Williams <[email-masked]>
Date: Fri, 05 Sep 2014 09:45:07 -0400

On 09/04/2014 06:37 AM, Tirumaleswar Reddy (tireddy) wrote:
> The normal user authentication is still in the picture. So if a wrong
> user uses the token that was granted to a different legitimate user,
> then the request will be rejected and the wrong user (that cannot
> authenticate itself as the original user) will not benefit by snooping
> the token. May be it is worth mentioning in the security section.
>

Agreed. The validation described here is adequate to ensure that a 
snooped token is not useful all by itself. Without a reference in the 
security considerations section, it didn't occur to me to go back 
through the rest of the document looking for something intended to meet 
this security requirement.

> [TR] Agreed. We can add a recommendation of constructing the token just
> like it’s done in http://tools.ietf.org/html/rfc4507#section-4

I get the impression that Oleg prefers a mobility ticket that is just a 
random string of bytes without any encoded meaning. Based on the 
discussion in this thread, I think that both approaches are reasonable 
and that the most important thing is for the security considerations 
section to describe the privacy protection requirement. The two 
approaches to token generation could be provided as examples of how to 
meet the privacy requirement in order to help make it clear.

--Brandon

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Fri, 5 Sep 2014 14:33:51 +0000

>to shift its flows to another relay would be beneficial.

Bad quality, if so, would probably be due to the new link. The host isn't
roaming across large boundaries that a new relay server would provide
significantly better quality.

-Prashanth

---

From: Brandon Williams <[email-masked]>
Date: Fri, 05 Sep 2014 11:13:35 -0400

> significantly better quality.

Do you mean that you specifically don't expect mobility tickets to be 
used in the case that I describe (going from a 3G address to a wifi 
address)? If that's not what you mean, then I don't understand your 
point. It would be quite common for the optimal relay to change when you 
change service providers, which you're probably doing when you change 
from 3G to wifi. This would be substantially less likely to be true 
(though not impossible) if you're just changing 3G access points.

--Brandon

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Fri, 5 Sep 2014 16:45:34 +0000

On 9/5/14 8:43 PM, "Brandon Williams" <[email-masked]> wrote:

>from 3G to wifi.

I could be mistaken but it seems to me that even if you changed service
providers, the likelihood of change in quality would not be significant
enough for a client to shift relays. Shifting relays would result in
session re-establishment with impact on the remote peer.

-Prashanth

> This would be substantially less likely to be true

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 5 Sep 2014 10:23:46 -0700

> session re-establishment with impact on the remote peer.
I had an impression that a relay change is beyond the scope of this
document.  And I also do not understand why we would need a session
mobility if we change the relay - we would just establish a new session
with the new relay server.

Another point is that the MICE is about changing the client endpoint
without changing the relay endpoint - the relay endpoint stays the same.
Well, if we change the relay server, it becomes impossible. The nature of
TCP/IP protocol does not allow shifting network endpoints from one server
to another, especially if they are in different regions.

So I do not understand why shifting relays is relevant in the context of
this discussion.

Thank
Oleg

---

From: Brandon Williams <[email-masked]>
Date: Fri, 05 Sep 2014 13:54:41 -0400

> with the new relay server.

I'm not suggesting that the ticket would be used to change the relay. 
I'm suggesting that the ticket functionality is of limited value for a 
system that does performance based relay selection unless the refresh 
response gives the client some indication that shifting the flow to 
another relay would be beneficial. The client would get the benefit of 
the ticket (maintaining the session across an address change), while at 
the same time getting the benefit of performance based relay selection.

> Well, if we change the relay server, it becomes impossible. The nature
> of TCP/IP protocol does not allow shifting network endpoints from one
> server to another, especially if they are in different regions.

I'm confused about how TCP/IP comes into this. Since TURN only supports 
TCP/IP between the client endpoint and the relay server (turnbis still 
says that UDP is the only allowed REQUESTED-TRANSPORT value), what makes 
TCP/IP semantics relevant? I'm not particularly familiar with MICE, so 
maybe the answer to my question is there and I just need to read up on it.

> So I do not understand why shifting relays is relevant in the context of

Just to be clear, I'm not suggesting any changes to how the ticket 
mechanism works or the conditions under which it would be used. I'm just 
suggesting that the mobility ticket use case creates a new situation 
where a try-alternate hint in a success response would be valuable to 
the client, helping it to provide better session quality.

--Brandon

---

From: Brandon Williams <[email-masked]>
Date: Fri, 05 Sep 2014 14:27:27 -0400

[snip]
> session re-establishment with impact on the remote peer.

Change in service provider can be one of the most significant factors 
influencing connection quality, because the peering relationships 
between providers are so important. If the peering relationships for the 
new provider are distinctly different than the peering relationships for 
the previous, that could be enough to make the relay server a very bad 
choice in some cases.

It could be the case that the relationship between the relay server and 
the carrier that it's on prevents it from being used by off-network 
clients, but in that case, it should not have handed back a mobility 
ticket in the first place. It might be a good idea to point that out in 
the draft. That's a little bit off the current topic though.

--Brandon

---

From: Brandon Williams <[email-masked]>
Date: Fri, 05 Sep 2014 14:37:31 -0400

> the draft. That's a little bit off the current topic though.

This is just wrong. Of course it would hand out mobility tickets to 
support changing address without changing provider. Under these 
conditions, the relay server should reject the mobility ticket with an 
error message that clearly indicates the reason if the new client 
address is not believed to be on the same provider.

--Brandon

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 5 Sep 2014 11:51:49 -0700

On Fri, Sep 5, 2014 at 10:54 AM, Brandon Williams <
[email-masked]> wrote:

> TCP/IP between the client endpoint and the relay server (turnbis still says
> that UDP is the only allowed REQUESTED-TRANSPORT value), what makes TCP/IP
> semantics relevant? I'm not particularly familiar with MICE, so maybe the
> answer to my question is there and I just need to read up on it.
>
>
In the common terminology, there is "TCP protocol", "UDP protocol" and
"TCP/IP stack of protocols". The "UDP protocol" is a part of the "TCP/IP
stack of protocols".

TCP relay (when TCP is used by the relay endpoints, too) is described in
RFC 6062. MICE and RFC 6062 do not contradict each other, so we assume that
the session mobility must be applicable to the TCP relay, too.

Either way, UDP or TCP, we cannot shift the relay endpoints from one relay
server to another.

Oleg

---

From: Brandon Williams <[email-masked]>
Date: Fri, 05 Sep 2014 15:41:03 -0400

Ah. "TCP/IP protocol" isn't commonly used as shorthand for "TCP/IP stack 
of protocols". The "s" on the end of "protocols" is probably key there. 
Anyway, thanks for the clarification.

Your point that it's not possible to serve a unicast relay endpoint 
address out of multiple relay server locations is of course correct. As 
per my previous message, I wasn't indicating anything of the sort.

--Brandon

On 09/05/2014 02:51 PM, Oleg Moskalenko wrote:
>
>
>
> On Fri, Sep 5, 2014 at 10:54 AM, Brandon Williams
>     I'm confused about how TCP/IP comes into this. Since TURN only
>     supports TCP/IP between the client endpoint and the relay server
>     (turnbis still says that UDP is the only allowed REQUESTED-TRANSPORT
>     value), what makes TCP/IP semantics relevant? I'm not particularly
>     familiar with MICE, so maybe the answer to my question is there and
>     I just need to read up on it.
>
>
> RFC 6062. MICE and RFC 6062 do not contradict each other, so we assume
> that the session mobility must be applicable to the TCP relay, too.
>
> Either way, UDP or TCP, we cannot shift the relay endpoints from one
> relay server to another.
>
> Oleg
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 6 Sep 2014 02:40:16 +0000

> -----Original Message-----
> From: Brandon Williams [mailto:[email-masked]]
> Sent: Friday, September 05, 2014 7:15 PM
> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko
> Cc: Prashanth Patil (praspati); [email-masked]
> > the document to make the argument that the token has no value of its
> > own and to highlight the internal requirements of the TURN server
> Agreed. The validation described here is adequate to ensure that a snooped
> token is not useful all by itself. Without a reference in the security
> considerations section, it didn't occur to me to go back through the rest of
> the document looking for something intended to meet this security
> requirement.
> 
> >
> > Brandon Wrote:
> >
> > I disagree. If there is no source of entropy, then I can learn
> > something from the ticket based on its encrypted form. For example, if
> > I can see that every connection with the same client-side tuple ends
> > up with exactly the same ticket, then I have most likely learned
> > something about the unencrypted form of the ticket that will help me
> > to crack the keys used to construct the ticket. If the source of
> > entropy is built into the algorithm, then you're right that a good algorithm is
> good enough.
> > [TR] Agreed. We can add a recommendation of constructing the token
> > just like it’s done in http://tools.ietf.org/html/rfc4507#section-4
> 
> I get the impression that Oleg prefers a mobility ticket that is just a random
> string of bytes without any encoded meaning. Based on the discussion in this
> thread, I think that both approaches are reasonable and that the most
> important thing is for the security considerations section to describe the
> privacy protection requirement. The two approaches to token generation
> could be provided as examples of how to meet the privacy requirement in
> order to help make it clear.

I am not sure about the need for two approaches. why would the TURN server state be stateless in case of Mobility ?

-Tiru

> 
> --Brandon
> 
> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 6 Sep 2014 02:57:15 +0000

> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Friday, September 05, 2014 8:44 PM
> To: Prashanth Patil (praspati); [email-masked]
> >> the mobility refresh request is important. When the client changes
> >> its IP address, this will often mean there was a significant change
> >> to its network geography as well. For example, when moving from a 3G
> >> address to a wifi address, continuing to use the same relay server
> >> will be good for short term connection continuity, but could be
> >> generally bad for call quality. Having the capability to signal that
> >> the client should attempt to shift its flows to another relay would be
> beneficial.
> >
> > Bad quality, if so, would probably be due to the new link. The host
> > isn't roaming across large boundaries that a new relay server would
> > provide significantly better quality.
> >
> 
> Do you mean that you specifically don't expect mobility tickets to be used in
> the case that I describe (going from a 3G address to a wifi address)? If that's
> not what you mean, then I don't understand your point. It would be quite
> common for the optimal relay to change when you change service providers,
> which you're probably doing when you change from 3G to wifi. This would be
> substantially less likely to be true (though not impossible) if you're just
> changing 3G access points.

When a mobile device roams from one eNodeB to another, Selected IP traffic offload (SIPTO) would cause NAT to change b/w the mobile device and TURN server (let's say provided by the application server). For more information on SIPTO refer to http://tools.ietf.org/html/draft-penno-rtcweb-pcp-00#section-3.8; 

-Tiru

> 
> --Brandon
> 
> > -Prashanth
> >
> >
> >>
> >> This capability could be handled via updated channel bind /
> >> permission requests using the mechanism from the peer-redirect draft,
> >> though allowing the redirect in the refresh response itself would be
> >> preferable I think.
> >>
> >> --Brandon
> >>
> >>> We've submitted a revision of the 'Mobility with TURN' draft. The
> >>> update addresses comments raised by Brandon during IETF-90 regarding
> >>> TURN client and server behavior when a STUN refresh message carrying
> >>> MOBILITY-TICKET attribute is lost.
> >>>
> >>> Comments welcome.
> >>>
> >>> Thanks,
> >>> Prashanth
> >>>
> >>>
> >>>> has been successfully submitted by Prashanth Patil and posted to
> >>>> the IETF repository.
> >>>>
> >>>> submission until the htmlized version and diff are available at
> >>>> tools.ietf.org.
> >>>>
> >>>> The IETF Secretariat
> >>>>
> >>>
> >> Brandon Williams; Senior Principal Software Engineer Emerging
> >> Products Engineering; Akamai Technologies Inc.
> >

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 6 Sep 2014 03:10:43 +0000

> Sent: Friday, September 05, 2014 11:57 PM
> >>point. It would be quite common for the optimal relay to change when
> >>you  change service providers, which you're probably doing when you
> >>change from 3G to wifi.
> >
> > I could be mistaken but it seems to me that even if you changed
> > service providers, the likelihood of change in quality would not be
> > significant enough for a client to shift relays. Shifting relays would
> > result in session re-establishment with impact on the remote peer.
> >
> 
> influencing connection quality, because the peering relationships between
> providers are so important. If the peering relationships for the new provider
> are distinctly different than the peering relationships for the previous, that
> could be enough to make the relay server a very bad choice in some cases.

1) how will peer-redirect work in this case ?
    Are you assuming that the relay server provided by both the service providers have some tie-up for peer-redirect to be used ?
2)If let's say the client is using application provided TURN server or third party provided TURN server  and the client moves from 3G to Wifi or vice-versa. 
    Is there a need for peer-redirect in this case ?

-Tiru

> 
> It could be the case that the relationship between the relay server and the
> carrier that it's on prevents it from being used by off-network clients, but in
> that case, it should not have handed back a mobility ticket in the first place. It
> might be a good idea to point that out in the draft. That's a little bit off the
> current topic though.
> 
> --Brandon
> 
> --

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 6 Sep 2014 03:16:48 +0000

> Sent: Saturday, September 06, 2014 12:08 AM
> > It could be the case that the relationship between the relay server
> > and the carrier that it's on prevents it from being used by
> > off-network clients, but in that case, it should not have handed back
> > a mobility ticket in the first place. It might be a good idea to point
> > that out in the draft. That's a little bit off the current topic though.
> 
> This is just wrong. Of course it would hand out mobility tickets to support
> changing address without changing provider. Under these conditions, the
> relay server should reject the mobility ticket with an error message that
> clearly indicates the reason if the new client address is not believed to be on
> the same provider.

In this case why would the TURN server even accept incoming packets from any random external endpoints and subject itself to DDOS attacks ?

-Tiru

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 5 Sep 2014 23:32:37 -0700

On Fri, Sep 5, 2014 at 7:40 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> random
Let me play a devil advocate... Let's imagine a massively scalable TURN
server with loosely coupled processes in one or several connected systems.
Then I can imagine an implementation that encodes all necessary information
in the token, encrypts it and signs it with a private key. That would be
perfectly meaningful - I can see a way to implement a TURN server where a
hash or map of tokens may be impossible to implement (if multiple processes
are involved). I suppose that a "stateless approach" can be useful for the
TURN server. I use a different (stateful) approach - but I can understand
why a developer may choose different implementation pattern.

Oleg

---

From: Brandon Williams <[email-masked]>
Date: Mon, 08 Sep 2014 09:42:24 -0400

Also, it's not entirely about whether the internal implementation is 
stateful or stateless. Some implementers of stateful systems may simply 
prefer the approach that seems to be suggested in the draft (encoding 
information in the ticket), while other may prefer the approach that 
Oleg describes (use a string of random bytes).

I think the thing that's important is to make sure that the privacy 
requirements for what gets transmitted are clearly stated. Descriptions 
of specific approaches could be useful to implementers as examples of 
how to meet the requirements. As Oleg has written previously, it is 
unnecessary and undesirable for the draft to use language that appears 
to require one approach or another.

--Brandon

On 09/06/2014 02:32 AM, Oleg Moskalenko wrote:
>
>
>
> On Fri, Sep 5, 2014 at 7:40 PM, Tirumaleswar Reddy (tireddy)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I am not sure about the need for two approaches. why would the TURN
>     server state be stateless in case of Mobility ?
>
>     -Tiru
>
>
> server with loosely coupled processes in one or several connected
> systems. Then I can imagine an implementation that encodes all necessary
> information in the token, encrypts it and signs it with a private key.
> That would be perfectly meaningful - I can see a way to implement a TURN
> server where a hash or map of tokens may be impossible to implement (if
> multiple processes are involved). I suppose that a "stateless approach"
> can be useful for the TURN server. I use a different (stateful) approach
> - but I can understand why a developer may choose different
> implementation pattern.
>
> Oleg
>

---

From: Brandon Williams <[email-masked]>
Date: Mon, 08 Sep 2014 09:51:47 -0400

> When a mobile device roams from one eNodeB to another, Selected IP traffic offload (SIPTO) would cause NAT to change b/w the mobile device and TURN server (let's say provided by the application ser…

I'm not entirely certain what you're point is here. What my comment was 
meant to indicate is that changing 3G access points is unlikely to mean 
that the optimal relay server changes, even when the public IP address 
for the device changes. If you also change service providers when you 
change access points, then the likelihood of a change to the optimal 
relay server goes up substantially.

--Brandon

---

From: Brandon Williams <[email-masked]>
Date: Mon, 08 Sep 2014 10:05:01 -0400

>      Are you assuming that the relay server provided by both the service providers have some tie-up for peer-redirect to be used ?

Performance-based redirection (or really any use of try-alternate) 
assumes that the relay servers have some sort of tie-up, even though it 
might be quite loose. The one sending try-alternate has to have some way 
to know what the reasonable candidates are.

That said, I'm not suggesting peer-redirect via a channelbind/permission 
response. I'm suggesting redirection via the refresh response. It would 
work something like this:

    * Client changes IP address and sends refresh with mobility ticket.

    * Relay sends refresh response with new mobility ticket and
      alternate server attribute.

    * Client continues to use relay with established session while at
      the same time setting up a new allocation and channel via the
      provided alternate server.

    * After the new allocation and channel are set up, the client can
      shift the flow to the new relay.

It's pretty similar to the peer redirect case, except that it would 
potentially impact all existing p2p flows.

>      Is there a need for peer-redirect in this case ?

Do you mean there would be a case where the client uses an app provided 
relay when on 3G and a 3rd party relay when on wifi (or vice versa)? If 
that's the case, then mobility tickets wouldn't be used anyway, right?

--Brandon

---

From: Brandon Williams <[email-masked]>
Date: Mon, 08 Sep 2014 10:10:53 -0400

> In this case why would the TURN server even accept incoming packets from any random external endpoints and subject itself to DDOS attacks ?

There are a variety of ways to handle the security here. Blocking early 
is great in an attack mitigation case, but for legitimate mobility 
cases, it's better for the relay to signal a useful error to the client. 
I think it's important to recognize the possible need for a 
try-alternate error with an alternate-server attribute. This could be 
preferable to just dropping the packets and requiring some timeout to 
expire for the refresh request. On the other hand, it's quite possible 
that the flow would be disrupted enough in either case to drive session 
termination.

--Brandon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 8 Sep 2014 16:48:25 +0000

> Sent: Monday, September 08, 2014 7:35 PM
> To: Tirumaleswar Reddy (tireddy); Prashanth Patil (praspati); [email-masked]
> >> Subject: Re: [tram] FW: New Version Notification for
> >> draft-wing-tram-turn- mobility-01.txt
> >>
> >>> On 9/5/14 8:43 PM, "Brandon Williams"
> <[email-masked]>
> >> wrote:
> >> [snip]
> >>>> Do you mean that you specifically don't expect mobility tickets to
> >>>> be used in the case that I describe (going from a 3G address to a
> >>>> wifi address)? If that's not what you mean, then I don't understand
> >>>> your point. It would be quite common for the optimal relay to
> >>>> change when you  change service providers, which you're probably
> >>>> doing when you change from 3G to wifi.
> >>>
> >>> significant enough for a client to shift relays. Shifting relays
> >>> would result in session re-establishment with impact on the remote
> peer.
> >>>
> >>
> >> between providers are so important. If the peering relationships for
> >> the new provider are distinctly different than the peering
> >> relationships for the previous, that could be enough to make the relay
> server a very bad choice in some cases.
> >
> >      Are you assuming that the relay server provided by both the service
> providers have some tie-up for peer-redirect to be used ?
> 
> Performance-based redirection (or really any use of try-alternate) assumes
> that the relay servers have some sort of tie-up, even though it might be quite
> loose. 

I thought they are tightly coupled (operated by the same vendor)

> The one sending try-alternate has to have some way to know what the
> reasonable candidates are.
> 
> response. I'm suggesting redirection via the refresh response. It would work
> something like this:
> 
> It's pretty similar to the peer redirect case, except that it would potentially
> impact all existing p2p flows.

Got it, I think the above mechanism should be explained in peer-redirect draft and not in TURN Mobility draft.

> 
> > 2)If let's say the client is using application provided TURN server or third
> party provided TURN server  and the client moves from 3G to Wifi or vice-
> versa.
> relay when on 3G and a 3rd party relay when on wifi (or vice versa)? 

No, I meant the TURN client uses the same application provided relay server in both 3G and Wifi networks. 
My question - Is there need for peer-redirect amongst the application provided TURN servers in this scenario ?

-Tiru

> If that's
> the case, then mobility tickets wouldn't be used anyway, right?
> 
> --Brandon
> 
> >
> > -Tiru
> >
> >>
> >> a mobility ticket in the first place. It might be a good idea to
> >> point that out in the draft. That's a little bit off the current topic though.
> >>
> >> --Brandon
> >>
> >> --

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 8 Sep 2014 17:12:45 +0000

> Sent: Monday, September 08, 2014 7:41 PM
> >>> off-network clients, but in that case, it should not have handed
> >>> back a mobility ticket in the first place. It might be a good idea
> >>> to point that out in the draft. That's a little bit off the current topic
> though.
> >>
> >> conditions, the relay server should reject the mobility ticket with
> >> an error message that clearly indicates the reason if the new client
> > In this case why would the TURN server even accept incoming packets from
> any random external endpoints and subject itself to DDOS attacks ?
> 
> There are a variety of ways to handle the security here. Blocking early is great
> in an attack mitigation case, but for legitimate mobility cases, it's better for
> the relay to signal a useful error to the client.

This kind of mobility is restrictive which does not work across SP. If client wants mobility it is better off picking application provided or third party TURN server and not the access network provided TURN server OR
the access network should provide a TURN server that could be accessed from another SP.

The security policy is easy to enforce in the above use case, place a FW that blocks all unsolicited traffic to the TURN server. This way Mobility works as long as the endpoint is attached to the SP but endpoint will not be able to gain access to the TURN server when it moves out. I don't see any big advantage to the endpoint in deploying a TURN server that provides this kind for limited mobility.

> I think it's important to recognize the possible need for a try-alternate error
> with an alternate-server attribute. 

The SP may or may not know what alternate-server server to provide ?
(Assuming the two SP do not have a tie-up)

-Tiru

> This could be preferable to just dropping
> the packets and requiring some timeout to expire for the refresh request. On
> the other hand, it's quite possible that the flow would be disrupted enough
> in either case to drive session termination.
> 
> --Brandon
> 
> >
> > -Tiru
> >
> >>
> >> --Brandon
> >>
> >> --

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 8 Sep 2014 17:17:59 +0000

> Sent: Monday, September 08, 2014 7:22 PM
> >>> On 9/4/14 7:22 PM, "Brandon Williams"
> >>>> For a large distributed system that selects the relay server for
> >>>> best performance, I think that support for redirection via the
> >>>> response to the mobility refresh request is important. When the
> >>>> client changes its IP address, this will often mean there was a
> >>>> significant change to its network geography as well. For example,
> >>>> when moving from a 3G address to a wifi address, continuing to use
> >>>> the same relay server will be good for short term connection
> >>>> continuity, but could be generally bad for call quality. Having the
> >>>> capability to signal that the client should attempt to shift its
> >>>> flows to another relay would be
> >> beneficial.
> >>>
> >> change from 3G to wifi. This would be substantially less likely to be
> >> true (though not impossible) if you're just changing 3G access points.
> >
> > When a mobile device roams from one eNodeB to another, Selected IP
> > traffic offload (SIPTO) would cause NAT to change b/w the mobile
> > device and TURN server (let's say provided by the application server).
> > For more information on SIPTO refer to
> > http://tools.ietf.org/html/draft-penno-rtcweb-pcp-00#section-3.8;
> 
> meant to indicate is that changing 3G access points is unlikely to mean that
> the optimal relay server changes, even when the public IP address for the
> device changes. If you also change service providers when you change access
> points, then the likelihood of a change to the optimal relay server goes up
> substantially.

Agreed (Got it after your later explanation in the mail thread :))

Cheers,
-Tiru

> >>>> permission requests using the mechanism from the peer-redirect
> >>>> draft, though allowing the redirect in the refresh response itself
> >>>> would be preferable I think.
> >>>>
> >>>> --Brandon
> >>>>
> >>>>> update addresses comments raised by Brandon during IETF-90
> >>>>> regarding TURN client and server behavior when a STUN refresh
> >>>>> message carrying MOBILITY-TICKET attribute is lost.
> >>>>>
> >>>>> Comments welcome.
> >>>>>
> >>>>> Thanks,
> >>>>> Prashanth
> >>>>>
> >>>>>
> >>>>>> http://www.ietf.org/internet-drafts/draft-wing-tram-turn-mobility
> >>>>>> -0
> >>>>>> 1.txt
> >>>>>> Status:

---

From: Brandon Williams <[email-masked]>
Date: Mon, 08 Sep 2014 17:14:17 -0400

On 09/08/2014 12:48 PM, Tirumaleswar Reddy (tireddy) wrote:
[snip]
> I thought they are tightly coupled (operated by the same vendor)

It would be a tight coupling in the Akamai use case today, but I've got 
no idea what we might see in the future.

> Got it, I think the above mechanism should be explained in peer-redirect draft and not in TURN Mobility draft.

I'm not describing peer-redirect here. I'm describing a scenario that's 
specifically associated with use of mobility tickets. If there is no 
specified way to drive the client to shift to another relay, then the 
only option for a relay server like the one I describe is to issue an 
error respond to the mobility ticket, breaking the session. Maybe that's 
OK, since that's what would have happened without mobility support. That 
having been said, if I end up writing a bit broader draft that discusses 
use of ALTERNATE-SERVER in general, what I'm describing could fit in 
well there.

> My question - Is there need for peer-redirect amongst the application provided TURN servers in this scenario ?

The utility of peer-redirection depends upon the relay server 
distribution. The same is true for redirection of almost any sort, I 
think. It doesn't really matter who provides the relay server capacity 
(whether the app provider or a 3rd party). The more centralized the 
relay capacity, the lower the likelihood that redirection will be 
required or even helpful.

--Brandon

---

From: Brandon Williams <[email-masked]>
Date: Mon, 08 Sep 2014 17:26:26 -0400

> the access network should provide a TURN server that could be accessed from another SP.

I'm not describing a relay server provided by the access network itself. 
I'm describing a 3rd party relay server that happens to be deployed on a 
network where the business relationship between the 3rd party relay 
provider and the access network limits the traffic that the relay server 
can handle. This is quite a common deployment scenario.

In this context, clients deployed on the network would benefit from 
mobility support as their addresses change as long as they remain on the 
same access provider, and they will tend to get better performance as a 
result of the relay being directly on network. They may lose performance 
or even lose access altogether if they change providers, but that's not 
the same as saying they get no benefit.

> The security policy is easy to enforce in the above use case, place a FW that blocks all unsolicited traffic to the TURN server. This way Mobility works as long as the endpoint is attached to the S…

Sure, you can just drop packets and make the user upset because their 
connection broke. Or you can allow them to attempt mobility and give 
better user experience through a direct indication of what's going on. 
I'm suggesting that the later would be preferable.

--Brandon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 9 Sep 2014 03:08:58 +0000

> Sent: Tuesday, September 09, 2014 2:56 AM
> >>>>> It could be the case that the relationship between the relay
> >>>>> server and the carrier that it's on prevents it from being used by
> >>>> an error message that clearly indicates the reason if the new
> >>>> client address is not believed to be on the same provider.
> >>>
> >> There are a variety of ways to handle the security here. Blocking
> >> early is great in an attack mitigation case, but for legitimate
> >> mobility cases, it's better for the relay to signal a useful error to the client.
> >
> > This kind of mobility is restrictive which does not work across SP. If
> > client wants mobility it is better off picking application provided or third
> party TURN server and not the access network provided TURN server OR the
> access network should provide a TURN server that could be accessed from
> another SP.
> 
> provider and the access network limits the traffic that the relay server can
> handle. This is quite a common deployment scenario.

Okay, looks similar to 3rd party downstream CDN deployed in access network.  

> 
> In this context, clients deployed on the network would benefit from mobility
> support as their addresses change as long as they remain on the same access
> provider, and they will tend to get better performance as a result of the relay
> being directly on network. They may lose performance or even lose access
> altogether if they change providers, but that's not the same as saying they get
> no benefit.

But changing provider is a common use case for Mobility. 
I don't see any such restriction discussed in Mobile IPv6 about Home Agent.

-Tiru

> 
> >
> > The security policy is easy to enforce in the above use case, place a FW that
> blocks all unsolicited traffic to the TURN server. This way Mobility works as
> long as the endpoint is attached to the SP but endpoint will not be able to
> gain access to the TURN server when it moves out. I don't see any big
> advantage to the endpoint in deploying a TURN server that provides this kind
> for limited mobility.
> 
> connection broke. Or you can allow them to attempt mobility and give better
> user experience through a direct indication of what's going on.
> >> try-alternate error with an alternate-server attribute.
> >
> >> This could be preferable to just dropping the packets and requiring
> >> some timeout to expire for the refresh request. On the other hand,
> >> it's quite possible that the flow would be disrupted enough in either
> >> case to drive session termination.
> >>
> >> --Brandon
> >>
> >>>
> >>> -Tiru
> >>>
> >>>>
> >>>> --Brandon
> >>>>
> >>>> --