PCP T. Reddy Internet-Draft P. Patil Intended status: Standards Track Cisco Expires: June 18, 2015 M. Boucadair France Telecom December 15, 2014 PCP Firewall Control in Managed Networks draft-reddy-pcp-sdn-firewall-00 Abstract In the context of ongoing efforts to add more automation and promote means to dynamically interact with network resources, e.g., SDN- labeled efforts, various proposals are made to accommodate the needs of Network Providers to program the network with flow information. This document describes a means for an SDN controller to install firewall rules using the Port Control Protocol (PCP). 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 June 18, 2015. Copyright Notice Copyright (c) 2014 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 Reddy, et al. Expires June 18, 2015 [Page 1] Internet-Draft SDN controlled PCP firewall December 2014 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Cloud conferencing server . . . . . . . . . . . . . . . . 3 1.2. TURN server . . . . . . . . . . . . . . . . . . . . . . . 4 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 3. TSELECT OPCODE . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. TSELECT OpCode Packet Format . . . . . . . . . . . . . . 4 3.2. Generating a TSELECT Request . . . . . . . . . . . . . . 6 3.3. Processing a TSELECT Request . . . . . . . . . . . . . . 6 3.4. Processing a TSELECT Response . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction All modern firewalls allow an administrator to change the policies in the firewall devices, although the ease of administration for making those changes, and the granularity of the policies, vary widely between firewalls and vendors. With the advent of Software-Defined Networking (SDN), which is a new approach for network programmability, it becomes important to have a means to program these firewalls in a generic fashion. Network programmability in the context of a firewall refers to the capacity to initialize, control, change, and manage firewall policies dynamically via open interfaces as opposed to relying on closed-box solutions and their associated proprietary interfaces. The Port Control Protocol (PCP) [RFC6887] provides a mechanism to control how incoming packets are forwarded by upstream devices such as Network Address Translator IPv6/IPv4 (NAT64), Network Address Translator IPv4/IPv4 (NAT44), and IPv6 and IPv4 firewall devices. PCP can be leveraged to program firewalls, for example, from an SDN controller using standardized mechanisms. Existing PCP methods, such as PCP THIRD PARTY OPTION, can be used to install firewall rules, but current PCP methods only allow to create firewall rules on a per-user basis. This document proposes a new PCP OPCODE to accommodate generic firewall based on standard traffic Reddy, et al. Expires June 18, 2015 [Page 2] Internet-Draft SDN controlled PCP firewall December 2014 selectors as described in [RFC6088]. Note, PCP MAP/PEER OpCodes can be used to achieve basic firewall control functionalities, but advanced functionalities are not supported in [RFC6887]. Concretely,[I-D.boucadair-pcp-sfc-classifier-control] identifies some missing PCP features to address the firewall control needs: (1) Extended THIRD_PARTY option to include a L2 identifier (e.g., MAC address), an opaque subscriber-identifier, an IMSI, etc.; (2) Extended FILTER to include a remote range of ports; and (3) DSCP- based filtering. The encoding in Section 3 and the support of the THIRD_PARTY_ID ([I-D.ripke-pcp-tunnel-id-option]) covers most of these functionalities. PCP extensions in this document can be used in non-SDN contexts such as managed networks. The following use-cases describe the need for SDN controlled firewalls. 1.1. Cloud conferencing server In the field of real-time conferencing there is a transformation towards cloud-based, virtualized and software based conferencing server implementations. The trend of using virtualized cloud-based services (e.g., conferencing) has a number of positive effects on flexibility, CAPEX, ease of use, etc. One enabling factor for cloud conferencing server is the increased capabilities of the end-points that allow them to decode and process multiple simultaneously received media streams. This in turn has made the central conferring media nodes to switch from mixing or composing media in the decoded domain to instead perform the much less heavy-weight operation of selection, switching and forwarding of media streams, at least for video. Cloud conferencing server typically supports Interactive Connectivity Establishment (ICE) [RFC5245] or at a minimum supports the ICE LITE functionality as described in section 2.7 of [RFC5245]. A cloud conferencing server can terminate ICE and thus have two ICE contexts with either endpoints. The reason for ICE termination is the need for cloud conferencing server to be in the media path. Cloud conferencing server advertises support for ICE in offer/answer and includes its candidates of different types for each component of each media stream. Enterprise leveraging cloud conferencing server may have a restricted firewall policy to only permit UDP traffic to cloud conferencing provided candidate addresses. The problem is that these candidate addresses could keep changing causing the firewall policy to be frequently modified with human intervention. This problem can be solved by the cloud conferencing server communicating its media candidate addresses to the SDN controller in the enterprise network through a cloud connector and the SDN controller in-turn configures Reddy, et al. Expires June 18, 2015 [Page 3] Internet-Draft SDN controlled PCP firewall December 2014 enterprise firewalls using PCP to permit UDP traffic to the cloud conferencing provided candidate addresses. 1.2. TURN server Traversal Using Relay NAT (TURN) [RFC5766] is a protocol that is often used to improve the connectivity of Peer-to-Peer (P2P) applications. TURN allows a connection to be established when one or both sides is incapable of a direct P2P connection. The TURN server is a building block to support interactive, real-time communication using audio, video, collaboration, games, etc., between two peer web browsers using the Web Real-Time Communication (WebRTC) framework explained in [I-D.ietf-rtcweb-overview]. A TURN server could be provided by an enterprise network, an access network, an application service provider or a third party provider. Enterprise that has business agreement with an application or third party provider hosting TURN servers may have a firewall policy to only permit UDP traffic to the external TURN servers provided by the application or third party provider. But the problem is that these TURN addresses could keep changing resulting in the firewall rules to be frequently modified with human intervention. This problem can be solved by the provider hosting the TURN servers to communicate the TURN server IP addresses to the SDN controller deployed in the enterprise network through a cloud connector and the SDN controller in-turn configures enterprise firewalls using PCP to permit UDP traffic to the TURN servers. 2. Notational Conventions 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]. 3. TSELECT OPCODE 3.1. TSELECT OpCode Packet Format Figure 1 shows the format of the TSELECT Opcode-specific information. Reddy, et al. Expires June 18, 2015 [Page 4] Internet-Draft SDN controlled PCP firewall December 2014 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Mapping Nonce (96 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TS Format | Direction | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Traffic Selector ... | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: TSELECT Opcode Request The fields are described below: Requested/Assigned lifetime (in common header): Requested lifetime of this firewall control rule entry, in seconds, in a request or assigned lifetime of this entry, in seconds, in a response . The value 0 indicates "delete". Mapping Nonce: Random value chosen by the PCP client. Mapping Nonce MUST be copied and returned by the PCP server in a response. TS Format: An 8-bit unsigned integer indicating the Traffic Selector Format. Value "0" is reserved and MUST NOT be used. The values for that field are defined in Section 3 of [RFC6088] and are repeated here for completeness. * When the value of the TS Format field is set to (1), the format that follows is the IPv4 binary traffic selector specified in Section 3.1 of [RFC6088]. * When the value of the TS Format field is set to (2), the format that follows is the IPv6 binary traffic selector specified in Section 3.2 of [RFC6088]. Direction: * 0 indicates outbound direction for traffic selector rule. * 1 indicates inbound direction for traffic selector rule. * 2 indicates inbound and outbound direction for traffic selector rule. Reddy, et al. Expires June 18, 2015 [Page 5] Internet-Draft SDN controlled PCP firewall December 2014 Reserved: 16 reserved bits, MUST be sent as 0 and MUST be ignored when received. Traffic Selector: The traffic selector defined in [RFC6088] is mandatory to implement. 3.2. Generating a TSELECT Request The PCP client, first does all processing described in Section 8.1 of [RFC6887]. It then includes the TSELECT OPCODE. The Mapping Nonce value is randomly chosen by the PCP client, following accepted practices for generating unguessable random numbers [RFC4086], and is used as part of the validation of PCP responses by the PCP client, and validation for mapping refreshes by the PCP server. The PCP client MUST use a different mapping nonce for each PCP server it communicates with, and it is RECOMMENDED to choose a new random mapping nonce whenever the PCP client is initialized. The client MAY use a different mapping nonce for every mapping. 3.3. Processing a TSELECT Request The PCP server performs processing in the order of the paragraphs below. Upon receiving a PCP request with the TSELECT opcode, the PCP server performs the processing described in Section 8.2 of [RFC6887]. If the PCP server can accommodate the request as described in the TSELECT request, it sends a PCP response with the SUCCESS response else returns a failure response with the appropriate error code. Discussion: How to deal with overlap in traffic selector rules ? 3.4. Processing a TSELECT Response Upon receiving a TSELECT response, the PCP client performs the normal processing described in Section 8.3 of [RFC6887]. 4. IANA Considerations In order to identify TSELECT Opcode, a new value (TBD) needs to be defined in the IANA registry for PCP Opcodes. Reddy, et al. Expires June 18, 2015 [Page 6] Internet-Draft SDN controlled PCP firewall December 2014 5. Security Considerations Only certain users or certain applications can be authorized to signal TSELECT request. This authorization can be achieved using PCP authentication [I-D.ietf-pcp-authentication]. PCP authentication must be used for mutual authentication between the application signaling TSELECT request and the PCP-aware firewall. Without this authentication enabled, the TSELECT request is open for attacks with fake applications falsely claiming to be legitimate applications that require special treatment, i.e., the firewall infrastructure is at risk of being misused. Should the firewall be spoofed, applications could be misled that the firewall has successfully processed the PCP request. 6. Acknowledgements Thanks to Dan wing for valuable inputs and comments. 7. References 7.1. Normative References [I-D.ietf-pcp-authentication] Wasserman, M., Hartman, S., Zhang, D., and T. Reddy, "Port Control Protocol (PCP) Authentication Mechanism", draft- ietf-pcp-authentication-06 (work in progress), October 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, January 2011. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013. Reddy, et al. Expires June 18, 2015 [Page 7] Internet-Draft SDN controlled PCP firewall December 2014 7.2. Informative References [I-D.boucadair-pcp-sfc-classifier-control] Boucadair, M., "PCP as a Traffic Classifier Control Protocol", draft-boucadair-pcp-sfc-classifier-control-01 (work in progress), October 2014. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-13 (work in progress), November 2014. [I-D.ripke-pcp-tunnel-id-option] Ripke, A., Dietz, T., Quittek, J., and R. Silva, "PCP Third Party ID Option", draft-ripke-pcp-tunnel-id- option-02 (work in progress), October 2014. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. Authors' Addresses Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India Email: tireddy@cisco.com Prashanth Patil Cisco Systems, Inc Bangalore India Email: praspati@cisco.com Mohamed Boucadair France Telecom Rennes 35000 France Email: mohamed.boucadair@orange.com Reddy, et al. Expires June 18, 2015 [Page 8]