Subject: [radext] RADEXT charter

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Wed, 9 May 2012 18:54:34 +0100

We have been discussing rechartering on and off since January.  Below is an updated proposal that we would appreciate your review and feedback.  The changes can be summarized as follows:

 *   Updating completed work items and casting new dates for work items not accomplished per the dates in existing charter
 *   Addition of network access identifier work item
 *   Addition of traffic accounting work item
 *   Addition of packet fragmentation work item

Thanks,
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, 5176 and 6158. 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 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.

- 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.

- Update and clarification of Network Access Identifiers (RFC4282).This work item will correct and clarify 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.

- RADIUS Accounting Extensions for Traffic Statistics. This work item will specify RADIUS accounting attributes for differentiated accounting polices and traffic recording.

- Fragmentation of RADIUS packets to support exchanges exceeding the existing 4KB limit imposed by RFC2865.

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
Done RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC
May 2012 IPv6 Access I-D submitted as a Proposed Standard RFC
May 2012 Extended Attributes I-D submitted as a Proposed Standard RFC
Jun 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC
Jun 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Aug 2012 RADIUS over DTLS I-D submitted as an Experimental RFC
Nov 2012    Traffic Statistics Attribute I-D submitted as a Proposed Standard RFC
Nov 2012    RADIUS packet fragmentation submitted as an Experimental RFC
Nov 2012 RFC 4282bis submitted as a Proposed Standard RFC
Apr 2013 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: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Tue, 22 May 2012 18:41:14 +0100

Gentle reminder that we would appreciate hearing your thoughts, either
positive or negative, on proposal below.

Thanks,
Mauricio and Jouni 

On 5/9/12 10:54 AM, "Sanchez, Mauricio (HP Networking)"
<[email-masked]> wrote:

>We have been discussing rechartering on and off since January.  Below is
>an updated proposal that we would appreciate your review and feedback.
>The changes can be summarized as follows:
>
> *   Updating completed work items and casting new dates for work items
>not accomplished per the dates in existing charter
>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, 5176 and 6158. 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
>- 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.
>
>- 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.
>
>- Update and clarification of Network Access Identifiers (RFC4282).This
>work item will correct and clarify 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.
>
>- RADIUS Accounting Extensions for Traffic Statistics. This work item
>will specify RADIUS accounting attributes for differentiated accounting
>polices and traffic recording.
>
>Done RADIUS Filtering Attributes draft submitted as a Proposed Standard
>RFC (split out from VLAN & Priority draft)
>Done RADIUS Redirection Attributes draft submitted as a Proposed Standard
>RFC (split out from VLAN & Priority draft)

---

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Tue, 22 May 2012 18:41:14 +0100

Thanks,
Mauricio and Jouni

---

From: Alan DeKok <[email-masked]>
Date: Tue, 22 May 2012 21:46:18 +0200

> positive or negative, on proposal below.

  It looks good.

  I would tentatively propose discussion of 5176 and proxying of CoA
packets.  The document is essentially silent on proxying.  The main open
problem is:

 - how do you proxy CoA packets across multiple hops?

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 22 May 2012 21:46:18 +0200

It looks good.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Wed, 23 May 2012 13:34:47 +0200

Hi,

on that topic, I've been wondering what good dynamic discovery can do here.

The current draft only enables lookup of home servers for auth/acct
purposes.

It *could* be used the other way around though: when a user has logged
in somewhere, and the "somewhere" includes the Operator-Name attribute
(DNS-style), the home server could lookup the Operator-Name content in
DNS (NAPTR entry TBD) to find out where to send CoA packets for his user to.

That would need lots of new text in the dyndisc draft - but I'm at it
anyway, so if there's some support for the idea on the list, this could
go in...

Greetings,

Stefan Winter

---

From: Stefan Winter <[email-masked]>
Date: Wed, 23 May 2012 13:34:47 +0200

Hi,

Greetings,

Stefan Winter

---

From: Sam Hartman <[email-masked]>
Date: Wed, 23 May 2012 13:07:04 +0000

I just want to confirm that the work to permit fragmentation of RADIUS messages would be within scope
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Stefan Winter <[email-masked]> wrote:

Hi,

Greetings,

Stefan Winter

On 22.05.12 21:46, Alan DeKok wrote:
>_____________________________________________

> https://www.ietf.org/mailman/listinfo/radext

_____________________________________________

radext mailing list
[email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Wed, 23 May 2012 13:07:04 +0000

Hi,

Greetings,

Stefan Winter

radext mailing list
[email-masked]

---

From: Alan DeKok <[email-masked]>
Date: Wed, 23 May 2012 15:09:48 +0200

> messages would be within scope

  I believe it should be.

  This is covered in the topic of "address packets longer than 4K"

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 23 May 2012 15:09:48 +0200

I believe it should be.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 23 May 2012 15:39:55 +0200

> on that topic, I've been wondering what good dynamic discovery can do here.

  Something, I'm sure. :)

> anyway, so if there's some support for the idea on the list, this could

  I'd prefer to publish the document now.  Get it done, published, and
deployed.

  We can then have a separate document which addresses CoA proxying.  It
can leverage 5580, and the dynamic discovery document.

  For anyone with spare time, see the git "master" branch on:

https://github.com/alandekok/freeradius-server/

  It has preliminary support for CoA proxying via Operator-Name.  This
should be sufficient for multi-hop CoA proxying.

  The remaining issue is how to get from the "local" RADIUS proxy to the
NAS.  Using Operator-Name won't work, as the "local" proxy is
authoritative for that realm.  Something else is needed, like a NAS
identifier.

  We could use NAS-IP-Address.  But that could have been changed or
deleted by anyone.  Maybe NAS-Identifier is a better choice.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 23 May 2012 15:39:55 +0200

Something, I'm sure. :)

  Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 23 May 2012 18:02:18 +0200

Hello,

I believe it too. Indeed, we are preparing an updated version of the 
fragmentation draft, that will be ready soon.

Regards,
Alejandro

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 23 May 2012 18:02:18 +0200

Hello,

Regards,
Alejandro