idnits 2.17.1 draft-irtf-hiprg-nat-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 550. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == 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 (May 15, 2006) is 6527 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.ietf-hip-mm' is defined on line 452, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-hip-arch (ref. 'I-D.ietf-hip-arch') == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. 'I-D.ietf-hip-base') ** Downref: Normative reference to an Informational RFC: RFC 2663 == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-02 == Outdated reference: A later version (-11) exists of draft-ietf-midcom-mib-06 -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 4091 (Obsoleted by RFC 5245) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP Research Group M. Stiemerling 3 Internet-Draft J. Quittek 4 Expires: November 16, 2006 L. Eggert 5 NEC 6 May 15, 2006 8 NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) 9 Communication 10 draft-irtf-hiprg-nat-02 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 This document may not be modified, and derivative works of it may not 19 be created, except to publish it as an RFC and to translate it into 20 languages other than English. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 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 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on November 16, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 The Host Identity Protocol (HIP) changes the way in which two 47 Internet hosts communicate. One key advantage over other schemes is 48 that HIP does not require modifications to the traditional network- 49 layer functionality of the Internet, i.e., its routers. In the 50 current Internet, however, many devices other than routers modify the 51 traditional network-layer behavior of the Internet. These 52 "middleboxes" are intermediary devices that perform functions other 53 than the standard functions of an IP router on the datagram path 54 between source and destination hosts. Whereas some types of 55 middleboxes may not interfere with HIP at all, others can affect some 56 aspects of HIP communication and others can render HIP communication 57 impossible. This document discusses the problems associated with HIP 58 communication across network paths that include specific types of 59 middleboxes, namely, network address translators and firewalls. It 60 identifies and discusses issues in the current HIP specifications 61 that affect communication across these types of middleboxes. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. HIP Across NATs . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1 Phase 1: HIP Base Exchange . . . . . . . . . . . . . . . . 4 68 2.1.1 IPv4 HIP Base Exchange . . . . . . . . . . . . . . . . 4 69 2.1.2 IPv6 HIP Base Exchange . . . . . . . . . . . . . . . . 5 70 2.2 Phase 2: ESP Data Exchange . . . . . . . . . . . . . . . . 5 71 3. HIP Across Firewalls . . . . . . . . . . . . . . . . . . . . . 6 72 3.1 Phase 1: HIP Base Exchange . . . . . . . . . . . . . . . . 6 73 3.1.1 IPv4 HIP Base Exchange . . . . . . . . . . . . . . . . 6 74 3.1.2 IPv6 HIP Base Exchange . . . . . . . . . . . . . . . . 6 75 3.2 Phase 2: ESP Data Exchange . . . . . . . . . . . . . . . . 6 76 4. HIP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 7 77 5. NAT Extensions . . . . . . . . . . . . . . . . . . . . . . . . 7 78 6. Legacy NAT and Firewall Traversal . . . . . . . . . . . . . . 8 79 7. HIP Across Other Middleboxes . . . . . . . . . . . . . . . . . 9 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 10.1 Normative References . . . . . . . . . . . . . . . . . . . 10 84 10.2 Informative References . . . . . . . . . . . . . . . . . . 10 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 86 Intellectual Property and Copyright Statements . . . . . . . . 13 88 1. Introduction 90 The current specification of the Host Identity Protocol (HIP) 91 [I-D.ietf-hip-arch] assumes simple Internet paths, where routers 92 forward globally routable IP packets based on their destination 93 address alone. 95 In the current Internet, such pure paths are becoming increasingly 96 rare. For a number of reasons, several types of devices modify or 97 extend the pure forwarding functionality the Internet's network layer 98 used to deliver. [RFC3234] coins the term middleboxes for such 99 devices: "A middlebox is (...) any intermediary device performing 100 functions other than the normal, standard functions of an IP router 101 on the datagram path between a source host and destination host." 103 Middleboxes affect communication in a number of ways. For example, 104 they may inspect the flows of some transport protocols, such as TCP, 105 and selectively drop, insert or modify packets. If such devices 106 encounter a higher-layer protocol they do not support, or even a 107 variant of a supported protocol that they do not know how to handle, 108 communication across the middlebox may become impossible for these 109 kinds of traffic. 111 There are many different variants of middleboxes. The most common 112 ones are network address translators and firewalls. [RFC3234] 113 identifies many other types of middleboxes. One broad way of 114 classifying them is by behavior. The first group operates on 115 packets, does not modify application-layer payloads and does not 116 insert additional packets. This group includes NAT, NAT-PT, SOCKS 117 gateways, IP tunnel endpoints, packet classifiers, markers, 118 schedulers, transport relays, IP firewalls, application firewalls, 119 involuntary packet redirectors and anonymizers. 121 Other middleboxes exist, such as TCP performance-enhancing proxies, 122 application-level gateways, gatekeepers and session control boxes, 123 transcoders, proxies, caches, modified DNS servers, content and 124 applications distribution boxes, load balancers that divert or modify 125 URLs, application-level interceptors and application-level multicast 126 systems. However, NATs and firewalls are the most frequent 127 middleboxes HIP traffic can encounter in the Internet. Consequently, 128 this memo focuses on how NAT and firewall middleboxes can interfere 129 with HIP traffic. 131 Middleboxes can cause two different kinds of communication problems 132 for HIP. They can interfere with the transmission of HIP control 133 traffic or with the transmission of the HIP data traffic carried 134 within Encapsulating Security Payload (ESP) [RFC4303]. 136 This document serves mainly as a problem description that solution 137 proposals can reference. But it also discusses known approaches to 138 solving the problem and gives recommendations for certain approaches 139 depending on the specific scenario. It does not promote the use of 140 any of the discussed types of middleboxes. 142 This memo was discussed and modified in the Host Identity Protocol 143 Research Group and represents a consensus view of the research group 144 at the time of its submission for publication. 146 2. HIP Across NATs 148 This section focuses on the traversal of HIP across network address 149 translator (NAT) middleboxes. This document uses the term NAT for a 150 basic translation of IP addresses, whereas it uses the term NAPT for 151 NATs that additionally performs port translation [RFC2663], if a 152 differentiation between the two is important. 154 HIP operates in two phases. It first performs a HIP "base exchange" 155 handshake before starting to exchange application data in the second 156 phase. This section describes the problems that occur in each of the 157 two phases when NATs are present along the path from the HIP 158 initiator to the responder. 160 2.1 Phase 1: HIP Base Exchange 162 The HIP base exchange uses different transport mechanisms for IPv6 163 and IPv4. With IPv6, it uses a HIP-specific IPv6 extension header, 164 whereas it uses the IP payload with IPv4 [I-D.ietf-hip-base]. 166 2.1.1 IPv4 HIP Base Exchange 168 The HIP protocol specification [I-D.ietf-hip-base] suggests 169 encapsulating the IPv4 HIP base exchange in a new IP payload type. 170 The chances of NAT traversal for this traffic are different, 171 depending on the type of NAT in the path. The IPv4 HIP base exchange 172 traverses basic NATs (that translate IP addresses only) without 173 problems, if the NAT only interprets and modifies the IP header, 174 i.e., it does not inspect the IP payload. 176 However, basic NATs are rare. NAPT devices that inspect and 177 translate transport-layer port numbers are much more common. Because 178 the IP payload used for the IPv4 base exchange does not contain port 179 numbers or other demultiplexing fields, NAPTs cannot relay it. 181 A second issue is the well-known "data receiver behind a NAT" 182 problem. HIP nodes behind a NAT are not reachable unless they 183 initiate the communication themselves, because the necessary 184 translation state is otherwise not present at the NAT. 186 2.1.2 IPv6 HIP Base Exchange 188 The IPv6 HIP base exchange uses empty IPv6 packets (without a 189 payload). New HIP extension headers carry the base exchange 190 information. This approach can cause problems if NAT middleboxes 191 translate or multiplex IP addresses. 193 At this time, IPv6 NATs are rare. However, when they exist, IPv6 194 NATs operate similarly to IPv4 NATs. Consequently, they will likely 195 block IP payloads other than the "well-known" transport protocols. 196 This includes the IPv6 HIP base exchange, which does not contain any 197 IP payload. 199 2.2 Phase 2: ESP Data Exchange 201 HIP uses ESP to secure the data transmission between two HIP nodes 202 after the base exchange completes. Thus, HIP faces the same 203 challenges as IPsec with regard to NAT traversal. [RFC3715] 204 discusses these issues for IPsec and describes three distinct problem 205 categories: NAT-intrinsic issues, NAT implementation issues, and 206 helper incompatibilities. 208 This section focuses on the first category, i.e., NAT-intrinsic 209 issues. The two other problem categories are out of this document's 210 scope. They are addressed in the BEHAVE working group or in 211 [RFC3489]. 213 With ESP-encrypted data traffic, all upper-layer headers are 214 invisible to a NAT. Thus, changes of the IP header during NAT 215 traversal can invalidate upper-layer checksums contained within the 216 ESP-protected payload. HIP hosts already avoid this problem by 217 substituting Host Identity Tags (HITs) for IP addresses during 218 checksum calculations [I-D.ietf-hip-base]. 220 Although the traversal of ESP-encrypted packets across NATs is 221 possible, [RFC3715] notes that the Security Parameter Index (SPI) 222 values of such traffic have only one-way significance. NATs can use 223 SPI values to demultiplex different IPsec flows, similar to how they 224 use port number pairs to demultiplex unencrypted transport flows. 225 Furthermore, NATs may modify the SPIs, similar to how they modify 226 port numbers, when multiple IPsec nodes behind them happen to choose 227 identical SPIs. However, NATs can only observe the SPIs of outgoing 228 IPsec flows and cannot determine the SPIs of the corresponding return 229 traffic. 231 3. HIP Across Firewalls 233 This section focuses on the traversal of HIP across IP firewalls and 234 packet filters. These types of middleboxes inspects individual 235 packets and decides whether to forward, discard, or process them in 236 some special way, based on a set of filter rules and associated 237 actions. 239 Firewalls are not inherently problematic for HIP, as long as their 240 policy rules permit HIP base exchange and IPsec traffic to traverse. 241 The next sections discuss specific issues for HIP in typical firewall 242 configurations. 244 3.1 Phase 1: HIP Base Exchange 246 3.1.1 IPv4 HIP Base Exchange 248 A common and recommended configuration for IPv4 firewalls is to block 249 all unknown traffic by default and to allow well-known transport 250 protocols only and often just on specific ports and with specific 251 characteristics ("scrubbed" traffic). This common configuration 252 blocks the HIP base exchange. 254 3.1.2 IPv6 HIP Base Exchange 256 The configuration of IPv6 firewalls is similar to IPv4 firewalls. 257 Many IPv4 firewalls discard any IP packet that includes an IP option 258 [FW-CONF]. With IPv6, the expectation is that firewalls will block 259 IPv6 extension headers in general or will at least block unknown 260 extension headers. Furthermore, payloads other than specific, well- 261 known transport protocols are likely to be blocked as well. Like 262 IPv4, this behavior blocks the HIP base exchange. 264 A problem similar to the "data receiver behind a NAT" issue (see 265 Section 2.1.1) applies to both IPv4 and IPv6 firewalls. Typically, 266 firewalls block all traffic into the protected network that is not 267 identifiable return traffic of a prior outbound communication. This 268 means that HIP peers are not reachable outside the protected network, 269 because firewalls block base exchange attempts from outside peers. 271 3.2 Phase 2: ESP Data Exchange 273 Firewalls are less problematic than NATs with regard to passing ESP 274 traffic. The largest concern is commonly used firewall 275 configurations that block ESP traffic, because it is not a well-known 276 transport protocol and ports cannot be used to identify return flows. 277 However, firewalls could use mechanisms similar to Security Parameter 278 Index (SPI) multiplexed NAT (SPINAT) to use SPIs as flow identifiers 280 [YLITALO]. 282 4. HIP Extensions 284 This section identifies possible changes to HIP that attempt to 285 improve NAT and firewall traversal, specifically, the reachability of 286 HIP peers behind those middleboxes and traversal of the HIP base 287 exchange. Section 2 and Section 3 describe several problems related 288 to encapsulation schemes for the HIP base exchange in IPv4 and IPv6. 290 UDP may improve HIP operation in the presence of NATs and firewalls. 291 It may also aid traversal of other middleboxes, too. For example, 292 load balancers that use IP- and transport-layer information can 293 correctly operate with UDP-encapsulated HIP traffic. 295 HIP nodes located behind a NAT must notify their communication peers 296 about the contact information. The contact information is the NAT's 297 public IP address and a specific UDP port number. This measure 298 enables the peers to send return traffic to HIP nodes behind the NAT. 299 This would require a new HIP mechanisms. 301 To be reachable behind a NAT, a rendezvous point is required that 302 lets HIP nodes behind a NAT register an IP address and port number 303 that can be used to contact them. Depending on the type of NAT, use 304 of this rendezvous point may be required only during the base 305 exchange or throughout the duration of a communication instance. A 306 rendezvous point is also useful for HIP nodes behind firewalls, 307 because they suffer from an analogous problem, as described in 308 Section 3. 310 The proposed mobility management packet exchange [I-D.ietf-hip- 311 mm][NIKANDER] can support this method of NAT traversal. The original 312 intention of this extension is to support host mobility and multi- 313 homing. This mechanism is similar to the Alternate Network Address 314 Types (ANAT) described in [RFC4091]. However, HIP peers use mobility 315 management messages to notify peers about rendezvous points, similar 316 to [RFC4091]. HIP peers must determine their contact address before 317 they can announced it to their peers. 319 5. NAT Extensions 321 IPsec SPIs have only one-way significance, as described in 322 Section 2.2. Consequently, NATs and firewalls can observe the SPI 323 values of outgoing packets, but they cannot learn the SPI values of 324 the corresponding inbound return traffic in the same way. Two 325 methods exist: 327 First, NATs can observe the HIP base exchange and learn the SPI 328 values that HIP peers agree to use. Afterwards, NATs can map 329 outgoing and incoming IPsec flows accordingly. This approach is 330 called architectured NAT, or SPINAT [YLITALO], and can be used by 331 firewalls as well. It requires HIP-specific NAT modifications. 333 Second, HIP peers can use a generic NAT or firewall signaling 334 protocol to explicitly signal appropriate SPI values to their NATs 335 and firewalls. This approach does not require HIP-specific changes 336 at the middlebox, but does require integration of HIP with the 337 signaling protocol at the end systems. 339 Possible solutions for signaling SPI values are the mechanisms 340 proposed in the IETF NSIS WG (NATFW NSLP) and MIDCOM MIB module 341 [I-D.ietf-midcom-mib]. Using MIDCOM in the context of HIP requires 342 additional knowledge about network topology. For example, in multi- 343 homed environments with different border NATs or firewalls, a host 344 must know which of the multiple NATs/firewalls to signal. Therefore, 345 this solution can be problematic. 347 By using the NSIS NAT/FW traversal (NATFW NSLP) mechanism HIP nodes 348 can signal the used SPI values for both directions. NATFW NSLP 349 ensures that signaling messages will reach all NATs and firewalls 350 along the data path (path-coupled signaling). Although NSIS 351 generally support at both peers, the NATFW NSLP offers a "proxy mode" 352 for scenarios where only one end supports NSIS. This has deployment 353 advantages. 355 6. Legacy NAT and Firewall Traversal 357 The solutions outlined in Section 5 require that NATs and firewalls 358 are updated to support new functions, such as HIP itself or NSIS 359 NATFW signaling. NATs and firewalls are already widely deployed. It 360 will be impossible to upgrade or replace all such middleboxes with 361 HIP support. This section explores how HIP operates in the presence 362 of legacy NATs and firewalls that are not HIP-aware. Because the 363 vast majority of deployed NATs currently support IPv4 only, this 364 section focuses on them. 366 For HIP over IPv4, UDP encapsulation of HIP traffic already solves 367 some NAT traversal issues. Usually, UDP packets can traverse NATs 368 and firewalls when communication was initiated from the inside. 369 However, traffic initiated outside a NAT is typically dropped, 370 because it cannot be demultiplexed to the final destination (for 371 NATs) or is prohibited by policy (for firewalls). 373 Even when UDP encapsulation enables the HIP base exchange to succeed, 374 ESP still causes problems [RFC3715]. Some NAT implementations offer 375 "VPN pass-through", where the NAT learns about IPsec flows and tries 376 to correlate outgoing and incoming SPI values. This often works 377 reliably only for a small number of nodes behind a single NAT, due to 378 the possibility of SPI collisions. 380 A better solution may be to use UDP encapsulation for ESP [RFC3948], 381 enabled through a new parameter in the base exchange. It is for 382 further study whether to mandate UDP encapsulation for all HIP 383 traffic to reduce the complexity of the protocol. 385 HIP may also consider other NAT/firewall traversal mechanisms, such 386 as the widely deployed Universal Plug and Play (UPNP) [UPNP]. UPNP 387 can be used to configure middleboxes on the same link as a HIP node. 389 7. HIP Across Other Middleboxes 391 This document focuses on NAT and firewall middleboxes and does not 392 currently discuss other types identified in [RFC3234]. NATs and 393 firewalls are the most frequently deployed middleboxes at the time of 394 writing. However, future versions of this document may describe how 395 HIP interacts with other types of middleboxes. 397 8. Security Considerations 399 Opening pinholes in firewalls (i.e., loading firewall rules allowing 400 packets to traverse) and creating NAT bindings are highly security- 401 sensitive actions. Any mechanism that does so in order to support 402 HIP traversal across middleboxes should be well protected. Detailed 403 discussion of the related security issues can be found in the 404 security considerations sections of the corresponding standards 405 documents, such as [RFC3715] and [I-D.ietf-midcom-mib]. 407 This document has not considered whether some of the options listed 408 above pose additional threats to security of the HIP protocol itself. 410 9. Acknowledgments 412 The following people have helped to improve this document through 413 thoughtful suggestions and feedback: Pekka Nikander, Tom Henderson, 414 and the HIP research group. The authors would like to thank the 415 final reviewers Kevin Fall, Mark Allman, and Karen Sollins. 417 Lars Eggert and Martin Stiemerling are partly funded by Ambient 418 Networks, a research project supported by the European Commission 419 under its Sixth Framework Program. The views and conclusions 420 contained herein are those of the authors and should not be 421 interpreted as necessarily representing the official policies or 422 endorsements, either expressed or implied, of the Ambient Networks 423 project or the European Commission. 425 10. References 427 10.1 Normative References 429 [I-D.ietf-hip-arch] 430 Moskowitz, R. and P. Nikander, "Host Identity Protocol 431 Architecture", draft-ietf-hip-arch-03 (work in progress), 432 August 2005. 434 [I-D.ietf-hip-base] 435 Moskowitz, R., "Host Identity Protocol", 436 draft-ietf-hip-base-04 (work in progress), October 2005. 438 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 439 Translator (NAT) Terminology and Considerations", 440 RFC 2663, August 1999. 442 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 443 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 444 RFC 3948, January 2005. 446 10.2 Informative References 448 [FW-CONF] CERT Web Site, "Configure firewall packet filtering", Web 449 Site http://www.cert.org/security-improvement/practices/ 450 p058.html, July 2005. 452 [I-D.ietf-hip-mm] 453 Nikander, P., "End-Host Mobility and Multihoming with the 454 Host Identity Protocol", draft-ietf-hip-mm-02 (work in 455 progress), July 2005. 457 [I-D.ietf-midcom-mib] 458 Quittek, J., "Definitions of Managed Objects for Middlebox 459 Communication", draft-ietf-midcom-mib-06 (work in 460 progress), January 2006. 462 [NIKANDER] 463 Nikander, P., Ylitalo, J., and J. Wall, "Integrating 464 Security, Mobility, and Multi-Homing in a HIP Way", Proc. 465 Network and Distributed Systems Security Symposium 466 (NDSS) 2003, February 2003. 468 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 469 Issues", RFC 3234, February 2002. 471 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 472 "STUN - Simple Traversal of User Datagram Protocol (UDP) 473 Through Network Address Translators (NATs)", RFC 3489, 474 March 2003. 476 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 477 (NAT) Compatibility Requirements", RFC 3715, March 2004. 479 [RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network 480 Address Types (ANAT) Semantics for the Session Description 481 Protocol (SDP) Grouping Framework", RFC 4091, June 2005. 483 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 484 RFC 4303, December 2005. 486 [UPNP] UPNP Web Site, "Universal Plug and Play Web Site", Web 487 Site http://www.upnp.org/, July 2005. 489 [YLITALO] Ylitalo, J., Melen, J., Nikander, P., and V. Torvinen, 490 "Re-Thinking Security in IP-Based Micro-Mobility", Proc. 491 7th Information Security Conference (ISC) 2004, 492 September 2004. 494 Authors' Addresses 496 Martin Stiemerling 497 NEC Network Laboratories 498 Kurfuersten-Anlage 36 499 Heidelberg 69115 500 Germany 502 Phone: +49 6221 4342 113 503 Fax: +49 6221 4342 155 504 Email: stiemerling@netlab.nec.de 505 URI: http://www.netlab.nec.de/ 507 Juergen Quittek 508 NEC Network Laboratories 509 Kurfuersten-Anlage 36 510 Heidelberg 69115 511 Germany 513 Phone: +49 6221 4342 115 514 Fax: +49 6221 4342 155 515 Email: juergen.quittek@netlab.nec.de 516 URI: http://www.netlab.nec.de/ 517 Lars Eggert 518 NEC Network Laboratories 519 Kurfuersten-Anlage 36 520 Heidelberg 69115 521 Germany 523 Phone: +49 6221 4342 143 524 Fax: +49 6221 4342 155 525 Email: lars.eggert@netlab.nec.de 526 URI: http://www.netlab.nec.de/ 528 Intellectual Property Statement 530 The IETF takes no position regarding the validity or scope of any 531 Intellectual Property Rights or other rights that might be claimed to 532 pertain to the implementation or use of the technology described in 533 this document or the extent to which any license under such rights 534 might or might not be available; nor does it represent that it has 535 made any independent effort to identify any such rights. Information 536 on the procedures with respect to rights in RFC documents can be 537 found in BCP 78 and BCP 79. 539 Copies of IPR disclosures made to the IETF Secretariat and any 540 assurances of licenses to be made available, or the result of an 541 attempt made to obtain a general license or permission for the use of 542 such proprietary rights by implementers or users of this 543 specification can be obtained from the IETF on-line IPR repository at 544 http://www.ietf.org/ipr. 546 The IETF invites any interested party to bring to its attention any 547 copyrights, patents or patent applications, or other proprietary 548 rights that may cover technology that may be required to implement 549 this standard. Please address the information to the IETF at 550 ietf-ipr@ietf.org. 552 Disclaimer of Validity 554 This document and the information contained herein are provided on an 555 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 556 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 557 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 558 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 559 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 560 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 562 Copyright Statement 564 Copyright (C) The Internet Society (2006). This document is subject 565 to the rights, licenses and restrictions contained in BCP 78, and 566 except as set forth therein, the authors retain all their rights. 568 Acknowledgment 570 Funding for the RFC Editor function is currently provided by the 571 Internet Society.