Internet DRAFT - draft-reddy-pcp-sdn-firewall
draft-reddy-pcp-sdn-firewall
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]
