Subject: Re: [radext] RADEXT recharter

From: Leaf yeh <[email-masked]>
Date: Fri, 17 Feb 2012 11:13:06 +0000

As per the MM of Radext session, IETF82-Taipei, http://www.ietf.org/proceedings/82/minutes/radext.txt

<quote>3. RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh
-Chair: Is anyone against having an accounting document? No objection. Ask authors to work out a single proposal. Need to determine if we bring into a new charter. ...
-Chair: Consensus check on adding this topic to the re-charter: Show of hands on who is interested and will participate in the effort? 4 - yes, 0 - against. Will take to list, strong consensus to update the charter and make this a working group item. Ask authors to work towards a unified proposal....
-Chair:Yes, not choosing a proposal today; legitimize the work item in the charter as a first step. </quote>

I suggest to add 'RADIUS Accounting Extensions for Traffic Statistics' as the work item in the charter.

The following text against the revision on the WG charter are for your reference and the further discussion.

Work Item
....

RADIUS Accounting Extensions for Traffic Statistics: This document specifies the dedicated RADIUS attributes on IPv4 and IPv6 traffic statistics for the differentiated accounting policies and traffic recording on the AAA server.

Goals and Milestones
...
Dec 2012  Traffic Statistics Attribute I-D submitted as a Proposed Standard RFC

OTOH, as per the MM of Radext session, 

<quote>3. RADIUS Accounting Extensions of Traffic Statistics, Leaf Yeh
http://www.ietf.org/proceedings/82/slides/radext-2.pptx ...
-AD: before we develop the contributions, ask authors to put together pros and cons of options, remaining points of disagreement. See if we can get agreement on a baseline proposal
-Chair: ...Ask authors to work towards a unified proposal. </quote>

and the discussion in the ML about draft-ietf-radext-radius-extensions and RFC6158, I will trigger a discussion on this attribute design soon again, then update the draft with Stefan for a 'baseline proposal'.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, January 24, 2012 8:21 PM
To: Sanchez, Mauricio (HP Networking); [email-masked]
Subject: Re: [radext] RADEXT recharter

Hi,

