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

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

Hi Oleg,

Please see inline [TR]

From: Oleg Moskalenko [mailto:[email-masked]]
Sent: Saturday, September 06, 2014 12:03 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Brandon Williams; Prashanth Patil (praspati); [email-masked]
Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.txt

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

>
> 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

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.

[TR]

a)If we consider the Mobility use case then Mobile node using the TURN server for relaying traffic moves from one network to another to trigger use of Mobility event with refresh request. In this scenario TURN server would already have Allocation state information and its associated 5-tuple stored in its memory. With refresh request and a valid ticket, the TURN server just has to just move this existing state information to a new 5-tuple.

I don’t see how in this scenario the TURN server is stateless unlike the use cases for TLS state resumption ?

b) The other trouble I have with encoding all the state information in the ticket is resulting size of it. It may not be possible to carry large tickets in UDP until STUN supports fragmentation and re-assembly.

-Tiru

Oleg

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 8 Sep 2014 11:25:36 -0700

Tiru, please see below inline [Oleg]:

On Mon, Sep 8, 2014 at 8:28 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

>
>
> *From:* Oleg Moskalenko [mailto:[email-masked]]
> *Sent:* Saturday, September 06, 2014 12:03 PM
> *To:* Tirumaleswar Reddy (tireddy)
> *Cc:* Brandon Williams; Prashanth Patil (praspati); [email-masked]
> *Subject:* Re: [tram] FW: New Version Notification for
> draft-wing-tram-turn-mobility-01.txt
>
>
>
>
>
>
>
> On Fri, Sep 5, 2014 at 7:40 PM, Tirumaleswar Reddy (tireddy) <
> [email-masked]> wrote:
>
> 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.
>
>
>
> [TR]
>
>
>
> a)If we consider the Mobility use case then Mobile node using the TURN
> server for relaying traffic moves from one network to another to trigger
> use of Mobility event with refresh request. In this scenario TURN server
> would already have Allocation state information and its associated 5-tuple
> stored in its memory. With refresh request and a valid ticket, the TURN
> server just has to just move this existing state information to a new
> 5-tuple.
>
>
>

[Oleg]

There is 50 shades of grey between 100% stateful and 100% stateless
implementations...

Without conveying too much details, I can share my personal experience. On
a proprietary hardware system, with proprietary network cards and
proprietary network drivers, with proprietary memory management system,
with semi-proprietary OS, there may be several processes running, each
process "attached" to a separate CPU (through affinity). All the processes
are getting traffic from the same network device. An incoming packet may be
delivered to any process - the packet destination is a function of some
network parameters. Let's say a TURN session S is established between
client IP1:port1 and the system's process P1. Then the client moves to
another network endpoint (IP2:port2). It sends the refresh request to the
TURN server. The refresh request is getting delivered to the system process
P2 (because the network parameter changed), with its own memory area that
has no information about the session S. The process P2 might just discard
the mobile refresh request...  But the process P2 may take the mobile
ticket, run the integrity check over it and determine that it has a valid
signature of the local system, then it may unpack the ticket and get the
information about the session S (for example the P1 process info, like the
process P1 incoming message queue address) and then the process P2 will
redirect the request to the process P1 that will be able to process the
refresh request properly. That would be a valid implementation pattern, a
real-life example.

My point is that the draft document would rather allow any meaningful
implementation pattern - unless it seriously violates the protocol security.

>
>
> b) The other trouble I have with encoding all the state information in the
> ticket is resulting size of it. It may not be possible to carry large
> tickets in UDP until STUN supports fragmentation and re-assembly.
>

[Oleg] of course some meaningful moderation must be applied...

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 9 Sep 2014 02:46:47 +0000

Hi Oleg,

Please see inline [TR2]

Sent: Monday, September 08, 2014 11:56 PM

On Mon, Sep 8, 2014 at 8:28 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

From: Oleg Moskalenko [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, September 06, 2014 12:03 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Brandon Williams; Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>
Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.txt

-Tiru

[TR]

[Oleg]
There is 50 shades of grey between 100% stateful and 100% stateless implementations...
Without conveying too much details, I can share my personal experience. On a proprietary hardware system, with proprietary network cards and proprietary network drivers, with proprietary memory management system, with semi-proprietary OS, there may be several processes running, each process "attached" to a separate CPU (through affinity). All the processes are getting traffic from the same network device. An incoming packet may be delivered to any process - the packet destination is a function of some network parameters. Let's say a TURN session S is established between client IP1:port1 and the system's process P1. Then the client moves to another network endpoint (IP2:port2). It sends the refresh request to the TURN server. The refresh request is getting delivered to the system process P2 (because the network parameter changed), with its own memory area that has no information about the session S. The process P2 might just discard the mobile refresh request...  But the process P2 may take the mobile ticket, run the integrity check over it and determine that it has a valid signature of the local system, then it may unpack the ticket and get the information about the session S (for example the P1 process info, like the process P1 incoming message queue address) and then the process P2 will redirect the request to the process P1 that will be able to process the refresh request properly. That would be a valid implementation pattern, a real-life example.
[TR2] Thanks for the above example, but TURN server is stateful even in this case. I am looking for a use case where TURN server on none of the processes stores any Allocation state information. For example if we consider TLS stateless state resumption, no state information is stored in any process P.
My point is that the draft document would rather allow any meaningful implementation pattern - unless it seriously violates the protocol security.

 [TR2] Agreed, will update the draft accordingly.

-Tiru