Internet DRAFT - draft-atwood-rtgwg-secure-rtg
draft-atwood-rtgwg-secure-rtg
RTGWG W. Atwood
Internet-Draft N. Prajapati
Intended status: Informational Concordia University/CSE
Expires: April 30, 2015 October 27, 2014
A Framework for Secure Routing Protocols
draft-atwood-rtgwg-secure-rtg-00
Abstract
When tightening the security of the core routing infrastructure, two
steps are necessary. The first is to secure the routing protocols'
packets on the wire. The second is to ensure that the keying
material for the routing protocol exchanges is distributed only to
the appropriate routers. This document specifies a way of organizing
the security parameters and a method for conveniently controlling
those parameters using YANG and NETCONF.
Status of This Memo
This Internet-Draft is submitted to IETF 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 30, 2015.
Copyright Notice
Copyright (c) 2014 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.
Atwood & Prajapati Expires April 30, 2015 [Page 1]
Internet-Draft Secure Routing October 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Routing Protocol Security . . . . . . . . . . . . . . . . . . 5
3. RPsec Configuration . . . . . . . . . . . . . . . . . . . . . 5
4. RPsec Databases . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. RSPD . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. CKT . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. RPAD . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. RPsec in Detail . . . . . . . . . . . . . . . . . . . . . . . 6
6. Representation and Distribution of RPsec Policies . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. Change History (RFC Editor: Delete Before Publishing) . . . . 7
10. Needs Work in Next Draft (RFC Editor: Delete Before
Publishing) . . . . . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Much effort has been expended to ensure the security of end-to-end
exchanges in the Internet. However, relatively little effort appears
to be being expended to secure the router-to-router exchanges that
define the forwarding path for the packets that make up the end-to-
end exchanges.
Methods for ensuring router-to-router security have been written into
the specifications of routing protocols for many years. However, the
security parameters (keys, permitted neighbors, etc.) are typically
installed manually on each router [RFC6862]. Because network
management personnel are scarce, and updating security parameters is
a labor-intensive task, if security is implemented at all, the keys
are often left in place for five years or more [RFC6862], leaving
ample opportunity for them to be compromised. This could lead to an
intruder router pretending to be a legitimate one and capturing
confidential data.
In March 2006, the Internet Architecture Board (IAB) held a workshop
on the topic "Unwanted Internet Traffic". The report from that
workshop is documented in [RFC4948]. Section 8.1 of that document
states, "A simple risk analysis would suggest that an ideal attack
target of minimal cost but maximal disruption is the core routing
infrastructure". Section 8.2 calls for "[t]ightening the security of
the core routing infrastructure".
Atwood & Prajapati Expires April 30, 2015 [Page 2]
Internet-Draft Secure Routing October 2014
One approach to achieving improved security is to automate the
process of updating the security parameters. This will reduce the
number of network management personnel needed and would potentially
improve security for all users of the Internet. This leads us to the
following requirements:
o Ensuring the authenticity and integrity of the routing protocol
messages;
o Ensuring the legitimacy of the neighboring routers, by making sure
that they are part of the "permitted adjacency" as explained
below;
o Automation of the entire process of key and adjacency management.
The notion of "permitted adjacency" can be re-stated as providing
answers to the following questions:
o Are you a legitimate member of my group? This is the question of
authentication.
o Are you permitted to connect to me for the purposes of this
routing protocol? This is the question of authorization.
Figure 1 shows a potential framework for discussion of secure
routing.
Routing Protocol Layer 1
Keys and Security Protocol Layer 2
Key and SA Management Layer 3
Configuration Management Layer 4
Figure 1: Secure Routing Framework
Layer 1 is the routing protocol layer. The routers run routing
protocols among themselves to collect and distribute topological
information for the network. The routing protocols distribute the
network information by "exchanging messages" with their peer routers
(neighbors). Each router processes all the information received from
the routing protocol peers to create and maintain the forwarding
table. This forwarding table is used to decide where to forward a
particular packet when it arrives.
Atwood & Prajapati Expires April 30, 2015 [Page 3]
Internet-Draft Secure Routing October 2014
Layer 2 represents the security mechanisms available for a routing
protocol. Each routing protocol will have a number of security
mechanisms available to it (including no security at all). A routing
protocol needs to be assured of two things about the messages that it
receives from its peer routers:
o that the peer is legitimate, and
o that the message from that peer has not been altered in transit.
The most common approach today is for a routing protocol to use a
pre-shared key for authorizing its neighbors as well as for
validating the message integrity. In effect, all the neighbors
(running the same routing protocol) that possess this key are
authorized to communicate with each other.
The configuration of keys and security associations, the choice of
keys and the security mechanism used for a routing protocol depend on
the key management methods at Layer 3. As discussed in Section 1,
the network operators use the manual management method, which is the
only solution available at this time for routing protocols. As a
result, keys are seldom changed.
Layer 4 focuses on the configuration and the distribution of keys and
security associations for routing protocols. At this time, this is
done manually, either by visiting the router itself, or accessing it
remotely through some configuration procedure. Each router
manufacturer has its own approach to faciltiate this.
Within the KARP Working Group, protocols and procedures for creating
shared keys for specific environments have been proposed
[I-D.hartman-karp-mrkmp][I-D.mahesh-karp-rkmp][I-D.tran-karp-mrmp],
under the assumption that the end points of the exchanges (the
routers) are entitled to enter into the conversation, i.e., that they
can prove that they are who they say they are. However, this only
addresses part of the problem at Layer 3, because these documents
provide no mechanism to assess or ensure that the end points are
entitled to be neighbors.
In addition, requirements for an operations and management model are
specified in [RFC7210].
This document addresses two issues: providing a flexible method for
managing the necessary keys and security associations, and providing
a way to configure a set of routers while satisfying operational
constraints.
Atwood & Prajapati Expires April 30, 2015 [Page 4]
Internet-Draft Secure Routing October 2014
2. Routing Protocol Security
To be able to effectively manage routing protocol security, it is
necessary to have a representation of the choices open to a key
negotiation protocol, and to have a convenient representation of the
parameters to be used in a particular security association that is
being used by the security features of a routing protocol.
The representation of parameters (keys and security associations, key
derivation functions) is provided by the Crypto-Key-Table specified
in [RFC7210].
The parameters for a specific peer router and protocol are provided
in the Routing Security Parameter Database (RSPD). The Routing Peer
Authorization Database (RPAD) provides information required for peer
authentication and authorization and specifies a key management
protocol to be used in establishing the peer relationship.
3. RPsec Configuration
To enable convenient configuration of the RPsec databases, YANG
models of these databases can be used, in conjunction with a central
controller to define updates to the security configurations.
4. RPsec Databases
4.1. RSPD
The objective of the RSPD is to provide security options (choice of
security protocol) for a routing protocol's security. Each entry (a
choice) specifies the security parameters required to establish a
security association between the peers. An authorized device may
communicate with many routing protocol peers. To do so, it must
agree on the security requirements of the routing protocol peer for
successful communication. The peers must agree on security
protocols, transforms, mode of communication along with the key
required to integrity protect messages exchanged between them. This
database aims to provide such information. The RSPD contains the
traffic descriptors for identifying each routing protocol traffic
that needs to be protected, bypassed or discarded. The RSPD, thus,
is a database to specify the traffic descriptors for the routing
protocol traffic, security protocols, lifetime and related parameters
for securing the communication between the two devices or among a
group in case of the multicast communication. This database provides
partial information towards security requirements of the routing
protocols. The rest of the information is provided by the CKT.
Atwood & Prajapati Expires April 30, 2015 [Page 5]
Internet-Draft Secure Routing October 2014
4.2. CKT
The CKT is an important database that provisions key material and
associated cryptographic algorithms to protect the routing protocol
messages. In RPsec, the CKT performs the role similar to the SAD in
IPsec. It stores the negotiated (or manually configured) SAs for the
routing protocols. In that, each RSPD entry points to an appropriate
entry in the CKT. Each RSPD entry that protects the routing protocol
traffic, provides a (security) protocol id and a peer id (traffic
descriptor) that identify an entry in this database. The form of the
protocol id and the peer id is specified in [RFC7210]. The RSPD
together with CKT ensure that the key is provided to a security
protocol that is used for securing the routing protocol.
4.3. RPAD
The RPAD's objective is to provide authentication information and a
KMP for the routing peers. It provides authentication information
necessary to assert a local device's identity and to validate the
identity asserted by the peer devices. A KMP uses the information in
the RPAD and the RSPD for authentication and SA negotiation,
respectively. Authentication is required to ensure that the devices
participating in the network infrastructure are legitimate. A
legitimate device should present its identity, identity of remote
peer(s) or group it wishes to communicate with, and an organization-
wide acceptable credential. If the device successfully passes the
peer device's scrutiny, it is authenticated to communicate with the
requested peer(s) or a group in the network. The communication
between the two devices must stop if the KMP fails to authenticate
the peers using the information available in the RPAD database. A
KMP negotiates a security association only after the authentication
is successful.
5. RPsec in Detail
Detailed design of the RPsec databases. To be included in the next
version of the draft.
6. Representation and Distribution of RPsec Policies
This section explains the YANG models for each RPsec database. It
describes a possible way of configuring RPsec databases in the
network in compiance with the IETF's policy-based network managment
(PBMN) and distributed management architecture.
For management of the contents of the RPsec databases, the data
fields of the RPsec databases are organized and defined in four
modules:
Atwood & Prajapati Expires April 30, 2015 [Page 6]
Internet-Draft Secure Routing October 2014
o RPsec common types module
o RPAD module
o RSPD module
o CKT module
The material on YANG models will be included in the next version of
the draft.
7. IANA Considerations
This document has no actions for IANA.
8. Acknowledgements
The original idea for the RAPD database was presented in
[I-D.atwood-karp-aapm-rp].
9. Change History (RFC Editor: Delete Before Publishing)
[NOTE TO RFC EDITOR: this section for use during I-D stage only.
Please remove before publishing as RFC.]
atwood-rtgwg-secure-routing-00 (original submission, based on Nitin's
thesis)
o copied in some sections of the thesis that are relevant to the
specification.
10. Needs Work in Next Draft (RFC Editor: Delete Before Publishing)
[NOTE TO RFC EDITOR: this section for use during I-D stage only.
Please remove before publishing as RFC.]
List of stuff that still needs work
o Flesh out sections on RPsec databases and YANG models.
o
o
o
o
Atwood & Prajapati Expires April 30, 2015 [Page 7]
Internet-Draft Secure Routing October 2014
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[I-D.atwood-karp-aapm-rp]
william.atwood@concordia.ca, w., Somanatha, R., Hartman,
S., and D. Zhang, "Authentication, Authorization and
Policy Management for Routing Protocols", draft-atwood-
karp-aapm-rp-00 (work in progress), July 2013.
[I-D.hartman-karp-mrkmp]
Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router
Key Management Protocol (MaRK)", draft-hartman-karp-
mrkmp-05 (work in progress), September 2012.
[I-D.mahesh-karp-rkmp]
Jethanandani, M., Weis, B., Patel, K., Zhang, D., Hartman,
S., Chunduri, U., Tian, A., and J. Touch, "Negotiation for
Keying Pairwise Routing Protocols in IKEv2", draft-mahesh-
karp-rkmp-05 (work in progress), November 2013.
[I-D.tran-karp-mrmp]
Tran, P. and B. Weis, "The Use of G-IKEv2 for Multicast
Router Key Management", draft-tran-karp-mrmp-02 (work in
progress), October 2012.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross,
"GSAKMP: Group Secure Association Key Management
Protocol", RFC 4535, June 2006.
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the
IAB workshop on Unwanted Traffic March 9-10, 2006", RFC
4948, August 2007.
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
Extensions to the Security Architecture for the Internet
Protocol", RFC 5374, November 2008.
Atwood & Prajapati Expires April 30, 2015 [Page 8]
Internet-Draft Secure Routing October 2014
[RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and
Confidentiality in Protocol Independent Multicast Sparse
Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, September 2010.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, October 2011.
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", RFC 6518,
February 2012.
[RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
Authentication for Routing Protocols (KARP) Overview,
Threats, and Requirements", RFC 6862, March 2013.
[RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys", RFC
7210, April 2014.
[RFC7211] Hartman, S. and D. Zhang, "Operations Model for Router
Keying", RFC 7211, June 2014.
Authors' Addresses
William Atwood
Concordia University/CSE
1455 de Maisonneuve Blvd, West
Montreal, QC H3G 1M8
Canada
Phone: +1(514)848-2424 ext3046
Email: william.atwood@concordia.ca
URI: http://users.encs.concordia.ca/~bill
Nitin Prajapati
Concordia University/CSE
1455 de Maisonneuve Blvd, West
Montreal, QC H3G 1M8
Canada
Email: prajapatinitin@hotmail.com
Atwood & Prajapati Expires April 30, 2015 [Page 9]
