Subject: Re: [tram] TURN ICE Mobility Draft

From: Oleg Moskalenko <[email-masked]>
Date: Wed, 20 Nov 2013 23:24:24 -0800

Hi Tiru

I found one more minor thing. In the section 5.1.2, a variant is absent
when MOBILITY-TICKET attribute is included into ALLOCATE request, but it
has a non-zero size. I'd suggest either 400 error code, or ignore the
ticket size altogether in the ALLOCATE request.

And also, the Mobility-Forbidden error code has to be defined, of course.

Regards,
Oleg

On Tue, Nov 19, 2013 at 10:15 AM, Oleg Moskalenko <[email-masked]>wrote:

> That's great. I ll provide a sort of proof-of-concept reference impl soon.
>
> Thanks
> Oleg
>
> Sent from my iPhone
>
> On Nov 19, 2013, at 4:26 AM, "Tirumaleswar Reddy (tireddy)" <
> [email-masked]> wrote:
>
> > Hi Oleg,
> >
> > Please see inline [TR]
> >
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Oleg Moskalenko
> > Sent: Monday, November 18, 2013 12:19 PM
> > To: Tirumaleswar Reddy (tireddy)
> > Cc: Simon Perreault; [email-masked]; [email-masked]; Justin Uberti
> > Subject: Re: [tram] First post
> >
> > Dan and Tiru,
> > while contemplating the MICE implementation, I stumbled upon a potential
> problem in the MICE draft.
> > According to the section 5.2.2, the server compares the encoded NONCE
> with the stored NONCE for the "old" 5-tuple session. But the problem is, a
> NONCE may expire. Its possible to have an expiration time for the NONCE (an
> enhanced security feature). In a non-mobility TURN implementation, that
> creates no problem: the server simple sends 438 error (stale nonce) back to
> the client together with the new generated NONCE value, and the client just
> re-calculates and re-sends the request.
> > With wording in the section 5.2.2, that becomes rather complicated in
> the mobility case. I am not sure that I understand the exact action
> sequence when the session NONCE expires with mobility feature.
> > I think that the problem can be fixed if the draft would not include
> wording about the MOBILE-TICKET internal structure. In one place it is
> saying that the ticket is opaque and implementation-dependent; but in other
> places it suggests how the ticket must be constructed and how it must be
> encoded. I think that this is unnecessary. Let's just say that the ticket
> is opaque and its structure has meaning only for the server - and that the
> server uses it as a unique identifier.
> > I see no reason why the server must encode any meaningful information in
> the ticket, like 5-tuple and NONCE. That's totally up to the server. The
> server, for example, may just keep a hashtable with all that information
> and the ticket may be just a random unique key in that table. As we are
> using message integrity authentication anyway, and the ticket is
> transferred openly over the Internet, the ticket does not create any new
> level of defense. This is, basically, just a session ID - to match the
> "old" session with the "new" session.
> >
> > [TR] Agreed with your assessment will update the draft accordingly.
> >
> > Thanks and Regards,
> > -Tiru.
> >
> > A similar approach is used in RFC 6062. They are solving a similar
> logical task: they are matching a new client network endpoint with an
> existing TURN session. They also are using a ticket, but they do not encode
> any information in it - that is just an opaque unique string. For
> protection, they also are validating the MESSAGE INTEGRITY. And they have
> no problem with the NONCE expiration because there is no NONCE encoded in
> the ticket.
> >
> > Let me know please what do you think about that.
> >
> > Thanks
> > Oleg
> >
> >
> >
> >
> >
> >
> > On Sun, Nov 17, 2013 at 5:36 AM, Tirumaleswar Reddy (tireddy) <
> [email-masked]> wrote:
> > Hi Oleg,
> >
> > It has some similarities but is a lot different from PCP third party
> authorization. For example for TURN the Authorization Server will be
> providing session key, MAC algorithm etc which is not required with the PCP
> third party authorization.  There are various other differences like PCP
> server would need to communicate with the Authorization Server to determine
> the token bound authorization data  (like the number of mappings permitted,
> flow characteristics allowed etc) which may not be required with TURN
> authorization.  PCP-controlled Firewall will most likely be in the same
> administrative domain as the endpoint but that may not be true with TURN.
> >
> > we are working on the details and will have something concrete in couple
> of weeks.
> >
> > Cheers,
> > -Tiru.
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Oleg Moskalenko
> > Sent: Saturday, November 16, 2013 12:56 PM
> > To: Tirumaleswar Reddy (tireddy)
> > Cc: Simon Perreault; [email-masked]; Justin Uberti
> >
> > Subject: Re: [tram] First post
> >
> > Tiru, I suppose that will be similar to this draft:
> >
> > http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-01
> > That would be a significant addition to the TURN server.
> > Regards,
> > Oleg
> >
> >
> > On Fri, Nov 15, 2013 at 7:20 PM, Tirumaleswar Reddy (tireddy) <
> [email-masked]> wrote:
> > Hi Oleg,
> >
> > I am co-author of the MICE, draft-reddy-behave-turn-auth drafts and we
> are interested in TURN evolution. Justin and we are working on TURN
> Extension for Third Party Authorization using OAuth which will address some
> of the problems discussed in above draft.
> >
> > Cheers,
> > -Tiru.
> >
> > From: Oleg Moskalenko <[email-masked]>
> > Subject: Re: [tram] First post
> > Date: November 15, 2013 11:01:24 AM PST
> > To: Simon Perreault <[email-masked]>
> > Cc: <[email-masked]>
> >
> > MMUSIC has an interesting draft on TURN mobility (MICE) that I am
> watching and I am going to implement. I wonder whether the authors of the
> draft may be interested in the TURN evolution.
> >
> > On Fri, Nov 15, 2013 at 10:55 AM, Simon Perreault <
> [email-masked]> wrote:
> > All,
> >
> > Any objection against sending the following to rtcweb, pntaw, and
> behave? Any other lists that should be included?
> >
> > Simon
> >
> > ====================
> >
> > All,
> >
> > A few of us have been working on a proposal for a new working group that
> would focus on enhancements to STUN and TURN. The proposed name is TRAM
> (Turn Revised And Modernized) and discussion is happening in <
> [email-masked]>.
> > Subscribe link: <https://www.ietf.org/mailman/listinfo/tram>
> >
> > Here is the charter we have been working on. If you would like to
> comment and/or get involved, please do so on the TRAM mailing list.
> >
> > Simon (and many others!)
> > Turn Revised And Modernized (tram)
> > ----------------------------------
> >
> > Traversal Using Relays around NAT (TURN) was published as RFC 5766 in
> April
> > 2010.  Until recently the protocol had only a rather limited deployment.
>  This
> > is primarily because its primary use case is as one of the NAT traversal
> > methods of the Interactive Connectivity Establishment (ICE) framework
> (RFC
> > 5245).  This inherent dependency on ICE combined with the fact that ICE
> itself
> > was slow to achieve widespread adoption because other alternative
> mechanisms
> > were historically used by the VoIP industry were the causes of the
> initial
> > lack of interest.  This situation has changed drastically as ICE, and
> > consequently TURN, are mandatory to implement in WebRTC, which is a set
> of
> > technologies developed at the IETF and W3C aiming to enable Real Time
> > Communication on the Web.
> >
> > Because of the ubiquity of the Web and of the new opportunities created
> by the
> > arrival of WebRTC, there is a renewed interest in TURN and ICE, as
> evidenced by
> > the recent work updating the ICE framework, as well as standardizing the
> URIs
> > used to access a STUN [RFC7064] or TURN [RFC7065] server.
> >
> > The goal of the TRAM Working Group is to consolidate the various
> initiatives
> > to update TURN and STUN, including the definition of new transport and
> > authentication mechanisms that make STUN and TURN more suitable for the
> WebRTC
> > environment.  The Working Group will closely coordinate with the
> appropriate
> > Working Groups, including RTCWEB, MMUSIC, and HTTPBIS.
> >
> > The current list of deliverable is:
> >
> > - DTLS transport for TURN
> >
> >   Candidate draft: draft-petithuguenin-tram-turn-dtls
> >
> >   TURN defines three transports: UDP, TCP, and TLS. A straightforward
> extension
> >   of this set is DTLS, enabling secure datagram-oriented transport.
> >
> > - New authentication mechanism for TURN
> >
> >   Problem analysis: draft-reddy-behave-turn-auth
> >   Candidate draft: draft-uberti-behave-turn-rest, OAuth has also been
> suggested
> >
> >   The current authentication mechanism for TURN, which is reused from
> STUN, has
> >   been designed with a SIP account database in mind. The new RTCWEB
> usages,
> >   which are mostly based on web applications, do not fit that model. A
> new
> >   authentication mechanism optimized for such web applications will be
> created.
> >
> > - TURN server auto-discovery mechanism for enterprise and ISPs
> >
> >   Candidate draft: TBD
> >
> >   Current TURN server discovery is based on the presence of SRV and/or
> NAPTR DNS
> >   records. These records are usually under the administrative control of
> the
> >   application or service provider, not the enterprise or the ISP on whose
> >   network the client is situated. Enterprises or ISPs wishing to provide
> their
> >   own TURN server, in an attempt to reduce so-called "triangle routing",
> need a
> >   new auto-discovery mechanism.
> >
> > - STUN-bis
> >
> >   Candidate draft: TBD
> >
> >   A new revision of RFC 5389 will contain:
> >
> >   - Various bug fixes
> >   - STUN hash algorithm agility (currently only SHA-1 is allowed)
> >
> > - TURN-bis
> >
> >   Candidate draft: TBD
> >
> >   A new revision of RFC 5766 will contain:
> >
> >   - Various bug fixes
> >   - Support for multi-tenant servers
> >     (Servers always send the same REALM attribute. No realm negotiation
> phase
> >      currently exists.)
> >
> > Goals and Milestones:
> >
> > [TBD]
> >
> > --
> > DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> > NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> > STUN/TURN server               --> http://numb.viagenie.ca
> > _______________________________________________
> > tram mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tram
> >
> > _______________________________________________
> > tram mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tram
> >
> >
>

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Fri, 22 Nov 2013 09:16:51 +0000

