Subject: Re: [radext] new charter proposal

From: Benoit Claise <[email-masked]>
Date: Sat, 29 Sep 2012 15:58:31 +0200

Dear all,

Since we also discussed this new charter during the IETF meeting, I'll 
take the lack of replies as agreement.

However, I have a concern regarding the RADIUS Accounting Extensions for 
Traffic Statistics, for two reasons:
1. there are two competing proposals, tactical approach vs. flexible 
approach, as mentioned in the meeting minutes. And there is ongoing 
discussion on the mailing regarding the direction to take.
2. If we go for the flexible approach, where do we stop in terms of 
flexibility?
Should the URN in WInter's draft contain: then ipv4 versus ipv6, then 
all the DSCP values, then the next hop, then AS-path ... All of which
To finally end up with the IPFIX flexibility, i.e. a template based 
mechanism, based on any selection of all IPFIX IANA IEs
<http://www.iana.org/assignments/ipfix/ipfix.xml>
So I would like the WG to agree on the problem statement first.

Since both the NAI and the fragmentation work is agreed upon, we could 
proceed with the new charter, modulo the "RADIUS Accounting Extensions 
for Traffic Statistics"

Regards, Benoit.

> 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 maintain interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items except those that just define new attributes 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.
>
> 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
> Aug 2012 IPv6 Access I-D submitted as a Proposed Standard RFC
> Aug 2012 Extended Attributes I-D submitted as a Proposed Standard RFC
> Aug 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC
> Sep 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
> Oct 2012 RADIUS over DTLS I-D submitted as an Experimental RFC
> Dec 2012 Traffic Statistics Attribute I-D submitted as a Proposed Standard RFC
> Dec 2012 RADIUS packet fragmentation submitted as an Experimental RFC
> Jan 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: Benoit Claise <[email-masked]>
Date: Sat, 29 Sep 2012 15:59:42 +0200

Sent to fast.
See in line.
> However, I have a concern regarding the RADIUS Accounting Extensions 
> for Traffic Statistics, for two reasons:
... could be used for differentiated charging.

Regards, Benoit.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 30 Sep 2012 08:58:30 +0200

> <http://www.iana.org/assignments/ipfix/ipfix.xml>

  That is definitely relevant.  If I may speak for the RADIUS side, I
think that the current goal is a *slightly* more capable accounting than
what we're doing now.

  However... there's a balance between doing "just a little more" and
re-inventing something, versus just doing it right the first time.  And
there's always the tendency to re-use your own expertise, rather than
using external expertise.

  My $0.02 is that IPFIX is very opaque.  I've spent some time reading
the RFCs, and all I know now is that there are sets, templates, layers,
and more layers.  It's not clear what's going on.

  For example, the link you posted above defines "flowStartSeconds".
