[radext] #147: Internationalization and draft-ietf-radext-dynamic-discovery

"radext issue tracker" <trac+radext@trac.tools.ietf.org> Sun, 23 December 2012 00:42 UTC

Return-Path: <trac+radext@trac.tools.ietf.org>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3698D21F8A53 for <radext@ietfa.amsl.com>; Sat, 22 Dec 2012 16:42:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.666
X-Spam-Level:
X-Spam-Status: No, score=-102.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbfoHVsnC5gK for <radext@ietfa.amsl.com>; Sat, 22 Dec 2012 16:42:39 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC3521F8A4D for <radext@ietf.org>; Sat, 22 Dec 2012 16:42:39 -0800 (PST)
Received: from localhost ([127.0.0.1]:52047 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac+radext@trac.tools.ietf.org>) id 1TmZeC-0006zb-Cj; Sun, 23 Dec 2012 01:42:32 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: radext issue tracker <trac+radext@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-radext-dynamic-discovery@tools.ietf.org, bernard_aboba@hotmail.com
X-Trac-Project: radext
Date: Sun, 23 Dec 2012 00:42:32 -0000
X-URL: http://tools.ietf.org/radext/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/147
Message-ID: <066.7bde70b0716a3259e78af5bfff386bfa@trac.tools.ietf.org>
X-Trac-Ticket-ID: 147
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-radext-dynamic-discovery@tools.ietf.org, bernard_aboba@hotmail.com, radext@ietf.org
X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: mikem@open.com.au, stefan.winter@restena.lu
Resent-Message-Id: <20121223004239.7EC3521F8A4D@ietfa.amsl.com>
Resent-Date: Sat, 22 Dec 2012 16:42:39 -0800
Resent-From: trac+radext@trac.tools.ietf.org
Cc: radext@ietf.org
Subject: [radext] #147: Internationalization and draft-ietf-radext-dynamic-discovery
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: radext@ietf.org
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Dec 2012 00:42:40 -0000

#147: Internationalization and draft-ietf-radext-dynamic-discovery

 Currently the internationalization advice provided in Section 2.3.1
 appears to differ from that provided in RFC 4282bis, creating potentially
 unpredictable interactions.

    Dynamic server discovery as defined in this document is only
    applicable for AAA transactions where a RADIUS server receives a
    request with a realm for which no home RADIUS server is known.

 [BA] Does this paragraph really apply to RADIUS servers and not proxies?
 Typically a server will only check the realm and see if it represents a
 realm it is serving; if not an error is flagged.  Asking RADIUS servers
 (not proxies) to route for realms for which they are not authoritative
 seems dangerous.

 Also, the meaning of "no home RADIUS server is known" is not clear.

 According to RFC 4282bis, only bit-by-bit comparisons are supported in the
 AAA infrastructure.  As a result, were a client to not provide a
 normalized realm, the resulting failure of the  comparison would trigger
 use of dynamic server discovery.  Is this what is intended??

 Section 2.3.1

    Note well: The attribute User-Name is defined to contain UTF-8 text.
    In practice, the content may or may not be UTF-8.  Even if UTF-8, it
    may or may not map to a domain name in the realm part. Implementors
    MUST take possible conversion error paths into consideration when
    parsing incoming User-Name attributes.

 [BA] This would appear to contradict RFC 4282bis requirements for realm
 normalization and realm correspondence to a legal FQDN. Although Section
 2.2 does mention conversion to punycode, the exact steps to be performed
 are not described:

    It is expected that in most cases, the label used for the records is
    the DNS representation (punycode) of the literal realm name for which
    the server is the RADIUS server.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-radext-
  bernard_aboba@hotmail.com          |  dynamic-discovery@tools.ietf.org
     Type:  defect                   |     Status:  new
 Priority:  critical                 |  Milestone:  milestone1
Component:  dynamic-discovery        |    Version:  1.0
 Severity:  In WG Last Call          |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/147>
radext <http://tools.ietf.org/radext/>