Hi Oleg,
Yes, the server should return a 400 Bad Request error. We'll update the draft accordingly.

Thanks,
Prashanth

From: Oleg Moskalenko <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 21, 2013 12:54 PM
To: "Tirumaleswar Reddy (tireddy)" <[email-masked]<mailto:[email-masked]>>
Cc: Simon Perreault <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Justin Uberti <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tram] TURN ICE Mobility Draft

Hi Tiru

I found one more minor thing. In the section 5.1.2, a variant is absent when MOBILITY-TICKET attribute is included into ALLOCATE request, but it has a non-zero size. I'd suggest either 400 error code, or ignore the ticket size altogether in the ALLOCATE request.

Regards,
Oleg

On Tue, Nov 19, 2013 at 10:15 AM, Oleg Moskalenko <[email-masked]<mailto:[email-masked]>> wrote:
That's great. I ll provide a sort of proof-of-concept reference impl soon.

Thanks
Oleg

Sent from my iPhone

On Nov 19, 2013, at 4:26 AM, "Tirumaleswar Reddy (tireddy)" <[email-masked]<mailto:[email-masked]>> wrote:

> Hi Oleg,
>
> Please see inline [TR]
>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Oleg Moskalenko
> Cc: Simon Perreault; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Justin Uberti
> while contemplating the MICE implementation, I stumbled upon a potential problem in the MICE draft.
> According to the section 5.2.2, the server compares the encoded NONCE with the stored NONCE for the "old" 5-tuple session. But the problem is, a NONCE may expire. Its possible to have an expiration time for the NONCE (an enhanced security feature). In a non-mobility TURN implementation, that creates no problem: the server simple sends 438 error (stale nonce) back to the client together with the new generated NONCE value, and the client just re-calculates and re-sends the request.
> With wording in the section 5.2.2, that becomes rather complicated in the mobility case. I am not sure that I understand the exact action sequence when the session NONCE expires with mobility feature.
> I think that the problem can be fixed if the draft would not include wording about the MOBILE-TICKET internal structure. In one place it is saying that the ticket is opaque and implementation-dependent; but in other places it suggests how the ticket must be constructed and how it must be encoded. I think that this is unnecessary. Let's just say that the ticket is opaque and its structure has meaning only for the server - and that the server uses it as a unique identifier.
> I see no reason why the server must encode any meaningful information in the ticket, like 5-tuple and NONCE. That's totally up to the server. The server, for example, may just keep a hashtable with all that information and the ticket may be just a random unique key in that table. As we are using message integrity authentication anyway, and the ticket is transferred openly over the Internet, the ticket does not create any new level of defense. This is, basically, just a session ID - to match the "old" session with the "new" session.
>
> A similar approach is used in RFC 6062. They are solving a similar logical task: they are matching a new client network endpoint with an existing TURN session. They also are using a ticket, but they do not encode any information in it - that is just an opaque unique string. For protection, they also are validating the MESSAGE INTEGRITY. And they have no problem with the NONCE expiration because there is no NONCE encoded in the ticket.
>
> On Sun, Nov 17, 2013 at 5:36 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
> Hi Oleg,
>
> It has some similarities but is a lot different from PCP third party authorization. For example for TURN the Authorization Server will be providing session key, MAC algorithm etc which is not required with the PCP third party authorization.  There are various other differences like PCP server would need to communicate with the Authorization Server to determine the token bound authorization data  (like the number of mappings permitted, flow characteristics allowed etc) which may not be required with TURN authorization.  PCP-controlled Firewall will most likely be in the same administrative domain as the endpoint but that may not be true with TURN.
>
> we are working on the details and will have something concrete in couple of weeks.
>
> Cheers,
> -Tiru.
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Oleg Moskalenko
> Cc: Simon Perreault; [email-masked]<mailto:[email-masked]>; Justin Uberti
>
> On Fri, Nov 15, 2013 at 7:20 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
> Hi Oleg,
>
> I am co-author of the MICE, draft-reddy-behave-turn-auth drafts and we are interested in TURN evolution. Justin and we are working on TURN Extension for Third Party Authorization using OAuth which will address some of the problems discussed in above draft.
>
> Cheers,
> -Tiru.
>
> From: Oleg Moskalenko <[email-masked]<mailto:[email-masked]>>
> To: Simon Perreault <[email-masked]<mailto:[email-masked]>>
> Cc: <[email-masked]<mailto:[email-masked]>>
>
> MMUSIC has an interesting draft on TURN mobility (MICE) that I am watching and I am going to implement. I wonder whether the authors of the draft may be interested in the TURN evolution.
>
> On Fri, Nov 15, 2013 at 10:55 AM, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:
> All,
>
> Any objection against sending the following to rtcweb, pntaw, and behave? Any other lists that should be included?
>
> Simon
>
> ====================
>
> All,
>
> A few of us have been working on a proposal for a new working group that would focus on enhancements to STUN and TURN. The proposed name is TRAM (Turn Revised And Modernized) and discussion is happening in <[email-masked]<mailto:[email-masked]>>.
> Here is the charter we have been working on. If you would like to comment and/or get involved, please do so on the TRAM mailing list.
>
> Simon (and many others!)
> Traversal Using Relays around NAT (TURN) was published as RFC 5766 in April
> 2010.  Until recently the protocol had only a rather limited deployment.  This
> methods of the Interactive Connectivity Establishment (ICE) framework (RFC
> 5245).  This inherent dependency on ICE combined with the fact that ICE itself
> was slow to achieve widespread adoption because other alternative mechanisms
> were historically used by the VoIP industry were the causes of the initial
> consequently TURN, are mandatory to implement in WebRTC, which is a set of
> Because of the ubiquity of the Web and of the new opportunities created by the
> arrival of WebRTC, there is a renewed interest in TURN and ICE, as evidenced by
> the recent work updating the ICE framework, as well as standardizing the URIs
> The goal of the TRAM Working Group is to consolidate the various initiatives
> authentication mechanisms that make STUN and TURN more suitable for the WebRTC
> environment.  The Working Group will closely coordinate with the appropriate
>   TURN defines three transports: UDP, TCP, and TLS. A straightforward extension
>   Candidate draft: draft-uberti-behave-turn-rest, OAuth has also been suggested
>
>   The current authentication mechanism for TURN, which is reused from STUN, has
>   been designed with a SIP account database in mind. The new RTCWEB usages,
>   which are mostly based on web applications, do not fit that model. A new
>   authentication mechanism optimized for such web applications will be created.
>
>   Current TURN server discovery is based on the presence of SRV and/or NAPTR DNS
>   records. These records are usually under the administrative control of the
>   network the client is situated. Enterprises or ISPs wishing to provide their
>   own TURN server, in an attempt to reduce so-called "triangle routing", need a
>     (Servers always send the same REALM attribute. No realm negotiation phase
>      currently exists.)
>
> Goals and Milestones:
>
> [TBD]
>
> --
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 25 Nov 2013 09:35:24 -0800

I added experimental Mobile ICE functionality support to our project, to
version 3.0.1.2:

http://code.google.com/p/rfc5766-turn-server/

You can test whether this is what you want to achieve in your specs.

As the "mobility forbidden" error code is not defined yet, I simply used
403.

Regards,
Oleg

On Fri, Nov 22, 2013 at 1:16 AM, Prashanth Patil (praspati) <
[email-masked]> wrote:

> To: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
> Cc: Simon Perreault <[email-masked]>, "[email-masked]" <
> [email-masked]>, Justin Uberti <[email-masked]>
>> > From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Oleg Moskalenko
>> > I see no reason why the server must encode any meaningful information
>> in the ticket, like 5-tuple and NONCE. That's totally up to the server. The
>> > From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Oleg Moskalenko
>> > A few of us have been working on a proposal for a new working group
>> that would focus on enhancements to STUN and TURN. The proposed name is
>> TRAM (Turn Revised And Modernized) and discussion is happening in <
>> [email-masked]>.