[radext] New charter to IESG

Stefan Winter <stefan.winter@restena.lu> Mon, 29 June 2015 06:34 UTC

Return-Path: <stefan.winter@restena.lu>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id A3DAD1A1B18 for <radext@ietfa.amsl.com>; Sun, 28 Jun 2015 23:34:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.791
X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fnF7nckxryhe for <radext@ietfa.amsl.com>; Sun, 28 Jun 2015 23:34:31 -0700 (PDT)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 221831A1B15 for <radext@ietf.org>; Sun, 28 Jun 2015 23:34:31 -0700 (PDT)
Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 7CF014395F for <radext@ietf.org>; Mon, 29 Jun 2015 08:34:29 +0200 (CEST)
Message-ID: <5590E6F5.1010407@restena.lu>
Date: Mon, 29 Jun 2015 08:34:29 +0200
From: Stefan Winter <stefan.winter@restena.lu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "radext@ietf.org" <radext@ietf.org>
OpenPGP: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UjfJ5NHgups28rNko32mnWhOLTLvdWKTv"
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/N5VvwQCjoOswFDaACsEe-SJf-HQ>
Subject: [radext] New charter to IESG
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 29 Jun 2015 06:34:33 -0000


since there was no dissent on my latest suggestion for the last
contentious paragraph in the charter, we now have a complete charter
text to send to the IESG. Thank you to all of you for reaching this
consensus. The text as will be sent to the IESG is:

"The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol pending approval of the new work from the Area Director
and clarify its usage and definition.

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
the following restriction is imposed on extensions considered by the
All documents produced MUST specify means of interoperation with legacy
RADIUS and, if possible, be backward compatible with existing 
RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675,
5080, 5090, 5176 and 6158. Transport profiles should, if possible, be
compatible with RFC 3539.

The WG will review its existing RFCs’ document track categories and
where necessary or useful change document tracks, with minor changes in
the documents if needed. Any changes to document tracks require approval
by the responsible Area Director.

Work Items

The immediate goals of the RADEXT working group are to address the
following issues:

- CoA proxying.  RFC 5176 permits proxying of CoA and Disconnect
messages, but makes no provisions for how that is done in a roaming
environment.  This work item will provide descriptions of how to use
the Operator-Name attribute in a roaming environment to proxy CoA
packets in a way that ensures only authorized proxies can send these
packets to the home CoA server.
The document will be Informational, in line with the CoA document

- Encoding Rules for EAP-Response/Identity packets over RADIUS. Neither
EAP (RFC3748) nor EAP over RADIUS (RFC3579) demand specific character
encoding and normalisation rules for EAP Identity responses. RADIUS
(RFC2865) requires User-Name attributes to be encoded in UTF-8. Where a
NAS is required to verbatimly copy an EAP-Identity into a User-Name,
invalid packets might be produced. This document will suggest
restrictions on EAP Identities so that transport over AAA becomes
correct under all circumstances (UTF-8) and deterministic (normalisation).

- Data Types. RFC 2865 defines a number of data types, but later
documents do not use those types in a consistent way.  This work item
will define data types, and update the IANA RADIUS Attribute Type
registry so that each attribute has a data type.  Where necessary, it
will correct issues with previous specifications.  This will be a
standards track document.

- Larger Packets. Support RADIUS packets greater than 4096-octets over
RADIUS transports with this capability.

- RADIUS Attributes for IP Port Configuration and Reporting. These
attributes are used by devices that implement IP port ranges to
configure and report TCP/UDP ports and ICMP identifiers, as well as
mapping behaviors. These attributes can be used in the context of
address sharing (e.g., NAT44 [RFC3022], Dual-Stack Lite AFTR [RFC6333],
CGN [RFC6888], NAT64 [RFC6146], Provider WLAN (e.g., [TR-146]), etc.).


(mark RFC4282bis as Done [RFC Editor Queue now])
(mark RADIUS packet fragemntation as Done [in RFC Editor Queue now])
(mark Dynamic Discovery as Done [in RFC Editor Queue now])

Nov 2015 - Submit CoA Proxying as Standards Track RFC
Nov 2016 - Submit Populating EAP Identity as BCP RFC
Nov 2015 - Data Types as Informational RFC
Nov 2015 - Larger Packets for RADIUS over TCP as Experimental RFC
Mar 2016 - IP Port RADIUS Extensions as Standards Track RFC


Stefan Winter

Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me