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