idnits 2.17.1 draft-ietf-6man-flow-3697bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3697, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2460, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2205, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2205, updated by this document, for RFC5378 checks: 1997-09-01) (Using the creation date from RFC2460, updated by this document, for RFC5378 checks: 1997-07-30) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 13, 2011) is 4793 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-gont-6man-flowlabel-security-01 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-07) exists of draft-ietf-6man-flow-update-03 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3697 (Obsoleted by RFC 6437) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN S. Amante 3 Internet-Draft Level 3 4 Obsoletes: 3697 (if approved) B. Carpenter 5 Updates: 2205, 2460 (if approved) Univ. of Auckland 6 Intended status: Standards Track S. Jiang 7 Expires: September 14, 2011 Huawei Technologies Co., Ltd 8 J. Rajahalme 9 Nokia-Siemens Networks 10 March 13, 2011 12 IPv6 Flow Label Specification 13 draft-ietf-6man-flow-3697bis-02 15 Abstract 17 This document specifies the IPv6 Flow Label field and the minimum 18 requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding 19 labeled packets, and flow state establishment methods. Even when 20 mentioned as examples of possible uses of the flow labeling, more 21 detailed requirements for specific use cases are out of scope for 22 this document. 24 The usage of the Flow Label field enables efficient IPv6 flow 25 classification based only on IPv6 main header fields in fixed 26 positions. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 14, 2011. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. IPv6 Flow Label Specification . . . . . . . . . . . . . . . . 5 76 3. Stateless Flow Labeling Requirements . . . . . . . . . . . . . 7 77 4. Flow State Establishment Requirements . . . . . . . . . . . . 8 78 5. Essential correction to RFC 2205 . . . . . . . . . . . . . . . 8 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 80 6.1. Theft and Denial of Service . . . . . . . . . . . . . . . 8 81 6.2. IPsec and Tunneling Interactions . . . . . . . . . . . . . 10 82 6.3. Security Filtering Interactions . . . . . . . . . . . . . 10 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 85 9. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 91 1. Introduction 93 A flow is a sequence of packets sent from a particular source to a 94 particular unicast, anycast, or multicast destination that a node 95 desires to label as a flow. A flow could consist of all packets in a 96 specific transport connection or a media stream. However, a flow is 97 not necessarily 1:1 mapped to a transport connection. 99 Traditionally, flow classifiers have been based on the 5-tuple of the 100 source and destination addresses, ports, and the transport protocol 101 type. However, some of these fields may be unavailable due to either 102 fragmentation or encryption, or locating them past a chain of IPv6 103 extension headers may be inefficient. Additionally, if classifiers 104 depend only on IP layer headers, later introduction of alternative 105 transport layer protocols will be easier. 107 The usage of the 3-tuple of the Flow Label and the Source and 108 Destination Address fields enables efficient IPv6 flow 109 classification, where only IPv6 main header fields in fixed positions 110 are used. 112 The flow label could be used in both stateless and stateful 113 scenarios. A stateless scenario is one where a node that sets the 114 flow label value for all packets of a given flow does not need to 115 store any information about the flow, and any node that processes the 116 flow label in any way also does not need to store any information 117 after a packet has been processed. A stateful scenario is one where 118 a node that sets or processes the flow label value needs to store 119 information about the flow, including the flow label value. A 120 stateful scenario might also require a signaling mechanism to 121 establish flow state in the network. 123 The flow label can be used most simply in stateless scenarios. This 124 specification concentrates on the stateless model and how it can be 125 used as a default mechanism. Details of stateful models, signaling, 126 specific flow state establishment methods and their related service 127 models are out of scope for this specification. The basic 128 requirement for stateful models is set forth in Section 4. 130 The minimum level of IPv6 flow support consists of labeling the 131 flows. A specific goal is to enable and encourage the use of the 132 flow label for various forms of stateless load distribution, 133 especially across Equal Cost Multi-Path (EMCP) and/or Link 134 Aggregation Group (LAG) paths. ECMP and LAG are methods to bond 135 together multiple physical links used to procure the required 136 capacity necessary to carry an offered load greater than the 137 bandwidth of an individual physical link. IPv6 source nodes SHOULD 138 be able to label known flows (e.g., TCP connections, application 139 streams), even if the node itself does not require any flow-specific 140 treatment. Node requirements for stateless flow labeling are given 141 in Section 3. 143 This document replaces [RFC3697] and Appendix A of [RFC2460]. A 144 rationale for the changes made is documented in 145 [I-D.ietf-6man-flow-update]. The present document also includes a 146 correction to [RFC2205] concerning the flow label. 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. 152 2. IPv6 Flow Label Specification 154 The 20-bit Flow Label field in the IPv6 header [RFC2460] is used by a 155 node to label packets of a flow. A Flow Label of zero is used to 156 indicate packets not part of any flow. Packet classifiers can use 157 the triplet of Flow Label, Source Address, and Destination Address 158 fields to identify which flow a particular packet belongs to. 159 Packets are processed in a flow-specific manner by nodes that are 160 able to do so in a stateless manner, or that have been set up with 161 flow-specific state. The nature of the specific treatment and the 162 methods for flow state establishment are out of scope for this 163 specification. However, any node that sets flow label values 164 according to a stateful scheme MUST ensure that packets conform to 165 Section 3 of the present specification if they are sent outside the 166 network domain using the stateful scheme. 168 As specified below in Section 3, the normal expectation is that flow 169 label values are uniformly distributed. In this specification, it is 170 recommended below that a pseudo-random method should be used to 171 achieve such a uniform distribution. Intentionally, there are no 172 precise mathematical requirements placed on the distribution or the 173 pseudo-random method. 175 Once set to a non-zero value, the Flow Label MUST be delivered 176 unchanged to the destination node(s). A forwarding node MUST NOT 177 change the flow label value in an arriving packet if it is non-zero. 178 However, there are two qualifications to this rule: 179 1. Implementers are advised that forwarding nodes, especially those 180 acting as domain border devices, might nevertheless be configured 181 to change the flow label value in packets. This is undetectable, 182 unless some future version of IPsec authentication [RFC4302] 183 protects the flow label value. 185 2. To enable stateless load distribution at any point in the 186 Internet, a network domain should never export packets 187 originating within the domain whose flow label values do not 188 conform to Section 3. However, neither domain border egress 189 routers nor intermediate routers/devices (using a flow-label, for 190 example, as a part of an input-key for a load-distribution hash) 191 can determine by inspection that a value is not part of a uniform 192 distribution. Therefore, if nodes within a domain ignore the 193 recommendations of Section 3, and such packets are forwarded 194 outside the domain, this might result in undesirable operational 195 implications (e.g., congestion, reordering) for not only the 196 inappropriately flow-labelled packets, but also well-behaved 197 flow-labelled packets, during forwarding at various intermediate 198 devices. Thus, a domain must protect its peers by never 199 exporting inappropriately labelled packets originating within the 200 domain. This is why nodes using a stateful scheme must not set 201 the flow label to a non-zero and non-uniformly distributed value 202 if the packet will leave their domain. If it is known to a 203 border router that flow labels originated within the domain are 204 not uniformly distributed, it will need to set outgoing flow 205 labels in the same manner as described for forwarding nodes in 206 Section 3. 208 There is no way to verify whether a flow label has been modified en 209 route or whether it belongs to a uniform distribution. Therefore, no 210 Internet-wide mechanism can depend mathematically on immutable and 211 uniformly distributed flow labels; they have a "best effort" quality. 212 This leads to the following formal rules: 213 o Implementers should be aware that the flow label is an unprotected 214 field that could have been accidentally or intentionally changed 215 en route. Implementations MUST take appropriate steps to protect 216 themselves from being vulnerable to denial of service and other 217 types of attack that could result (see Section 6.1). 218 o Forwarding nodes such as routers and load balancers MUST NOT 219 depend only on Flow Label values being uniformly distributed. In 220 any usage such as a hash key for load distribution, the Flow Label 221 bits MUST be combined at least with bits from other sources within 222 the packet, so as to produce a constant hash value for each flow 223 and a suitable distribution of hash values across flows. 225 Although uniformly distributed flow label values are recommended 226 below, and will always be helpful for load balancing, it is unsafe to 227 assume their presence in the general case, and the use case needs to 228 work even if the flow label value is zero. 230 The use of the Flow Label field does not necessarily signal any 231 requirement on packet reordering. Especially, the zero label does 232 not imply that significant reordering is acceptable. 234 An IPv6 node that does not set the flow label to a non-zero value, or 235 make use of it in any way, MUST ignore it when receiving or 236 forwarding a packet. 238 3. Stateless Flow Labeling Requirements 240 This section defines the minimum requirements for stateless methods 241 of setting the flow label value. 243 To enable Flow Label based classification, source nodes SHOULD assign 244 each unrelated transport connection and application data stream to a 245 new flow. A typical definition of a flow for this purpose is any set 246 of packets carrying the same 5-tuple {dest addr, source addr, 247 protocol, dest port, source port}. 249 It is desirable that flow label values should be uniformly 250 distributed to assist load distribution. It is therefore RECOMMENDED 251 that source hosts support the flow label by setting the flow label 252 field for all packets of a given flow to the same uniformly 253 distributed pseudo-random value. Both stateful and stateless methods 254 of assigning a pseudo-random value could be used, but it is outside 255 the scope of this specification to mandate an algorithm. In a 256 stateless mechanism, the algorithm SHOULD ensure that the resulting 257 flow label values are unique with high probability. 259 An OPTIONAL algorithm for generating such a pseudo-random value is 260 described in [I-D.gont-6man-flowlabel-security]. 262 [[ NOTE TO RFC EDITOR: The preceding sentence should be deleted, and 263 the reference should be changed to Informative, if the cited draft is 264 not on the standards track at the time of publication. ]] 266 A source node which does not otherwise set the flow label MUST set 267 its value to zero. 269 A node that forwards a flow whose flow label value in arriving 270 packets is zero MAY set the flow label value. In that case, it is 271 RECOMMENDED that the forwarding node sets the flow label field for a 272 flow to a uniformly distributed pseudo-random value. 273 o The same considerations apply as to source hosts setting the flow 274 label; in particular, the normal case is that a flow is defined by 275 the 5-tuple. 276 o This option, if implemented, would presumably be used by first-hop 277 or ingress routers. It might place a considerable per-packet 278 processing load on them, even if they adopted a stateless method 279 of flow identification and label assignment. This is why the 280 principal recommendation is that the source host should set the 281 label. 283 The preceding rules taken together allow a given network domain to 284 include routers that set flow labels on behalf of hosts that do not 285 do so. They also recommend that flow labels exported to the Internet 286 are always either zero or uniformly distributed. 288 4. Flow State Establishment Requirements 290 A node that sets the flow label MAY also take part in a flow state 291 establishment method that results in assigning specific treatments to 292 specific flows, possibly including signaling. Any such method MUST 293 NOT disturb nodes taking part in the stateless model just described. 294 Further details are not discussed in this document. 296 5. Essential correction to RFC 2205 298 [RFC2460] reduced the size of the flow label field from 24 to 20 299 bits. The references to a 24 bit flow label field on pages 87 and 88 300 of [RFC2205] are updated accordingly. 302 6. Security Considerations 304 This section considers security issues raised by the use of the Flow 305 Label, primarily the potential for denial-of-service attacks, and the 306 related potential for theft of service by unauthorized traffic 307 (Section 6.1). Section 6.2 addresses the use of the Flow Label in 308 the presence of IPsec including its interaction with IPsec tunnel 309 mode and other tunneling protocols. We also note that inspection of 310 unencrypted Flow Labels may allow some forms of traffic analysis by 311 revealing some structure of the underlying communications. Even if 312 the flow label were encrypted, its presence as a constant value in a 313 fixed position might assist traffic analysis and cryptoanalysis. 315 The flow label is not protected in any way and can be forged by an 316 on-path attacker. On the other hand, a uniformly distributed pseudo- 317 random flow label cannot be readily guessed by an off-path attacker; 318 see [I-D.gont-6man-flowlabel-security] for further discussion. 320 6.1. Theft and Denial of Service 322 Since the mapping of network traffic to flow-specific treatment is 323 triggered by the IP addresses and Flow Label value of the IPv6 324 header, an adversary may be able to obtain unintended service by 325 modifying the IPv6 header or by injecting packets with false 326 addresses and/or labels. Theft of service is not further discussed 327 in this document, since it can only be analysed for specific stateful 328 methods of using the flow label. However, a denial of service attack 329 becomes possible in the stateless model when the modified or injected 330 traffic depletes the resources available to forward it and other 331 traffic streams. If a DoS attack were undertaken against a given 332 Flow Label (or set of Flow Labels), then traffic containing an 333 affected Flow Label might well experience worse-than-best-effort 334 network performance. 336 Note that since the treatment of IP headers by nodes is typically 337 unverified, there is no guarantee that flow labels sent by a node are 338 set according to the recommendations in this document. A man-in-the- 339 middle or injected-traffic denial of service attack specifically 340 directed at flow label handling would involve setting unusual flow 341 labels. For example, an attacker could set all flow labels reaching 342 a given router to the same arbitrary non-zero value, or could perform 343 rapid cycling of flow label values such that the packets of a given 344 flow will each have a different value. Either of these attacks would 345 cause a stateless load distribution algorithm to perform badly and 346 would cause a stateful mechanism to behave incorrectly. For this 347 reason, stateless mechanisms should not use the flow label alone to 348 control load distribution, and stateful mechanisms should include 349 explicit methods to detect and ignore suspect flow label values. 351 Since flows are identified by the 3-tuple of the Flow Label and the 352 Source and Destination Address, the risk of denial of service 353 introduced by the Flow Label is closely related to the risk of denial 354 of service by address spoofing. An adversary who is in a position to 355 forge an address is also likely to be able to forge a label, and vice 356 versa. 358 There are two issues with different properties: Spoofing of the Flow 359 Label only, and spoofing of the whole 3-tuple, including Source and 360 Destination Address. 362 The former can be done inside a node which is using or transmitting 363 the correct source address. The ability to spoof a Flow Label 364 typically implies being in a position to also forge an address, but 365 in many cases, spoofing an address may not be interesting to the 366 spoofer, especially if the spoofer's goal is theft of service, rather 367 than denial of service. 369 The latter can be done by a host which is not subject to ingress 370 filtering [RFC2827] or by an intermediate router. Due to its 371 properties, this is typically useful only for denial of service. In 372 the absence of ingress filtering, almost any third party could 373 instigate such an attack. 375 In the presence of ingress filtering, forging a non-zero Flow Label 376 on packets that originated with a zero label, or modifying or 377 clearing a label, could only occur if an intermediate system such as 378 a router was compromised, or through some other form of man-in-the- 379 middle attack. 381 6.2. IPsec and Tunneling Interactions 383 The IPsec protocol, as defined in [RFC4301], [RFC4302], [RFC4303] 384 does not include the IPv6 header's Flow Label in any of its 385 cryptographic calculations (in the case of tunnel mode, it is the 386 outer IPv6 header's Flow Label that is not included). Hence 387 modification of the Flow Label by a network node has no effect on 388 IPsec end-to-end security, because it cannot cause any IPsec 389 integrity check to fail. As a consequence, IPsec does not provide 390 any defense against an adversary's modification of the Flow Label 391 (i.e., a man-in-the-middle attack). 393 IPsec tunnel mode provides security for the encapsulated IP header's 394 Flow Label. A tunnel mode IPsec packet contains two IP headers: an 395 outer header supplied by the tunnel ingress node and an encapsulated 396 inner header supplied by the original source of the packet. When an 397 IPsec tunnel is passing through nodes performing flow classification, 398 the intermediate network nodes operate on the Flow Label in the outer 399 header. At the tunnel egress node, IPsec processing includes 400 removing the outer header and forwarding the packet (if required) 401 using the inner header. The IPsec protocol requires that the inner 402 header's Flow Label not be changed by this decapsulation processing 403 to ensure that modifications to label cannot be used to launch theft- 404 or denial-of-service attacks across an IPsec tunnel endpoint. This 405 document makes no change to that requirement; indeed it forbids 406 changes to the Flow Label. 408 When IPsec tunnel egress decapsulation processing includes a 409 sufficiently strong cryptographic integrity check of the encapsulated 410 packet (where sufficiency is determined by local security policy), 411 the tunnel egress node can safely assume that the Flow Label in the 412 inner header has the same value as it had at the tunnel ingress node. 414 This analysis and its implications apply to any tunneling protocol 415 that performs integrity checks. Of course, any Flow Label set in an 416 encapsulating IPv6 header is subject to the risks described in the 417 previous section. 419 6.3. Security Filtering Interactions 421 The Flow Label does nothing to eliminate the need for packet 422 filtering based on headers past the IP header, if such filtering is 423 deemed necessary for security reasons on nodes such as firewalls or 424 filtering routers. 426 However, security devices that clear or rewrite non-zero flow label 427 values would be in violation of this specification. 429 7. IANA Considerations 431 This document requests no action by IANA. 433 8. Acknowledgements 435 Steve Deering and Alex Conta were co-authors of RFC 3697, on which 436 this document is based. 438 Valuable comments and contributions were made by Fred Baker, Steve 439 Blake, Remi Despres, Alan Ford, Fernando Gont, Brian Haberman, Tony 440 Hain, Joel Halpern, Qinwen Hu, Chris Morrow, Thomas Narten, Mark 441 Smith, Pascal Thubert, Iljitsch van Beijnum, and other participants 442 in the 6man working group. 444 Contributors to the development of RFC 3697 included Ran Atkinson, 445 Steve Blake, Jim Bound, Francis Dupont, Robert Elz, Tony Hain, Robert 446 Hancock, Bob Hinden, Christian Huitema, Frank Kastenholz, Thomas 447 Narten, Charles Perkins, Pekka Savola, Hesham Soliman, Michael 448 Thomas, Margaret Wasserman, and Alex Zinin. 450 This document was produced using the xml2rfc tool [RFC2629]. 452 9. Change log 454 draft-ietf-6man-flow-3697bis-02: update to remove most text about 455 stateful methods, 2011-03-13 457 draft-ietf-6man-flow-3697bis-01: update after resolving 11 initial 458 issues, 2011-02-26 460 draft-ietf-6man-flow-3697bis-00: original version, built from RFC3697 461 and draft-ietf-6man-flow-update-01, 2011-01-31 463 10. References 464 10.1. Normative References 466 [I-D.gont-6man-flowlabel-security] 467 Gont, F., "Security Assessment of the IPv6 Flow Label", 468 draft-gont-6man-flowlabel-security-01 (work in progress), 469 November 2010. 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, March 1997. 474 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 475 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 476 Functional Specification", RFC 2205, September 1997. 478 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 479 (IPv6) Specification", RFC 2460, December 1998. 481 10.2. Informative References 483 [I-D.ietf-6man-flow-update] 484 Amante, S., Carpenter, B., and S. Jiang, "Rationale for 485 update to the IPv6 flow label specification", 486 draft-ietf-6man-flow-update-03 (work in progress), 487 February 2011. 489 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 490 June 1999. 492 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 493 Defeating Denial of Service Attacks which employ IP Source 494 Address Spoofing", BCP 38, RFC 2827, May 2000. 496 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, 497 "IPv6 Flow Label Specification", RFC 3697, March 2004. 499 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 500 Internet Protocol", RFC 4301, December 2005. 502 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 503 December 2005. 505 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 506 RFC 4303, December 2005. 508 Authors' Addresses 510 Shane Amante 511 Level 3 Communications, LLC 512 1025 Eldorado Blvd 513 Broomfield, CO 80021 514 USA 516 Email: shane@level3.net 518 Brian Carpenter 519 Department of Computer Science 520 University of Auckland 521 PB 92019 522 Auckland, 1142 523 New Zealand 525 Email: brian.e.carpenter@gmail.com 527 Sheng Jiang 528 Huawei Technologies Co., Ltd 529 Huawei Building, No.3 Xinxi Rd., 530 Shang-Di Information Industry Base, Hai-Dian District, Beijing 531 P.R. China 533 Email: shengjiang@huawei.com 535 Jarno Rajahalme 536 Nokia-Siemens Networks 537 TBD 538 TBD 539 Finland 541 Email: jarno.rajahalme@nsn.com