SDNAuth H. Rafiee
INTERNET-DRAFT A. Petrescu
Intended Status: Informational
Expires: December 6, 2015 June 6, 2015
SDNauth Usecases and Requirements
<draft-rafiee-sdnauth-usecase-01.txt>
Abstract
This document aims to explain the requirement and usecases for a
secure authentication model for different SDN components (e.g. SDN
switch, application, etc.). It also covers the standard structure for
the communications of two SDN controllers or an application to
different SDN controllers via a mediator service.
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 December 6, 2015.
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
Rafiee & Petrescu Expires December 6, 2015 [Page 1]
INTERNET DRAFT SDNauth usecases June 6, 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. User movements in carrier WiFi networks . . . . . . . . . 4
3.2. Limited UI devices connections to public hotspot areas . 5
3.3. Distributed SDN controllers . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Rafiee & Petrescu Expires December 6, 2015 [Page 2]
INTERNET DRAFT SDNauth usecases June 6, 2015
1. Terminology
There is already a good SDN terminology available [RFC74269]. Here is
the list of terms that has special meaning in this document.
- End system: any device that is used by a user to start its
communication ? a laptop, a smartphone, etc.
- Network element: any physical or logical network devices such as a
switch, a router, virtual switch (vswitch), etc.
- Application (App): In this document, application is any piece of
software that wants to communicate with SDN controller to exchange
information or enforce any policy via SDN controller on target
switch(es). e.g. an authentication/authorization app
- Traffic flow : a group of traffic with the similar source or
destination and port
- Foreign SDN controller: a SDN controller that an application is not
authorized to run anything on it.
- Home SDN controller: a SDN controller that an application is
pre-configured with to enforce any policy on.
2. Introduction
Today, the advances of technology provide us with new capabilities
and the possibility to use scalable logical networks and flexible and
programmable virtual network devices (which uses Software Defined
Network (SDN)[1,2], Network Function Virtualization (NFV) -based
techniques or the combination of these two techniques. Since these
techniques also promote the openness and abstraction concepts,
authentication and authorization are both critical in such
infrastructures.
This is because, before two SDN components (e.g. an application, an
SDN switch, a SDN router, etc.) want to communicate to a SDN
controller, they need to be authenticated and authorized. This
process will avoid the propagation of attacks on the whole SDN based
infrastructure by preventing unauthenticated and unauthorized access
to a centralized SDN controller and as a result to the network
devices. The existing authentication scheme used in SDN solution is
based on TLS certificates.
The problem with the use of self-signed certificates is the spoofing
attack at the beginning of the TLS establishments. In case the
certificates are introduced to both SDN components, the problem is
key management and scalability of such solution.
The use of the existing public CA solves the scalability and key
Rafiee & Petrescu Expires December 6, 2015 [Page 3]
INTERNET DRAFT SDNauth usecases June 6, 2015
management problem but this approach doesn't fit to the nature of a
SDN solution. This is because, if the private key of a CA is
compromised, then it might affect all SDN based infrastructure that
has their certificates signed by the compromised CA which may result
in serious damages on the operators' networks. One solution would be
the use of local PKI models. This solution will reduce the range of
attacks to a limited scope such as only one operator but cannot
completely eliminate such attacks. Therefore, improving the
authentication model of SDN components and reduce the range of
attacks as much as possible is demanding and this is what this group
wants to address.
Furthermore, an operator might have distributed SDN controllers (each
does different task) in different data centers that these SDN
controllers belong to a vendor or there might be a case where an
operator received its service from different vendors but wants to
have overall information about its network. There might be also a
case where SDN controllers belong to multi-operators. Therefore, the
communications of these SDN controllers is one of the requirements
for such distributed networks. At the moment, there is a lack of
standard communication protocols for the communication of two SDN
controllers for exchanging topology information or any other
information which is demanding.
Since the security of a SDN controller is really important. Having a
single point of communication to a SDN controller reduces the range
of attacks on a SDN controller. Therefore, the mediator service can
be used to handle these communications among SDN controllers together
and applications to SDN controllers. Since there is no standard model
for this communication, this document introduces some use case
scenarios for the communication of two SDN controller.
This document addresses the following problems:
- Requirements for a secure authentication model for a SDN based
solution
- Secure communications of a mediator service to apps that belong to
different operators and running on different data centers
- Secure communications of SDN controllers to exchange different
information such as topology, user session, etc.
3. Use cases
The following subsections explain example use case scenarios that
SDNAuth can address.
3.1. User movements in carrier WiFi networks
User A belongs to operator A network. It authenticates to the WiFi
Rafiee & Petrescu Expires December 6, 2015 [Page 4]
INTERNET DRAFT SDNauth usecases June 6, 2015
interface in its home network (The protocol might be EAP and RADIUS).
It moves to a new place that is in the domain of operator B. Operator
A does not provide any service there but there is an agreement
between these two operators so that user A can connect to this
network. Operator B can define different access control for this
guest user so that this user receives similar service as it had in
its home network. This involves too much administrative works and it
is a time consuming process. Here the purpose is to improve this
process and reduce human interaction as much as possible by the use
of SDN solution. Therefore, the purpose is to offer an improved model
for this scenario via the communications of SDN controllers and
exchanging user information and user session data.
3.2. Limited UI devices connections to public hotspot areas
A growing number of constrained devices are equipped with WiFi
interfaces. But since they are not featuring full-blown User
Interfaces traditionally used in larger devices (screens and
keyboards on smartphones, tablets, PCs) these devices can connect to
WiFi Access Points only by using pre-configured WiFi parameters, like
the "ESSID" and network passwords. The pre-configuration operation
involves using a smartphone or other device carrying a full UI.
Under mobility conditions, it would be very difficult to manually
re-configure these parameters such as to connect to public WiFi
hotspots. It is impossible to stop by and and re-set the ESSID on a
smartwatch without much additional effort.
Other use-case involves devices requiring continuous Internet
connection during mobility. For example, a multimedia personal device
(mp3 player) needs to stream content from a server while the person
moves from one hotspot to another. On these devices it is very
difficult to re-set the ESSID and password at each public WiFi
hotspot.
Finally, On-Board Units carried by automobiles also need to connect
to public WiFi hotspots. Whereas OBUs may be easily equipped with
large screens and keyboards, the driver is forbidden from using these
while driving the automobile - safety first. In this situation again,
it is impossible to manually change the ESSID and password when
moving from one public WiFi hotspot to another.
It should be mentioned that ESSID and password are given only as
examples of parameters which need to be re-configured in mobility
situations from one public WiFi hotspot to another. Since WiFi
Broadband Alliance (WBA) tries to improve the user authentication and
Rafiee & Petrescu Expires December 6, 2015 [Page 5]
INTERNET DRAFT SDNauth usecases June 6, 2015
the purpose is to limit the use of web portals, this document only
focuses on ESSID/passwords or similar authentication techniques but
not web portals.
Therefore, this problem can be solved by the use of SDN solution and
the communication of SDN controllers can provide the authenticator
application with the new place of this user and can assist in this
scenario by exchanging information about the user's session.
3.3. Distributed SDN controllers
Tenant A has a distributed networks in two different data centers
that each is under the control of different SDN controller. Tenant A
wants to have overview of the overall network topology. At the moment
there is no possibility to exchange data among these SDN controllers.
Using a mediator service might help this process but lack of standard
structure for the communication of this mediator service to different
SDN controllers leads to complexity in deployment of such mediator.
This is what SDNauth plans to address by offering a simple model for
this mediator and divide its tasks to different applications so that
the existing implementation of different protocols still can be used.
4. Requirements
This section defines the scope of this document and introduces the
requirement.
[1] A standard structure for the communications of two SDN
controllers via mediator service and the applications (e.g. RADIUS)
[2] To reduce human interactions and reduce time to receive service
for users
[3] To provide the user with similar access control as it had in its
home network while by default some services might not be available in
its visited network (e.g. VoIP)
[4] It needs to provide an improved authentication model for the
authentication of different SDN components such as applications to
mediator, etc. to facilitate the authentication of application A from
domain A to a mediator service in domain B. (a improved SDN based
PKI)
[5] It needs to provide high security and privacy especially for end
systems
[6] It needs to support different clients with different resources
(Memory, Battery, CPU, etc.) -- Laptops, IPod, Smartphone, etc.
Good performance for constrained devices.
Rafiee & Petrescu Expires December 6, 2015 [Page 6]
INTERNET DRAFT SDNauth usecases June 6, 2015
[7] It needs to be backward compatible by the possibility to re-use
the existing protocols while at the same time keep the mediator
service so simple.
5. Security Considerations
There is no security consideration
6. IANA Considerations
There is no IANA consideration
7. Acknowledgements
The authors would like to thank people who helped to improve this
work.
8. References
8.1. Normative References
[RFC2865] Rigney, C., Willens, S., Rubens, A., Simpson, W.,
" Remote Authentication Dial In User Service (RADIUS)",RFC
2865, June 2000
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., Zorn, G.,
"Diameter Base Protocol" RFC 6733, October 2012.
[RFC7426] Haleplidis, E., Pentikousis , K., Denazis , S.,
Hadi Salim, J., Meyer, D., Koufopavlou , O.,
"Software-Defined Networking (SDN): Layers and Architecture
Terminology", RFC 7426, January 2015
[1] Haleplidis, E., Pentikousis , K., Denazis , S., Hadi Salim,
J., Meyer, D., Koufopavlou , O., "Software-Defined Networking
(SDN): Layers and Architecture Terminology", RFC 7426, January
2015
[2] Kreutz, D., Ramos, F.M.V., Esteves Verissimo, P., Esteve
Rothenberg, C., "Software-Defined Networking: A Comprehensive
Survey", DOI: 10.1109/JPROC.2014.2371999 , January 2015
Rafiee & Petrescu Expires December 6, 2015 [Page 7]
INTERNET DRAFT SDNauth usecases June 6, 2015
Rafiee & Petrescu Expires December 6, 2015 [Page 8]
INTERNET DRAFT SDNauth usecases June 6, 2015
Authors' Addresses
Hosnieh Rafiee
Huawei
Munich, Germany
Phone: +49 (0)162 204 74 58
E-mail: ietf@rozanak.com
Alexandru Petrescu
Email: alexandru.petrescu@gmail.com
Rafiee & Petrescu Expires December 6, 2015 [Page 9]