Re: [radext] new charter proposal

["Leaf Yeh" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
Benoit Claise
Sent: Saturday, September 29, 2012 10:00 PM
To: Sanchez, Mauricio (HP Networking)
Cc: [e-mail]
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.

To finally end up with the IPFIX flexibility, i.e. a template based
mechanism, based on any selection of all IPFIX IANA IEs

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
[e-mail]
https://www.ietf.org/mailman/listinfo/radext