idnits 2.17.1 draft-shore-nvo3-middleboxes-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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 11, 2013) is 3970 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Shore 3 Internet-Draft No Mountain Software 4 Expires: December 13, 2013 Y. Gu 5 Huawei 6 S. Sivakumar 7 Cisco Systems 8 June 11, 2013 10 Middlebox considerations in NVO3 overlay networks 11 draft-shore-nvo3-middleboxes-00 13 Abstract 15 This document examines middlebox considerations in nvo3 overlay 16 networks. We are concerned with both the impacts of middlebox 17 presence on nvo3 overlays, and the impacts of nvo3 overlays and 18 encapsulations on middlebox function. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 13, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Middlebox function within a network . . . . . . . . . . . . . 4 56 3. Middleboxes and NVO3 . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. General considerations . . . . . . . . . . . . . . . . . . 5 58 3.2. VM mobility . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2.1. Firewalls . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2.2. Network Address Translation . . . . . . . . . . . . . 6 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 5. Informative References . . . . . . . . . . . . . . . . . . . . 9 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 65 1. Introduction 67 This document describes issues stemming from the presence of 68 middleboxes in networks where nvo3> overlay networks are present. We 69 address both the impacts of nvo overlay networks and encapsulation on 70 middlebox function, and of middlebox presence on nvo3 overlays. 72 Much has been written about middleboxes, about middlebox impacts on 73 networks and on transport and application protocols, about 74 workarounds and accommodations, etc. Among recent documents, the 75 multipath TCP (mtcp) working group has done a particularly good job 76 describing [RFC6182] the problems introduced by the presence of 77 middleboxes in IP networks. It is no longer safe (if it ever was) to 78 assume that the network path between two endpoints is completely 79 transparent, and that traffic is not being modified or inspected. 81 Middleboxes in the network may include: 83 o Firewalls 85 o NAT (Network Address Translators) 87 o Tunnel endpoints 89 o Application-level gateways 91 o TCP accelerators 93 o TCP proxies 95 among others. Please see [RFC3234] for a comprehensive, if somewhat 96 outdated, list. 98 This document tries to address specific impacts, but it should be 99 understood that there are broader issues around complexity and 100 manageability that are problematic but out of scope for this paper. 102 Also, note that in this initial version of the draft we will be 103 focusing on firewall and NAT middleboxes, with subsequent revisions 104 introducing discussions of other types of middleboxes. 106 2. Middlebox function within a network 108 Because middleboxes are not endpoints for a communication, they 109 typically (but not always) function by inspecting and/or modifying 110 traffic that flows across them. For example, firewalls look into 111 packets for particular pieces of data (addresses, protocol numbers or 112 ports, application-specific pieces of data) as traffic flows across 113 them. This implies several preconditions or other considerations: 115 o the traffic must be readable by the firewalls, which is to say 116 that it must either be unencrypted or that the firewall must have 117 a copy of the decryption key 119 o the data of interest must be "findable," either because they're at 120 a fixed location within a packet or that there are other data in 121 the packet that give the data of interest's location. 123 o Because NAT rewrites addresses in IP headers, and potentially 124 rewrites application endpoint addresses in "session-oriented" 125 protocols (VoIP, for example), there may be issues with integrity- 126 protecting traffic. If an address that is rewritten as part of a 127 NAT process is included in integrity-protected data, validation of 128 the data will fail. ("Content-aware" firewalls, which may also 129 rewrite data, but in the application layer, can introduce the same 130 problem) 132 o It should also be noted that NAT incidentally functions as a 133 (partial) route-pinning device, in that when a NAT writes its 134 address into the source address of an IP packet, it is forcing 135 return traffic through that same device. 137 3. Middleboxes and NVO3 139 3.1. General considerations 141 Middleboxes make policy (or policy-like) decisions based on packet 142 content. Consequently, as described above, the packet contents used 143 as a basis for policy decisions need to be accessible to the 144 middlebox, particularly in cases where the default action is to drop 145 a packet unless its contents match a permitted policy. 147 As a result, packet encapsulations and tunneling protocols risk of 148 having their contents dropped if a firewall or other type of 149 middlebox is unable to determine whether or not the traffic conforms 150 to permitted policy. Again, the conditions which might lead to this 151 are 153 o The middlebox being unable to locate the data of interest because 154 the encapsulation offsets the data from the beginning of the 155 packet, and 157 o The data are encrypted and unreadable 159 There may be considerable architectural advantage to co-locating 160 middlebox functions with nvo3 NVEs. 162 3.2. VM mobility 164 The nvo3 working group has identified Virtual Machine (VM) mobility 165 as a problem that must be addressed by their specifications. In 166 particular, there is an expectation that the live migration of a VM 167 both within a data center or between geographically disparate data 168 centers will be "seamless," or that network sessions will not be 169 interrupted when a VM migrates. In particular, the IP addresses and 170 MAC addresses of the VM will remain the same. 172 3.2.1. Firewalls 174 Firewalls may be located in a variety of locations within a data 175 center, and this may impact the ability of a VM to migrate without 176 interrupting live network sessions. Firewall placement can have a 177 varying degree of closeness, or coupledness, with the systems the 178 firewall protects. 180 Here are some examples of firewall placement, working from closely 181 coupled with the system the firewall protects to very loose coupling: 183 o A firewall may be running on a server, protecting only that 184 server. This is often referred to as a "host-based" firewall. 185 Examples include Linux's iptables and FreeBSD's ipfw. These are 186 typically implemented as kernel modules and may sit between the 187 NIC and the network stack 189 o A firewall may be running on a hypervisor, underneath a VM. The 190 firewall is not visible to the VM's operating system and is 191 logically similar to a stand-alone firewall or a firewall embedded 192 in a router. 194 o A firewall may be running on an appliance or embedded in a router 195 and be placed at the border between two administratively or policy 196 disparate networks, such as between a branch office network and a 197 central data center network. 199 Firewalls traversed by traffic between a mobile or migrating VM and a 200 network peer will have traffic-associated state, such as a pinhole 201 allowing the traffic through the firewall. A pinhole may be created 202 in several ways, such as 204 o explicit configuration: a network administrator configures a 205 firewall pinhole on a given port or for a given application 206 between the mobile VM and a particular peer 208 o policy conformance: local policy may be configured to allow 209 traffic through if it meets certain criteria, such as an 210 "external" address range, traffic initiated from inside the 211 firewall always being permitted, etc. 213 Regardless of how the state is instantiated, if that state is not 214 migrated with the VM and there is a new firewall on the path between 215 the migrated VM and its network peer, there will not be pinholes for 216 the traffic and the traffic will be blocked (dropped). The only case 217 in which state is currently migrated is in the case of host 218 firewalls. 220 3.2.2. Network Address Translation 222 NATs are often seen as being similar to firewalls, and it is the case 223 that they play a similar role in enforcing boundaries between 224 logically distinct networks, and that they have similar impacts on 225 network topologies. In some cases they may have static mappings 226 configured between external addresses/ports and internal addresses/ 227 ports, but in nearly all cases any traffic that traverses them has 228 the address of a device behind the NAT translated to another address. 230 This has two consequences of interest: 232 o Each packet traversing the device is being modified, and 234 o Traffic from outside is being addressed to the NAT, imposing loose 235 routing on the packet 237 There are at least two scenarios of interest when considering a 238 Virtual server migration and NAT. 240 In the first case, the newly-migrated server is behind the same NAT 241 device that it was prior to migration. When this is the case the new 242 server could either be using the same IP address and listening on the 243 same port for the service, or it can have a different IP address but 244 relies on the NAT to map the external address to the current active 245 server. Assuming that the new server is using the same IP address, 246 the migration is transparent to the NAT device, NAT just translates 247 the packets and forwards it. The new server would have all relevant 248 state information migrated with it, and is ready to process packets. 249 This is the simplest case. 251 If the new server is listening on a different IP address, this could 252 mean that a new NAT mapping will have to be installed once all the 253 state migration is done between the new and the old servers. For 254 example, the IP address of old server is S1 and is mapped to the 255 external address on the NAT device as E1, when the old server has 256 completely migrated to the new server, some external entity on the 257 network (preferably the hypervisor) will remove the existing mapping 258 between S1 and E1 and install a new mapping between S2 and E1, where 259 S2 is the IP address of the new server. Note, the external address 260 will remain unchanged thus hiding the internal changes in the 261 network. 263 The second scenario is that the server is migrated to a new location 264 that is not behind the same NAT device as it was previously. Because 265 of the asynchronous nature of IP communication, packets can arrive at 266 the old NAT even after the server migration is complete. In this 267 case, the NAT translates the IP address but will route the packet in 268 a sub-optimal way to new server. However, the packets could be 269 dropped or incorrectly routed if the internal address of the server 270 is not routable by the old NAT device or if there are overlapping 271 addresses in the network. When the server migrates in such a way 272 that it is not behind the same NAT device, the state on the NAT 273 device should also be migrated, so that all the packets are routed to 274 the new NAT device on the path. If the NAT is not migrated along 275 with the server state, the session may have to be re-established 276 depending on the application (Eg. VoIP or FTP). 278 4. Security Considerations 280 Middlebox interactions are nearly always rife with security issues, 281 in large part because for the middlebox to treat packet correctly in 282 conformance with its policy, information about that packet must be 283 exposed, whether it's address information or actual packet contents. 284 We know that there are deployments of technologies, such as VoIP, 285 where the deployer has chosen to forgo applying security technologies 286 in favor of making the traffic available to their middleboxes. It 287 should be noted that this is happening with or without nvo3 and is 288 not peculiar to nvo3. 290 However, in situations in which VMs are migrating between physical 291 networks and middlebox state must be migrated as well, there is a 292 risk of the state migration technology being used to hijack traffic, 293 perform a Denial-of-Service (DoS) attack, or to create other 294 compromises. Any time a new middlebox communication protocol is 295 deployed it creates new security exposures. 297 5. Informative References 299 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 300 Iyengar, "Architectural Guidelines for Multipath TCP 301 Development", RFC 6182, March 2011. 303 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 304 Issues", RFC 3234, February 2002. 306 Authors' Addresses 308 Melinda Shore 309 No Mountain Software 310 PO Box 16271 311 Two Rivers, AK 99716 312 US 314 Phone: +1 907 322 9522 315 Email: melinda.shore@nomountain.net 317 Yingjie Gu 318 Huawei 320 Phone: +86-25-56624760 321 Fax: +86-25-56624702 322 Email: guyingjie@huawei.com 324 Senthil Sivakumar 325 Cisco Systems 326 7100-8 Kit Creek Road 327 Research Triangle Park, NC 328 US 330 Email: ssenthil@cisco.com