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 19, 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 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
• 1.1. Cloud conferencing server
• 1.2. TURN server
• 2. Notational Conventions
• 3. TSELECT OPCODE
• 3.1. TSELECT OpCode Packet Format
• 3.2. Generating a TSELECT Request
• 3.3. Processing a TSELECT Request
• 3.4. Processing a TSELECT Response
• 4. IANA Considerations
• 5. Security Considerations
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

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 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 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.

      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 ...                         |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+