idnits 2.17.1 draft-patil-pcp-multihoming-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 (October 11, 2012) is 4213 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) == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-28 == Outdated reference: A later version (-13) exists of draft-ietf-pcp-dhcp-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP Working Group P. Patil 3 Internet-Draft T. Reddy 4 Intended status: Standards Track R. Penno 5 Expires: April 14, 2013 D. Wing 6 Cisco 7 October 11, 2012 9 Using PCP to control NAT and Firewalls in Multihoming 10 draft-patil-pcp-multihoming-00 12 Abstract 14 This note describes how Port Control Protocol (PCP) can be used to 15 control NATs and Firewalls in multihoming deployments. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 14, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. IPv6 Multihoming . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. IPv4 Multihoming . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. Other Multihoming use cases . . . . . . . . . . . . . . . . . . 5 56 5.1. IPv6 Network-Managed Firewall . . . . . . . . . . . . . . . 6 57 5.2. IPv4 Policy based Routing . . . . . . . . . . . . . . . . . 7 58 6. Multiple interfaces and Servers . . . . . . . . . . . . . . . . 7 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 63 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 A host can use the Port Control Protocol (PCP) to flexibly manage the 69 IP address and port mapping information on Network Address 70 Translators (NATs) or firewalls, to facilitate communications with 71 remote hosts. In a multihomed network, there may be multiple PCP 72 servers providing Firewall or prefix translation functions to hosts 73 in the network. 75 This document covers PCP related considerations in IPv4 and IPv6 76 multihomed networks. 78 2. Problem Statement 80 The main problem of a PCP multihoming situation can be succintly 81 described as 'one client, multiple servers'. PCP-base 82 [I-D.ietf-pcp-base] does not address how a PCP Client should behave 83 in a situation when it discovers multiple PCP Servers and therefore 84 many questions are open to standardization. For example, if multiple 85 PCP Servers are discovered through the same interface, should the 86 client send PCP requests be sent to all of them? Are there 87 significant differences between a multihoming and high-availability 88 scenarios? If yes, how can a PCP Client determine one versus the 89 other. These are just a few questions related to the problem. 91 In this document we make the following simplifying assumption: 93 o Whenever a PCP Client discovers multiple PCP Servers, it will send 94 requests to all of them in parallel as described in 95 [I-D.boucadair-pcp-server-selection]. 97 o There is no requirement that multiple PCP Servers have the same 98 capabilities. 100 o PCP Requests to different servers are independent, meaning that 101 the result of a PCP request to one server does not influence 102 another. 104 o If PCP Servers provides NAT, it is out of scope how the client 105 manages ports across PCP Servers. For example, whether PCP Client 106 requires all external ports to be the same or whether there are 107 ports available at all. 109 In all scenarios below PCP client has a single interface unless 110 explicitly noted otherwise. 112 3. IPv6 Multihoming 114 In an IPv6 multihomed network, two or more routers co-located with 115 firewalls are present on a single link shared with the host(s). Each 116 router is in turn connected to a different service provider network 117 and the host in this environment would be offered multiple prefixes 118 and advertised multiple DNS/NTP servers. Consider a scenario in 119 which firewalls within an IPv6 multihoming environment also implement 120 a PCP Server. PCP client learns of the available PCP servers by 121 using DHCP [I-D.ietf-pcp-dhcp] or any other PCP server discovery 122 technique defined in future specifications. The PCP client will send 123 PCP requests in parallel to each of the PCP Servers as described in 124 [I-D.boucadair-pcp-server-selection]. 126 ================== 127 | Internet | 128 ================== 129 | | 130 | | 131 +----+-+ +-+----+ 132 | ISP1 | | ISP2 | 133 +----+-+ +-+----+ ISP Network 134 | | 135 ......................................................... 136 | | 137 | | Subscriber Network 138 +-------+---+ +----+------+ 139 | rtr1 with | | rtr2 with | 140 | FW1 | | FW2 | 141 +-------+---+ +----+------+ 142 | | 143 | | 144 | | 145 -----+-+-----+------ 146 | 147 +-+-----+ 148 | Hosts | 149 +-------+ 151 Figure 1: IPv6 Multihoming 153 4. IPv4 Multihoming 155 In an IPv4 multihomed network, the gateway router is connected to 156 different service provider networks. The host is connected to the 157 gateway router and is given a private IPv4 address oblivious to the 158 fact that there are multiple service providers. The Gateway router 159 will be configured with multiple PCP proxy servers, each 160 corresponding to an upstream PCP server. Each PCP Server is 161 announced independently since it is within a different ISP. PCP 162 client can learn these multiple PCP proxy addresses using DHCP or any 163 other PCP server discovery technique. The PCP client, by sending PCP 164 requests in parallel to both the PCP proxies, will learn the external 165 IP addresses and ports allocated by each of the upstream PCP servers. 166 The Gateway router which implements a PCP Proxy [I-D.bpw-pcp-proxy] , 167 creates local NAT state, modifies the PCP request and forwards it to 168 the PCP server. The incoming PCP response will be updated by the PCP 169 Proxy and forwarded to the PCP client. 171 ==================== 172 | Internet | 173 ===================== 174 | | 175 | | 176 +----+--------+ +-+------------+ 177 | ISP1 | | ISP2 | 178 | PCP ServerA | | PCP ServerB | 179 +----+--------+ +-+------------+ ISP Network 180 | | 181 | | 182 .............................................................. 183 | | 184 | Port1 | Port2 Subscriber Network 185 | | 186 +----+-----------------+ 187 | NAPT & PCP Proxy | 188 | GW Router | 189 +----+-----------------+ 190 | 191 | 192 | 193 -----+-+-----+------ 194 | 195 +-+-----+ 196 | Hosts | (private address space) 197 +-------+ 199 Figure 2: IPv4 Multihomed environment with Gateway Router performing 200 NAPT 202 5. Other Multihoming use cases 203 5.1. IPv6 Network-Managed Firewall 205 A network-managed Firewall uses the same techniques as the premises- 206 based firewall, but the firewall service is delivered using a 207 security appliance positioned in the ISP. The requesting router in 208 customer premises may obtain the PCP server addresses from the ISP 209 delegating router, and then pass that configuration information on to 210 the PCP clients through a DHCP server in the requesting router in the 211 customer premises. The PCP client can also learn PCP servers using 212 other PCP server discovery techniques. Each PCP Server is announced 213 independently since it is within a different ISP. 214 ==================== 215 | Internet | 216 ===================== 217 | | 218 | | 219 +----+------+ +-+---------+ 220 | | | | 221 | ISP1 with | | ISP2 with | 222 | FW1 | | FW2 | 223 +----+------+ +-+---------+ ISP Network 224 | | 225 ............................................................ 226 | | 227 | Port1 | Port2 Subscriber Network 228 | | 229 +----+-----------------+ 230 | Gateway | 231 | Router | 232 +----+-----------------+ 233 | 234 | 235 | 236 -----+-+-----+------ 237 | 238 +-+-----+ 239 | Hosts | 240 +-------+ 242 Figure 3: Network-Managed Firewall 244 When the PCP client sends a PCP request to the PCP server deployed in 245 the ISP and the source address of the PCP request is not the one that 246 is delegated by the upstream ISP, then that PCP request will be 247 dropped at the ISP by its ingress filter rule. Ingress filtering is 248 becoming more popular among ISPs to mitigate the damage of denial-of- 249 service (DoS) attacks as explained in section 2.1.2 of [RFC5220]. In 250 IPv6 multihoming the PCP client will eventually learn that the PCP 251 server responds to only PCP requests with specific source address 252 after few attempts and hence can discard sending PCP requests with 253 wrong source address to the PCP server provided by the ISP. 255 5.2. IPv4 Policy based Routing 257 Policy based Routing (PBR) with multi-homing is typically used in 258 enterprises to route packets from the same source IP address to 259 different ISP based on configuration policies and match conditions 260 based on source IP address, destination IP address, destination port, 261 DSCP value(s), L4 and L7 protocols (e.g., SIP, RTP, RTSP) etc. For 262 e.g. a site with Dual WAN connections Gold-ISP, Bronze-ISP and uses 263 Gold-ISP for certain traffic only (e.g. Media). In such a 264 environment NAT has different NAT pools and would rely on pre- 265 configured PBR policy to determine which NAT address pool to use when 266 an IP packet comes from an internal host. PCP allows a host to 267 interact with a PCP-controlled NAT device and request an external IP 268 and port. Therefore a PCP Server that controls the NAT device with 269 PBR and receives a PCP request from a PCP client needs to know from 270 which NAT pool to allocate an external IP address and port. 272 The PCP PEER request would contain the destination IP address, 273 destination port and transport protocol of the remote peer that the 274 PCP client will be trying to communicate with. The PCP MAP request 275 with FILTER option would also contain the destination IP address, 276 transport port but the destination port could be all ports. The NAT 277 device based on the information present in the PCP request can 278 possibly select the NAT pool, create mapping and return the external 279 IP address and port in PCP response. 281 There is also a possibility that PBR is determined based on other 282 information like L7 protocol, DSCP value(s) that is not conveyed by 283 default in the PCP PEER or MAP with FILTER option. Further In case 284 of PCP MAP request with just the 3-tuple information (internal port, 285 protocol and source IP address), the NAT device does not know which 286 NAT pool to use. Hence if the information conveyed in PCP request is 287 not sufficient to execute the policy then the PCP server will return 288 a new error code (PROVIDE_MORE_DATA) in the PCP response to the PCP 289 client asking it to provide additional information in subsequent PCP 290 requests. The PCP client can then convey more information like 291 DESCRIPTION, DSCP_POLICY using the PCP extensions defined in 292 [I-D.boucadair-pcp-extensions]. 294 6. Multiple interfaces and Servers 296 One interesting case for PCP multi-homing is when a end host such as 297 a mobile terminal has multiple interfaces concurrently active, for 298 example, Wi-Fi and 3G. In this case PCP client would discover 299 different PCP Servers over different interfaces. Although multiple 300 interfaces are available, an application might choose to use just one 301 based on, for example, bandwidth requirements, and therefore would 302 need to send PCP requests to just one PCP Server. 304 This scenario requires further discussion. TBD 306 7. Security Considerations 308 Security considerations in [I-D.ietf-pcp-base] apply to this use. 310 8. IANA Considerations 312 The following PCP result code is to be allocated : PROVIDE_MORE_DATA 314 9. References 316 9.1. Normative References 318 [I-D.boucadair-pcp-extensions] 319 Boucadair, M., Penno, R., and D. Wing, "Some Extensions to 320 Port Control Protocol (PCP)", 321 draft-boucadair-pcp-extensions-03 (work in progress), 322 April 2012. 324 [I-D.boucadair-pcp-server-selection] 325 Boucadair, M., Penno, R., and D. Wing, "PCP Server 326 Selection", draft-boucadair-pcp-server-selection-00 (work 327 in progress), September 2012. 329 [I-D.bpw-pcp-proxy] 330 Boucadair, M., Penno, R., Wing, D., and F. Dupont, "Port 331 Control Protocol (PCP) Proxy Function", 332 draft-bpw-pcp-proxy-02 (work in progress), September 2011. 334 [I-D.ietf-pcp-base] 335 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 336 Selkirk, "Port Control Protocol (PCP)", 337 draft-ietf-pcp-base-28 (work in progress), October 2012. 339 [I-D.ietf-pcp-dhcp] 340 Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 341 the Port Control Protocol (PCP)", draft-ietf-pcp-dhcp-05 342 (work in progress), September 2012. 344 9.2. Informative References 346 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 347 "Problem Statement for Default Address Selection in Multi- 348 Prefix Environments: Operational Issues of RFC 3484 349 Default Rules", RFC 5220, July 2008. 351 Authors' Addresses 353 Prashanth Patil 354 Cisco Systems, Inc. 355 Cessna Business Park, Varthur Hobli 356 Sarjapur Marthalli Outer Ring Road 357 Bangalore, Karnataka 560103 358 India 360 Email: praspati@cisco.com 362 Tirumaleswar Reddy 363 Cisco Systems, Inc. 364 Cessna Business Park, Varthur Hobli 365 Sarjapur Marathalli Outer Ring Road 366 Bangalore, Karnataka 560103 367 India 369 Email: tireddy@cisco.com 371 Reinaldo Penno 372 Cisco Systems, Inc. 373 170 West Tasman Drive 374 San Jose, California 95134 375 USA 377 Email: repenno@cisco.com 379 Dan Wing 380 Cisco Systems, Inc. 381 170 West Tasman Drive 382 San Jose, California 95134 383 USA 385 Email: dwing@cisco.com