idnits 2.17.1 draft-weis-gdoi-mac-tek-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (September 12, 2011) is 4607 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 informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MSEC Working Group B. Weis 3 Internet-Draft S. Rowles 4 Intended status: Standards Track Cisco Systems 5 Expires: March 15, 2012 September 12, 2011 7 GDOI Generic Message Authentication Code Policy 8 draft-weis-gdoi-mac-tek-03 10 Abstract 12 A number of IETF signaling and routing applications require a set of 13 devices to share the same policy and keying material and include a 14 message authentication code in their protocols packets for 15 authentication . It is often beneficial for this keying material to 16 be chosen dynamically using a group key management protocol. This 17 memo describes the policy required for the Group Domain of 18 Interpretation (GDOI) group key management system to distribute a 19 message authentication code key and associated policy. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 15, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 3 59 2. GDOI Discussion . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. New GDOI Payload Definitions . . . . . . . . . . . . . . . . . 5 62 3.1. Message Authentication Code Policy SA TEK . . . . . . . . 5 63 3.1.1. Application Types . . . . . . . . . . . . . . . . . . 6 64 3.1.2. MAC Algorithm Types . . . . . . . . . . . . . . . . . 7 65 3.1.3. Anti-Replay Types . . . . . . . . . . . . . . . . . . 7 66 3.1.4. Application-Specific Policy Attributes . . . . . . . . 7 67 3.2. Key Packet definition for MACs . . . . . . . . . . . . . . 7 69 4. RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.1. RSVP SA TEK Policy . . . . . . . . . . . . . . . . . . . . 9 71 4.2. Anti-Replay Discussion . . . . . . . . . . . . . . . . . . 9 72 4.3. Application-specific attributes . . . . . . . . . . . . . 10 74 5. NLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.1. NLS SA TEK Policy . . . . . . . . . . . . . . . . . . . . 11 76 5.2. Application-specific attributes . . . . . . . . . . . . . 11 78 6. Requirements for adding additional application support . . . . 12 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 86 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 92 The Group Domain of Interpretation (GDOI) [I-D.ietf-msec-gdoi-update] 93 is a group key management protocol fitting into the Multicast 94 Security Group Key Management Architecture [RFC3740]. GDOI is used 95 to disseminate group security policy and keying material to group 96 members for use with a particular cryptographic system. GDOI 97 describes the distribution of group security policy and keying 98 material for network traffic protected by IPsec [RFC4301], however 99 group security policy and keying material for other types of 100 cryptographic systems can also be distributed by GDOI as well. 102 A number of transport and routing protocol specifications specify a 103 MAC to provide packet authentication between devices. When the 104 protocol instantiation includes a group of devices, they all need to 105 share a common set of authentication policy and keying material to 106 create and validate the Message Authentication Code (MAC) included in 107 protocol packets. The requirements for each of the protocol 108 specifications are generally similar. This document describes how 109 GDOI can be used to distribute the group authentication policy and 110 keying material for these protocols. 112 This memo refers to candidate protocol specifications as 113 "applications" of the GDOI Generic Message Authentication Code 114 Policy. Policy distribution for two applications is described: 115 Resource reSerVation Protocol (RSVP) and Network Layer Signaling 116 (NLS). 118 1.1. Scope 120 This memo is intended to provide policy for applications not 121 specifying the use of ESP [RFC4303] or AH [RFC4302] for 122 authentication. Such applications SHOULD use the relevant payload 123 definitions described in [I-D.ietf-msec-gdoi-update]. Group 124 applications requiring the use of encryption MUST NOT use payloads 125 described in this memo, and are encouraged to use ESP. 127 1.2. Requirements notation 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 2. GDOI Discussion 135 This section provides a short informative discussion of the GDOI 136 group key management protocol. For definitive information regarding 137 the GDOI protocol, please refer to [I-D.ietf-msec-gdoi-update]. For 138 more information on group security, please refer to RFC 3740. 140 The GDOI group key management protocol actively manages security 141 policy and keying material for a set of group members. GDOI begins 142 operation when a client application on the group member initiates a 143 request to the GDOI subsystem on the group member. The GDOI 144 subsystem "registers" to a GDOI Group Controller/Key Server (GCKS) 145 device using the GROUPKEY_PULL protocol. The group member and GCKS 146 setup a private and authenticated exchange. After successful 147 authentication and authorization, the GCKS provides group security 148 policy and keying material to the GDOI subsystem on the group member. 149 When the GDOI subsystem on the group member receives both security 150 policy and keying material, it makes it available to the client 151 application on the device that originally requested the MAC policy. 153 The GDOI key server also distributes policy and keys that describe 154 how it will distribute updates to group policy over time. Described 155 in GDOI as the GROUPKEY_PUSH message, it is more generally known as a 156 "rekey" message. Rekey messages are typically distributed as IP 157 multicast packets. They provide replacement security policy and 158 keying material to group members (e.g., prior to a key expiration) or 159 to revoke group members in a manner that is non-disruptive to the 160 extant group members. 162 3. New GDOI Payload Definitions 164 The following sections describe how the GDOI Generic Message 165 Authentication Code Policy is applied to GDOI protocol payloads. 166 There are two affected payloads: the Security Association (SA) 167 payload and the Key Download (KD) payload. 169 The GDOI SA payload includes a set of SA attribute payloads, 170 including an SA attribute payload which distributes a definition of 171 the traffic to be secured. This payload is known as the SA TEK. 172 This memo describes a new type of SA TEK for distributing GDOI 173 Generic Message Authentication Code Policy. For more information on 174 the SA TEK attribute payload, please refer to Section 5.5 of 175 [I-D.ietf-msec-gdoi-update]. 177 The GDOI KD payload carries keying material associated with policy 178 previously distributed in SA attribute payloads. This memo does not 179 define any new types of key policy for the Message Authentication 180 Protocol Policy, but does place restrictions on the types of keys 181 that can be distributed. 183 3.1. Message Authentication Code Policy SA TEK 185 This section describes the SA TEK payload used to distribute MAC 186 policy. Protocols that use a MAC typically define a limited number 187 of policy attributes associated with the MAC. These policy 188 attributes are described in the MAC SA TEK. 190 The GDOI subsystem on a group member must maintain separation between 191 client applications, and as such needs to know what application 192 requested a particular set of policy. Thus, the SA TEK includes an 193 Application field naming the correct application with the group 194 member. In some instances, client applications define additional 195 policy, and this policy is described in a set of application-specific 196 policy attributes attached to the SA TEK. 198 A GDOI key server may distribute more than on SA TEK for a particular 199 Application. In particular, the Application-Specific Policy 200 Attributes may describe discrete instances of an application. 202 0 1 2 3 203 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 205 ! Application | MAC Algorithm ! Anti-Replay ! 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 207 ! Key Lifetime ! 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 ! SPI Size ! SPI ~ 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 211 ! Application-Specific Policy Attributes ~ 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 214 The SA TEK Payload fields are defined as follows: 216 o Application (2 octets -- Value describing the client application. 217 Application types are defined below. Values are defined in the 218 IANA Considerations section. 220 o MAC Algorithm (1 octet) -- Value specifying which Message 221 Authentication Code (MAC) used to generate MAC. MAC Algorithm 222 types are defined below. Values are defined in the IANA 223 Considerations section. 225 o Anti-Replay (1 octet) -- Value specifying the type of anti-replay 226 protection that is used with this application. Anti-replay types 227 are defined below. Values are defined in the IANA Considerations 228 section. 230 o Key Lifetime (4 octets) -- Value specifying the remaining lifetime 231 of the SA TEK, in seconds. A time of zero indicates that the use 232 of this policy does not terminate based on time. 234 o SPI Size (1 octet) -- Length (in octets) of the SPI associated 235 with this SA TEK. 237 o SPI (Variable) -- Value describing the identity of the key. The 238 key identifier uniquely defines an SA TEK. 240 o Application-Specific Policy Attributes (Variable) -- TLV policy 241 attributes specific to this application. These attributes are 242 defined by client application-specific policy. 244 3.1.1. Application Types 246 The following Client Applications are defined for use with the MAC SA 247 TEK. 249 o RSVP. The Resource reSerVation Protocol [RFC3097] 251 o NLS. Network Layer Signaling protocol [I-D.shore-nls-tl] 253 Other protocols may be defined for use with the Generic Message 254 Authentication Code Policy SA TEK. However, they must first satisfy 255 the requirements described in Section 4. 257 3.1.2. MAC Algorithm Types 259 The following MAC algorithms are defined for use with this TEK. 261 o HMAC-MD5. The MD5 algorithm used with an HMAC construction 262 [RFC2104]. This MAC algorithm is considered weak, but is required 263 by some protocols. 265 o HMAC-SHA1-96. The SHA1 algorithm used with an HMAC construction, 266 with a length truncated to 96 bits.[RFC2104]. 268 3.1.3. Anti-Replay Types 270 The following methods of constructing sequence numbers is defined for 271 use with this TEK. 273 o NONE. This value indicates that no anti-replay protection is used 274 with this TEK. 276 o COUNTER. Counters (also known as sequence numbers) provide anti- 277 replay protection in an application-specific manner. 279 o TIME. Values from a clock are used for replay protection in an 280 application-specific manner. 282 3.1.4. Application-Specific Policy Attributes 284 Application-Specific Attributes are defined for each application that 285 requires them. The attributes must follow the format defined in 286 ISAKMP [RFC2408] Section 3.3. In the table, attributes that are 287 defined as TV are marked as Basic (B); attributes that are defined as 288 TLV are marked as Variable (V). Values are defined in the IANA 289 Considerations section. 291 3.2. Key Packet definition for MACs 293 Keying material is distributed in a Key Packet as part of the GDOI KD 294 payload. The Key packet is formed as follows. 296 o KD Type. The type of KD MUST be TEK. 298 o SPI. The SPI from the SA TEK is placed in the SPI field. 300 o Key. The keying material for the MAC algorithm is placed in a 301 TEK_INTEGRITY_KEY attribute. 303 The Key Packet MUST NOT contain a TEK_ALGORITHM_KEY or 304 TEK_SOURCE_AUTH_KEY attribute. 306 4. RSVP 308 The RSVP protocol provides a means for establishing resource 309 reservations between cooperating systems. To ensure the integrity of 310 the associated reservation and admission control mechanisms, the RSVP 311 INTEGRITY Option defined in [RFC2747] and [RFC3097] may be used. 312 These protect RSVP message integrity hop-by-hop and provide node 313 authentication as well as replay protection, thereby protecting 314 against corruption and spoofing of RSVP messages. In some network 315 configurations, a group of cooperating devices exchange RSVP packets 316 such that the sender of an RSVP packet cannot determine a priori 317 which RSVP device will be receiving it. These cooperating devices 318 can benefit from sharing the same group policy and keying material. 319 [I-D.ietf-tsvwg-rsvp-security-groupkeying] presents a framework for 320 RSVP security using dynamic group keying and discusses its 321 applicability. In line with this framework, this section describes 322 extensions to GDOI for distribution of security policy and keying 323 material for RSVP. 325 The policy distributed in this section meets the key management 326 assumptions made by the RSVP Security Properties memo [RFC4230]. 328 4.1. RSVP SA TEK Policy 330 The following describes how the RSVP Integrity object policy is 331 represented in the MAC SA TEK payload. 333 o MAC Algorithm. This field maps to the Keyed Message Digest field 334 of the RFC 2747 INTEGRITY Object. Supported algorithms are: HMAC- 335 MD5 and HMAC-SHA1-96. 337 o Anti-Replay. COUNTER and TIME types are both valid types of anti- 338 replay protection. See a discussion of how they are used below. 340 o Key Lifetime. If the KeyStartValid optional attribute is included 341 in the SA TEK, this lifetime specifies the entire lifetime of the 342 SA TEK. Otherwise, it represents the partial remaining lifetime. 344 o SPI. This field matches the Key Identifier in the RFC 2747 345 INTEGRITY Object, and 347 o SPI Size. The length of the SPI MUST be 1 to 6 octets. 349 4.2. Anti-Replay Discussion 351 COUNTER corresponds to the Simple Sequence Numbers method defined in 352 Section 3.1 of RFC 2747. When COUNTER based sequence numbers are 353 used, each group member maintains its own sequence number for a given 354 group in order to set the sequence number field in RSVP messages 355 generated in this group. Therefore, an RSVP receiver MUST track 356 received sequence numbers separately for each RSVP neighbour in order 357 to reliably distinguish between new and replay messages. 359 TIME corresponds to the Sequence Numbers Based on a Real Time Clock 360 method described in Section 3.2 of RFC 2747 or the Sequence Numbers 361 Based on a Network Recovered Clock method described in Section 3.3 or 362 RFC 2747. 364 4.3. Application-specific attributes 366 o KeyStartValid (V). This attribute specifies an real time in the 367 future when the TEK will take effect [RFC2747]. Note that the 368 corresponding KeyEndValid time defined in RFC 2747 is not 369 distributed by GDOI, but is computed by adding the Key Lifetime 370 value to KeyStartValid. The KeyStartValid value is represented as 371 the number of seconds since 0 hours, 0 minutes, 0 seconds, January 372 1, 1970. 374 5. NLS 376 NLS [I-D.shore-nls-tl] is a core protocol for a generalized on-path 377 request protocol that is being used today to carry topology discovery 378 and other requests. NLS specifies the use of group security, where 379 group members share a MAC key. A MAC result is carried in the NLS 380 A_RESPONSE and B_RESPONSE TLVs, which consummate authenticated nonce 381 exchanges. A MAC result is also carried in the NLS AUTHENTICATION 382 TLV, which is used to ensure integrity of NLS messages. This TLV 383 also includes a Sequence Number for anti-replay protection. NLS 384 associates a set of Application Group IDs (AGIDs) with a particular 385 MAC key. Each AGID represents a unique authorization, within the 386 context of a particular NLS group. 388 5.1. NLS SA TEK Policy 390 The following describes how NLS policy is represented in the MAC SA 391 TEK payload. 393 o MAC Algorithm. This field maps to the Keyed Message Digest field 394 of the RFC 2747 INTEGRITY Object. Supported algorithms are: HMAC- 395 SHA1-96. 397 o Anti-Replay. The COUNTER type of anti-replay protection is 398 supported. 400 o Key Lifetime. NLS does not specify a validity period for policy. 401 This field MUST be set to zero. 403 o SPI. NLS does not specify a key identifier, but this field is 404 used by GDOI to synchronize policy distributed in an MAC SA TEK 405 and KD payloads. 407 o SPI Size. The length of the SPI MUST be 4 octets. 409 5.2. Application-specific attributes 411 o AGID (V). This attribute specifies a single NLS AGID that is 412 associated with this policy. Multiple AGIDs attributes (each 413 specifying a unique AGID) MAY be included in the SA TEK. 415 o Authz (V). This attribute contains a token used for 416 authorization. The format and usage of this authorization token 417 is outside of the scope of this memo. 419 6. Requirements for adding additional application support 421 Any memo supporting the definitions in the memo MUST include the 422 following information relating to the application: 424 o Define an Application Type mnemonic, and provide a reference to a 425 document describing the protocol specification. 427 o Define a set of MAC algorithms. 429 o Define anti-replay types. 431 o Define key lifetime parameters. 433 o Define valid SPI values and lengths. 435 o Description of Optional Attributes. 437 7. IANA Considerations 439 A new GDOI SA TEK type Protocol-ID type [GDOI-REG] should be assigned 440 from the Unassigned space. The new algorithm id should be called 441 GDOI_PROTO_MAC, and refers to the Message Authentication Code Policy 442 SA TEK described in Section 3.1 of this memo. 444 Terms describing policies for allocating new name space types below 445 are defined in [RFC5226]. 447 The following applications are defined as part of this memo. 449 Application Type Value 450 ------------------ ----- 451 RESERVED 0 452 RSVP 1 453 NLS 2 454 Specification Required 3-127 455 Private Use 128-255 457 The following MAC Algorithms are defined as a part of this memo. 459 MAC Algorithm Type Value 460 ------------------ ----- 461 RESERVED 0 462 HMAC-MD5 1 463 HMAC-SHA1-96 2 464 Specification Required 3-127 465 Private Use 128-255 467 The following Sequence Number Types are defined as a part of this 468 memo. 470 Sequence Number Type Value 471 -------------------- ----- 472 RESERVED 0 473 COUNTER 1 474 TIME 2 475 Specification Required 3-127 476 Private Use 128-255 478 The following Optional Attributes are defined as part of this memo, 479 used with an Application of type RSVP. 481 RSVP Optional Attribute Value 482 ----------------------- ----- 483 RESERVED 0 484 KeyStartValid 1 485 Specification Required 2-127 486 Private Use 128-255 488 The following Optional Attributes are defined as part of this memo, 489 used with an Application of type NLS. 491 NLS Optional Attribute Value 492 ---------------------- ----- 493 RESERVED 0 494 AGID 1 495 Authz 2 496 Specification Required 3-127 497 Private Use 128-255 499 8. Security Considerations 501 This memo describes the passing of policy and keying material used by 502 two applications: an RSVP speaker producing an RFC 2747 INTEGRITY 503 Object, and an NLS speaker producing A_RESPONSE, B_RESPONSE, and 504 AUTHENTICATION TLVs. This policy and keying material is protected by 505 the GDOI protocol described in [I-D.ietf-msec-gdoi-update]. The 506 security considerations in that memo apply fully to this memo as 507 well. 509 The use of the MAC SA TEK to distribute policy and keys is only 510 appropriate when the application is using a group security model. 511 [I-D.ietf-tsvwg-rsvp-security-groupkeying] describes the 512 circumstances when a group security model may be used with RSVP. NLS 513 always uses a group security model. 515 9. References 517 9.1. Normative References 519 [I-D.ietf-msec-gdoi-update] 520 Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 521 of Interpretation", draft-ietf-msec-gdoi-update-11 (work 522 in progress), August 2011. 524 9.2. Informative References 526 [GDOI-REG] 527 Internet Assigned Numbers Authority, "Group Domain of 528 Interpretation (GDOI) Payload Type Values", IANA Registry, 529 December 2004, 530 . 532 [I-D.ietf-tsvwg-rsvp-security-groupkeying] 533 Behringer, M., Faucheur, F., and B. Weis, "Applicability 534 of Keying Methods for RSVP Security", 535 draft-ietf-tsvwg-rsvp-security-groupkeying-11 (work in 536 progress), September 2011. 538 [I-D.shore-nls-tl] 539 Shore, M., McGrew, D., and K. Biswas, "Network-Layer 540 Signaling: Transport Layer", draft-shore-nls-tl-06 (work 541 in progress), July 2008. 543 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 544 Hashing for Message Authentication", RFC 2104, 545 February 1997. 547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, March 1997. 550 [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet 551 Security Association and Key Management Protocol 552 (ISAKMP)", RFC 2408, November 1998. 554 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 555 Authentication", RFC 2747, January 2000. 557 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 558 Authentication -- Updated Message Type Value", RFC 3097, 559 April 2001. 561 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 562 Architecture", RFC 3740, March 2004. 564 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security 565 Properties", RFC 4230, December 2005. 567 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 568 Internet Protocol", RFC 4301, December 2005. 570 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 571 December 2005. 573 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 574 RFC 4303, December 2005. 576 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 577 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 578 May 2008. 580 Authors' Addresses 582 Brian Weis 583 Cisco Systems 584 170 W. Tasman Drive 585 San Jose, California 95134-1706 586 USA 588 Phone: +1-408-526-4796 589 Email: bew@cisco.com 591 Sheela Rowles 592 Cisco Systems 593 170 W. Tasman Drive 594 San Jose, California 95134-1706 595 USA 597 Phone: +1-408-527-7677 598 Email: srowles@cisco.com