As Dave Nelson already pointed out, two of the documents in the charter
were already approved as RFCs. Also the milestones need to be revisited
in case the discussions of this new charter continue until IETF-83 (end
of March 2012) because most of them target January - March 2012. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Sanchez, Mauricio (HP Networking)
> Sent: Tuesday, January 24, 2012 12:11 AM
> To: [email-masked]
> Subject: [radext] RADEXT recharter
> 
> At IETF 82, the RADEXT WG discussed (see notes section 7
> http://www.ietf.org/proceedings/82/minutes/radext.txt) updating the
> charter to position the WG to be able to embrace several work items
> that the WG believes relevant, as well as recalibrating dates on
> several committed goals.
> 
> Below is the new proposed WG charter that your chairs and AD agreed
> upon.
> Attached are a PDF version of updated milestones and a marked version
> detailing changes introduced from existing charter. At this time the
> chairs would like to open up the list for discussion. Propose your
> changes and justify why.
> 
> Our aim is to have this re-chartering discussion completed by next
IETF
> meeting.
> 
> - Mauricio and Jouni
> 
> 
> ---------
> 
> Description of Working Group
> 
> The RADIUS Extensions Working Group will focus on extensions to the
> RADIUS protocol required to expand and enrich the standard attribute
> space, address cryptographic algorithm agility, use of new secure
> transports and clarify its usage and definition.
> 
> In order to enable interoperation of heterogeneous RADIUS/Diameter
> deployments, all RADEXT WG work items MUST contain a Diameter
> compatibility section, outlining how interoperability with Diameter
> will be maintained.
> Furthermore, to ensure backward compatibility with existing RADIUS
> implementations, as well as compatibility between RADIUS and Diameter,
> the following restrictions are imposed on extensions considered by the
> RADEXT
> WG:
> 
> - All documents produced MUST specify means of interoperation with
> legacy RADIUS and, if possible, be backward compatible with existing
> RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-
> 4673,4675, 5080, 5090 and 5176. Transport profiles should, if
possible,
> be compatible with RFC 3539.
> 
> - All RADIUS work MUST be compatible with equivalent facilities in
> Diameter. Where possible, new attributes should be defined so that the
> same attribute can be used in both RADIUS and Diameter without
> translation. In other cases a translation considerations section
should
> be included in the specification.
> 
> Work Items
> The immediate goals of the RADEXT working group are to address the
> following issues:
> 
> -RADIUS design guidelines. This document will provide guidelines for
> design of RADIUS attributes. It will specifically consider how complex
> data types may be introduced in a robust manner, maintaining backwards
> compatibility with existing RADIUS RFCs, across all the classes of
> attributes: Standard, Vendor-Specific and SDO-Specific. In addition,
it
> will review RADIUS data types and associated backwards compatibility
> issues.
> 
> -RADIUS Management authorization. This document will define the use of
> RADIUS for NAS management over IP.
> 
> -RADIUS attribute space extension. The standard RADIUS attribute space
> is currently being depleted. This document will provide additional
> standard attribute space, while maintaining backward compatibility
with
> existing attributes.
> 
> -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally
> relied on MD5 for both per-packet integrity and authentication as well
> as attribute confidentiality. Given the increasingly successful
attacks
> being mounted against MD5, the ability to support alternative
> algorithms is required. This work item will include documentation of
> RADIUS crypto-agility requirements, as well as development of one or
> more Experimental RFCs providing support for negotiation of
alternative
> cryptographic algorithms to protect RADIUS.
> 
> -IEEE 802 attributes. New attributes have been proposed to support
IEEE
> 802 standards for wired and wireless LANs. This work item will support
> authentication, authorization and accounting attributes needed by IEEE
> 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16.
> 
> - New RADIUS transports. A reliable transport profile for RADIUS will
> be developed, as well as specifications for Secure transports,
> including TCP/TLS (RADSEC) and UDP/DTLS.
> 
> - Documentation of Status-Server usage. A document describing usage of
> the Status-Server facility will be developed.
> 
> - Update and clarification of Network Access Identifiers
(RFC4282).This
> work item will correct and clarify egregious issues present with
> RFC4282 in two phases.  In first phase, RFC4282bis will be issued to
> eliminate fundamental incompatibilities with RADIUS around character
> encoding and NAI modifications by proxies.  In second phase, a fresh
> review of NAI internationalization requirements and behavior will be
> undertaken with a clear goal of maintaining compatibility with RADIUS.
> 
> Goals and Milestones
> Done		Updates to RFC 2618-2621 RADIUS MIBs submitted for
> publication
> Done		SIP RADIUS authentication draft submitted as a Proposed
> Standard RFC
> Done		RFC 2486bis submitted as a Proposed Standard RFC
> Done		RFC 3576 MIBs submitted as an Informational RFC
> Done		RADIUS VLAN and Priority Attributes draft submitted as a
> Proposed
> Standard RFC (reduced in scope)
> Done		RADIUS Implementation Issues and Fixes draft submitted
as
> an
> Informational RFC
> Done		RADIUS Filtering Attributes draft submitted as a
Proposed
> Standard
> RFC (split out from VLAN & Priority draft)
> Done		RFC 3576bis submitted as an Informational RFC (split out
> from Issues
> & Fixes draft)
> Done		RADIUS Redirection Attributes draft submitted as a
Proposed
> Standard
> RFC (split out from VLAN & Priority draft)
> Done		RADIUS Design Guidelines submitted as a Best Current
> Practice RFC
> Done		RADIUS Management Authorization I-D submitted as a
Proposed
> Standard
> RFC
> Done		Reliable Transport Profile for RADIUS I-D submitted as a
> Proposed
> Standard RFC
> Done		Status-Server I-D submitted as a Proposed Standard RFC
> Done		RADIUS Crypto-agility Requirements submitted as an
> Informational RFC
> Jan 2012	RADSEC (RADIUS over TCP/TLS) draft submitted as an
> Experimental
> RFC
> Feb 2012	IPv6 Access I-D submitted as a Proposed Standard RFC
> Feb 2012	Extended Attributes I-D submitted as a Proposed Standard
> RFC
> Feb 2012	Dynamic Discovery I-D submitted as a Proposed Standard
RFC
> Mar 2012	RFC 4282bis submitted as a Proposed Standard RFC
> Mar 2012	RADIUS over DTLS I-D submitted as an Experimental RFC
> Apr 2012	IEEE 802 Attributes I-D submitted as a Proposed Standard
> RFC
> Oct 2012	RADIUS support for NAI Internationalization I-D
submitted
> as a
> Proposed Standard RFC

_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: Leaf yeh <[email-masked]>
Date: Fri, 17 Feb 2012 11:13:06 +0000

Work Item
....

Goals and Milestones
...

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, January 24, 2012 8:21 PM
To: Sanchez, Mauricio (HP Networking); [email-masked]
Subject: Re: [radext] RADEXT recharter

Hi,

Regards,

Dan

IETF
possible,
should
it
with
attacks
alternative
IEEE
(RFC4282).This
as
Proposed
Proposed
Proposed
RFC
submitted