KARP Working Group Y. Wei, Ed. Internet-Draft H. Wang Intended status: Informational X. Liang Expires: April 26, 2011 ZTE Corporation C. Wan Southeast University October 23, 2010 Analysis of Security Association for Current Routing Protocols draft-wei-karp-analysis-rp-sa-01 Abstract This document analyzes the security associations used by current routing protocols, including RIPv2, OSPFv2, ISIS, BFD, and BGP. It also discusses the possible methods for the diversity issue of routing protocol security association (SA). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 26, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Wei, et al. Expires April 26, 2011 [Page 1] Internet-Draft RP SA October 2010 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 2. Analysis of Security Associations for Current Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Summary for Security Associations of Current Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Analysis of Security Associations of Current Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Discussion of Generic Security Association . . . . . . . . 8 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Informative references . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Appendix: Existing SA Definition . . . . . . . . . . 10 A.1. RIPv2 SA . . . . . . . . . . . . . . . . . . . . . . . . . 10 A.2. OSPFv2 SA . . . . . . . . . . . . . . . . . . . . . . . . 11 A.3. ISIS SA . . . . . . . . . . . . . . . . . . . . . . . . . 12 A.4. BFD SA . . . . . . . . . . . . . . . . . . . . . . . . . . 12 A.5. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 A.6. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 A.7. PCE . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 A.8. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 A.9. LMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 A.10. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 A.11. RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . 15 A.12. PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Wei, et al. Expires April 26, 2011 [Page 2] Internet-Draft RP SA October 2010 1. Introduction The karp (Keying and Authentication for Routing Protocols) working group aims to secure the packets on the wire of the routing protocol exchanges. This work has been divided into two phases, (1) Enhance the routing protocol's current authentication mechanism; (2) Develop an automated keying framework [I-D.ietf-karp-design-guide]. Currently, there are a variety of routing protocols. Many routing protocols (or groups of protocols) have already defined security association (SA) for cryptographic message authentication and integrity protection, which are listed in the appendix. SA is the basis for protecting the packet of routing protocol; it may also affect the design of key management protocol (KMP) and framework of the karp. As a start, it is desirable to analyze existing security associations of routing protocols. The main idea of this document is as follows: 1. Briefly overview of existing SA of routing protocols. 2. Compare those typical fields in routing protocol SA one by one, and identify potential issues. 3. Discuss the possible methods for that problem. 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. When used in lower case, these words convey their typical use in common language, and are not to be interpreted as described in RFC2119 [RFC2119]. 2. Analysis of Security Associations for Current Routing Protocols This section considers the security associations of the following routing protocols: RIPv2, OSPFv2, ISIS, BFD, PCE, LDP, MSDP,BGP,OSPFv3, LMP, RSVP-TE, PIM. Note: Maybe there are lacks of commonly accepted term - BGP SA. This document regards Master Key Tuple (MKT) in TCP-AO [RFC5925] as BGP SA. Wei, et al. Expires April 26, 2011 [Page 3] Internet-Draft RP SA October 2010 2.1. Summary for Security Associations of Current Routing Protocols The security associations of current routing protocol are summarized as follows: o The RIPv2 SA [RFC4822] includes the following information: key identifier, cryptographic algorithms, key length, sequence number, and life time of SA. o The OSPFv2 SA [RFC5709] includes the following information: key identifier, cryptographic algorithms, key length, and life time of SA. o The ISIS SA [RFC5310] includes the following information: key identifier, cryptographic algorithms, key length. o The BFD SA [I-D.bhatia-bfd-crypto-auth] includes the following information: key identifier, cryptographic algorithms, key. o The BGP, PCE, LDP, MSDP SA includes the following information[RFC5925]: key identifier, cryptographic algorithms, master key, key derivation function (KDF), sequence number, etc. o The OSPFv3, LMP, RSVP-TE, PIM SA includes the following information[RFC4301]: Security Parameter Index, Sequence Number Counter, Sequence Counter Overflow, Anti-Replay Window, AH Authentication algorithm and key, ESP Encryption algorithm and key and mode, ESP integrity algorithm and keys, ESP combined mode algorithms and key, Lifetime, IPsec protocol mode, Stateful fragment checking flag, Bypass DF bit, DSCP values, Bypass DSCP, Path MTU, Tunnel header IP source and destination address. The details of these SAs are listed in the appendix. 2.2. Analysis of Security Associations of Current Routing Protocols The fields in the above security associations are analyzed as follows: o Key identifier: Key identifier (Key ID) is used to uniquely identify a SA. All SAs used in routing protocols specify this field. For example, OSPFv2 SA defines Key Identifier field to identify an OSPF SA. Wei, et al. Expires April 26, 2011 [Page 4] Internet-Draft RP SA October 2010 Table 1 Key identifier field of SA +--------------/-----------------/------------------+ | SA of Routing| Name of Key ID | Length of Key ID | | Protocol | | | ---------------|-----------------|------------------- | RIPv2 | Key Identifier | 8 bits | ---------------|-----------------|------------------- | OSPFv2 | Key Identifier | 8 bits | ---------------|-----------------|------------------- | ISIS | Key Identifier | 2 octets | ---------------|-----------------|------------------- | BFD | Authentication | 2 octets | | | Key Identifier | | ---------------|-----------------|------------------- | TCP-AO | KeyID | 8 bits | ---------------|-----------------|------------------| |IPSEC | SPI | 32 bits | +--------------\-----------------\------------------+ The key identifier maybe manually be configured or generated by automated key management protocol (KMP) which is one ongoing work in karp. One obvious distinction among these routing protocols' SA is that the length of key ID is different. If KMP generates key ID according to specific routing protocol, the design of KMP will be complex and bound to underlying routing protocol. o Cryptographic algorithms and key: For the purpose of authentication and integrity protection, the algorithm and key are used to produce message authentication code (MAC), which is used to protect the packet on the wire. Typically, key length is related to a specific algorithm. Wei, et al. Expires April 26, 2011 [Page 5] Internet-Draft RP SA October 2010 Table 2 Algorithms and keys +----------------/-------------------/-----------------------------+ | SA of Routing | Algorithms | Key Length | | Protocol | | | -----------------|-------------------|------------------------------ | RIPv2 | KEYED-MD5, | The length is variable | | | HMAC-SHA-1, | and dependent on algorithm | | | HMAC-SHA-256, | | | | HMAC-SHA-384, | | | | HMAC-SHA-512. | | -----------------|-------------------|------------------------------ | OSPFv2 | Keyed-MD5, | Same as above | | | HMAC-SHA-1, | | | | HMAC-SHA-256, | | | | HMAC-SHA-384, | | | | HMAC-SHA-512 | | -----------------|-------------------|------------------------------ | ISIS | HMAC-SHA-1, | Same as above | | | HMAC-SHA-224, | | | | HMAC-SHA-256, | | | | HMAC-SHA-384, | | | | HMAC-SHA-512 | | -----------------|-------------------|------------------------------ | BFD | Keyed MD5, | Same as above | | | Keyed SHA-1, | | | | HMAC-SHA-1, | | | | HMAC-SHA-256, | | | | HMAC-SHA-384 | | | | HMAC-SHA-512 | | -----------------|-------------------|------------------------------ | TCP-AO | Keyed MD5 | Same as above | | | HMAC-SHA-1-96 | | | | AES-128-CMAC-96 | | -----------------|-------------------|-----------------------------| |IPSEC | HMAC_MD5_96 | Same as above | | | HMAC_SHA1_96 | | | | DES_MAC | | | | KPDK_MD5 | | | | AES_XCBC_96 | | +----------------\-------------------\-----------------------------+ Note: The IPSEC integrity algorithms are taken from Transform Type 3, section 3.3.2 of RFC4306. The cryptographic algorithms used in routing protocol are almost the same except for the protection of BGP, which is based on TCP-AO. This case also shows that manual configuration or KMP are also required to differentiate underlying routing protocol, which Wei, et al. Expires April 26, 2011 [Page 6] Internet-Draft RP SA October 2010 makes them complex. o Lifetime: It specifies whether the SA is valid or not. For example, OSPFv2 SA [RFC5709] uses four fields (Key Start Accept, Key Start Generate, Key Stop Generate, Key Stop Accept) to control the lifetime of the SA. Table 3 Lifetime +---------------/--------------------+ | SA of Routing | Fields | | Protocol | | ----------------|--------------------- | RIPv2 | Start Time | | | Stop Time | ----------------|--------------------- | OSPFv2 | Key Start Accept | | | Key Start Generate | | | Key Stop Generate | | | Key Stop Accept | ----------------|--------------------- | ISIS | None | ----------------|--------------------- | BFD | None | ----------------|--------------------- | TCP-AO | None | ----------------|--------------------- | IPSEC | time or byte count | +---------------\--------------------+ It can be seen that some routing protocols' SA define lifetime, others do not. This implies that underlying routing protocol does not exhibit unified interface to upper layer. In some cases, a rekeying mechanism is used to trigger the lifetime of SA. However, current routing protocol SA does not specify what to do when the key expires. o Sequence number: Sequence number is typically defined to avoid replay attacks. Wei, et al. Expires April 26, 2011 [Page 7] Internet-Draft RP SA October 2010 Table 4 Sequence number +---------------/---------------------+ | SA of Routing | Length of Sequence | | Protocol | number | --------------------------------------- | RIPv2 | 32bits | --------------------------------------- | OSPFv2 | 32bits | --------------------------------------- | ISIS | 32bits | --------------------------------------- | BFD | 32bits | --------------------------------------- | TCP-AO | 32bits | --------------------------------------- | IPSEC | 64bits | +---------------\---------------------+ The length of sequence number above is 32 bits, which is convenient to the manual configuration or KMP because it is unrelated to underlying routing protocol. 2.3. Discussion of Generic Security Association As shown in section 2.2, the definition and its value of SA is different for each routing protocol. This document just covers part of routing protocol. Some other routing protocols such as OSPFv3, RIPng depends on the protection of IPsec SA [RFC4301]. If this case is taken into consideration, the differences among these SAs are more bigger. It is required to consider the diversity of routing protocol SA when starting the karp's work. Here are two possible ways to deal with this issue. 1. Each routing protocol (or category) has its own specific manual configuration or KMP. The advantage is that it can be implemented easily and straightforwardly. The disadvantage is obvious: The system is complex and cumbersome because there exist a dozen of routing protocols. In this case, the karp's work seems complicated. 2. A generic SA (gSA) is introduced to hide the diversity of underlying routing protocol SA. It can be regarded as abstract layer; it is a bridge between manual configuration or KMP protocol and routing protocol. The advantages are as follows: 1. It provides a unified interface to manual configuration or KMP protocol. Wei, et al. Expires April 26, 2011 [Page 8] Internet-Draft RP SA October 2010 2. It decouples KMP with underlying routing protocol, which addresses the requirement identified in [I-D.ietf-karp-threats-reqs]. 3. KMP and routing protocol can be evolved independently. 4. The complexity of the design of KMP is greatly reduced. The disadvantage of this method may be that a new layer is added, which produces extra cost. 3. IANA Considerations To be completed. 4. Security Considerations To be completed. 5. Informative references [I-D.bhatia-bfd-crypto-auth] Bhatia, M. and V. Manral, "BFD Generic Cryptographic Authentication", draft-bhatia-bfd-crypto-auth-02 (work in progress), June 2010. [I-D.ietf-karp-design-guide] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", draft-ietf-karp-design-guide-01 (work in progress), September 2010. [I-D.ietf-karp-threats-reqs] Lebovitz, G., Bhatia, M., and R. White, "The Threat Analysis and Requirements for Cryptographic Authentication of Routing Protocols' Transports", draft-ietf-karp-threats-reqs-01 (work in progress), October 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. Wei, et al. Expires April 26, 2011 [Page 9] Internet-Draft RP SA October 2010 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204, October 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009. [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010. Appendix A. Appendix: Existing SA Definition This section is for information. It can be safely removed in the future. A.1. RIPv2 SA RIPv2 Security Association[RFC4822]: Wei, et al. Expires April 26, 2011 [Page 10] Internet-Draft RP SA October 2010 KEY-IDENTIFIER (KEY-ID) - The unsigned 8-bit KEY-ID value is used to identify the RIPv2 Security Association in use for this packet. AUTHENTICATION ALGORITHM - This specifies the cryptographic algorithm and algorithm mode used with the RIPv2 Security Association. AUTHENTICATION KEY - This is the value of the cryptographic authentication key used with the associated Authentication Algorithm. SEQUENCE NUMBER - This is an unsigned 32-bit number. START TIME - This is a local representation of the day and time that this Security Association first becomes valid. STOP TIME - This is a local representation of the day and time that this Security Association becomes invalid. A.2. OSPFv2 SA OSPFv2 Security Association [RFC5709]: Key Identifier (KeyID) - This is an 8-bit unsigned value used to uniquely identify an OSPFv2 SA and is configured either by the router administrator (or, in the future, possibly by some key management protocol specified by the IETF). The receiver uses this to locate the appropriate OSPFv2 SA to use. The sender puts this KeyID value in the OSPF packet based on the active OSPF configuration. Authentication Algorithm - This indicates the authentication algorithm (and also the cryptographic mode, such as HMAC) to be used. This information SHOULD never be sent over the wire in cleartext form. At present, valid values are Keyed-MD5, HMAC-SHA-1, HMAC-SHA- 256, HMAC-SHA-384, and HMAC-SHA-512. Authentication Key - This is the cryptographic key used for cryptographic authentication with this OSPFv2 SA. Key Start Accept - The time that this OSPF router will accept packets that have been created with this OSPF Security Association. Key Start Generate - The time that this OSPF router will begin using this OSPF Security Association for OSPF packet generation. Key Stop Generate - The time that this OSPF router will stop using this OSPF Security Association for OSPF packet generation. Key Stop Accept - The time that this OSPF router will stop accepting packets generated with this OSPF Security Association. Wei, et al. Expires April 26, 2011 [Page 11] Internet-Draft RP SA October 2010 A.3. ISIS SA An IS-IS Security Association contains a set of parameters shared between any two legitimate IS-IS speakers. Parameters associated with an IS-IS SA[RFC5310]: Key Identifier (Key ID) - This is a two-octet unsigned integer used to uniquely identify an IS-IS SA, as manually configured by the network operator. The receiver determines the active SA by looking at the Key ID field in the incoming PDU. The sender, based on the active configuration, selects the Security Association to use and puts the correct Key ID value associated with the Security Association in the IS-IS PDU. If multiple valid and active IS-IS Security Associations exist for a given outbound interface at the time an IS-IS PDU is sent, the sender may use any of those Security Associations to protect the packet. Authentication Algorithm - This signifies the authentication algorithm to be used with the IS-IS SA. At present, the following values are possible: HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC- SHA-384, and HMAC-SHA-512. Authentication Key - This value denotes the cryptographic authentication key associated with the IS-IS SA. The length of this key is variable and depends upon the authentication algorithm specified by the IS-IS SA. A.4. BFD SA The BFD protocol does not include an in-band mechanism to create or manage BFD Security Associations (BFD SA). A BFD SA contains a set of shared parameters between any two legitimate BFD routers. Parameters associated with a BFD SA[I-D.bhatia-bfd-crypto-auth]: Authentication Key Identifier (Key ID) - This is a two octet unsigned integer used to uniquely identify the BFD SA, as manually configured by the network operator (or, in the future, possibly by some key management protocol specified by the IETF). The receiver determines the active SA by looking at this field in the incoming packet. The sender puts this Key ID in the BFD packet based on the active configuration. Authentication Algorithm - This indicates the authentication algorithm to be used with the BFD SA. The following values are possible: Keyed MD5, Keyed SHA-1, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA- 384 and HMAC-SHA-512. Authentication Key - This indicates the cryptographic key associated Wei, et al. Expires April 26, 2011 [Page 12] Internet-Draft RP SA October 2010 with this BFD SA. The length of this key is variable and depends upon the authentication algorithm specified by the BFD SA. A.5. BGP BGP uses TCP-AO as its security mechanim. A Master Key Tuple (MKT) describes TCP-AO properties to be associated with one or more connections. It is composed of the following[RFC5925]: IDs - The values used in the KeyID or RNextKeyID of a TCP-AO option; used to differentiate MKTs in concurrent use (KeyID), as well as to indicate when MKTs are ready for use in the opposite direction (RNextKeyID). Each MKT has two IDs - a SendID and a RecvID. The SendID is inserted as the KeyID of the TCP-OP option of outgoing segments, and the RecvID is matched against the KeyID of the TCP-AO option of incoming segments. MKT IDs MUST support any value, 0-255 inclusive. There are no reserved ID values. Master key - A byte sequence used for generating traffic keys, this may be derived from a separate shared key by an external protocol over a separate channel. Implementations are advised to keep master key values in a private, protected area of memory or other storage. Key Derivation Function (KDF) - Indicates the key derivation function and its parameters, as used to generate traffic keys from master keys. Message Authentication Code (MAC) algorithm - Indicates the MAC algorithm and its parameters as used for this connection. A.6. OSPFv3 Ospfv3 uses IPSEC as its security mechanism. The IPsec SA is defined in [RFC4301]: Security Parameter Index (SPI)- a 32-bit value selected by the receiving end of an SA to uniquely identify the SA. In an SAD entry for an outbound SA, the SPI is used to construct the packet's AH or ESP header. In an SAD entry for an inbound SA, the SPI is used to map traffic to the appropriate SA. Sequence Number Counter - a 64-bit counter used to generate the Sequence Number field in AH or ESP headers. 64-bit sequence numbers are the default, but 32-bit sequence numbers are also supported if Wei, et al. Expires April 26, 2011 [Page 13] Internet-Draft RP SA October 2010 negotiated. Sequence Counter Overflow - a flag indicating whether overflow of the sequence number counter should generate an auditable event and prevent transmission of additional packets on the SA, or whether rollover is permitted. The audit log entry for this event SHOULD include the SPI value, current date/time, Local Address, Remote Address, and the selectors from the relevant SAD entry. Anti-Replay Window - a 64-bit counter and a bit-map (or equivalent) used to determine whether an inbound AH or ESP packet is a replay. AH Authentication algorithm, key, etc - This is required only if AH is supported. ESP Encryption algorithm, key, mode, IV, etc - If a combined mode algorithm is used, these fields will not be applicable. ESP integrity algorithm, keys, etc - If the integrity service is not selected, these fields will not be applicable. If a combined mode algorithm is used, these fields will not be applicable. ESP combined mode algorithms, key(s), etc - This data is used when a combined mode (encryption and integrity) algorithm is used with ESP. If a combined mode algorithm is not used, these fields are not applicable. Lifetime of this SA - a time interval after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur. This may be expressed as a time or byte count, or a simultaneous use of both with the first lifetime to expire taking precedence. A compliant implementation MUST support both types of lifetimes, and MUST support a simultaneous use of both. If time is employed, and if IKE employs X.509 certificates for SA establishment, the SA lifetime must be constrained by the validity intervals of the certificates, and the NextIssueDate of the Certificate Revocation Lists (CRLs) used in the IKE exchange for the SA. IPsec protocol mode - tunnel or transport. Indicates which mode of AH or ESP is applied to traffic on this SA. Stateful fragment checking flag - Indicates whether or not stateful fragment checking applies to this SA. Bypass DF bit (T/F) - applicable to tunnel mode SAs where both inner and outer headers are IPv4. DSCP values - the set of DSCP values allowed for packets carried over this SA. If no values are Wei, et al. Expires April 26, 2011 [Page 14] Internet-Draft RP SA October 2010 specified, no DSCP-specific filtering is applied. If one or more values are specified, these are used to select one SA among several that match the traffic selectors for an outbound packet. Note that these values are NOT checked against inbound traffic arriving on the SA. Bypass DSCP (T/F) or map to unprotected DSCP values (array) if needed to restrict bypass of DSCP values - applicable to tunnel mode SAs. This feature maps DSCP values from an inner header to values in an outer header, e.g., to address covert channel signaling concerns. Path MTU - any observed path MTU and aging variables. Tunnel header IP source and destination address - both addresses must be either IPv4 or IPv6 addresses. The version implies the type of IP header to be used. Only used when the IPsec protocol mode is tunnel. A.7. PCE PCEP uses TCP-AO as its message authentication mechanism, as discussed in [RFC5440]. A.8. LDP LDP uses TCP-AO as its message authentication mechanism, as discussed in [RFC5036]. A.9. LMP LMP uses IPsec as its message authentication mechanism, as discussed in [RFC4204]. A.10. MSDP MSDP uses TCP-AO as its message authentication mechanism, as discussed in [RFC3618]. A.11. RSVP-TE The RSVP-TE protocol is defined in [RFC3209]. It poses no security exposures over and above the base RSVP protocol defined in [RFC2205]. The RSVP protocol uses IPSEC as its message authentication mechanism, as discussed in [RFC2205]. A.12. PIM PIM uses IPSEC as its message authentication mechanism, as discussed in [RFC4601]. Wei, et al. Expires April 26, 2011 [Page 15] Internet-Draft RP SA October 2010 Authors' Addresses Yinxing Wei (editor) ZTE Corporation No. 6, HuashenDa Road, Yuhuatai District Nanjing, Jiangsu 210012 China Phone: +86 25 52877993 Email: wei.yinxing@zte.com.cn Hongyan Wang ZTE Corporation No. 6, HuashenDa Road, Yuhuatai District Nanjing, Jiangsu 210012 China Phone: +86 25 52877993 Email: wang.hongyan4@zte.com.cn Xiaoping Liang ZTE Corporation No. 6, HuashenDa Road, Yuhuatai District Nanjing, Jiangsu 210012 China Phone: +86 25 52877610 Email: liang.xiaoping@zte.com.cn Changsheng Wan Southeast University No. 2, Sipailou, Radio Department, Southeast University Nanjing, Jiangsu 210096 China Phone: +86 25 83795822-866 Email: wanchangsheng@seu.edu.cn Wei, et al. Expires April 26, 2011 [Page 16]