Internet DRAFT - draft-dekok-radius-ipfix
draft-dekok-radius-ipfix
Network Working Group A. DeKok
INTERNET-DRAFT FreeRADIUS
Category: Experimental S. Winter
<draft-dekok-radius-ipfix-00.txt> RESTENA
Expires: April 5, 2013
8 October 2012
RADIUS accounting via IPFIX
draft-dekok-radius-ipfix
Abstract
The Remote Authentication Dial In User Server (RADIUS) Protocol
provides for a number of simple session-based metrics. There is a
need to increase the number of metrics, and to add metrics for
individual flows within a session. This document leverages IP Flow
Information Export (IPFIX) to address both needs.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 12, 2011
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
DeKok, Alan Experimental [Page 1]
INTERNET-DRAFT RADIUS Accounting via IPFIX 8 October 2012
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info/) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
DeKok, Alan Experimental [Page 2]
INTERNET-DRAFT RADIUS Accounting via IPFIX 8 October 2012
Table of Contents
1. Introduction ............................................. 4
1.1. Terminology ......................................... 4
1.2. Requirements Language ............................... 4
2. IPFIX in RADIUS .......................................... 5
2.1. IPFIX-Container Attribute ........................... 5
2.2. IPFIX to RADIUS Data Type Mappings .................. 6
2.3. IPFIX ElementID to RADIUS TLV Mapping ............... 7
2.4. Summary of the Mappings ............................. 8
3. IPFIX-Container in RADIUS Packets ........................ 8
3.1. IPFIX-Container in Access-Accept .................... 8
3.2. IPFIX-Container in Accounting-Request ............... 9
3.3. Administratively Configured Flows ................... 9
4. Caveats .................................................. 10
5. Examples ................................................. 10
5.1. Access-Accept ....................................... 10
5.2. Accounting-Request .................................. 11
6. Security Considerations .................................. 11
7. IANA Considerations ...................................... 11
8. References ............................................... 11
8.1. Normative References ................................ 11
8.2. Informative References .............................. 12
Appendix A - XML to RADIUS Dictionary Converter .............. 13
Appendix A.1 - Code for XML to RADIUS Dictionary Converter ... 14
DeKok, Alan Experimental [Page 3]
INTERNET-DRAFT RADIUS Accounting via IPFIX 8 October 2012
1. Introduction
The Remote Authentication Dial In User Server (RADIUS) Protocol
defines in [RFC2866] and others metrics for transporting session-
based accounting. We wish to extend those capabilities, while having
a specification that satisfies the following criteria:
* follows the RADIUS data model as defined in [RFC6158],
and [EXTEN],
* allows for an increased number of metrics per session,
* allows for metrics for individual flows within a session,
* can describe flows in an Access-Accept, for later accounting
in an Accounting-Request,
* requires minimal work from the RADEXT working group to define
new metrics
We believe this document satisifies those criteria. We propose to do
this by leveraging IP Flow Information Export (IPFIX) entries,
defined in [IPFIX]. The benefits of this approach are many. We
leverage existing expertise and work, we do not create a new standard
to exchange the same information, etc.
1.1. Terminology
This document uses the following terms:
RADIUS client
A device that provides an access service for a user to a network.
Also referred to as a Network Access Server, or NAS.
RADIUS server
A device that provides one or more of authentication,
authorization, and/or accounting (AAA) services to a NAS.
RADIUS proxy
A RADIUS proxy acts as a RADIUS server to the NAS, and a RADIUS
client to the RADIUS server.
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
DeKok, Alan Experimental [Page 4]
INTERNET-DRAFT RADIUS Accounting via IPFIX 8 October 2012
2. IPFIX in RADIUS
This section defines how IPFIX information is carried inside of
RADIUS attributes.
2.1. IPFIX-Container Attribute
We define a new attribute, called IPFIX-Container. It leverages the
"Long Extended" type defined in [EXTEN] Section X.Y. A summary of
the Attribute format is shown below. The fields are transmitted from
left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD - IANA allocation from the "long extended" type space
Length
The Length of the attribute, as previously defined in [RFC2865]
Section 5. Permitted values are between 5 and 255. If a client
or server receives an IPFIX-Containter attribute with a Length of
2, 3, or 4, then that Attribute MUST be considered to be an
"invalid attribute", and be handled as per [EXTEN] Section 2.7.
Extended-Type
TBD - IANA allocation from the "long extended" type space
M (More)
The More field is one (1) bit in length, and indicates whether or
not the current attribute contains "more" than 251 octets of data.
The More field MUST be clear (0) if the Length field has value
less than 255. The More field MAY be set (1) if the Length field
has value of 255.
If the More field is set (1), it indicates that the Value field
has been fragmented across multiple RADIUS attributes. When the
More field is set (1), the attribute SHOULD have a Length field of
value 255; it MUST NOT have a length Field of value 4; there MUST
DeKok, Alan Experimental [Page 5]
INTERNET-DRAFT RADIUS Accounting via IPFIX 8 October 2012
be an attribute following this one; and the next attribute MUST
have both the same Type and Extended Type. That is, multiple
fragments of the same value MUST be in order and MUST be
consecutive attributes in the packet, and the last attribute in a
packet MUST NOT have the More field set (1).
When the Length field of an attribute has value less than 255, the
More field SHOULD be clear (0).
If a client or server receives an attribute fragment with the
"More" field set (1), but for which no subsequent fragment can be
found, then the fragmented attribute is considered to be an
"invalid attribute", and handled as per [EXTEN] Section 2.7.
Reserved
This field is 7 bits long, and is reserved for future use.
Implementations MUST set it to zero (0) when encoding an attribute
for sending in a packet. The contents SHOULD be ignored on
reception.
Value
The value is a series of Type-Length-Values (TLVs), which are the
IPFIX information elements as defined in [IPFIX]. One flow MUST
be encapsulated in one IPFIX-Container attribute. An IPFIX-
Container attribute MUST NOT contain zero, or multiple flows.
2.2. IPFIX to RADIUS Data Type Mappings
The IPFIX specification defines a number of data types. Some can be
mapped to RADIUS, others cannot. We document those mappings here.
Where a data type is not mapped, IPFIX information elements using
that data type MUST NOT appear in a RADIUS packet.
We use the RADIUS data types as defined in [RFC6158]. The following
table defines the mappings.
Mapping Table
IPFIX RADIUS
----- -------
unsigned8 integer
unsigned16 integer
unsigned32 integer
unsigned64' integer64
ipv4Address IP Address
ipv6Address IPv6 Address
string text
DeKok, Alan Experimental [Page 6]
INTERNET-DRAFT RADIUS Accounting via IPFIX 8 October 2012
octetArray string
dateTimeSeconds date
dateTimeMilliseconds integer64
dateTimeMicroseconds integer64
dateTimeNanoseconds integer64
macAddress string
boolean integer
RADIUS does not permit eight (8) or sixteen (16) bit data types, so
IPFIX "integer" types of those sizes are mapped to RADIUS 32-bit
integers.
We want to avoid creating new RADIUS data types. Therefore, the
IPFIX "dateTime" types are mapped to "integer64". The only exception
is "dateTimeSeconds", which maps to the RADIUS "date" data type.
RADIUS does not have a "MAC Address" data type. Therefore the IPFIX
"macAddress" data type maps to the RADIUS "string" data type.
2.3. IPFIX ElementID to RADIUS TLV Mapping
The IPFIX ElementIDs are fifteen (15) bits long, while the RADIUS
attribute IDs are eight (8) bits. We therefore need a mapping from
one to the other. The mapping involves allocating two layers of
TLVs, which allows for sixteen (16) bits of mapping. The mapping
function is as follows:
TLV1 = (ElementId >> 8) & 0xFF
TLV2 = ElementId & 0xFF
The resulting RADIUS attribute is then TBD.TLV1.TLV2. (IANA NOTE:
Replace TBD with the allocated "long extended" attribute, e.g.
245.1).
We do not allocate or name TBD.TLV1 in the RADIUS attribute space.
(IANA NOTE: Replace TBD with the allocated "long extended" attribute,
e.g. 245.1). It is simple a container which is never referenced by
itself.
We do not provide an exhaustive mapping of which IPFIX ElementID is
appropriate (or not) for inclusion in which RADIUS packet. We
instead provide general guidelines and recommendations.
IPFIX ElementIDs relating to counters and flow identification are
useful in RADIUS. Other ElementIDs are less useful, and SHOULD NOT
be used. ElementIDs related to security and packet signing MUST NOT
be used in RADIUS.
DeKok, Alan Experimental [Page 7]
INTERNET-DRAFT RADIUS Accounting via IPFIX 8 October 2012
2.4. Summary of the Mappings
The mapping from IPFIX Information Elements to RADIUS attributes is
simple and mechanical. New IPFIX Information Elements can be used by
RADIUS without requiring new specifications in the RADIUS space.
A short Perl program is available in Appendix A, below. It provides
an example of how the mapping can be done automatically. However, it
does not provide a standard of any kind.
3. IPFIX-Container in RADIUS Packets
The IPFIX-Container attribute is permitted in Access-Accept packets,
and in Accounting-Request packets. It MUST NOT occur in any other
kind of RADIUS packet.
3.1. IPFIX-Container in Access-Accept
The IPFIX-Container can be sent in an Access-Accept packet. This
indicates a request from the server that the NAS send Accounting-
Request packets containing the requested information. The NAS MAY
ignore this request, and send different information, or no
information.
The contents of the IPFIX-Container are ElementIDs which describe a
particular flow. Multiple IPFIX-Container attributes MAY be sent in
an Access-Accept.
The ElementIds which describe a particular flow are not enumerated
here. Instead, we suggest ElementIDs relating to IP addresses,
protocols, ports, etc. Where ElementIDs relating to flow
identification are omitted, the IPFIX-Container SHOULD be interpreted
as applying to all traffic.
The only restriction is that each IPFIX-Container attribute MUST
contain a flowID. It is RECOMMENDED that the RADIUS server allocate
these flowIDs through a robust process that generates globally and
temporally unique values. The method for doing so is not described
here.
An Access-Accept MUST NOT contain multiple IPFIX-Container attributes
with the same flowID.
This restriction comes about as a result of issues seen with Acct-
Session-Id. Deployment experience shows that many NAS
implementations choose repeating values for Acct-Session-Id. That
repetition makes it difficult for RADIUS servers to track individual
user sessions. Allowing for flow-based accounting would make that
DeKok, Alan Experimental [Page 8]
INTERNET-DRAFT RADIUS Accounting via IPFIX 8 October 2012
problem worse.
This document instead requires that flowIDs are allocated by the
RADIUS server. NAS implementations MUST NOT create flowIDs.
3.2. IPFIX-Container in Accounting-Request
The IPFIX-Container can be sent in an Accounting-Request packet.
This indicates that the NAS is sending accounting information about a
particular flow.
The contents of the IPFIX-Container are ElementIDs which describe a
the accounting data for a particular flow. Multiple IPFIX-Container
attributes MAY be sent in an Accounting-Request. The IPFIX-Container
MAY avoid sending ElementIDs which describe the flow. i.e.
ElementIDs which are sent in an Access-Accept. The flowID is
generally sufficient to uniquely describe a flow.
However, in situations where the flowIDs are administratively
configured, those ElementIDs which describe the flow MUST be included
in the IPFIX-Container attribute. This inclusion ensures that the
combination of flowID and flow description is unique.
The ElementIds which describe accounting for a particular flow are
not enumerated here. Instead, we suggest ElementIDs relating to
packet counting, octet counting, time, etc.
The only restriction is that each IPFIX-Container attribute MUST
contain a flowID. The NAS MUST use flowIDs taken from a
corresponding Access-Accept packet, or flowIDs which have been
administratively configured. It MUST NOT generate flowIDs by itself.
An Accounting-Request packet MUST NOT contain multiple IPFIX-
Container attributes with the same flowID.
3.3. Administratively Configured Flows
A NAS MAY permit an administrator to manually configure flows. In
that case, it can send flows in an Accounting-Request packet which
were not requested in an Accounting-Accept packet. In that case,
ElementIDs which describe the flow MUST be included in the IPFIX-
Container attribute. The flowID MUST also be configured by the
administrator, and not created by the NAS.
For administratively configured flows, a NAS MAY give the
administrator the choice of using incrementing flowIDs for each flow
in a session, starting from the value one (1).
DeKok, Alan Experimental [Page 9]
INTERNET-DRAFT RADIUS Accounting via IPFIX 8 October 2012
4. Caveats
The flows in IPFIX are unidirectional. RADIUS uses different
attributes to count data for each direction. As a result, where
RADIUS would use two attributes Acct-Input-Octets and Acct-Output-
Octets, we would require two IPFIX-Container attributes.
Not all of the IPFIX data types are mapped. We have no suggestions
for what to do with the more complex data types.
The IPFIX "basicList" data type appears to be unnecessary in RADIUS.
Instead of encapsulating multiple ports in a basicList, we can simply
send multiple port descriptions in one IPFIX-Container attribute.
Mapping eight and sixteen-bit IPFIX integers to a 32-bit RADIUS
integer type is suboptimal. However, it meets the requirements of
[RFC6158]. The major benefit of reusing the RADIUS data model
outweighs the minor benefit of a slightly more efficient packing.
IPFIX allows for sending data up to 64K in size. The multiple
encapsulations define here allows for only a maximum of 249 octets.
This limitation does not matter for the bulk of the ElementIDs which
are relevant to RADIUS. For the rest, we offer no suggestion other
than to administratively limit strings to a particular length.
Not all implementations will support this specification. Therefore,
the existing RADIUS accounting attributes SHOULD be sent in addition
to the IPFIX-Container attribute. Sending only IPFIX-Container is
NOT RECOMMENDED.
5. Examples
This section contains examples. We use names for the attributes
taken from the output of the Perl program in Appendix A. We show
only the IPFIX-Container attribute and the TLVs related to IPFIX
ElementIDs. We do not show intermediate TLVs.
5.1. Access-Accept
IPFIX-Container
IPFIX-flowId = 1
IPFIX-flowDirection = 0x00
IPFIX-Container
IPFIX-flowId = 2
IPFIX-flowDirection = 0x01
DeKok, Alan Experimental [Page 10]
INTERNET-DRAFT RADIUS Accounting via IPFIX 8 October 2012
5.2. Accounting-Request
Acct-Input-Octets = 1024
Acct-Output-Octets = 2048
Acct-Input-Packets = 10
Acct-Output-Packets = 20
IPFIX-Container
IPFIX-flowId = 1
IPFIX-flowDirection = 0x00
IPFIX-octetTotalCount = 1024
IPFIX-packetTotalCount = 10
IPFIX-Container
IPFIX-flowId = 2
IPFIX-flowDirection = 0x01
IPFIX-octetTotalCount = 2048
IPFIX-packetTotalCount = 20
6. Security Considerations
This document defines new RADIUS attributes, but makes no changes to
the RADIUS protocol. As such, there are no security considerations.
The IPFIX protocol defines security related ElementIDs such as
messageMD5Checksum. These ElementIDs MUST NOT appear in a RADIUS
packet. Existing RADIUS security is sufficient to protect the
packets.
7. IANA Considerations
This document requests the allocation of a new attribute, "IPFIX-
Container", from the "long extended" RADIUS attribute type space.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
[IPFIX] http://www.iana.org/assignments/ipfix/
[EXTEN] DeKok, A, Lior, A, "Remote Authentication Dial In User Service
(RADIUS) Protocol Extensions", draft-ietf-radext-radius-
DeKok, Alan Experimental [Page 11]
INTERNET-DRAFT RADIUS Accounting via IPFIX 8 October 2012
extensions-05.txt, (work in progress)
8.2. Informative References
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC6158] DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC
6158, March 2011.
Acknowledgments
The initial suggestion to leverage IPFIX was from Benoit Claise.
DeKok, Alan Experimental [Page 12]
INTERNET-DRAFT RADIUS Accounting via IPFIX 8 October 2012
Appendix A - XML to RADIUS Dictionary Converter
The following page contains a simple Perl script which converts the
[IPFIX] XML registry to a RADIUS dictionary file. It is intended as
a guide to show that the conversion is mechanical. It does not
specify a standard, and implementors are free to use their own method
for converting the IPFIX registry to a RADIUS dictionary.
DeKok, Alan Experimental [Page 13]
INTERNET-DRAFT RADIUS Accounting via IPFIX 8 October 2012
Appendix A.1 - Code for XML to RADIUS Dictionary Converter
#!/usr/bin/env perl
use XML::Simple;
use Data::Dumper;
$prefix = "TBD"; # IANA - to be updated
print "ATTRIBUTE IPFIX-Container $prefix long-extended\n";
$map = {
'unsigned8' => 'integer',
'unsigned16' => 'integer',
'unsigned32' => 'integer',
'unsigned64' => 'integer64',
'ipv4Address' => 'ipaddr',
'ipv6Address' => 'ipv6ddr',
'string' => 'text',
'octetArray' => 'string',
'dateTimeSeconds' => 'date',
'dateTimeMilliseconds' => 'integer64',
'dateTimeMicroseconds' => 'integer64',
'dateTimeNanoseconds' => 'integer64',
'macAddress' => 'string',
'boolean' => 'integer',
};
$xml = new XML::Simple;
$data = $xml->XMLin("ipfix.xml");
$elements = $data->{registry}->{'ipfix-information-elements'}->{record};
foreach $record (@{$elements}) {
next if $record->{unassigned};
next if $record->{reserved};
$name = $record->{name};
$name =~ s/\s+//g;
$upper = 1 + (($record->{elementId} & ~0xff) >> 8);
$lower = $record->{elementId} & 0xff;
$oid = "$prefix.$upper.$lower";
$type = $record->{dataType};
if (!defined $map->{$type}) {
print "# ATTRIBUTE IPFix-$name $oid ", $type, "\n";
} else {
print "ATTRIBUTE IPFix-$name $oid ", $map->{$type}, "\n";
}
DeKok, Alan Experimental [Page 14]
INTERNET-DRAFT RADIUS Accounting via IPFIX 8 October 2012
}
Authors' Addresses
Alan DeKok
The FreeRADIUS Server Project
http://freeradius.org/
Email: aland@freeradius.org
Stefan Winter
Fondation RESTENA
6, rue Richard Coudenhove-Kalergi
Luxembourg 1359
Luxembourg
Phone: +352 424409 1
Fax: +352 422473
EMail: stefan.winter@restena.lu
URI: http://www.restena.lu
DeKok, Alan Experimental [Page 15]
