Internet DRAFT - draft-marin-sdnrg-sdn-aaa-mng
draft-marin-sdnrg-sdn-aaa-mng
SDNRG R. Marin-Lopez
Internet-Draft G. Lopez-Millan
Intended status: Experimental University of Murcia
Expires: May 14, 2016 November 11, 2015
Software-Defined Networking (SDN)-based AAA Infrastructures Management
draft-marin-sdnrg-sdn-aaa-mng-00
Abstract
This document describes the management of Authentication,
Authorization and Accounting (AAA) infraesctrutures by means of a
Software-Defined Network (SDN) controller and raises the requirements
to support this service. It considers the management of AAA routing
and the establishment of security associations between AAA entities.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 14, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Marin-Lopez & Lopez-MillaExpires May 14, 2016 [Page 1]
Internet-Draft SDN AAA Management November 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. AAA flow based routing . . . . . . . . . . . . . . . . . . . 6
6. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. AAA routing and security association establishment . . . 10
6.2. AAA agents under different SDN controllers . . . . . . . 12
7. Relationship with I2NSF . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
Software-Defined Networking (SDN) is an architecture that enables
users to directly program, orchestrate, control and manage network
resources through software. SDN paradigm relocates the control of
network resources to a dedicated network element, namely SDN
controller. The SDN controller manages and configures the
distributed network resources and provides an abstracted view of the
network resources to the SDN applications. The SDN application can
customize and automate the operations (including management) of the
abstracted network resources in a programmable manner via this
interface [RFC7149][ITU-T.Y.3300]
[ONF-SDN-Architecture][ONF-OpenFlow].
Authentication, Authorization and Accounting (AAA) [RFC2903][RFC2904]
infrastructures manage three basic security services to control the
access to network resources: Authentication, in order to determine
who the end user is; Authorization, in order to determine under what
conditions an end user is granted access to the network resource; and
Accounting, in order to account the resource usage of the end user.
Following the terminology in [RFC6733], an AAA infrastructure is
formed by AAA nodes. An AAA protocol is used to exchange AAA
information between them. RADIUS [RFC2865], [RFC2866] and Diameter
[RFC6733]. These AAA nodes can be classified as follows:
o AAA client. It is a AAA node that implement the client part of a
AAA protocol.
Marin-Lopez & Lopez-MillaExpires May 14, 2016 [Page 2]
Internet-Draft SDN AAA Management November 2015
o AAA server. AAA node that handles authentication, authorization,
and accounting requests for a particular realm.
o AAA agent. AAA node that implements one of the following
functionalities:
o
* Relay Agents. They are agents that accept requests and route
messages (making use of a routing table) to other nodes based
on information found in the DIAMETER messages.
* Proxy Agents. Similarly to relays, proxy agents also route
messages using a routing table. However, they differ since
they modify messages to implement policy enforcement.
* Redirect Agents. Redirect agents do not relay Diameter
messages, they return an answer with the information required
by the agents to communicate directly, so they do not modify
messages. They are useful in scenarios where routing
configuration needs to be centralized.
* Translation Agents. A translation agent is a device that
provides translation between two protocols (e.g.,
RADIUS<->Diameter, TACACS+<->Diameter).
As depicted in Figure 1, the AAA framework [RFC2903] defines a model
consisting of the User desiring gain access to a specific network
service; the AAA server in the User Home Organization (UHO) which has
registered the User's identity and credentials; and the AAA server
located in the Service Provider (SP) operating and controlling the
access to the network service through a Service Equipment. In non-
federated environments, User Home Organization and Service Provider
are the same organization. In federated environments, they are two
separate organizations.
Between the AAA client and the AAA server in the UHO, the AAA
infrastructure can deploy other intermediate AAA agents to forward
the information between both entities. RADIUS defines, apart from
the RADIUS client and RADIUS server, the role of proxy RADIUS or
forwarding RADIUS. Proxy RADIUS receives authentication requests
from a RADIUS client, forwards the request to a remote RADIUS server,
receives authentication responses from the remote server and forwards
the response to the client. In Diameter, apart from the AAA client
and the AAA server, it defines a set of these Diameter agents that
corresponds with the agents described above.
Marin-Lopez & Lopez-MillaExpires May 14, 2016 [Page 3]
Internet-Draft SDN AAA Management November 2015
It is important to note that the AAA node can act as AAA server in a
realm but also can act as, for example, Relay/Proxy agent for those
types of AAA requests that cannot be processed and need to be
forwarded to the next AAA node. It is also important to note that
some kind of trust relationship is required to be established between
these AAA nodes, in order to protect the AAA traffic
Typically, Proxy RADIUS and Diameter agents (from now on AAA agents)
hold and manage AAA routing information. Moreover AAA
infrastructures are manually configured, specially the AAA routing
information. For example, RADIUS implementations typically require
the name or address of servers or clients be manually configured,
besides passwords or cryptographic material to establish a security
associations between AAA entities. It makes difficult their
management and generates a lack of flexibility, specially if the
number of entities is high and the AAA infrastructure is complex.
With the grow of SDN-based scenarios where network resources are
deployed in an autonomous manner, a mechanism to manage AAA
infrastructures according to the SDN paradigm becomes more relevant.
Thus, the SDN-based service described in this document deals with AAA
infrastructures in such as an autonomous manner.
Marin-Lopez & Lopez-MillaExpires May 14, 2016 [Page 4]
Internet-Draft SDN AAA Management November 2015
+------+ +-------------------------+
| | | User Home Organization |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| |
| |
| |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | AAA Client | |
| | | |-------------------| |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Figure 1: AAA framework
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 RFC 2119 [RFC2119].
When these words appear in lower case, they have their natural
language meaning.
3. Terminology
This document uses the terminology described in [RFC7149], [RFC6733],
[ITU-T.Y.3300], [ONF-SDN-Architecture], [ONF-OpenFlow],
[ITU-T.X.1252], and [ITU-T.X.800]. In addition, the following terms
are defined below:
o Software-Defined Networking: A set of techniques enabling to
directly program, orchestrate, control, and manage network
resources, which facilitates the design, delivery and operation of
network services in a dynamic and scalable manner [ITU-T.Y.3300].
Marin-Lopez & Lopez-MillaExpires May 14, 2016 [Page 5]
Internet-Draft SDN AAA Management November 2015
4. Objectives
o Flow-based AAA traffic routing: SDN-based management allows to
route AAA traffic (flow) between different AAA agents so that the
authentication, authorization and accounting tasks can be
preformed. Thus, it can adapt quickly the routing information
when a AAA route is not available to redirect the AAA traffic to
other nodes.
o Bootstrapping security associations: SDN-based flow protection
allows the centralized bootstrapping of credentials to protect the
AAA traffic between two adjacent AAA nodes (hop-by-hop) or between
two separate AAA nodes without intermediate AAA nodes in between
(end-to-end).
5. AAA flow based routing
As mentioned, the AAA infrastructure is formed by a set of AAA nodes.
These nodes interconnect each other using the AAA protocol, such as
RADIUS or Diameter. When the User desires to access a service which
requires authentication and authorization, she typically sends her
identity to the Service Equipment. The Service Equipment (e.g. an
WiFi access point) deploys the AAA client to interact with the AAA
infrastructure. The User's identity contains the realm where she
belongs to. For example, an identity can be "alice@um.es". The
identifier is "alice" and the realm is "um.es". Based on this realm
(realm-based routing), the AAA agents, for example, AAA relay or
proxy, route the AAA information to the specific AAA server in the
User Home Organization that has a register of "alice@um.es". This
AAA server will be in charge of authenticate and authorize the Users
in the realm. In order to achieve a correct routing of AAA
information each AAA agent maintains a AAA routing table and another
table with the adjacent AAA servers, which are considered as next
"AAA hop".
As an example of AAA routing table, Diameter defines a format where
each table entry contains the following fields:
Realm Name
This is the field that MUST be used as a primary key in the
routing table lookups. Note that some implementations perform
their lookups based on longest-match-from-the-right on the realm
rather than requiring an exact match.
Application Identifier
Marin-Lopez & Lopez-MillaExpires May 14, 2016 [Page 6]
Internet-Draft SDN AAA Management November 2015
A Diameter Application (i.e. NAS-REQ, EAP, etc.) is identified by
an Application Id. The Diameter message can have a different
destination (route entry) based on the Application Id in the
message header. This field MUST be used as a secondary key field
in routing table lookups.
Local Action
The Local Action field is used to identify how a message should be
treated. The following actions are supported:
1. LOCAL - Diameter messages that can be satisfied locally, and
do not need to be routed to another Diameter entity.
2. RELAY - All Diameter messages that fall within this category
MUST be routed to a next hop Diameter entity that is indicated
by the identifier described below. Routing is done without
modifying any non-routing AVPs.
3. PROXY - All Diameter messages that fall within this category
MUST be routed to a next Diameter entity that is indicated by
the identifier described below. The local server MAY apply
its local policies to the message by including new AVPs to the
message prior to routing.
4. REDIRECT - Diameter messages that fall within this category
MUST have the identity of the home Diameter server(s)
appended, and returned to the sender of the message.
Additionally, Diameter specification defines the Peer Table, which is
used for message forwarding, and referenced by the Routing Table. A
Peer Table entry contains the following fields:
Host identity
The name of the peer (i.e. Diameter URI of the peer).
StatusT
This is the state of the peer entry.
Static or Dynamic
Marin-Lopez & Lopez-MillaExpires May 14, 2016 [Page 7]
Internet-Draft SDN AAA Management November 2015
Specifies whether a peer entry was statically configured or
dynamically discovered.
Expiration time
Specifies the time at which dynamically discovered peer table
entries are to be either refreshed, or expired.
TLS/TCP and DTLS/SCTP Enabled
Specifies whether TLS/TCP or DTLS/SCTP is to be used when
communicating with the peer.
Thus, the general idea presented in the document assumes that a SDN
controller can manage and fill this routing information in the
different AAA entities under its control. In particular, a set of
tasks (not exhaustive) that the SDN controller can perform over the
AAA infrastructure is the following:
o The SDN controller can provide this AAA routing information to the
AAA agents so having a dynamic AAA routing. In general, the SDN
controller can fill the AAA routing and peer table of any AAA
agents and servers, but also the AAA client to indicate the next
AAA hop. This brings all the existing advantages right now for
general IP routing with SDN paradigm to AAA routing. That is, it
provides flexibility, scalability, availability, and security.
o AAA entity and its adjacent ones typically keep a security
association (hop-by-hop security). For example, RADIUS has a
simple and weak model based on shared secrets. Extensions such as
RADSec [RFC6614] has been proposed for running TLS between two
RADIUS servers. Diameter mandates the usage of TLS and optionally
IPsec. To avoid manual configuration of these security
associations, the SDN controller can dynamically provide this
cryptographic information to both interacting AAA servers.
o When forming AAA federations, security is usually provided hop-by-
hop, which means that, between each pair of neighboring AAA
entities, the AAA protocol provides message protection.
Sometimes, for example in RADIUS, this protection is based on
message authentication, but not message encryption. So these
intermediate AAA entities can see all the information in clear.
To avoid this, end-to-end security MAY be required. With a SDN-
approach we foresee achieving the following. When the SP's AAA
server observes that the User belongs to a different realm that it
Marin-Lopez & Lopez-MillaExpires May 14, 2016 [Page 8]
Internet-Draft SDN AAA Management November 2015
does not know (managed by the UHO's AAA server), it can inform the
SDN controller. The SDN controller can then enforce cryptographic
material to both the UHO's AAA and SP's AAA server to establish a
direct security association between them. Thus, in a simple
architecture, the SDN controller would act as the manager of the
federation. Nevertheless, more complex cases can be envisages
such as each AAA server is managed by a different SDN-controller.
o The SDN controller can modulate the behaviour between a relay,
proxy and translation agent. For example, the SDN controller can
enforce routing tables but not sending any particular policy to
the agent, so that it behaves as a relay agent. However, if a
proxy is required the particular behaviour is enforced by the
controller based on internal policies. For certain routes the AAA
agent can act as a Redirect Agent. In fact, in relationship with
Network Function Virtualization (NVF) and Network Security
Function (NSF), we envisage that the SDN controller can order the
instantiation of a particular AAA agent (VNF) when it is required
and "places it" in the path of the chain of AAA agents where the
AAA requests and responses have to travel. For example, if the
SDN controller realizes the request is a RADIUS message and it has
to traverse a Diameter-based AAA infrastructure, it can
instantiate a Translation Agent, so that the requests and
responses are automatically translated from and to the different
AAA protocols. Once it is instantiated, the SDN controller can
install a routing entry in the RADIUS proxy so that the AAA
request goes through the Translation Agent.
o The SDN controller MAY also manage the User's credentials. In
other words, the SDN controller can store all the User information
provided by the administrator. When the AAA server is going to
act as UHO's AAA server for a set of services and users, it will
require this information to complete the authentication and
authorization steps. The SDN can proactively push this
information to the AAA server. Or, reactively, when the AAA
server does not know how to authenticate and authorize a request
it can ask for the advice of the SDN controller and the controller
can enforce the behaviour and the user's 'information.
o The SDN controller can also select the AAA server in charge of
(exclusively) Accounting. This accounting information can be also
route to the specific AAA server.
NOTE: In general, the SDN controller MAY make use of NETCONF and YANG
model for AAA entities to configure them.
Marin-Lopez & Lopez-MillaExpires May 14, 2016 [Page 9]
Internet-Draft SDN AAA Management November 2015
6. Scenarios
This section explains two main use cases as examples for the SDN-
based AAA management: first, when a single SDN controller is used;
second, when multiple SDN controllers take place in the
infrastructure.
6.1. AAA routing and security association establishment
As depicted in Figure 2, the SDN controller represents the "AAA
control plane" where the decisions of AAA routing are taken based on
AAA policies provided by the administrator (1). Once, the SDN
controller interprets these policies (2), it sends the AAA routing
information ("AAA data plane") to the AAA entities (e.g. Relay,
Proxies or Redirect) to carry out the forwarding of the AAA request.
This information is used to fill the AAA routing table and peer table
of AAA agent 1 and AAA agent 2 (3). Associated to this routing
information any security credential is also provided (4) by the SDN
controller to establish hop-by-hop security (5). In general, the SDN
controller can fill all the required information to the different AAA
agents that form the AAA routing path to the destination.
+----------------------------------------+
| SDN Controller |
| |
(1)| +--------------+ (2)+--------------+ |
AAA ------>| AAA Routing/ |--->| South. Prot. | |
Policies | | Key Distr. | | | |
| +--------------+ +--------------+ |
| AAA Control Plane | | |
| | | |
+--------------------------|-----|-------+
| |
| (3) |
|--------------------------+ (4) +---|
AAA V AAA Data Plane V AAA
request +-------------+ +-----------+request
------->| AAA |===============>| AAA |------>
| agent 1 | hop-by-hop | agent 2 |
| | security | |
+-------------+ (5) +-----------+
Figure 2: Example of AAA agent-to-agent routing.
Figure 3 represents the case where end-to-end security (5) is
established. In this case, the SDN controller enables credential and
AAA routing information so that the AAA request goes directly between
Marin-Lopez & Lopez-MillaExpires May 14, 2016 [Page 10]
Internet-Draft SDN AAA Management November 2015
the SP's AAA server and the UHO's AAA server without passing through
any intermediate AAA entity.
+----------------------------------------+
| SDN Controller |
| |
(1)| +--------------+ (2)+--------------+ |
AAA --------| AAA Routing/ |--->| South. Prot. | |
Policies. | Key Distr. | | | |
| +--------------+ +--------------+ |
| AAA Control Plane | | |
| | | |
+--------------------------|----------|--+
| |
(3) (4) | | (3)(4)
|--------------------+ + -----|
V AAA Data Plane V
AAA request +----------------+ +-----------+
------>| SP's AAA | | UHO's AAA |
| server |=================>| Server |
+----------------+ (5) +-----------+
end-to-end
security
Figure 3: Example of AAA server-to-server routing (end-to-end
security).
Finally, Figure 4 describes the case of pushing AAA routing
information only when really required (reactive). Let us assume that
the administrator has provided general AAA policies (1). When a
initial AAA request arrives the first time to the AAA agent 1, it
notifies about the request to the SDN Controller (2). The SDN
Controller looks for AAA routing information associated with the AAA
policies and the information in the AAA request. It decides that the
AAA request has to be forwarded to AAA agent 2 (3). The SDN
controller installs then AAA routing information in the routing table
and peer table in AAA agent 1 (4). Moreover, it fills the routing
and peer tables within AAA agent 2 (5). It also sends credentials to
both agents to establish a security association (6) in order to
provide hop-by-hop or end-to-end security (7).
Marin-Lopez & Lopez-MillaExpires May 14, 2016 [Page 11]
Internet-Draft SDN AAA Management November 2015
+----------------------------------------+
| (1) SDN Controller |
AAA ----------------+ |
Policies | V |
| +----------+ (3) +-------------+ |
---------->| AAA |<--->|South. Prot. | |
| | | Policies | | | |
| | +----------+ +-------------+ |
| | | | |
| | | | |
(2) | +------------------------| --- | --------+
| | |
| (4)(6)| |(5)(6)
| |------------------------+ +--|
AAA | V V AAA
request +-------------+ +-----------+request
------->| AAA |================= >| AAA |------>
| agent 1 | hop-to-hop/ | agent 2 |
| | security | |
+-------------+ (7) +-----------+
Figure 4: Example of SDN controller pushing AAA routing information
(reactive)
NOTE: It is worth noting that for the same AAA request some
information can be enforced proactively and other can be retrieved
reactively during the travel of the AAA request.
6.2. AAA agents under different SDN controllers
Another case (Figure 5) is when, for example, two organizations, ISP
A and ISP B have their own SDN controller (A and B respectively),
each one controlling a different set of AAA agents. During the
travel of a AAA request, it may need to pass from the AAA agent 1
controlled by SDN Controller A to another AAA agent 2 which is under
the control of a different SDN controller B.
In this case, both SDN controllers may coordinate each other and
determine whether the AAA request is allowed to traverse through both
realms or not (1). If they agree the conditions (2), the AAA
policies that represents this agreement are enforced by the SDN
controllers as AAA routing information and credentials into the AAA
agents (3). Then the AAA request can move forward (4).
Marin-Lopez & Lopez-MillaExpires May 14, 2016 [Page 12]
Internet-Draft SDN AAA Management November 2015
+-------------+ +-------------+
AAA | SDN |<=================>| SDN |
Policy. -->| Controller A| (2) |Controller B |
(1) | | | |
+-------------+ +-------------+
| |
| (3) (3) |
AAA V V AAA
request +-------------+ +-------------+ request
------>| AAA agent 1 |<=============>| AAA agent 2 |------>
+-------------+ (4) +-------------+
Figure 5: Gateway-to-gateway multi controller flow in case 1
7. Relationship with I2NSF
According to [I-D.merged-i2nsf-framework-04] I2NSF needs to provide
identity information, along with additional data that Authentication,
Authorization, and Accounting (AAA) frameworks can use. This enables
those frameworks to perform AAA functions on the I2NSF traffic. In
this sense, we assume that each AAA entity is, in the end, a NSF that
may need to be configured with AAA-related information and where the
administrator can obtain some valuable information such as, number
authentications executed, number of active users accessing the
service, accounting records, etc.
We envisage that SDN controller MAY also instantiate a vNSF acting as
one of the AAA agents (relay, proxy, redirect, translation, server,
etc...) when necessary. Even more, an administrator MAY instantiate
a AAA server that works as UHO's AAA server. For that, apart from
create the vNSF, it needs to register the users that the AAA server
needs.
Marin-Lopez & Lopez-MillaExpires May 14, 2016 [Page 13]
Internet-Draft SDN AAA Management November 2015
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Application | App.
| (e.g.Identity and AAA Management) | Layer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Support | SDN/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security
|AAA Control Plane(routing,key distribution.| Controller
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AAA server
| AAA Data Plane |(NSF)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
----> | Policy and Event Repository (PER) | --->
+-------------------------------------------+
| AAA routing table (AAA-RT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: High-level Architecture for SDN-based AAA management
Figure 6 describes the mapping with our use cases. In the right side
of the figure each entity follows the same terminology than
[I-D.merged-i2nsf-framework-04]
8. Security Considerations
TBD.
9. Acknowledgements
TBD.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<http://www.rfc-editor.org/info/rfc2865>.
Marin-Lopez & Lopez-MillaExpires May 14, 2016 [Page 14]
Internet-Draft SDN AAA Management November 2015
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
DOI 10.17487/RFC2866, June 2000,
<http://www.rfc-editor.org/info/rfc2866>.
[RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J., and
D. Spence, "Generic AAA Architecture", RFC 2903,
DOI 10.17487/RFC2903, August 2000,
<http://www.rfc-editor.org/info/rfc2903>.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
D. Spence, "AAA Authorization Framework", RFC 2904,
DOI 10.17487/RFC2904, August 2000,
<http://www.rfc-editor.org/info/rfc2904>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, DOI 10.17487/RFC6614, May 2012,
<http://www.rfc-editor.org/info/rfc6614>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012,
<http://www.rfc-editor.org/info/rfc6733>.
10.2. Informative References
[I-D.merged-i2nsf-framework-04]
Lopez, E., Lopez, D., Zhuang, X., Dunbar, L., Parrott, J.,
Krishnan, R., and SR. Durbha, "Framework for Interface to
Network Security Functions", draft-merged-i2nsf-framework-
04.txt (work in progress), October 2015.
[ITU-T.X.1252]
"Baseline Identity Management Terms and Definitions",
April 2010.
[ITU-T.X.800]
"Security Architecture for Open Systems Interconnection
for CCITT Applications", March 1991.
[ITU-T.Y.3300]
"Recommendation ITU-T Y.3300", June 2014.
[ONF-OpenFlow]
ONF, "OpenFlow Switch Specification (Version 1.4.0)",
October 2013.
Marin-Lopez & Lopez-MillaExpires May 14, 2016 [Page 15]
Internet-Draft SDN AAA Management November 2015
[ONF-SDN-Architecture]
"SDN Architecture", June 2014.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider
Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
<http://www.rfc-editor.org/info/rfc7149>.
Authors' Addresses
Rafa Marin-Lopez
University of Murcia
Campus de Espinardo S/N, Faculty of Computer Science
Murcia 30100
Spain
Phone: +34 868 88 85 01
Email: rafa@um.es
Gabriel Lopez-Millan
University of Murcia
Campus de Espinardo S/N, Faculty of Computer Science
Murcia 30100
Spain
Phone: +34 868 88 85 04
Email: gabilm@um.es
Marin-Lopez & Lopez-MillaExpires May 14, 2016 [Page 16]
