idnits 2.17.1 draft-touch-ipsec-vpn-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 26, 2004) is 7358 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) ** Obsolete normative reference: RFC 2401 (ref. '1') (Obsoleted by RFC 4301) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2402 (ref. '5') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '6') (Obsoleted by RFC 4303, RFC 4305) ** Downref: Normative reference to an Informational RFC: RFC 2107 (ref. '8') -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. '9') (Obsoleted by RFC 4306) == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-12 == Outdated reference: A later version (-11) exists of draft-ietf-ipsec-rfc2402bis-06 == Outdated reference: A later version (-10) exists of draft-ietf-ipsec-esp-v3-07 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Touch 3 Internet-Draft ISI 4 Expires: August 26, 2004 L. Eggert 5 NEC 6 Y. Wang 7 ISI 8 February 26, 2004 10 Use of IPsec Transport Mode for Dynamic Routing 11 draft-touch-ipsec-vpn-07 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026 except that the right to 17 produce derivative works is not granted. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 26, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document addresses the use of IPsec to secure the links of a 43 multihop network, to secure communication between trusted components, 44 such as may be used for a secure virtual network (VN), overlay, or 45 virtual private network (VPN). It describes how virtual links 46 established by IPsec tunnel mode can conflict with routing and 47 forwarding inside the VN, due to the IP routing dependence on 48 references to interfaces and next-hop IP addresses. It is exactly 49 because IPsec specification is ambiguous on this issue that compliant 50 implementations cannot be relied upon to avoid conflicts between 51 routing and forwarding inside a VN. 53 This document proposes a solution, called IIPtran, in which IPIP 54 encapsulation separate from IPsec is used together with 55 transport-mode IPsec. IPIP tunnel encapsulation occurs as a separate 56 initial step, based on a forwarding lookup of the VN packet. After 57 the forwarding lookup, IPsec transport mode processes the resulting 58 (tunneled) IP packet with an SA determined through a security 59 association database (SAD) match on the tunnel header. 61 IIPtran supports dynamic routing inside the VN without changes to the 62 current IPsec architecture, by establishing a complete virtual 63 topology with IPIP tunnels that supports static and dynamic routing, 64 and then securing it with IPsec transport mode. IIPtran is an 65 interpretation of how to configure any IPsec specification compliant 66 implementations to avoid the aforementioned conflicts. 68 The document also discusses how IIPtran compares to several 69 alternative mechanisms for VN routing, and their respective impact on 70 IPsec, routing, policy enforcement and interactions with the Internet 71 Key Exchange (IKE), among other issues. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Problem Description . . . . . . . . . . . . . . . . . . . . 5 77 2.1 IPsec Overview . . . . . . . . . . . . . . . . . . . . . . . 6 78 2.2 Forwarding Example . . . . . . . . . . . . . . . . . . . . . 7 79 2.3 Problem 1: Forwarding Issues . . . . . . . . . . . . . . . . 8 80 2.4 Problem 2: Source Address Selection . . . . . . . . . . . . 9 81 3. IIPtran: IPIP Tunnel Devices + IPsec Transport Mode . . . . 11 82 3.1 IIPtran Details . . . . . . . . . . . . . . . . . . . . . . 11 83 3.2 Solving Problem 1: Forwarding Issues . . . . . . . . . . . . 13 84 3.3 Solving Problem 2: Source Address Selection . . . . . . . . 13 85 4. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 4.1 Other Proposed Solutions . . . . . . . . . . . . . . . . . . 14 87 4.1.1 Alternative 1: IPsec with Interface SAs . . . . . . . . . . 14 88 4.1.2 Alternative 2: IPsec with Initial Forwarding Lookup . . . . 15 89 4.1.3 Alternative 3: IPsec with Integrated Forwarding . . . . . . 15 90 4.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 4.2.1 VN Routing Support and Complexity . . . . . . . . . . . . . 15 92 4.2.2 Impact on the IPsec Architecture . . . . . . . . . . . . . . 16 93 4.2.3 Policy Enforcement and Selectors . . . . . . . . . . . . . . 17 94 4.2.4 IKE Impact . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 5. Security Considerations . . . . . . . . . . . . . . . . . . 21 96 6. Summary and Recommendations . . . . . . . . . . . . . . . . 22 97 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23 98 Normative References . . . . . . . . . . . . . . . . . . . . 24 99 Informative References . . . . . . . . . . . . . . . . . . . 25 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25 101 A. Encapsulation/Decapsulation Issues . . . . . . . . . . . . . 27 102 A.1 Encapsulation Issues . . . . . . . . . . . . . . . . . . . . 27 103 A.2 Decapsulation Issues . . . . . . . . . . . . . . . . . . . . 27 104 A.3 Appendix Summary . . . . . . . . . . . . . . . . . . . . . . 28 105 Intellectual Property and Copyright Statements . . . . . . . 29 107 1. Introduction 109 The IP security architecture (IPsec) consists of two modes, transport 110 mode and tunnel mode [1]. Transport mode is allowed between two end 111 hosts only; tunnel mode is required when at least one of the 112 endpoints is a "security gateway" (intermediate system that 113 implements IPsec functionality, e.g. a router.) 115 IPsec can be used to secure the links of a virtual network (VN), 116 creating a secure VN. In a secure VN, trusted routers inside the 117 network dynamically forward packets in the clear (internally), and 118 exchange the packets on secure tunnels, where paths may traverse 119 multiple tunnels. Contrast this to the conventional 'virtual private 120 network' (VPN), which often assumes that paths tend to traverse one 121 secure tunnel to resources in a secure core. A general secure VN 122 allows this secure core to be distributed, composed of trusted or 123 privately-managed resources anywhere in the network. 125 This document addresses the use of IPsec to secure the links of a 126 multihop, distributed VN. It describes how virtual links established 127 by IPsec tunnel mode can conflict with routing and forwarding inside 128 the VN, due to the IP routing dependence on references to interfaces 129 and next-hop IP addresses. 131 This document proposes a solution called IIPtran that separates the 132 step of IP tunnel encapsulation from IPsec processing. The solution 133 combines a subset of the current IPsec architecture with other 134 Internet standards to arrive at an interoperable equivalent that is 135 both simpler and has a modular specification. 137 Later sections of this document compare IIPtran to other proposals 138 for dynamic routing inside VPNs, focusing on the impact the different 139 proposals have on the overall IPsec architecture, routing protocols, 140 security policy enforcement, and the Internet Key Exchange (IKE) 141 [9][10]. An appendix addresses IP tunnel processing issues in IPsec 142 related to IPIP encapsulation and decapsulation. 144 This document assumes familiarity with other Internet standards 145 [1][2], notably with terminology and numerous acronyms therein. 147 2. Problem Description 149 Virtual networks connect subsets of resources of an underlying base 150 network, and present the result as a virtual network layer to 151 upper-layer protocols. Similar to a real network, virtual networks 152 consist of virtual hosts (packet sources and sinks) and virtual 153 routers (packet transits), both of which can have a number of network 154 interfaces, and links, which connect multiple network interfaces 155 together. Virtual links (also called tunnels, esp. when 156 point-to-point) are one-hop links in the VN topology, but are either 157 direct links or paths (sequences of connected links) in the 158 underlying base network. 160 Base network hosts and routers can be part of multiple virtual 161 networks at the same time, and their role in the base network does 162 not need to coincide with their role in a virtual network (i.e. base 163 network hosts may act as VN routers or hosts, as may base network 164 routers). 166 It is important to note that this definition of a VN is more general 167 than some other definitions, where the VN participation of end 168 systems is limited. Some proposals only allow end systems to be part 169 of a single VN, or even only allow them to be part of the VN and not 170 the base network, substituting the VN for the Internet. The 171 definition above explicitly allows hosts and routers to participate 172 in multiple, parallel VNs, and allows layered VNs (VN inside VN). 174 It can be useful for a VN to secure its virtual links [3][4], 175 resulting in a VPN. This is not equivalent to end-to-end security, 176 but can be useful when end hosts do not support secure communication 177 themselves. It can provide an additional level of hop-by-hop network 178 security to secure routing in the VPN and isolate the traffic of 179 different VPNs. 181 The topology of an IPsec VPN commonly consists of IPsec tunnel mode 182 virtual links, as required by the IPsec architecture when the 183 communicating peers are gateway pairs, or a host and a gateway [1]. 184 However, this current required use of IPsec tunnel mode can be 185 incompatible with dynamic routing [3]. 187 The next section provides a short overview on IPsec transport and 188 tunnel mode processing, as far as it is relevant for the 189 understanding of the problem scenarios that follow. The following 190 sections discuss routing problems in detail, based on a common 191 example. 193 2.1 IPsec Overview 195 There are two modes of IPsec, transport mode and tunnel mode [1]. 196 Transport mode secures portions of the existing IP header and the 197 payload data of the packet, and inserts an IPsec header between the 198 IP header and the payload; tunnel mode adds an additional IP header 199 before performing similar operations. This section gives a short 200 overview of the relevant processing steps for both modes. 202 In transport mode, IPsec inserts a security protocol header into 203 outgoing IP packets between the original IP header and the packet 204 payload (Figure 1) [5][6][11][12]. The contents of the IPsec header 205 are based on the result of a "security association" (SA) lookup that 206 uses the contents of the original packet header (Figure 1, arrow) as 207 well as its payload (esp. transport layer headers) to locate an SA in 208 the security association database (SAD). 210 Original Outbound Packet Outbound Packet (IPsec Transport Mode) 211 +-----------+---------+ +-----------+==============+---------+ 212 | IP Header | Payload | | IP Header | IPsec Header | Payload | 213 +-----------+---------+ +-----------+==============+---------+ 214 | ^ 215 | | 216 +-------------+ 217 SA Lookup 219 Figure 1: Outbound Packet Construction under IPsec Transport Mode 221 When receiving packets secured with IPsec transport mode, a similar 222 SA lookup occurs based on the IP and IPsec headers, followed by a 223 verification step after IPsec processing that checks the contents of 224 the packet and its payload against the respective SA. The 225 verification step is similar to firewall processing. 227 When using tunnel mode, IPsec prepends an IPsec header and an 228 additional IP header to the outgoing IP packet (Figure 2). In 229 essence, the original packet becomes the payload of another IP 230 packet, which IPsec then secures. This has been described [1] as "a 231 tunnel mode SA is essentially a [transport mode] SA applied to an IP 232 tunnel." However, there are significant differences between the two, 233 as described in the remainder of this section. 235 In IPsec tunnel mode, the IP header of the outbound original packet 236 together with its payload (esp. transport headers) determines the 237 IPsec SA, as for transport mode. However, a tunnel mode SA also 238 contains encapsulation information, including the source and 239 destination IP addresses for the outer tunnel IP header, which is 240 also based on the original outbound packet header and its payload 241 (Figure 2, arrows). 243 Outbound Packet (IPsec Tunnel Mode) 244 +==================+==============+-----------------+---------+ 245 | Tunnel IP Header | IPsec Header | Orig. IP Header | Payload | 246 +==================+==============+-----------------+---------+ 247 ^ ^ | | 248 | | | | 249 | +--------------+ | 250 | SA Lookup | 251 | | 252 +---------------------------------+ 253 IP Encapsulation 255 Figure 2: Outbound Packet Construction under IPsec Tunnel Mode 257 When receiving packets secured with tunnel mode IPsec, an SA lookup 258 occurs based on the contents of the IPsec header and the outer IP 259 header. Next, the packet is decrypted or authenticated based on its 260 IPsec header and the SA, followed by a verification step that checks 261 the contents of the original packet and its payload (esp. the inner 262 IP header and transport headers) against the respective SA. 264 2.2 Forwarding Example 266 Consider a VPN topology with virtual links established by IPsec 267 tunnel mode SAs, as would be required for compliance with [1]. Such 268 hop-by-hop security can be useful, for example, to secure VN routing, 269 and when legacy end systems do not support end-to-end IPsec 270 themselves. 272 Virtual routers in a VN need to forward packets the same way regular 273 Internet routers do: based on the destination IP address and the 274 forwarding table. These two determine the next hop IP address the 275 packet should be forwarded to (additional header fields and inner 276 headers can be used, e.g. in policy routing.) 278 In Figure 3, traffic arrives at gateway A on virtual link 1, having 279 come from any of the virtual hosts upstream of that virtual link. 280 There are two outgoing virtual links for this incoming traffic: out 281 link 3 going to the VPN next-hop gateway B, and out link 4 going to 282 the VPN next-hop gateway C. 284 For this example, assume the incoming traffic is from a single VPN 285 source X, going to a single VPN destination Y. Ellipses (...) 286 represent multiple virtual links in Figure 3. 288 B ---...--- 289 / \ 290 / 3 \ 291 / \ 292 X ---...--- A D ---...--- Y 293 1 2 \ / 294 \ 4 / 295 \ / 296 C ---...--- 298 Figure 3: Topology of a Virtual Network 300 Two problems arise; one is forwarding of VN traffic over IPsec tunnel 301 mode links, the other is source address selection on VN end systems. 303 2.3 Problem 1: Forwarding Issues 305 Assume a packet from source X to destination Y arrives on link 2 at 306 gateway A. Gateway A now needs to both forward and encrypt the packet 307 to make progress to the next hop gateway inside the VPN. 309 Dynamically routed gateways forward packets based on a forwarding 310 table managed by a routing daemon that exchanges connectivity 311 information with directly connected peers by communicating on its 312 local interfaces. Entries in the forwarding table map destination IP 313 addresses to the IP address of a next-hop gateway and an associated 314 outbound interface. 316 The problem is that an intermediate router needs to pick a next hop 317 gateway for a transit packet based on its destination IP address and 318 the contents of the forwarding table. However, the IPsec architecture 319 does not define if and how tunnel mode SAs are represented in the 320 forwarding table. 322 The problem occurs when A tries to decide how to forward the packet 323 X->Y. In a regular IP network, this decision depends on a forwarding 324 lookup on destination address Y, which indicates the IP address of 325 the next-hop gateway and an associated outbound interface. In the 326 case of a VN, forwarding lookups occur on virtual destination 327 addresses. For the forwarding lookup on such a virtual destination 328 address to succeed, routes through virtual interfaces (tunnels) must 329 exist in the forwarding table. 331 There are two common implementation scenarios for tunnel mode SAs: 332 One is based on firewall-like packet matching operations where tunnel 333 mode SAs are not virtual interfaces, another is tunnel-based, and 334 treats a tunnel mode SA as a virtual interface. The current IPsec 335 architecture does not mandate one or the other. 337 Under the first approach, the presence of IPsec tunnel mode SAs is 338 invisible to the IP forwarding mechanism. The lookup uses matching 339 rules in the SA lookup process, closer to firewall matching than 340 traditional IP forwarding lookups, and independent from existing IP 341 forwarding tables. The SA lookup determines which virtual link the 342 packet will be forwarded over, because the tunnel mode SA includes 343 encapsulation information. This lookup and the subsequent tunnel mode 344 processing both ignore the contents of the existing IP forwarding 345 table, whether static or dynamic routing are used. This type of 346 tunnel mode processing is thus incompatible with dynamically routed 347 VPNs. 349 The second approach - requiring tunnel mode SAs to be interfaces - 350 can be compatible with dynamically routed VPNs (see Section 4) 351 depending on how it is implemented; however, IIPtran (see Section 3) 352 has the additional benefit of greatly simplifying the IPsec 353 architecture and related specifications, and of being compatible with 354 all IPsec specification compliant implementations. 356 2.4 Problem 2: Source Address Selection 358 A second issue is source address selection at the source host. When 359 an application sends traffic to another host, the host must choose an 360 IP source address for the IP packets before transmission. 362 When an end system is connected to multiple networks, it must set the 363 source address properly to receive return traffic over the correct 364 network. When a node participates in a virtual network, it is always 365 connected to two networks, the base network and the VN (more if it 366 connects to at least two VNs.) The IPsec specification currently does 367 not define how tunnel mode SAs integrate with source address 368 selection. 370 For example, when communication occurs over a virtual network, the 371 source address must lie inside the VN. When X sends to Y (Figure 3), 372 the source address must be the IP address of X's local end of tunnel 373 1. If host A, which has multiple interfaces inside the VN, sends to 374 Y, the source address must be the IP address of the local end of 375 either tunnel 3 or 4. 377 Most applications do not bind to a specific source IP address, and 378 instead let the host pick one for their traffic [7]. Rules for source 379 address selection that depend heavily on the notions of interfaces 380 and routes. 382 According to [7], the IP source address of an outbound packet should: 383 (1) for directly connected networks derive from the corresponding 384 interface, or (2) derive from existing dynamic or static route 385 entries to the destination, or finally (3) derive from the interface 386 attached to a default gateway. 388 Because IPsec tunnel mode SAs are not required to be interfaces, 389 rules (1) and (2) may not return a usable source address for a given 390 packet. Consequently, VN packets will use the IP address of the local 391 interface connecting to a default gateway as their source address. 392 Often, a default gateway for a host provides connectivity in the base 393 network underlying the VN. The outgoing packet will thus have a 394 source address in the base network, and a destination address in the 395 VN. 397 This can result in numerous problems, including applications that 398 fail to operation at all, as well as firewalls and admission control 399 failures, and may even lead to compromised security. Consider two 400 cases, one with IPsec tunnels configured with no wildcard tunnel 401 addresses, the other using certain wildcards. In both cases, an 402 application whose source address is set by RFC 1122 [7]rules may send 403 packets (e.g.) with the source address of that host's base network 404 (via the default route) and a destination address of the remote 405 tunnel endpoint. 407 3. IIPtran: IPIP Tunnel Devices + IPsec Transport Mode 409 This section introduces a solution - called IIPtran - for the two 410 issues identified above. IIPtran replaces IPsec tunnel mode with a 411 combination of IPIP tunnel interfaces that support forwarding and 412 source address selection (as per RFC 2003 [2]), followed by IPsec 413 transport mode on the encapsulated packet. 415 The IPsec architecture [1] defines the appropriate use of IPsec 416 transport mode and IPsec tunnel mode (host-to-host communication for 417 the former, and all transit communication for the latter). IIPtran 418 appears to violate this requirement, because it uses IPsec transport 419 mode for transit communication. 421 However, for an IPIP tunnel between security gateways, the gateways 422 themselves source or sink base network traffic when tunneling - they 423 act as hosts in the base network. Thus, IPsec transport mode is also 424 appropriate, if not required, for encapsulated traffic, according to 425 [1]. 427 As a result, replacing IPsec tunnel mode with IPIP tunnel devices and 428 IPsec transport mode is consistent with the existing architecture. 429 Furthermore, this does not compromise the end-to-end use of IPsec, 430 either inside a VPN or in the base network; it only adds IPsec 431 protection to secure virtual links. 433 The next sections will give a short overview of IPIP encapsulation, 434 and show it combines with IPsec transport mode processing. These 435 section will then discuss how IIPtran addresses each of the problems 436 identified above. 438 3.1 IIPtran Details 440 IIPtran uses IPIP tunnels (as defined in RFC 2003 [2]), followed by 441 IPsec transport mode on the encapsulated packet. 443 RFC 2003 [2] uniquely specifies IPIP encapsulation (placing an IP 444 packet as payload inside another IP packet.) Originally developed for 445 MobileIP, it has since often been adopted when virtual topologies 446 were required. Examples include virtual (overlay) networks to support 447 emerging protocols such as IP Multicast, IPv6, and Mobile IP itself, 448 as well as systems that provide private networks over the Internet 449 (X-Bone [3] and PPVPN). 451 IPIP outbound packet processing, as specified by RFC 2003, [2]tunnels 452 an existing IP packet by prepending it with another IP header (Figure 453 4.) 454 Outbound Packet (IPIP Tunnel) 455 +==================+-----------------+---------+ 456 | Tunnel IP Header | Orig. IP Header | Payload | 457 +==================+-----------------+---------+ 458 ^ | 459 | | 460 +------------------+ 461 IPIP Encapsulation 463 Figure 4: Outbound Packet Construction for IPIP Tunnel 465 IIPtran performs this IPIP processing as a first step, followed by 466 IPsec transport mode processing on the resulting IPIP packet (Figure 467 5.) 469 Outbound Packet (IPIP Tunnel + IPsec Transport Mode) 470 +==================+==============+-----------------+---------+ 471 | Tunnel IP Header | IPsec Header | Orig. IP Header | Payload | 472 +==================+==============+-----------------+---------+ 473 ^ | ^ | 474 | | | | 475 | +---------------+ | 476 | SA Lookup | 477 | | 478 +----------------------------------+ 479 IPIP Encapsulation 481 Figure 5: Outbound Packet Construction for IPIP Tunnel with IPsec 482 Transport Mode 484 A key difference between Figure 2 and Figure 5 is that in the 485 proposed solution, the IPsec header is based on the outer IP header, 486 whereas under IPsec tunnel mode processing, the IPsec header depends 487 on the contents of the inner IP header and payload (see Section 2.1). 489 However, the resulting VPN packet (Figure 5) on the wire cannot be 490 distinguished from a VPN packet generated by IPsec tunnel mode 491 processing (Figure 2); and the two methods inter-operate, given 492 appropriate configurations on both ends [3]. 494 A detailed discussion of the differences between IIPtran, IPsec 495 tunnel mode, and other proposed mechanisms follows in Section 4. The 496 remainder of this section will describe how IIPtran combines IPIP 497 tunnel devices with IPsec transport mode to solve the problems 498 identified in Section 2. 500 3.2 Solving Problem 1: Forwarding Issues 502 Section 2.3 described how IP forwarding over IPsec tunnel mode SAs 503 breaks, because tunnel mode SAs are not required to be network 504 interfaces. IIPtran uses RFC 2003 IPIP tunnels [2] to establish the 505 topology of the virtual network. RFC 2003 [2] requires that IPIP 506 tunnels can be routed to, and have configurable addresses. Thus, they 507 can be references in node's routing table (supporting static 508 routing), as well as used by dynamic routing daemons for local 509 communication of reachability information. 511 RFC 2003 [2] addressed the issue of inserting an IPsec header between 512 the two IP headers that are a result of IPIP encapsulation. IIPtran 513 provides further details on this configuration, and demonstrates how 514 it enables dynamic routing in a virtual network. 516 It is important to note that the RFC 2003 IPIP tunnels [2] already 517 provide a complete virtual network that an support static or dynamic 518 routing. The proposed solution of using IPIP tunnel with IPsec 519 transport mode decouples IPsec processing from routing and 520 forwarding. IIPtran's use of IPsec is limited to securing the links 521 of the VN (creating a VPN), because IPsec (rightly) lacks internal 522 support for routing and forwarding. 524 3.3 Solving Problem 2: Source Address Selection 526 Section 2.4 gave an overview of IP source address selection and its 527 dependence on interfaces and routes. 529 Using RFC 2003 IPIP tunnel devices [2] for VN links, instead of IPsec 530 tunnel mode SAs, allows existing multihoming solutions for source 531 address selection [1] to solve source address selection in this 532 context as well. As indicated in Section 2.4, according to [1], the 533 IP source address of an outbound packet is determined by the outbound 534 interface, which is in turn determined by existing forwarding 535 mechanism. Because IPIP tunnels are full-fledged interfaces with 536 associated routes (as in Section 3.2 of [2]), the routes and address 537 selection as specified in [1] can also operate as desired in the 538 context of VN links. 540 4. Comparison 542 The previous sections described problems when IPsec tunnel mode 543 provides VPN links, and proposed a solution. This section introduces 544 a number of proposed alternatives, and compares their effect on the 545 IPsec architecture, routing, and policy enforcement, among others, to 546 IIPtran. 548 4.1 Other Proposed Solutions 550 This section gives a brief overview of a number of alternative 551 proposals that aim at establishing support for dynamic routing for 552 IPsec-secured VNs. The following section then compares these 553 proposals in detail. 555 Although some of the alternatives also address the issues identified 556 above, IIPtran alone also significantly simplifies and modularizes 557 the IPsec architecture. 559 4.1.1 Alternative 1: IPsec with Interface SAs 561 In the first alternative, each IPsec tunnel mode SA is required to 562 act as a full-fledged network interface. This SA interface acts as 563 the outbound interface of the virtual destination's forwarding table 564 entry. IPsec dynamically updates the SA interface configuration in 565 response to SAD changes, e.g. caused by IKE negotiation. 567 This approach supports dynamic routing and existing source address 568 selection rules, but requires extensions to the IPsec architecture 569 that define tunnel mode SA interfaces and their associated management 570 procedures. 572 It would necessitate recapitulating the definition of the entirety of 573 RFC 2003 IPIP encapsulation [2], including the association of tunnels 574 with interfaces, inside IPsec. This defeats the modular architecture 575 of the Internet, and violates the specification of type 4 IP in IP 576 packets as being uniquely defined by a single Internet standard (it 577 is already standardized by [2]). 579 This solution also requires augmenting the IPsec specification to 580 mandate an implementation detail, one that may be difficult to 581 resolve with other IPsec designs, notably the BITS 582 (bump-in-the-stack) alternative. Although the current IPsec 583 specification is ambiguous and allows this implementation, an 584 implementation-independent design is preferable. 586 4.1.2 Alternative 2: IPsec with Initial Forwarding Lookup 588 A second alternative is the addition of an extra forwarding lookup 589 before IPsec tunnel mode processing. This forwarding lookup will 590 return a "virtual interface" identifier that which indicates how to 591 route the packet [13]. Due to a lack of concrete documentation of 592 this alternative at this time, proposed for an update pending to RFC 593 2401 [1], two variants are presumed possible: 595 In the first scenario, the extra forwarding lookup indicates the 596 outbound interface of the final encapsulated tunnel mode packet, i.e. 597 usually a physical interface in the base network. The tunnel mode SA 598 lookup following the forwarding lookup will occur in the 599 per-interface SAD associated with the respective virtual interface. 601 In the second scenario, the extra forwarding lookup returns an 602 outbound tunnel SA interface. This solution seems to be equivalent to 603 the one described above (Section 4.1.1), i.e. all tunnel mode SAs 604 must be interfaces, and is not discussed separately below. 606 4.1.3 Alternative 3: IPsec with Integrated Forwarding 608 In the third alternative, the routing protocols and forwarding 609 mechanisms are modified to consult both the routing tables and SADs 610 to make forwarding decision. To prevent IPsec processing from 611 interfering with routing, forwarding table lookup must precede SAD 612 lookup. 614 This approach supports dynamic routing, but requires changes to 615 routing mechanisms such that SAD contents are included in the route 616 exchanges. It is unclear how transport-layer selectors would affect 617 this approach. 619 4.2 Discussion 621 This section compares the three different alternatives and IIPtran 622 according to a number of evaluation criteria, such as support for VN 623 forwarding, or impact on the IPsec architecture. 625 4.2.1 VN Routing Support and Complexity 627 This section investigates whether the three alternatives and IIPtran 628 support VN routing, esp. dynamic routing based on existing IP routing 629 protocols. 631 Both IIPtran (IPIP tunnels + transport mode) and alternative 1 632 (per-SA interfaces) establish VN links as full-fledged devices that 633 can be referred to in the routing table, as well as used for local 634 communication by dynamic routing protocols. They both support static 635 and dynamic VN routing. 637 However, because the current IPsec architecture does not require 638 tunnel mode SAs to behave similarly to interfaces (some implementers 639 chose alternative 1, but it is not mandated by the specification), 640 alternative 1 requires extensions to the current IPsec architecture 641 that define the exact behavior of tunnel mode SAs. The proposed 642 solution does not require any such changes to IPsec, and for tunnels 643 RFC 2003 already specifies those requirements [2]. Furthermore, 644 addition of those requirements would be redundant and potentially 645 conflict with RFC 2003 [2]. 647 Alternative 3 supports dynamic VN routing, but requires modifying 648 routing protocols and forwarding lookup mechanisms to act or 649 synchronize based on SAD entries. This requires substantial changes 650 to routing software and forwarding mechanisms in all participating 651 nodes to interface to the internals of IPsec; this would require 652 revising a large number of current Internet standards. It is also not 653 clear how tunnel mode SAs that specify port selectors would operate 654 under this scheme, since IP routing has no dependence on 655 transport-layer fields. 657 Alternative 2 does not support dynamic VN routing. The additional 658 forwarding lookup before IPsec processing is irrelevant, because 659 IPsec tunnel mode SAs are not represented as interfaces, and thus 660 invisible to IP routing protocols. 662 Additionally, the forwarding lookup suggested for alternative 2 is 663 not compatible with a weak ES model described in [1], which requires 664 both an outbound interface indicator as well as the IP address of the 665 next-hop gateway. For example, multiple tunnels can use the same 666 outgoing interface and thus same SAD. The forwarding lookup would 667 return only the interface; lacking the next-hop gateway, the correct 668 SAD entry cannot be determined. Given the next-hop gateway would not 669 help, because the SAD is not indexed by tunnel mode SA encapsulation 670 destination IP address. 672 Because alternative 2 fails to support VN routing, it will not be 673 discussed in the remainder of this section. 675 4.2.2 Impact on the IPsec Architecture 677 IIPtran recognizes that encapsulation is already a property of 678 interface processing, and thus relies on IPIP tunnel devices to 679 handle the IPIP encapsulation for VN links. Tunnel mode IPsec thus 680 becomes unnecessary and can potentially be removed from the IPsec 681 architecture, greatly simplifying the specification. 683 Alternative 1 requires SAs to be represented as full-fledged 684 interfaces, for the purpose of routing. SAD changes must furthermore 685 dynamically update the configuration of these SA interfaces. The 686 IPsec architecture thus needs extensions that define the operation of 687 interfaces and their interactions with the forwarding table and 688 routes. 690 Additionally, RFC 2401 [1] describes per-interface SADs as a 691 component of IPsec. When tunnel mode SAs themselves act as 692 interfaces, the function of per-interface SADs needs clarification as 693 follows: 695 First, each tunnel interface SAD must contain exactly one IPsec 696 tunnel mode SA. Transport mode SAs are prohibited, because they 697 would not result in IP encapsulation (the encapsulation header is 698 part of the tunnel mode SA, a transport mode SA would not cause 699 encapsulation), and thus lead to processing loops. Multiple tunnel 700 mode SAs are prohibited, because dynamic routing algorithms construct 701 topology information based on per-interface communication. Merging 702 different virtual links (tunnels) into a single SA interface can 703 cause routing events on one virtual link to apply incorrectly to 704 other links sharing an SA interface. 706 Second, only the SAD of physical interfaces may contain IPsec 707 transport mode SAs; otherwise, the current issues with VN routing 708 remain unsolved. 710 In summary, these restrictions result in only SADs of SA interfaces 711 containing tunnel mode SAs, and only SADs of regular interfaces 712 containing transport mode SAs. Thus, tunnel encapsulation essentially 713 becomes a unique property of the interface, and not IPsec. 715 IIPtran already recognizes this property. Consequently, it uses IPIP 716 tunnels directly, and combines them with transport mode processing. 717 By eliminating the use of tunnel mode, it removes the need for 718 additional constraints on the contents of per-interface SAs. 720 4.2.3 Policy Enforcement and Selectors 722 On receiving a packet, both IPsec tunnel mode and IIPtran decrypt 723 and/or authenticate the packet with the same techniques. IPsec tunnel 724 mode decapsulates and decrypts the packet in a single step, followed 725 by a policy check of the inner packet and its payload against the 726 respective IPsec tunnel mode SA. IIPtran uses IPsec transport mode to 727 decrypt and verify the incoming packet, then passes the decrypted 728 IPIP packet on to RFC 2003 IPIP processing [2]. At that point, 729 IIPtran can support selector checks on both the header and its 730 payload using firewall mechanisms, similar to IPsec tunnel mode 731 processing. 733 The primary difference between the two is that IPsec tunnel mode does 734 not require a separate processing step for validating packets; once 735 IPsec accepts them during the policy check during decapsulation, they 736 are accepted. IIPtran requires additional processing on the 737 decapsulated packets, to validate whether they conform to their 738 respective IPsec policy. 740 As noted in Section 5.2 of the IPsec architecture document [1], IPsec 741 processing should retain information about what SAs matched a given 742 packet, for subsequent IPsec or firewall processing. To allow for 743 complex accept policies, it should be possible to reconstruct the 744 format of the original packet at the time it first entered a machine 745 based on saved processing context at any time during inbound 746 processing. IIPtran accepts incoming VN packets only if they have 747 arrived over a specific IPIP tunnel that was secured with IPsec 748 transport mode, but as a separate step following IPIP decapsulation. 750 Note that IPsec tunnel mode and IIPtran are interoperable [3]. 751 Experiments have verified this interoperability, notably because 752 there are no differences in the resulting packets on the wire, given 753 appropriate keys. 755 4.2.3.1 Selector Expressiveness 757 When looking up an SA for a given packet, IPsec allows selectors to 758 match on the contents of the IP header and transport headers. IIPtran 759 using existing IPsec cannot support transport header matches, because 760 SA lookup occurs before decapsulation. A small extension to IPsec can 761 address this issue in a modular way. 763 RFC 2401 [1] explicitly recognizes that the transport layer header 764 may be nested several headers deep inside the packet, and allows a 765 system to (quote) "chain through the packet headers checking the 766 'Protocol' or 'Next Header' field until it encounters either one it 767 recognizes as a transport protocol, or until it reaches one that 768 isn't on its list of extension headers, or until it encounters an ESP 769 header that renders the transport protocol opaque." 771 With IIPtran, the SA lookup starts on the outer (tunnel) header, and 772 selectors including port number information must thus traverse the 773 inner IP header (and possibly other headers) before they can match on 774 the transport headers. IIPtran thus requires that IP be a known IPsec 775 "extension header." This recognizes that with IPIP encapsulation, IP 776 VNs use the base IP network as a link layer. Although this small 777 extension to IPsec is not explicitly required, it is already implied. 779 Recognizing IP as a valid transport layer over IP also allows 780 selectors to match on the contents of the inner ("transport") IP 781 header. Thus, IPsec selectors under IIPtran can express the same set 782 of policies as conventional IPsec tunnel mode. 784 Note that in both cases, these policy enforcement rules violate 785 layering by looking at information other than the outermost header. 786 This is consistent with IPsec's current use of port-based selectors. 787 The next section discusses that selectors may not be useful for 788 virtual networks. 790 4.2.3.2 Role of Selectors for VPNs 792 For secure VN links established via IPsec tunnel mode SAs, the 793 selectors for the inner (VN) source and destination IP addresses 794 often need to be wildcarded to support dynamic routing in a VN. Thus, 795 the limitation described in 4.2.3.1 (without the proposed extension) 796 may not be important in a VN scenario. 798 Consider a four-node VN with nodes A, B, C and N (Figure 6). Consider 799 the case where N is either a new node joining an existing VPN, or an 800 existing node that had been disconnected and was just rediscovered 801 via dynamic routing. 803 In this example, A has IPsec tunnel mode SAs to B and C. If the 804 selectors for the virtual source and destination IP addresses for 805 those SAs are not wildcards, the SA needs to be dynamically modified 806 to permit packets from N to pass over the tunnels to B and C. This 807 becomes quickly impractical as VPN sizes grow. 809 B 810 / 811 / 812 / 813 N ------ A 814 \ 815 \ 816 \ 817 C 819 Figure 6: Topology of a Virtual Network 821 Thus, IPsec selectors appear much less useful in a VPN scenario than 822 expected. A consequence might be that IIPtran - even without 823 extensions to support the full expressiveness of tunnel mode SA 824 selectors as described above - can still support the majority of VPN 825 scenarios. 827 One purpose of selectors matching on transport header content is 828 policy routing. Different SAs can apply to different applications, 829 resulting in different apparent virtual topologies. IIPtran supports 830 policy routing in a more modular way, by having existing policy 831 routing implementations forward traffic over multiple, parallel VNs. 832 IIPtran supports arbitrary IP-based policy routing schemes, while 833 policies are limited by the expressiveness of IPsec's selectors in 834 the former case. 836 4.2.4 IKE Impact 838 The Internet Key Exchange (IKE) [9][10] is a protocol to negotiate 839 IPsec keys between end systems dynamically and securely. It is not a 840 strictly required component of IPsec in the sense that two hosts can 841 communicate using IPsec without having used IKE to negotiate keys 842 (through manually keyed SAs, for example). Despite its name, IKE also 843 acts as a tunnel management protocol (when IPsec tunnel mode SAs are 844 configured), and negotiates security policies between the peers. 846 Alternatives 1 and 3 use existing IKE without changes. 848 One possible approach to use IKE with IIPtran is to negotiate a 849 tunnel mode SA, and then treat it as a transport mode SA against an 850 IPIP tunnel when communicating with conventional peers. For policies 851 that do not specify selectors based on transport-layer information, 852 this establishes interoperability. 854 However, since IIPtran eliminates IPsec tunnel mode, it could also 855 simplify IKE, by limiting it to its original purpose of key exchange. 856 A new tunnel management protocol (e.g. ATMP [8]) would set up IPIP 857 tunnels, use an as of yet unspecified second protocol to negotiate 858 security policy, and then use IKE to exchange keys for use with the 859 policy. 861 Current IKE operation would become a modular composition of separate 862 protocols, similar to how IIPtran modularizes IPsec by combining 863 existing Internet standards. For example, a VPN link creation could 864 follow these steps: (1) IKE negotiation in the base network to secure 865 (2) a subsequent tunnel management exchange [8] in the base network, 866 followed by (3) IKE exchanges over the established tunnel to create a 867 secure VPN link. 869 5. Security Considerations 871 This document addresses security considerations throughout, as they 872 are a primary concern of proposed uses of IPsec. 874 The primary purpose of this document is to extend the use of IPsec to 875 dynamically routed VPNs, which will extend the use of IPsec and, it 876 is hoped, increase the security of VPN infrastructures using existing 877 protocols. 879 6. Summary and Recommendations 881 This document presents a mechanism consistent with the current use of 882 IPsec which supports dynamic routing inside a virtual network that 883 uses IPsec to secure its links. It illustrates how current use of 884 IPsec tunnel mode can fail to support dynamic VN routing (depending 885 on the implementation), and compares IIPtran with several different 886 alternatives. It finds that IIPtran, a composite of a subset of IPsec 887 (i.e. transport mode) together with existing standard IPIP 888 encapsulation, results in an interoperable, standards-conforming 889 equivalent that is both simpler and modular. 891 7. Acknowledgments 893 The authors would like to thank the members of the X-Bone and 894 DynaBone projects at USC/ISI for their contributions to the ideas 895 behind this draft, notably (current) Greg Finn and (past) Amy Hughes, 896 Steve Hotz and Anindo Banerjea. 898 The authors would also like to thank Jun-ichiro (itojun) Hagino and 899 the KAME project for bringing IKE implications of this proposal to 900 our attention, as well as implementing the mechanisms in this draft 901 in the KAME IPv6/IPsec network stack. Members of several IETF WGs 902 (especially IPsec: Stephen Kent, PPVPN: Eric Vyncke, Paul Knight, 903 various members of MobileIP) provided valuable input on the details 904 of IPsec processing in earlier revisions of this document. 906 Effort sponsored by the Defense Advanced Research Projects Agency 907 (DARPA) and Air Force Research Laboratory, Air Force Materiel 908 Command, USAF, under agreements number F30602-98-1-0200 entitled 909 "X-Bone" and number F30602-01-2-0529 entitled "DynaBone". 911 Normative References 913 [1] Kent, S. and R. Atkinson, "Security Architecture for the 914 Internet Protocol", RFC 2401, November 1998. 916 [2] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 917 1996. 919 [3] Touch, J., "Dynamic Internet overlay deployment and management 920 using the X-Bone", Computer Networks Vol. 36, No. 2-3, July 921 2001. 923 [4] Touch, J., Wang, Y., Eggert, L. and G. Finn, "A Virtual Internet 924 Architecture", ISI Technical Report ISI-TR-570, Workshop on 925 Future Directions in Network Architecture (FDNA) 2003, March 926 2003. 928 [5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, 929 November 1998. 931 [6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 932 (ESP)", RFC 2406, November 1998. 934 [7] Braden, R., "Requirements for Internet Hosts - Communication 935 Layers", STD 3, RFC 1122, October 1989. 937 [8] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 938 2107, February 1997. 940 Informative References 942 [9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 943 RFC 2409, November 1998. 945 [10] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 946 draft-ietf-ipsec-ikev2-12 (work in progress), January 2004. 948 [11] Kent, S., "IP Authentication Header", 949 draft-ietf-ipsec-rfc2402bis-06 (work in progress), February 950 2004. 952 [12] Kent, S., "IP Encapsulating Security Payload (ESP)", 953 draft-ietf-ipsec-esp-v3-07 (work in progress), February 2004. 955 [13] Kent, S., "Personal Communication", November 2002. 957 [14] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 958 November 1990. 960 [15] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, 961 September 2000. 963 Authors' Addresses 965 Joe Touch 966 USC Information Sciences Institute 967 4676 Admiralty Way 968 Marina del Rey, CA 90292 969 US 971 Phone: +1 310 822 1511 972 Fax: +1 310 823 6714 973 EMail: touch@isi.edu 974 URI: http://www.isi.edu/touch 976 Lars Eggert 977 NEC Network Laboratories 978 Kurfuersten-Anlage 36 979 Heidelberg 69115 980 DE 982 Phone: +49 6221 90511 43 983 Fax: +49 6221 90511 55 984 EMail: lars.eggert@netlab.nec.de 985 URI: http://www.netlab.nec.de/ 986 Yu-Shun Wang 987 USC Information Sciences Institute 988 4676 Admiralty Way 989 Marina del Rey, CA 90292 990 US 992 Phone: +1 310 822 1511 993 Fax: +1 310 823 6714 994 EMail: yushunwa@isi.edu 995 URI: http://www.isi.edu/yushunwa 997 Appendix A. Encapsulation/Decapsulation Issues 999 There are inconsistencies between the IPIP encapsulation rules 1000 specified by IPsec [1] and those specified by MobileIP [2]. The 1001 latter specification is standards track, and the IP protocol number 1002 of 4 (payload of an IP packet of type 4) is uniquely specified by RFC 1003 2003 according to IANA [2]. The use of IPIP inside an IPsec transport 1004 packet can be confused with IPsec tunnel mode, because IPsec does not 1005 specify any limits on the types of IP packets that transport mode can 1006 secure, 1008 A.1 Encapsulation Issues 1010 When an IP packet is encapsulated as payload inside another IP 1011 packet, some of the outer header fields can be newly written (and the 1012 inner header determines some others [2].) Among these fields is the 1013 IP DF (do not fragment) flag. When the inner packet DF flag is clear, 1014 the outer packet may copy it or set it; however, when the inner DF 1015 flag is set, the outer header must copy it [2]. IPsec defines 1016 conflicting rules, where that flag and other similar fields (TOS, 1017 etc.) may be copied, cleared, or set as specified by an SA. 1019 The IPsec specification indicates that such fields must be 1020 controlled, to achieve security. Otherwise, such fields could provide 1021 a covert channel between the inner packet header and outer packet 1022 header. However, RFC 2003 [2] requires that the outer fields not be 1023 cleared when the inner ones are set, to prevent MTU discovery "black 1024 holes" [14][15]. 1026 To avoid a conflict between these rules, and to avoid security 1027 weaknesses associated with solely copying the fields, it is 1028 recommended that IPsec IPIP encapsulation not permit the clearing of 1029 the outer DF flag. When the SA requires clearing the DF flag, and the 1030 inner packet DF is set, it is proposed that IPsec drop that packet, 1031 rather than violate RFC 2003 processing rules [2]. Similar rules are 1032 being developed for TOS and other similar IP header fields, to be 1033 included in an update of RFC 2003 [2]. 1035 Another approach to closing the covert channel is always to set the 1036 DF flag in the outer header (whether or not it is set in the inner 1037 header). Setting the DF flag allows PMTU discovery to operate 1038 normally. The details of this approach are discussed in [2]. 1040 A.2 Decapsulation Issues 1042 Given identical keys, a packet created by IPIP tunnel encapsulation 1043 combined with IPsec transport mode and an IPsec tunnel mode packet 1044 look identical on the wire. Thus, when an IPsec'ed packet arrives 1045 that contains an IPIP inner packet, it is not possible to distinguish 1046 whether the packet was created using IPsec tunnel mode or IPsec 1047 transport mode of an IPIP encapsulated packet. In both cases, the 1048 protocol field of the outer header is IPsec (AH or ESP), and the 1049 "next header" field for the inner data is 4 (IP). IPsec requires the 1050 SA matching a received packet to indicate whether to apply tunnel 1051 mode or transport mode. 1053 Incoming packet processing must check the SAD before determining 1054 whether to decapsulate IPsec packets with inner payload of protocol 1055 type 4. If the SAD indicates that a tunnel mode association applies, 1056 IPsec must decapsulate the packet. If the SAD indicates that a 1057 transport mode association applies, IPsec must not decapsulate the 1058 packet. This requires that the SAD indicate one of these two options; 1059 wildcard SAD entries ("ANY", or "TUNNEL or TRANSPORT") cannot be 1060 supported. 1062 A.3 Appendix Summary 1064 IPsec's use of IPIP encapsulation conflicts with the IPIP standard 1065 [2], This issue is already being resolved in an update to RFC 2003, 1066 instead of specifying a non-standard conforming variant of IPIP 1067 encapsulation inside IPsec. 1069 Intellectual Property Statement 1071 The IETF takes no position regarding the validity or scope of any 1072 intellectual property or other rights that might be claimed to 1073 pertain to the implementation or use of the technology described in 1074 this document or the extent to which any license under such rights 1075 might or might not be available; neither does it represent that it 1076 has made any effort to identify any such rights. Information on the 1077 IETF's procedures with respect to rights in standards-track and 1078 standards-related documentation can be found in BCP-11. Copies of 1079 claims of rights made available for publication and any assurances of 1080 licenses to be made available, or the result of an attempt made to 1081 obtain a general license or permission for the use of such 1082 proprietary rights by implementors or users of this specification can 1083 be obtained from the IETF Secretariat. 1085 The IETF invites any interested party to bring to its attention any 1086 copyrights, patents or patent applications, or other proprietary 1087 rights which may cover technology that may be required to practice 1088 this standard. Please address the information to the IETF Executive 1089 Director. 1091 Full Copyright Statement 1093 Copyright (C) The Internet Society (2004). All Rights Reserved. 1095 This document and translations of it may be copied and furnished to 1096 others, and derivative works that comment on or otherwise explain it 1097 or assist in its implementation may be prepared, copied, published 1098 and distributed, in whole or in part, without restriction of any 1099 kind, provided that the above copyright notice and this paragraph are 1100 included on all such copies and derivative works. However, this 1101 document itself may not be modified in any way, such as by removing 1102 the copyright notice or references to the Internet Society or other 1103 Internet organizations, except as needed for the purpose of 1104 developing Internet standards in which case the procedures for 1105 copyrights defined in the Internet Standards process must be 1106 followed, or as required to translate it into languages other than 1107 English. 1109 The limited permissions granted above are perpetual and will not be 1110 revoked by the Internet Society or its successors or assignees. 1112 This document and the information contained herein is provided on an 1113 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1114 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1115 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1116 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1117 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1119 Acknowledgment 1121 Funding for the RFC Editor function is currently provided by the 1122 Internet Society.