idnits 2.17.1 draft-reddy-pcp-sdn-firewall-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 15, 2014) is 3420 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.boucadair-pcp-sfc-classifier-control' is defined on line 329, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-pcp-authentication-06 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-13 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP T. Reddy 3 Internet-Draft P. Patil 4 Intended status: Standards Track Cisco 5 Expires: June 18, 2015 M. Boucadair 6 France Telecom 7 December 15, 2014 9 PCP Firewall Control in Managed Networks 10 draft-reddy-pcp-sdn-firewall-00 12 Abstract 14 In the context of ongoing efforts to add more automation and promote 15 means to dynamically interact with network resources, e.g., SDN- 16 labeled efforts, various proposals are made to accommodate the needs 17 of Network Providers to program the network with flow information. 18 This document describes a means for an SDN controller to install 19 firewall rules using the Port Control Protocol (PCP). 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 18, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Cloud conferencing server . . . . . . . . . . . . . . . . 3 57 1.2. TURN server . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 59 3. TSELECT OPCODE . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. TSELECT OpCode Packet Format . . . . . . . . . . . . . . 4 61 3.2. Generating a TSELECT Request . . . . . . . . . . . . . . 6 62 3.3. Processing a TSELECT Request . . . . . . . . . . . . . . 6 63 3.4. Processing a TSELECT Response . . . . . . . . . . . . . . 6 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 7.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 All modern firewalls allow an administrator to change the policies in 75 the firewall devices, although the ease of administration for making 76 those changes, and the granularity of the policies, vary widely 77 between firewalls and vendors. With the advent of Software-Defined 78 Networking (SDN), which is a new approach for network 79 programmability, it becomes important to have a means to program 80 these firewalls in a generic fashion. Network programmability in the 81 context of a firewall refers to the capacity to initialize, control, 82 change, and manage firewall policies dynamically via open interfaces 83 as opposed to relying on closed-box solutions and their associated 84 proprietary interfaces. 86 The Port Control Protocol (PCP) [RFC6887] provides a mechanism to 87 control how incoming packets are forwarded by upstream devices such 88 as Network Address Translator IPv6/IPv4 (NAT64), Network Address 89 Translator IPv4/IPv4 (NAT44), and IPv6 and IPv4 firewall devices. 90 PCP can be leveraged to program firewalls, for example, from an SDN 91 controller using standardized mechanisms. 93 Existing PCP methods, such as PCP THIRD PARTY OPTION, can be used to 94 install firewall rules, but current PCP methods only allow to create 95 firewall rules on a per-user basis. This document proposes a new PCP 96 OPCODE to accommodate generic firewall based on standard traffic 97 selectors as described in [RFC6088]. Note, PCP MAP/PEER OpCodes can 98 be used to achieve basic firewall control functionalities, but 99 advanced functionalities are not supported in [RFC6887]. 100 Concretely,[I-D.boucadair-pcp-sfc-classifier-control] identifies some 101 missing PCP features to address the firewall control needs: (1) 102 Extended THIRD_PARTY option to include a L2 identifier (e.g., MAC 103 address), an opaque subscriber-identifier, an IMSI, etc.; (2) 104 Extended FILTER to include a remote range of ports; and (3) DSCP- 105 based filtering. The encoding in Section 3 and the support of the 106 THIRD_PARTY_ID ([I-D.ripke-pcp-tunnel-id-option]) covers most of 107 these functionalities. 109 PCP extensions in this document can be used in non-SDN contexts such 110 as managed networks. The following use-cases describe the need for 111 SDN controlled firewalls. 113 1.1. Cloud conferencing server 115 In the field of real-time conferencing there is a transformation 116 towards cloud-based, virtualized and software based conferencing 117 server implementations. The trend of using virtualized cloud-based 118 services (e.g., conferencing) has a number of positive effects on 119 flexibility, CAPEX, ease of use, etc. One enabling factor for cloud 120 conferencing server is the increased capabilities of the end-points 121 that allow them to decode and process multiple simultaneously 122 received media streams. This in turn has made the central conferring 123 media nodes to switch from mixing or composing media in the decoded 124 domain to instead perform the much less heavy-weight operation of 125 selection, switching and forwarding of media streams, at least for 126 video. Cloud conferencing server typically supports Interactive 127 Connectivity Establishment (ICE) [RFC5245] or at a minimum supports 128 the ICE LITE functionality as described in section 2.7 of [RFC5245]. 129 A cloud conferencing server can terminate ICE and thus have two ICE 130 contexts with either endpoints. The reason for ICE termination is 131 the need for cloud conferencing server to be in the media path. 132 Cloud conferencing server advertises support for ICE in offer/answer 133 and includes its candidates of different types for each component of 134 each media stream. 136 Enterprise leveraging cloud conferencing server may have a restricted 137 firewall policy to only permit UDP traffic to cloud conferencing 138 provided candidate addresses. The problem is that these candidate 139 addresses could keep changing causing the firewall policy to be 140 frequently modified with human intervention. This problem can be 141 solved by the cloud conferencing server communicating its media 142 candidate addresses to the SDN controller in the enterprise network 143 through a cloud connector and the SDN controller in-turn configures 144 enterprise firewalls using PCP to permit UDP traffic to the cloud 145 conferencing provided candidate addresses. 147 1.2. TURN server 149 Traversal Using Relay NAT (TURN) [RFC5766] is a protocol that is 150 often used to improve the connectivity of Peer-to-Peer (P2P) 151 applications. TURN allows a connection to be established when one or 152 both sides is incapable of a direct P2P connection. The TURN server 153 is a building block to support interactive, real-time communication 154 using audio, video, collaboration, games, etc., between two peer web 155 browsers using the Web Real-Time Communication (WebRTC) framework 156 explained in [I-D.ietf-rtcweb-overview]. A TURN server could be 157 provided by an enterprise network, an access network, an application 158 service provider or a third party provider. 160 Enterprise that has business agreement with an application or third 161 party provider hosting TURN servers may have a firewall policy to 162 only permit UDP traffic to the external TURN servers provided by the 163 application or third party provider. But the problem is that these 164 TURN addresses could keep changing resulting in the firewall rules to 165 be frequently modified with human intervention. This problem can be 166 solved by the provider hosting the TURN servers to communicate the 167 TURN server IP addresses to the SDN controller deployed in the 168 enterprise network through a cloud connector and the SDN controller 169 in-turn configures enterprise firewalls using PCP to permit UDP 170 traffic to the TURN servers. 172 2. Notational Conventions 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in [RFC2119]. 178 3. TSELECT OPCODE 180 3.1. TSELECT OpCode Packet Format 182 Figure 1 shows the format of the TSELECT Opcode-specific information. 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | | 188 | Mapping Nonce (96 bits) | 189 | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | TS Format | Direction | Reserved | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | | 194 | Traffic Selector ... | 195 | | 196 | | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 1: TSELECT Opcode Request 201 The fields are described below: 203 Requested/Assigned lifetime (in common header): Requested lifetime 204 of this firewall control rule entry, in seconds, in a request or 205 assigned lifetime of this entry, in seconds, in a response . The 206 value 0 indicates "delete". 208 Mapping Nonce: Random value chosen by the PCP client. Mapping Nonce 209 MUST be copied and returned by the PCP server in a response. 211 TS Format: An 8-bit unsigned integer indicating the Traffic Selector 212 Format. Value "0" is reserved and MUST NOT be used. The values 213 for that field are defined in Section 3 of [RFC6088] and are 214 repeated here for completeness. 216 * When the value of the TS Format field is set to (1), the format 217 that follows is the IPv4 binary traffic selector specified in 218 Section 3.1 of [RFC6088]. 220 * When the value of the TS Format field is set to (2), the format 221 that follows is the IPv6 binary traffic selector specified in 222 Section 3.2 of [RFC6088]. 224 Direction: 226 * 0 indicates outbound direction for traffic selector rule. 228 * 1 indicates inbound direction for traffic selector rule. 230 * 2 indicates inbound and outbound direction for traffic selector 231 rule. 233 Reserved: 16 reserved bits, MUST be sent as 0 and MUST be ignored 234 when received. 236 Traffic Selector: The traffic selector defined in [RFC6088] is 237 mandatory to implement. 239 3.2. Generating a TSELECT Request 241 The PCP client, first does all processing described in Section 8.1 of 242 [RFC6887]. It then includes the TSELECT OPCODE. 244 The Mapping Nonce value is randomly chosen by the PCP client, 245 following accepted practices for generating unguessable random 246 numbers [RFC4086], and is used as part of the validation of PCP 247 responses by the PCP client, and validation for mapping refreshes by 248 the PCP server. 250 The PCP client MUST use a different mapping nonce for each PCP server 251 it communicates with, and it is RECOMMENDED to choose a new random 252 mapping nonce whenever the PCP client is initialized. The client MAY 253 use a different mapping nonce for every mapping. 255 3.3. Processing a TSELECT Request 257 The PCP server performs processing in the order of the paragraphs 258 below. 260 Upon receiving a PCP request with the TSELECT opcode, the PCP server 261 performs the processing described in Section 8.2 of [RFC6887]. If 262 the PCP server can accommodate the request as described in the 263 TSELECT request, it sends a PCP response with the SUCCESS response 264 else returns a failure response with the appropriate error code. 266 Discussion: How to deal with overlap in traffic selector rules ? 268 3.4. Processing a TSELECT Response 270 Upon receiving a TSELECT response, the PCP client performs the normal 271 processing described in Section 8.3 of [RFC6887]. 273 4. IANA Considerations 275 In order to identify TSELECT Opcode, a new value (TBD) needs to be 276 defined in the IANA registry for PCP Opcodes. 278 5. Security Considerations 280 Only certain users or certain applications can be authorized to 281 signal TSELECT request. This authorization can be achieved using PCP 282 authentication [I-D.ietf-pcp-authentication]. PCP authentication 283 must be used for mutual authentication between the application 284 signaling TSELECT request and the PCP-aware firewall. Without this 285 authentication enabled, the TSELECT request is open for attacks with 286 fake applications falsely claiming to be legitimate applications that 287 require special treatment, i.e., the firewall infrastructure is at 288 risk of being misused. 290 Should the firewall be spoofed, applications could be misled that the 291 firewall has successfully processed the PCP request. 293 6. Acknowledgements 295 Thanks to Dan wing for valuable inputs and comments. 297 7. References 299 7.1. Normative References 301 [I-D.ietf-pcp-authentication] 302 Wasserman, M., Hartman, S., Zhang, D., and T. Reddy, "Port 303 Control Protocol (PCP) Authentication Mechanism", draft- 304 ietf-pcp-authentication-06 (work in progress), October 305 2014. 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, March 1997. 310 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 311 (ICE): A Protocol for Network Address Translator (NAT) 312 Traversal for Offer/Answer Protocols", RFC 5245, April 313 2010. 315 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 316 Relays around NAT (TURN): Relay Extensions to Session 317 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 319 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, 320 "Traffic Selectors for Flow Bindings", RFC 6088, January 321 2011. 323 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 324 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 325 2013. 327 7.2. Informative References 329 [I-D.boucadair-pcp-sfc-classifier-control] 330 Boucadair, M., "PCP as a Traffic Classifier Control 331 Protocol", draft-boucadair-pcp-sfc-classifier-control-01 332 (work in progress), October 2014. 334 [I-D.ietf-rtcweb-overview] 335 Alvestrand, H., "Overview: Real Time Protocols for 336 Browser-based Applications", draft-ietf-rtcweb-overview-13 337 (work in progress), November 2014. 339 [I-D.ripke-pcp-tunnel-id-option] 340 Ripke, A., Dietz, T., Quittek, J., and R. Silva, "PCP 341 Third Party ID Option", draft-ripke-pcp-tunnel-id- 342 option-02 (work in progress), October 2014. 344 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 345 Requirements for Security", BCP 106, RFC 4086, June 2005. 347 Authors' Addresses 349 Tirumaleswar Reddy 350 Cisco Systems, Inc. 351 Cessna Business Park, Varthur Hobli 352 Sarjapur Marathalli Outer Ring Road 353 Bangalore, Karnataka 560103 354 India 356 Email: tireddy@cisco.com 358 Prashanth Patil 359 Cisco Systems, Inc 360 Bangalore 361 India 363 Email: praspati@cisco.com 365 Mohamed Boucadair 366 France Telecom 367 Rennes 35000 368 France 370 Email: mohamed.boucadair@orange.com