SDNAuth H. Rafiee INTERNET-DRAFT A. Petrescu Intended Status: Informational Expires: December 6, 2015 June 6, 2015 SDNauth Usecases and Requirements 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]