Which is in a unit called "dateTimeSeconds".  It's defined in RFC 5102.
Section 3.1.15 (http://tools.ietf.org/html/rfc5102#section-3.1.15)
defines it.

  But... it doesn't say how *big* it is.  I still have no idea how many
bytes to put into a packet.  This makes re-using IPFIX problematic.  We
would have to re-define some of the terms used in IPFIX.

  My take-away is that re-using IPFIX could be very helpful.  The main
benefit is that we would not need to re-define *what* piece of
information we're tracking.  We could just reference the IPFIX definitions.

  We would still be left with the problem of how to *represent* that
information in RADIUS.  That requires some work.

  Alan DeKok.

---

From: "Leaf Yeh" <[email-masked]>
Date: Mon, 1 Oct 2012 12:14:08 +0800

Dear Benoit,

Benoit - If we go for the flexible approach, where do we stop in terms of
flexibility? 

Draft-yeh-radext-ext-traffic-statistics suggests we could get the 1st stop
at stack-type (ipv4-only, ipv6-only & dual-stack) and DSCP-type (optional).
Within this solution, Stack-type can directly meet the explicit requirement
defined in section 9.4 of BBF TR-187. Even if we intend to report traffic of
each subscriber in DSCP-types, that always means triple (or more) statistic
resources for each subscriber are required on the NAS, right?

Benoit - Should the URN in WInter's draft contain: then ipv4 versus ipv6,
then all the DSCP values, then the next hop, then AS-path ... All of which
... could be used for differentiated charging.

a.  I haven't see the requirement, application scenario or business model
from the industry related to the differentiated accounting with 'next hop',
'AS-path' & etc. 

   [BBF TR-187]
   [draft-hu-v6ops-radius-issues-ipv6-00]  from China Telecom 
   [draft-maglione-radext-ipv6-acct-extensions-01] from Telecom Italia.

mentioned in draft-yeh-radext-ext-traffic-statistics-03 may show some of the
interests from the industry for your reference. 

b.  I doubt 'next hop' or 'AS-path' are subscrber-specified (or based)
feature, which sounds not associated with the accounting for the different
subscribers.

c.  In the RADIUS accounting protocol defined in RFC2866, we only have 2
messages. Accounting-Request is for reporting, and Accounting-Response is
for acknowledgement. To my understanding, RADIUS can only report service
duration (per the attribute of Acct-Session-Time) or traffic volume (per the
attribute of Acct-Input/Output-Octet/Packet) now, it seems we have still
have no means (or attributes) defined for the Access-Accept to support the
on-demand accounting information reporting. If the assumption sounds IPFIX
informational model (which I am not familiar with yet) can provide more
information related with the traffic aspects than here for each subscriber,
we still need figure out which of those information is what the subscriber
accounting need, and find a way for the on-demand reporting, right?

d.  As a date type, the newly proposed 'String in URN format' sounds an
alternative option of the traditional existing date type of 'Enumerated
Integer' for the same enumeration question of the traffic type in this case.
I meant the data type of 'Enumerated Integer' is the convention for
enumeration in RADIUS (almost in every RADIUS RFC) before, it can just solve
the problem in this case, but it is called 'tactical approach' here now. 

Best Regards,
Leaf

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Benoit Claise
Sent: Saturday, September 29, 2012 10:00 PM
To: Sanchez, Mauricio (HP Networking)
Cc: [email-masked]
Subject: Re: [radext] new charter proposal

Sent to fast.
See in line.
Dear all,

Since we also discussed this new charter during the IETF meeting, I'll take
the lack of replies as agreement. 

However, I have a concern regarding the RADIUS Accounting Extensions for
Traffic Statistics, for two reasons: 
1. there are two competing proposals, tactical approach vs. flexible
approach, as mentioned in the meeting minutes. And there is ongoing
discussion on the mailing regarding the direction to take.
2. If we go for the flexible approach, where do we stop in terms of
flexibility? 
Should the URN in WInter's draft contain: then ipv4 versus ipv6, then all
the DSCP values, then the next hop, then AS-path ... All of which 
... could be used for differentiated charging.

Regards, Benoit.

Since both the NAI and the fragmentation work is agreed upon, we could
proceed with the new charter, modulo the "RADIUS Accounting Extensions for
Traffic Statistics"

Regards, Benoit.

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 maintain interoperation of heterogeneous RADIUS/Diameter
deployments, all RADEXT WG work items except those that just define new
attributes 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.

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
Aug 2012 IPv6 Access I-D submitted as a Proposed Standard RFC
Aug 2012 Extended Attributes I-D submitted as a Proposed Standard RFC
Aug 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC
Sep 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Oct 2012 RADIUS over DTLS I-D submitted as an Experimental RFC
Dec 2012 Traffic Statistics Attribute I-D submitted as a Proposed Standard
RFC
Dec 2012 RADIUS packet fragmentation submitted as an Experimental RFC
Jan 2012 RFC 4282bis submitted as a Proposed Standard RFC
Apr 2013 RADIUS support for NAI Internationalization I-D submitted as a
Proposed Standard RFC