Re: [tram] First post

[Oleg Moskalenko <[e-mail]>]

Hi Tiru

in regard to Mobile ICE, I filled the RFC 6982 template - you can add it as
"implementation status" section to the draft, please see below.

Thanks
Oleg

==============================

   o  The organization responsible for the implementation, if any.

This is a public project, the full list of authors and contributors here:
http://turnserver.open-sys.org/downloads/AUTHORS


   o  The implementation's name and/or a link to a web page describing
      the implementation.

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


   o  A brief general description.

A mature open-source TURN server specs implementation (RFC 5766, RFC
6062, RFC 6156, etc)
designed for high-performance applications, especially geared for WebRTC.


   o  The implementation's level of maturity: research, prototype,
      alpha, beta, production, widely used, etc.

widely used (the TURN server itself).

The Mobile ICE feature implementation can be qualified as "production" - it
is well tested and fully implemented, but not widely used, yet.


   o  Coverage: which parts of the protocol specification are
      implemented and which versions of the Internet-Draft were
      implemented.

Fully implements MICE with TURN protocol



   o  Licensing: the terms under which the implementation can be used.
      For example: proprietary, royalty licensing, freely distributable
      with acknowledgement (BSD style), freely distributable with
      requirement to redistribute source (General Public License (GPL)
      style), and other (specify).

BSD:

http://turnserver.open-sys.org/downloads/LICENSE

 o  Implementation experience: any useful information the implementers
      want to share with the community.

MICE implementation is somewhat challenging for a multi-threaded
performance-oriented application (because the mobile ticket information
must be shared between the threads) but it is doable.

========================================================================




On Tue, Nov 19, 2013 at 4:26 AM, Tirumaleswar Reddy (tireddy) <
[e-mail]> wrote:

> Hi Oleg,
>
> Please see inline [TR]
>
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Oleg Moskalenko
> Sent: Monday, November 18, 2013 12:19 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: Simon Perreault; [e-mail]; [e-mail]; 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) <
> [e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Oleg Moskalenko
> Sent: Saturday, November 16, 2013 12:56 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: Simon Perreault; [e-mail]; 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) <
> [e-mail]> 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 <[e-mail]>
> Subject: Re: [tram] First post
> Date: November 15, 2013 11:01:24 AM PST
> To: Simon Perreault <[e-mail]>
> Cc: <[e-mail]>
>
> 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 <
> [e-mail]> 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 <
> [e-mail]>.
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>
>
>