Subject: Re: [radext] new charter proposal

From: Stefan Winter <[email-masked]>
Date: Mon, 01 Oct 2012 13:40:23 +0200

Hi,

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

If I recall the meeting correctly (remote participation only), I believe
there was an extensive discussion and a show of hands which direction to
take. I heard after the meeting that the result was 4:1 in favour of a
flexivle approach.

That show of hands was to be confirmed on the list, but IIRC, this
hasn't happened yet.

I'd suggest a corresponding poll on the list, and take the result of
that as the basis for the new charter.

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

I believe that once the principle direction "flexible vs. one-purpose"
is settle, the *details* of how that flexibility should look like could
be part of the normal WG work and doesn't have to explicitly called out
in the charter.

Greetings,

Stefan Winter

> 
> 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
>>
>>
> 
> 
> 
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
> 

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

---

From: Stefan Winter <[email-masked]>
Date: Mon, 01 Oct 2012 13:49:46 +0200

Hi,

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

Reusing IPFIX definitions sounds good to me, under some conditions.

1. The information in the Accounting packet should not be required to
contain the entire definition of that flow; a label of sorts should
attached / admin-defined and that label should be used.

2. The question of how to configure the NAS for such accounting should
be out of scope for the accounting document. I could imagine it to
happen within an Access-Accept for a specific user, or as a
configuration action by the administrator on the NAS. In any case, not
within an Accounting message; and since this draft is about Accounting,
it should happen somewhere else.

I believe 2. was discussed lately, and agreed upon already. If that's
true, the discussion would boil down to

- "How to map from an IPFIX flow definition to a handle / label?"

- "How to transport the label and related accounting data from client to
server?"

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Mon, 01 Oct 2012 14:16:28 +0200

> attached / admin-defined and that label should be used.

  IPFIX has a 64-bit "flowID" field.  That should work.  My only hard
requirement is that the flowID is either set by the administrator, or by
the RADIUS server in an Access-Request.  NASes shouldn't invent it
themselves.

> it should happen somewhere else.

  I agree.

> - "How to transport the label and related accounting data from client to

  I've done some research.  I think I have a reasonable solution.  I'll
try to post a -00 before October 8.

  Alan DeKok.

---

From: "Leaf Yeh" <[email-masked]>
Date: Mon, 1 Oct 2012 21:33:37 +0800

The mail below recorded us one more support to make the item of 'RADIUS
Accounting Extensions for Traffic Statistics' into the Radext new charter.
:-)

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stefan Winter
Sent: Monday, October 01, 2012 7:40 PM
To: [email-masked]
Subject: Re: [radext] new charter proposal

Hi,

> However, I have a concern regarding the RADIUS Accounting Extensions 
> for Traffic Statistics, for two reasons:

That show of hands was to be confirmed on the list, but IIRC, this hasn't
happened yet.

I'd suggest a corresponding poll on the list, and take the result of that as
the basis for the new charter.

I believe that once the principle direction "flexible vs. one-purpose"
is settle, the *details* of how that flexibility should look like could be
part of the normal WG work and doesn't have to explicitly called out in the
charter.

Greetings,

Stefan Winter

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

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

---

From: Peter Deacon <[email-masked]>
Date: Mon, 1 Oct 2012 09:46:20 -0700 (Pacific Daylight Time)

On Sat, 29 Sep 2012, Benoit Claise wrote:

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

> 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

I would settle for some kind of standard Class attribute in RADIUS 
authorization message able to find its way into a flow field in flows 
exported by NAS and just use a collector.

Correlating addresses to sessions with aggregation delays and dynamically 
assigned addresses stink.  Having something you can key off and always 
sliced on at least "Class" boundaries regardless of aggregation scheme 
would be awesome.

> 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

Was thinking the other day of using the opaque labels concept as a bridge 
to correlate RADIUS accounting counters with filters defined during 
authorization and or OOB.  Not saying I am for or against this just an 
idea.

For example I need IPv6 flows I send a message during authorization saying 
please send me IPv6 -- and by the way use label 'MyIPv6' during accounting 
to provide this data.

In accounting I would see a TLV with label 'MyIPv6' containing my byte and 
packet counts.  I know what 'MyIPv6' means because this was defined during 
authorization using some undefined syntax??

A few points I think is important about this scheme and generally:

You don't have to answer the complexity question up front.  New filter 
syntaxes can be defined at any time for specific or general tasks without 
effecting the accounting portion.

Could be as simple as filter defined in NAS OOB from RADIUS requiring no 
authorization attributes.

It could be a complex IP filter defined via RADIUS authorization.

It could be a complex filter defined in NAS.

Accounting message size remains fixed regardless of complexity of a filter 
defined during RADIUS authorization.

As mentioned before I still think that any sufficiently complex definition 
requires explanation to be useful to an accounting system.  It is not 
enough simply to punt for example a DSCP option and expect the accounting 
system to understand what it means especially if it has only local 
significance per NAS or admin domain.

If it was set via authorization the context to understand intention is 
available to accounting.  If it is set OOB and you just get the DSCP 
option then potentially necessary context is lost.

Other thoughts.. I don't see value in schemes where a ton of detailed data 
is transmitted for example flows between source and destination addresses. 
Better off using netflow if you want to do that.  If I want data via AAA I 
only want to track a few things.. anything requiring a template cache is 
likely too much.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 01 Oct 2012 18:54:44 +0200

Peter Deacon wrote:
> Correlating addresses to sessions with aggregation delays and
> dynamically assigned addresses stink.  Having something you can key off
> and always sliced on at least "Class" boundaries regardless of
> aggregation scheme would be awesome.

  I agree.  IPFIX supports a 64-bit flowID.  That would seem to work here.

> Other thoughts.. I don't see value in schemes where a ton of detailed
> data is transmitted for example flows between source and destination
> addresses. Better off using netflow if you want to do that.  If I want
> data via AAA I only want to track a few things.. anything requiring a
> template cache is likely too much.

  That is a good point.  I think there is getting to be more overlap
between netflow and fine-grained AAA accounting.

  However, people have RADIUS proxy systems in place.  They don't have
much similar for netflow.

  Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Mon, 8 Oct 2012 07:58:55 +0000

Peter - As mentioned before I still think that any sufficiently complex definition 

I regard DSCP-type is optional now, it might need more discussion. If operators need it, it sounds closely to the SLA (gold, silver or bronze, and etc) of services, which is associated with billing or accounting. 

But it seems to me the full DSCP codes looks naturally as the 'Enumerated Integer'. I meant it is easier to express it in 'integer'. :-)

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Deacon
Sent: Tuesday, October 02, 2012 12:46 AM
To: Benoit Claise
Cc: [email-masked]; Sanchez, Mauricio (HP Networking)
Subject: Re: [radext] new charter proposal

regards,
Peter