Re: [BEHAVE] FW: New Version Notification for draft-reddy-behave-turn-auth-02.txt

chen wilson <oeichenwei@gmail.com> Fri, 21 June 2013 02:48 UTC

Return-Path: <oeichenwei@gmail.com>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A637A11E814F for <behave@ietfa.amsl.com>; Thu, 20 Jun 2013 19:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8rdkrKdAy7u for <behave@ietfa.amsl.com>; Thu, 20 Jun 2013 19:48:56 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 47BB011E8149 for <behave@ietf.org>; Thu, 20 Jun 2013 19:48:56 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id fo12so6345827lab.25 for <behave@ietf.org>; Thu, 20 Jun 2013 19:48:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=srJzVB2yXicz4lNiscSNhWKmOn0+hYDT7J2qjUNf2lk=; b=KbvMq+D+SBMYqYJwaGixBGW0CLaEplsWS8RieuPgZ8JgKJ8KWrDSqurMv2Q40UwYEf VqfjZmGRPg+M85fcYehWihtRKynrQlp5B6UjLISIPDRI/J9XVlffSog8jzIwCjSEBcXs STOLwlJN3+VgjsjFEb4oKTJwkmJEcta9n7mf8FmmGEnFd5Wz23FQxJJJfI8kYO4Ca10g GRtfy6uB/9IYybG+CUv0FbenEOf9POK6bEd2D3Ou77hp0e1MN2GwxQkFV2x9Dpj79JFN rJgQdciJSPEcVb4348QZ5Kb0Cgy4LERD4Y6fkvfPMLq7RED3dXD6G5tFI2QxWdr6o05+ KQoQ==
MIME-Version: 1.0
X-Received: by 10.112.55.9 with SMTP id n9mr6851209lbp.5.1371782934946; Thu, 20 Jun 2013 19:48:54 -0700 (PDT)
Received: by 10.112.67.133 with HTTP; Thu, 20 Jun 2013 19:48:54 -0700 (PDT)
In-Reply-To: <E92E67B176B8B64D8D3A8F5E44E9D8F41EC0FE43@xmb-aln-x05.cisco.com>
References: <20130612103314.16399.8755.idtracker@ietfa.amsl.com> <E92E67B176B8B64D8D3A8F5E44E9D8F41EC0FE43@xmb-aln-x05.cisco.com>
Date: Fri, 21 Jun 2013 10:48:54 +0800
Message-ID: <CAEXiFzY8D96O1Qt+b7gK3D5yFuHVtbB72yjPZRzCzkUhWi2yVw@mail.gmail.com>
From: chen wilson <oeichenwei@gmail.com>
To: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
Content-Type: multipart/alternative; boundary="001a11c333b08be97b04dfa11aee"
Cc: "behave@ietf.org" <behave@ietf.org>
Subject: Re: [BEHAVE] FW: New Version Notification for draft-reddy-behave-turn-auth-02.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jun 2013 02:48:57 -0000

Good point, If the TURN server is configured with multiple realms, it might
want to respond all realms it supports (multiple realm attributes), or it
might respond some special meaningful realm then the client can get help
out of band, or just randomly pick one, etc...
The problem 1 and 2, listed in the draft is very common. Implementers are
easy to get missed without a clear guidance.

Thanks,
Wilson Chen

On Tue, Jun 18, 2013 at 12:53 PM, Ram Mohan R (rmohanr)
<rmohanr@cisco.com>wrote:

> We have published the revision of this draft. This has changes to
> following text of "Problems with STUN Authentication" section
>
> <snip>
> 5.  Hosting multiple realms on a single IP address is challenging
>        with TURN.  When a TURN server needs to send the REALM attribute
>        in response to an unauthenticated request, it has no useful
>        information for determining which realm it should send, except
>        the source transport address of the TURN request.  Note this is a
>        problem with multi-tenant scenarios only.  This is not a problem
>        when deployed in Enterprise.
>
>
> </snip>
>
> Please review and provide any inputs/comments on this draft.
>
> Authors
>
> > On 12/06/13 4:03 PM, "internet-drafts@ietf.org"
> ><internet-drafts@ietf.org> wrote:
>
> >
> >A new version of I-D, draft-reddy-behave-turn-auth-02.txt
> >has been successfully submitted by Tirumaleswar Reddy and posted to the
> >IETF repository.
> >
> >Filename:       draft-reddy-behave-turn-auth
> >Revision:       02
> >Title:          Problems with STUN Authentication for TURN
> >Creation date:  2013-06-12
> >Group:          Individual Submission
> >Number of pages: 7
> >URL:
> >http://www.ietf.org/internet-drafts/draft-reddy-behave-turn-auth-02.txt
> >Status:
> >http://datatracker.ietf.org/doc/draft-reddy-behave-turn-auth
> >Htmlized:
> >http://tools.ietf.org/html/draft-reddy-behave-turn-auth-02
> >Diff:
> >http://www.ietf.org/rfcdiff?url2=draft-reddy-behave-turn-auth-02
> >
> >Abstract:
> >   This document discusses some of the issues with STUN authentication
> >   for TURN messages.
> >
> >
> >
> >
> >
> >The IETF Secretariat
> >
> >
>
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>