Internet DRAFT - draft-wei-karp-analysis-rp-sa
draft-wei-karp-analysis-rp-sa
KARP Working Group Y. Wei
Internet-Draft X. Liang, Ed.
Intended status: Informational H. Wang
Expires: April 27, 2012 ZTE Corporation
C. Wan
Southeast University
October 25, 2011
Analysis of Security Association for Current Routing Protocols
draft-wei-karp-analysis-rp-sa-03
Abstract
This document analyzes the security associations used by current
routing protocols, including RIPv2, OSPFv2, ISIS, BFD, BGP, OSPFv3,
PCE, LDP, LMP, MSDP, RSVP-TE, PIM, and BGP. It also discusses the
possible approach to the diversity issue of routing protocol security
associations.
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 27, 2012.
Copyright Notice
Copyright (c) 2011 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
Wei, et al. Expires April 27, 2012 [Page 1]
Internet-Draft RP SA October 2011
include Simplified BSD License text as described in Section 4.e of
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. Appendix: Existing SA definition . . . . . . . . . . . . . . . 9
5.1. RIPv2 SA . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. OSPFv2 SA . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. ISIS SA . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. BFD SA . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.5. RSVP-TE SA . . . . . . . . . . . . . . . . . . . . . . . . 11
5.6. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.7. ospfv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.8. PCE . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.9. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.10. LMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.11. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.12. RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.13. PIM . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Informative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Wei, et al. Expires April 27, 2012 [Page 2]
Internet-Draft RP SA October 2011
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 [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, OSPFv3, PCE, LDP, LMP,
MSDP, RSVP-TE, PIM, and BGP.
Among the above routing protocols, BGP [RFC5925], PCE [RFC5440], LDP
[RFC5036], and MSDP [RFC3618], use TCP-AO as protection, hence lack
the definition of SA as other routing protocols especially those
using IPsec as protection. We may consider the attributes of TCP-AO
as parameters of SA for those routing protocols listed in this
paragraph.
Wei, et al. Expires April 27, 2012 [Page 3]
Internet-Draft RP SA October 2011
2.1. Summary for security associations of current routing protocols
The security associations of current routing protocols 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 [draft-bhatia-bfd-crypto-auth] includes the following
information: key identifier, cryptographic algorithms, key.
o The RSVP-TE SA [RFC2747] includes the following information: key
identifier, cryptographic algorithms, algorithm mode, key, life time
of the key, sequence number.
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, PIM, RSVP-TE (when using IPsec as its security
protocol) 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
as listed in table 1.
Wei, et al. Expires April 27, 2012 [Page 4]
Internet-Draft RP SA October 2011
Table 1 Key Identifier Field of SAs
+--------------/-----------------/------------------+
| 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 | |
---------------|-----------------|-------------------
| RSVP-TE | Key Identifier | 48 bits |
---------------|-----------------|-------------------
| 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 algorithms and keys 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 as listed in table 2.
Wei, et al. Expires April 27, 2012 [Page 5]
Internet-Draft RP SA October 2011
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 | |
|----------------|-------------------|-----------------------------|
| RSVP-TE | HMAC-MD5, | Same as above |
| | HMAC-SHA-1 | |
|----------------|-------------------|-----------------------------|
| 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
Wei, et al. Expires April 27, 2012 [Page 6]
Internet-Draft RP SA October 2011
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 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 as listed in table 3.
Table 3 Lifetime
+---------------/--------------------+
| SA of Routing | Fields |
| Protocols | |
|---------------|--------------------|
| RIPv2 | Start Time |
| | Stop Time |
|---------------|--------------------|
| OSPFv2 | Key Start Accept |
| | Key Start Generate |
| | Key Stop Generate |
| | Key Stop Accept |
|---------------|--------------------|
| ISIS | None |
|---------------|--------------------|
| BFD | None |
|---------------|--------------------|
| RSVP-TE | key lifetime |
|---------------|--------------------|
| 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. The sequence number fields of current routing
protocols are listed below.
Wei, et al. Expires April 27, 2012 [Page 7]
Internet-Draft RP SA October 2011
Table 4 Sequence Number
+---------------/---------------------+
| SA of Routing | Length of Sequence |
| Protocol | number |
|-------------------------------------|
| RIPv2 | 32bits |
|-------------------------------------|
| OSPFv2 | 32bits |
|-------------------------------------|
| ISIS | 32bits |
|-------------------------------------|
| BFD | 32bits |
|-------------------------------------|
| RSVP-TE | 64bits |
|-------------------------------------|
| TCP-AO | 32bits |
|-------------------------------------|
| IPSEC | 64bits |
+---------------\---------------------+
The lengths of most underlying routing protocols' sequence number
above are 32 bits, and others' are 64 bits. This case also shows
that manual configuration or KMP are also required to differentiate
underlying routing protocol, which makes them complex.
2.3. Discussion of generic security association
As shown in Section 2.2, each routing protocol has its own SA with
parameters different from others. We may call it diversity of
routing protocol SA. If we want a KMP work for most if not all
routing protocols with enhanced security, we need to deal with the
diversity issue, and the following should be considered.
1. Identify the full definition of SA for routing protocols.
2. Fulfill or extend the SA for routing protocols if it has not
reach full definition.
3. Identify how to process SA when both IPsec and TCP-AO are in use
together.
4. ...
The advantages to have a KMP like this are as follows:
1. It provides a unified interface to manual configuration or KMP
protocol.
Wei, et al. Expires April 27, 2012 [Page 8]
Internet-Draft RP SA October 2011
2. It decouples KMP with underlying routing protocol, which
addresses the requirement identified in [ietf-karp-threats-req].
3. KMP and routing protocol can be evolving independently.
4. The complexity of the design of KMP is greatly reduced.
3. IANA considerations
To be completed.
4. security considerations
To be completed.
5. Appendix: Existing SA definition
This section is for information. It can be safely removed in the
future.
5.1. RIPv2 SA
RIPv2 Security Association[RFC4822]:
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.
5.2. OSPFv2 SA
OSPFv2 Security Association [RFC5709]:
Wei, et al. Expires April 27, 2012 [Page 9]
Internet-Draft RP SA October 2011
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.
5.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-
Wei, et al. Expires April 27, 2012 [Page 10]
Internet-Draft RP SA October 2011
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.
5.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[draft-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
with this BFD SA. The length of this key is variable and depends
upon the authentication algorithm specified by the BFD SA.
5.5. RSVP-TE SA
RSVP-TE Security Association [RFC2747]:
Key Identifier - An unsigned 48-bit number that MUST be unique for a
given sender. Locally unique Key Identifiers can be generated using
some combination of the address (IP or MAC or LIH) of the sending
interface and the key number. The combination of the Key Identifier
and the sending system's IP address uniquely identifies the security
association.
Sequence Number - An unsigned 64-bit monotonically increasing, unique
sequence number. Sequence Number values may be any monotonically
increasing sequence that provides the INTEGRITY object [of each RSVP
message] with a tag that is unique for the associated key's lifetime.
Authentication algorithm and algorithm mode being used.
Wei, et al. Expires April 27, 2012 [Page 11]
Internet-Draft RP SA October 2011
Key used with the authentication algorithm.
Lifetime of the key.
Associated sending interface and other security association selection
criteria [REQUIRED at Sending System].
Source Address of the sending system [REQUIRED at Receiving System].
Latest sending sequence number used with this key identifier
[REQUIRED at Sending System].
List of last N sequence numbers received with this key identifier
[REQUIRED at Receiving System].
5.6. 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.
Wei, et al. Expires April 27, 2012 [Page 12]
Internet-Draft RP SA October 2011
5.7. 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
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
Wei, et al. Expires April 27, 2012 [Page 13]
Internet-Draft RP SA October 2011
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
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.
5.8. PCE
PCEP uses TCP-AO as its message authentication mechanism, as
discussed in [RFC5440].
5.9. LDP
LDP uses TCP-AO as its message authentication mechanism, as discussed
in [RFC5036].
5.10. LMP
LMP uses IPsec as its message authentication mechanism, as discussed
in [RFC4204].
Wei, et al. Expires April 27, 2012 [Page 14]
Internet-Draft RP SA October 2011
5.11. MSDP
MSDP uses TCP-AO as its message authentication mechanism, as
discussed in [RFC3618].
5.12. 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].
5.13. PIM
PIM uses IPSEC as its message authentication mechanism, as discussed
in [RFC4601].
6. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", September 1997.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", January 2000.
[RFC3209] Awduche, D. and Al. Et., "RSVP-TE: Extensions to RSVP for
LSP Tunnels", December 2001.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", October 2003.
[RFC4204] Lang, J., "Link Management Protocol (LMP)", October 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", December 2005.
[RFC4601] Fenner, B. and Al. Et., "Protocol Independent Multicast -
Sparse Mode (PIM-SM): Protocol Specification (Revised)",
August 2006.
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
Authentication", February 2007.
[RFC5036] Andersson, L. and Al. Et., "LDP Specification",
Wei, et al. Expires April 27, 2012 [Page 15]
Internet-Draft RP SA October 2011
October 2007.
[RFC5310] Bhatia, M. and Al. Et., "IS-IS Generic Cryptographic
Authentication", February 2009.
[RFC5440] Vasseur, J. and J. Roux, "Path Computation Element (PCE)
Communication Protocol (PCEP)", March 2009.
[RFC5709] Bhatia, M. and Al. Et., "OSPFv2 HMAC-SHA Cryptographic
Authentication", October 2009.
[RFC5925] Touch, J., Mankin, A., and Al. Et., "The TCP
Authentication Option", January 2010.
[draft-bhatia-bfd-crypto-auth]
Bhatia, M. and V. Manral, "Generic Cryptographic
Authentication", June 2010.
[ietf-karp-design-guide]
Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines",
February 2010.
[ietf-karp-threats-req]
Lebovitz, G., "KARP Threats and Requirements",
February 2010.
Authors' Addresses
Yinxing Wei
ZTE Corporation
No. 6, HuashenDa Road, Yuhuatai District
Nanjing, Jiangsu 210012
China
Phone: +86 25 52877993
Email: wei.yinxing@zte.com.cn
Wei, et al. Expires April 27, 2012 [Page 16]
Internet-Draft RP SA October 2011
Xiaoping Liang (editor)
ZTE Corporation
No. 6, HuashenDa Road, Yuhuatai District
Nanjing, Jiangsu 210012
China
Phone: +86 25 52877610
Email: liang.xiaoping@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
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 27, 2012 [Page 17]
