KARP Working Group X. Liang, Ed.
Internet-Draft H. Wang
Intended status: Informational Y. Wei
Expires: April 21, 2011 ZTE Corporation
C. Wan
Southeast University
October 18, 2010
Automated Security Association Management for Routing Protocols
draft-liang-karp-auto-sa-management-rp-00
Abstract
This document discusses automated security association (SA)
management for routing protocols, which includes SA establishment and
SA maintenance for routing protocols, and also discusses two
candidate solutions of automated SA management that are based on
IKEv2 and ISAKMP respectively.
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 21, 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
Liang, et al. Expires April 21, 2011 [Page 1]
Internet-Draft RP SA Management October 2010
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. Automated SA Management for Routing Protocols . . . . . . . . 3
2.1. RP SA Attributes/Parameters/Components/Contents . . . . . 4
2.2. RP SA Format . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Secure Channel . . . . . . . . . . . . . . . . . . . . . . 4
2.4. RP SA Negotiation . . . . . . . . . . . . . . . . . . . . 4
2.5. RP SA Creation/Generation . . . . . . . . . . . . . . . . 5
2.6. RP SA Distribution and Delivery . . . . . . . . . . . . . 5
2.7. RP SA Deletion, Update, and Rekeying . . . . . . . . . . . 5
3. Candidate Solutions . . . . . . . . . . . . . . . . . . . . . 6
3.1. IKEv2 Extensions . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Extending SA Payload to Support PR SA Management . . . 6
3.1.2. Adding New Payload to Support RP SA Management . . . . 8
3.1.3. Adding New Exchange Type to Support RP SA
Management . . . . . . . . . . . . . . . . . . . . . . 9
3.2. ISAKMP Extensions . . . . . . . . . . . . . . . . . . . . 9
4. Security considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative references . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Liang, et al. Expires April 21, 2011 [Page 2]
Internet-Draft RP SA Management October 2010
1. Introduction
The draft [I-D.wei-karp-analysis-rp-sa] has shown the diversity of SA
of routing protocols, and then one problem arises -- how to manage
these diverse SAs of routing protocols automatically? An automated
key management protocol (KMP) is desired to manage SAs of routing
protocols. When considering KMP design for routing protocols,
automated SA management is the main function that KMP should provide
for routing protocols. In some sense and to some extent, KMP for
routing protocols is automated SA management for routing protocols
essentially.
The following sections discuss automated SA management for routing
protocols based on [I-D.wei-karp-analysis-rp-sa] , and also discuss
the candidate solutions based on IKEv2 [RFC4306] [RFC4307] [RFC4718]
[RFC5996] and ISAKMP [RFC2408], respectively.
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. Automated SA Management for Routing Protocols
An SA is a simplex "connection" that affords security services to the
traffic carried by it [RFC4301]. In the routing protocol context, an
SA of routing protocol is a set of cryptographic algorithms and other
security parameters to be used to protect routing protocol message,
i.e., to perform routing protocol message authentication and
integrity protection (see [I-D.ietf-karp-framework] and
[I-D.ietf-karp-design-guide]). The document uses RP SA to represent
routing protocol security association, i.e., security association for
routing protocols, and uses RP SAs to represent its plural form.
Since manual SA management is vulnerable to a variety of security
issues as discussed in [I-D.ietf-karp-threats-reqs], automated SA
management is the desired solution to be considered.
To achieve automated SA management for routing protocols, the
following items to be considered are identified and defined.
Liang, et al. Expires April 21, 2011 [Page 3]
Internet-Draft RP SA Management October 2010
2.1. RP SA Attributes/Parameters/Components/Contents
In this document, the four words -- attribute, parameter, component
and content, refer to the same meaning to RP SA, and among them,
attribute is preferred in RFC 2408 [RFC2408]. The attributes of RP
SA is different from that of IPsec [RFC4301], since RP SA is
dedicated to routing protocols. The draft
[I-D.wei-karp-analysis-rp-sa] has identified the attributes of RP SA,
i.e., Key ID, authentication algorithm, authentication key, life
time, sequence number, etc. In order to distinguish different RP
SAs, routing protocol ID, message type ID of routing protocol, which
is related to message transaction type, and etc., may also be taken
into consideration. Attention should be paid to the direction
attribute of SA. In IPsec, the SA is simplex, while in routing
protocols, the direction attribute of SA is not defined, and it seems
that the direction attribute of RP SA depends on how to use the
traffic key by routing protocol message. If the communicating peers
use different traffic keys in both directions, RP SA is simplex; if
the communicating peers use the same traffic key in both directions,
RP SA is duplex; and vice versa.
2.2. RP SA Format
An agreed on RP SA format should be formed to achieve interoperation
between/among communicating peers. It is about how RP SA to be
constructed, e.g., the header format and the payload format of RP SA.
The RP SA format could support as much as possible, if not all, the
RP SA attributes.
2.3. Secure Channel
RP SA is shared information between/among involving peers, and the
attributes of RP SA that will be transferred should be protected via
secure channel. Secure channel is needed to be established before RP
SA is involved in the communication between/among peers, for example,
RP SA negotiation, RP SA distribution, etc. Generally, the secure
channel protection provides encryption and message authentication and
anti-replay for RP SA.
2.4. RP SA Negotiation
In RFC 2408 [RFC2408], the need for negotiation was stated, and the
main reason for SA negotiation is the diverse security requirements
and security services of different networks. To achieve common
supported security functionality for interoperation and cooperation
between/among communicating peers for routing protocols, RP SA
negotiation is desired in automated SA management for routing
protocols. In other words, the diverse configurations and security
Liang, et al. Expires April 21, 2011 [Page 4]
Internet-Draft RP SA Management October 2010
functionalities of routers and their deployed routing protocols are
the main reason that makes RP SA negotiation desirable, and
automation requirement of SA management makes RP SA negotiation
necessary. The RP SA negotiation procedures and payloads that will
be transferred should be identified and defined in automated SA
management for routing protocols. What attributes of RP SA will be
negotiated is dependent on specific routing protocol and its message
transaction type, etc.
2.5. RP SA Creation/Generation
Creation and generation of RP SA have the same meaning in this
document. If the RP SA attributes and format are defined, and the
negotiation of needed attributes of RP SA is finished successfully,
then automated SA management takes the task of RP SA creation
according to corresponding RP SA attributes, format, and specific
routing protocol, etc., obtained via negotiaotion. In this creation
process, one or more databases may be involved, e.g., cryptography
algorithms database, cryptography functions database, and key
databases, or one database composed of these three things.
2.6. RP SA Distribution and Delivery
This may involve two scenarios, that is, RP SA is distributed to
other peers, and RP SA is delivered to routing protocol served by
KMP. The former scenario may be a group SA for routing protocol that
is distributed to all the group member peers, and this kind of
distribution should be under the protection of secure channel. The
later scenario may be that the RP SA is delivered to the
corresponding routing protocol directly, or to a key store, which
then will serve the corresponding routing protocol with the RP SA.
2.7. RP SA Deletion, Update, and Rekeying
Since RP SA is time relevant, and some routing protocol messages are
updated periodically, RP SA deletion, update, and rekeying are very
important. The life time or life cycle attribute of RP SA is a key
factor that effects RP SA deletion, update, and rekeying. If life
time is expired, then the RP SA can be deleted or updated or rekeyed.
Deletion means to remove RP SA from corresponding store, update means
to assign new values to attributes of RP SA, which may be by the
means of negotiation, and rekeying means to create a new RP SA
totally, which may involve using different cryptography algorithms,
different key, etc. Attention should be paid to adjacencies bouncing
problem during RP SA deletion, update, and rekeying. Roughly
speaking though, update and rekeying indicate the same meaning, and
both involve deletion of old RP SA.
Liang, et al. Expires April 21, 2011 [Page 5]
Internet-Draft RP SA Management October 2010
3. Candidate Solutions
According to the design spirit of KMP for routing protocols
[I-D.ietf-karp-design-guide], it is best to reuse existing
technology/mechanisms to solve problems. In this sense, IKEv2 and
ISAKMP are good candidates for automated SA management for routing
protocols, since they are existing and mature protocols for key
management that is evolving along time, and they provide some
flexible and extendable mechanism that can be exploited. Taking into
consideration the above items discussed in section 2, IKEv2 and
ISAKMP can be extended to support automated SA management for routing
protocols. The details of extending IKEv2 is discussed in section
3.1, and the details of extending ISAKMP is discussed in section 3.2.
Both extensions are focusing on peer-to-peer communication at the
time being, and the extension to support group RP SA will be
discussed in later update version of the document.
3.1. IKEv2 Extensions
IKEv2 is dedicated to IPsec, specifically ESP [RFC4303] [RFC4305]
[RFC4835] and/or AH [RFC2402] [RFC4302] [RFC4305] [RFC4835], to
establish and maintain SAs for two communicating peers, and cannot be
applied to routing protocols as automated SA management for routing
protocols directly. IKEv2 can be extended and made adaptive to
routing protocols. Specifically, IKEv2 can be extended to support
attributes of RP SA, to provide unified format for RP SA, to
establish secure channel for RP SA negotiation and distribution if
applicable, to negotiate RP SA between/among communicating peers, to
create RP SA, to distribute RP SA if applicable, and to update and
rekey RP SA.
Three ways of IKEv2 extension to support RP SA management are
considered, that is, extending SA payload, adding new payload, and
adding new exchange type.
3.1.1. Extending SA Payload to Support PR SA Management
The SA payload of IKEv2 has proposals substructure which has
transforms substructure, which has Transform Attributes in turn to
describe key length for encryption algorithm, etc., to support the SA
for ESP and/or AH of IPsec. The following changes to SA payload can
be made to adapt for RP SA.
o Extend Protocol ID field of proposal substructure to include
routing protocols, and take the ID values from those reserved to
IANA, i.e., 4-200, e.g., assign OSPFv2 [RFC2328] the value 3.
Liang, et al. Expires April 21, 2011 [Page 6]
Internet-Draft RP SA Management October 2010
o Match SPI field in proposal substructure to Key ID of RP SA, and
extend SPI Size (in octet) field of proposal substructure to
include routing protocols, e.g., assign OSPFv2 the value 1, since
the length of Key ID is 8 bits.
o Extend Transform Type 3 in transform substructure to be also used
in routing protocols, and extend Transform ID of Transform Type 3
to include authentication algorithms used by routing protocols,
and take the ID values from those reserved to IANA, i.e., 6-1023,
e.g., assign AUTH_HMAC_SHA_256, which stands for HMAC-SHA-256
[RFC5709] as authentication algorithm, the value 8.
o Extend Attribute Type in transform substructure to include key
length and life time attributes for routing protocols. As to the
Attribute Type 14 Key Length (in bits), it is defined for
encryption algorithm only, and can be extended to use in
authentication algorithm in case of negotiation of key length of
authentication algorithm. As to the life time attributes, they
can be defined as a new Attribute Type and assigned the Attribute
Type values from those reserved to IANA, i.e., 18-16383, e.g.,
Start Time can be defined as one new Attribute Type, and its
Attribute Type Value can be assigned 18.
The above extensions together can support attributes and format of RP
SA. The extended SA can be denoted as SAe, where !oe!+/- means
extension.
The procedures to establish secure channel and negotiate RP SA can be
as follows:
Initiator Responder
--------------------------------------------------------
HDR, SAi, KEi, Ni -->
<-- HDR, SAr, KEr, Nr, [CERTREQ]
The above IKE_SA_INIT exchange results in IKE_SA, which will be used
to encrypt and authenticate the subsequent exchange content in brace
following SK, hence, the secure channel is established.
Initiator Responder
-----------------------------------------------------------
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAe, TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
SAe, TSi, TSr}
Liang, et al. Expires April 21, 2011 [Page 7]
Internet-Draft RP SA Management October 2010
In the above IKE_AUTH exchange, Initiator offers a list of proposals
in the extended payload SAe, and the Responder chooses one, put it in
the SAe, and send to the Initiator. Then Initiator hands the SA to
routing protocol being served. Hence the RP SA negotiation is
finished.
As to the Authentication Key in RP SA, it can be calculated by
Pseudo-random Function (PRF) with the inputs of Nonce from both peers
and from KE (Key Exchange) payload that will be used in Diffie-
Hellman exchange.
3.1.2. Adding New Payload to Support RP SA Management
Alternatively, a new payload to support attributes and format of RP
SA can be created in IKEv2, for example, it may be named SARP, which
stands for security association of routing protocol , and take the
Next Payload Type value, say 49, from the reserved to IANA value 49-
127. The Next Payload Type of the original SA payload in IKEv2 is
33.
The structure of SARP can be similar to that of SA, with the
following differences:
o Add Length of Life Time field and the Life Time field in the
Proposal Substructure.
o Replace SPI Size field with Length of Key ID field, and Key ID
field substitutes the SPI field.
o Define Transform Type to include Pseudo-random Function (PRF),
Integrity Algorithm (INTEG), and Sequence Numbers (SN), etc.,
which are used by routing protocols.
o Define Transform ID for PRF that will be used by routing
protocols.
o Define Transform ID for INTEG that will be used by routing
protocols.
o Define Key Length of PRF or/and INTEG that will be used by routing
protocols in case the length of key can be negotiated.
As to the Authentication Key in RP SA, it can be calculated by PRF
with the inputs from Nonce payload and KE payload of both peers.
The procedures to negotiate RP SA using the above new payload SARP
are the same as that of extending SA payload above, with SAe payload
substituted by SARP payload.
Liang, et al. Expires April 21, 2011 [Page 8]
Internet-Draft RP SA Management October 2010
The benefit gained by adding new payload to support RP SA management
is a bit fast processing for automated SA management.
3.1.3. Adding New Exchange Type to Support RP SA Management
New exchange type can also be defined to do RP SA negotiation. For
example, IKE_RP_AUTH exchange can be defined dedicated to RP SA
negotiation, and take the value, say 38, from the reserved to IANA
value 38-239, as its Exchange Type value. Note that the Exchange
Type of IKE_AUTH is 35. The payloads involved in IKE_RP_AUTH
exchange may be similar with that in IKE_AUTH, and the major
difference may be the SA payload. The extended SA payload SAe or the
new added payload SARP can be used in this exchange, replacing the SA
payload in IKE_AUTH exchange. In this way, i.e., with a dedicated
exchange, the negotiation of RP SA can be speeded up to some extent.
Extending SA payload and adding new payload can be used independently
or even hybridly if applicable, and can also be combined with the new
added exchange type defined in section 3.1.3, to finish the RP SA
negotiation, creation, and distribution if applicable.
3.2. ISAKMP Extensions
ISAKMP [RFC2408] defines procedures and packet formats to establish,
negotiate, modify and delete SA. SAs contain all the information
required for execution of various network security services, such as
the IP layer services (such as header authentication and payload
encapsulation), transport or application layer services, or self-
protection of negotiation traffic. ISAKMP is intended to support the
negotiation of SAs for security protocols at all layers of the
network stack. However, ISAKMP provides a framework but not define
them [RFC2409]. This section tries to discuss ISAKMP extensions and
definitions to serve routing protocol.
The following changes can be made in ISAKMP to support automated SA
management for routing protocols:
o Extend DOI (Domain of Interpretation) field of SA payload to
indicate the subsequent payloads are used to negotiate RP SA,
e.g., define a new DOI and assign it the value 3 if applicable,
and denote it as SARPDOI, which means DOI for routing protocol
security association.
o Extend Security Protocol Identifiers of proposal for RP SA, e.g.,
define OSPFv2 as PROTO_ OSPFv2 and assign it the value 5 if
applicable. In this way, the RP SA established for OSPFv2 is
shown.
Liang, et al. Expires April 21, 2011 [Page 9]
Internet-Draft RP SA Management October 2010
o Match SPI field in proposal substructure to Key ID of RP SA, and
extend SPI Size (in octet) field of proposal substructure to
include routing protocols, e.g., assign OSPFv2 the value 1, since
the length of Key ID is 8 bits.
o Extend Transform Identifiers to define transform for specific
routing protocol, e.g., define new transforms OSPFv2_MD5 and
OSPFv2_SHA for OSPFv2, which means OSPFv2 using MD5 and SHA-1 as
authentication algorithm respectively, and assign them the value 2
and 3 respectively.
o Extend Attribute Type to support attributes of RP SA, e.g., define
Start Time for life time of OSPFv2, and assign it the value 4.
Alternatively, DOI (Domain of Interpretation ) can be extended in
this way -- extend DOI field of SA payload to indicate the subsequent
payloads will be used to negotiate RP SA, e.g., define SPFv2 DOI and
assign it the value 3.
4. Security considerations
To be completed.
5. IANA Considerations
To be completed.
6. Acknowledgement
To be completed.
7. References
7.1. Normative references
[RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
Liang, et al. Expires April 21, 2011 [Page 10]
Internet-Draft RP SA Management October 2010
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
7.2. Informative References
[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-framework]
Atwood, W. and G. Lebovitz, "Framework for Cryptographic
Authentication of Routing Protocol Packets on the Wire",
draft-ietf-karp-framework-00 (work in progress),
February 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.
[I-D.wei-karp-analysis-rp-sa]
Wei, Y., Wang, H., and X. Liang, "Analysis of Security
Association for Current Routing Protocol",
draft-wei-karp-analysis-rp-sa-00 (work in progress),
July 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
Liang, et al. Expires April 21, 2011 [Page 11]
Internet-Draft RP SA Management October 2010
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4305, December 2005.
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006.
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4835, April 2007.
[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.
Authors' Addresses
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
Liang, et al. Expires April 21, 2011 [Page 12]
Internet-Draft RP SA Management October 2010
Yinxing Wei
ZTE Corporation
No. 6, HuashenDa Road, Yuhuatai District
Nanjing, Jiangsu 210012
China
Phone: +86 25 52877993
Email: wei.yinxing@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
Liang, et al. Expires April 21, 2011 [Page 13]