draft-ietf-karp-ops-model-09.txt   draft-ietf-karp-ops-model-10.txt 
Network Working Group S. Hartman Network Working Group S. Hartman
Internet-Draft Painless Security Internet-Draft Painless Security
Intended status: Informational D. Zhang Intended status: Informational D. Zhang
Expires: April 14, 2014 Huawei Expires: July 13, 2014 Huawei
October 11, 2013 January 9, 2014
Operations Model for Router Keying Operations Model for Router Keying
draft-ietf-karp-ops-model-09.txt draft-ietf-karp-ops-model-10.txt
Abstract Abstract
The IETF is engaged in an effort to analyze security of routing The IETF is engaged in an effort to analyze security of routing
protocol authentication according to design guidelines discussed in protocol authentication according to design guidelines discussed in
RFC 6518. Developing an operational and management model for routing RFC 6518. Developing an operational and management model for routing
protocol security that works with all the routing protocols will be protocol security that works with all the routing protocols will be
critical to the deployability of these efforts. This document gives critical to the deployability of these efforts. This document gives
recommendations to operators and implementors regarding management recommendations to operators and implementors regarding management
and operation of router authentication. These recommendations will and operation of router authentication. These recommendations will
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 14, 2014. This Internet-Draft will expire on July 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 25 skipping to change at page 2, line 25
3.1. Integrity of the Key Table . . . . . . . . . . . . . . . . 6 3.1. Integrity of the Key Table . . . . . . . . . . . . . . . . 6
3.2. Management of Key Table . . . . . . . . . . . . . . . . . 6 3.2. Management of Key Table . . . . . . . . . . . . . . . . . 6
3.3. Interactions with Automated Key Management . . . . . . . . 7 3.3. Interactions with Automated Key Management . . . . . . . . 7
3.4. Virtual Routing and Forwarding Instances (VRFs) . . . . . 7 3.4. Virtual Routing and Forwarding Instances (VRFs) . . . . . 7
4. Credentials and Authorization . . . . . . . . . . . . . . . . 8 4. Credentials and Authorization . . . . . . . . . . . . . . . . 8
4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Sharing Keys and Zones of Trust . . . . . . . . . . . 10 4.1.1. Sharing Keys and Zones of Trust . . . . . . . . . . . 10
4.1.2. Key Separation and Protocol Design . . . . . . . . . . 11 4.1.2. Key Separation and Protocol Design . . . . . . . . . . 11
4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 11 4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 11
4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 12 4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 12
4.4. The role of Central Servers . . . . . . . . . . . . . . . 12 4.4. The role of Central Servers . . . . . . . . . . . . . . . 13
5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 14 5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 14
6. Administrator Involvement . . . . . . . . . . . . . . . . . . 16 6. Administrator Involvement . . . . . . . . . . . . . . . . . . 16
6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 16 6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 16
7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . . 18 7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
skipping to change at page 6, line 31 skipping to change at page 6, line 31
determination, the router MUST verify the internal consistency of determination, the router MUST verify the internal consistency of
entries added to the table. Routing protocols describe how their entries added to the table. Routing protocols describe how their
protocol interacts with the key table including what validation MUST protocol interacts with the key table including what validation MUST
be performed. At a minimum, the router MUST verify: be performed. At a minimum, the router MUST verify:
o The cryptographic algorithms are valid for the protocol. o The cryptographic algorithms are valid for the protocol.
o The key derivation function is valid for the protocol. o The key derivation function is valid for the protocol.
o The direction is valid for the protocol; for example protocols o The direction is valid for the protocol; for example protocols
that require the same session key be used in both directions MUST that require the same session key be used in both directions
have a direction of both. REQUIRE have a direction of both be specified in the key table
entry.
o The peer specification is consistent with the protocol. o The peer specification is consistent with the protocol.
Other checks are possible. For example the router could verify that Other checks are possible. For example the router could verify that
if a key is associated with a peer, that peer is a configured peer if a key is associated with a peer, that peer is a configured peer
for the specified protocol. However, this may be undesirable. It for the specified protocol. However, this may be undesirable. It
may be desirable to load a key table when some peers have not yet may be desirable to load a key table when some peers have not yet
been configured. Also, it may be desirable to share portions of a been configured. Also, it may be desirable to share portions of a
key table across devices even when their current configuration does key table across devices even when their current configuration does
not require an adjacency with a particular peer in the interest of not require an adjacency with a particular peer in the interest of
uniform configuration or preparing for fail-over. For these reasons, uniform configuration or preparing for fail-over. For these reasons,
these additional checks are generally undesirable. these additional checks are generally undesirable.
3.2. Management of Key Table 3.2. Management of Key Table
Several management operations will be quite common. For service Several management interfaces will be quite common. For service
provider deployments the configuration management system can simply provider deployments the configuration management system can simply
update the key table. However, for smaller deployments, efficient update the key table. However, for smaller deployments, efficient
management operations that do not require a configuration management management interfaces that do not require a configuration management
system are important. In these environments configuration interfaces system are important. In these environments configuration interfaces
(such as web interfaces and command-line interfaces) provided (such as web interfaces and command-line interfaces) provided
directly by the router will be important to easy management of the directly by the router will be important to easy management of the
router. router.
As part of adding a new key it is typically desirable to set an As part of adding a new key it is typically desirable to set an
expiration time for an old key. The management interface SHOULD expiration time for an old key. The management interface SHOULD
provide a mechanism to easily update the expiration time for a provide a mechanism to easily update the expiration time for a
current key used with a given peer or interface. Also when adding a current key used with a given peer or interface. Also when adding a
key it is desirable to push the key out to nodes that will need it, key it is desirable to push the key out to nodes that will need it,
allowing use for receiving packets then later enabling transmit. allowing use for receiving packets then later enabling transmit.
This can be accomplished automatically by providing a delay between This can be accomplished automatically by providing a delay between
when a key becomes valid for reception and transmission. However, when a key becomes valid for reception and transmission. However,
some environments may not be able to predict when all the necessary some environments may not be able to predict when all the necessary
changes will be made. In these cases having a mechanism to enable a changes will be made. In these cases having a mechanism to enable a
key for sending is desirable. Management interfaces SHOULD provide key for sending is desirable. The management interface SHOULD
an easy mechanism to update the direction of an existing key or to provide an easy mechanism to update the direction of an existing key
enable a disabled key. or to enable a disabled key.
Implementations SHOULD permit a configuration in which if no Implementations SHOULD permit a configuration in which if no
unexpired key is available, existing security associations continue unexpired key is available, existing security associations continue
using the expired key with which they were established. using the expired key with which they were established.
Implementations MUST support a configuration in which security Implementations MUST support a configuration in which security
associations fail if no un-expired key is available for them. See associations fail if no un-expired key is available for them. See
Section 6.2 for a discussion of reporting and managing security Section 6.2 for a discussion of reporting and managing security
faults including those related to key expiration. faults including those related to key expiration.
3.3. Interactions with Automated Key Management 3.3. Interactions with Automated Key Management
skipping to change at page 12, line 44 skipping to change at page 12, line 44
Assuming that self-signed certificates are used by routers that wish Assuming that self-signed certificates are used by routers that wish
to use public keys but that do not need a PKI, then PKI and the to use public keys but that do not need a PKI, then PKI and the
infrastructureless mode of public-key operation described in the infrastructureless mode of public-key operation described in the
previous section can work well together. One router could identify previous section can work well together. One router could identify
its peers based on names and use certificate validation. Another its peers based on names and use certificate validation. Another
router could use hashes of certificates. This could be very useful router could use hashes of certificates. This could be very useful
for border routers between two organizations. Smaller organizations for border routers between two organizations. Smaller organizations
could use public keys and larger organizations could use PKI. could use public keys and larger organizations could use PKI.
A PKI has significant operational concerns including certification
practices, handling revocation and operational practices around
certificate validation. The Routing PKI (RPKI) has addressed these
concerns within the scope of BGP and validation of address ownership.
Adapting these practices to routing protocol authentication is
outside the scope of this document.
4.4. The role of Central Servers 4.4. The role of Central Servers
An area to explore is the role of central servers like RADIUS or An area to explore is the role of central servers like RADIUS or
directories. Routers need to securely operate in order to provide directories. Routers need to securely operate in order to provide
network routing services. Routers cannot generally contact a central network routing services. Routers cannot generally contact a central
server while establishing routing because the router might not have a server while establishing routing because the router might not have a
functioning route to the central service until after routing is functioning route to the central service until after routing is
established. As a result, a system where keys are pushed by a established. As a result, a system where keys are pushed by a
central management system is an undesirable result for router keying. central management system is an undesirable result for router keying.
However central servers may play a role in authorization and key However central servers may play a role in authorization and key
skipping to change at page 18, line 20 skipping to change at page 18, line 20
a phased upgrade from manual keying to automated key management. a phased upgrade from manual keying to automated key management.
This upgrade procedure needs to be easy and have a very low risk of This upgrade procedure needs to be easy and have a very low risk of
disrupting routing. Today, many operators do not update keys because disrupting routing. Today, many operators do not update keys because
the perceived risk of an attack is lower than the cost of an update the perceived risk of an attack is lower than the cost of an update
combined with the potential cost of routing disruptions during the combined with the potential cost of routing disruptions during the
update. Even when a routing protocol has technical mechanisms that update. Even when a routing protocol has technical mechanisms that
permit an update with no disruption in service, there is still a permit an update with no disruption in service, there is still a
potential cost of service disruptions as operational procedures and potential cost of service disruptions as operational procedures and
practices need to correctly use the technical mechanisms. practices need to correctly use the technical mechanisms.
For peer-to-peer protocols such as BGP, this can be relatively easy. For peer-to-peer protocols such as BGP, upgrading to automated key
First, code that supports automated key management needs to be loaded management can be relatively easy. First, code that supports
on both peers. Then the adjacency can be upgraded. The automated key management needs to be loaded on both peers. Then the
configuration can be updated to switch to automated key management adjacency can be upgraded. The configuration can be updated to
when the second router reboots. Alternatively, if the key management switch to automated key management when the second router reboots.
protocols involved can detect that both peers now support automated Alternatively, if the key management protocols involved can detect
key management, then a key can potentially be negotiated for an that both peers now support automated key management, then a key can
existing session. potentially be negotiated for an existing session.
The situation is more complex for organizations that have not The situation is more complex for organizations that have not
upgraded from TCP MD5 [RFC2385] to the TCP Authentication Option upgraded from TCP MD5 [RFC2385] to the TCP Authentication Option
[RFC5925]. Today, routers typically need to understand whether a [RFC5925]. Today, routers typically need to understand whether a
given peer supports TCP MD5 or TCP-AO before opening a TCP given peer supports TCP MD5 or TCP-AO before opening a TCP
connection. In addition, many implementations support grouping connection. In addition, many implementations support grouping
configuration of related peers including security configuration configuration of related peers including security configuration
together. Implementations make it challenging to move from TCP-MD5 together. Implementations make it challenging to move from TCP-MD5
to TCP-AO before all peers in the group are ready. Operators to TCP-AO before all peers in the group are ready. Operators
perceive it as high risk to update the configuration of a large perceive it as high risk to update the configuration of a large
skipping to change at page 23, line 12 skipping to change at page 23, line 12
The authors would like to thank Bill Atwood , Randy Bush, Wes George, The authors would like to thank Bill Atwood , Randy Bush, Wes George,
Gregory Lebovitz, and Russ White for valuable reviews. Gregory Lebovitz, and Russ White for valuable reviews.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-karp-crypto-key-table] [I-D.ietf-karp-crypto-key-table]
Housley, R., Polk, T., Hartman, S., and D. Zhang, Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys", "Database of Long-Lived Symmetric Cryptographic Keys",
draft-ietf-karp-crypto-key-table-08 (work in progress), draft-ietf-karp-crypto-key-table-10 (work in progress),
July 2013. December 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References 11.2. Informative References
[I-D.ietf-karp-design-guide] [I-D.ietf-karp-design-guide]
Lebovitz, G. and M. Bhatia, "Keying and Authentication for Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", Routing Protocols (KARP) Design Guidelines",
draft-ietf-karp-design-guide-10 (work in progress), draft-ietf-karp-design-guide-10 (work in progress),
December 2011. December 2011.
[I-D.ietf-sidr-rtr-keying] [I-D.ietf-sidr-rtr-keying]
Turner, S., Patel, K., and R. Bush, "Router Keying for Turner, S., Patel, K., and R. Bush, "Router Keying for
BGPsec", draft-ietf-sidr-rtr-keying-03 (work in progress), BGPsec", draft-ietf-sidr-rtr-keying-04 (work in progress),
September 2013. December 2013.
[I-D.liu-ospfv3-automated-keying-req] [I-D.liu-ospfv3-automated-keying-req]
Liu, Y., "OSPFv3 Automated Group Keying Requirements", Liu, Y., "OSPFv3 Automated Group Keying Requirements",
draft-liu-ospfv3-automated-keying-req-01 (work in draft-liu-ospfv3-automated-keying-req-01 (work in
progress), July 2007. progress), July 2007.
[I-D.polk-saag-rtg-auth-keytable] [I-D.polk-saag-rtg-auth-keytable]
Polk, T. and R. Housley, "Routing Authentication Using A Polk, T. and R. Housley, "Routing Authentication Using A
Database of Long-Lived Cryptographic Keys", Database of Long-Lived Cryptographic Keys",
draft-polk-saag-rtg-auth-keytable-05 (work in progress), draft-polk-saag-rtg-auth-keytable-05 (work in progress),
 End of changes. 13 change blocks. 
25 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/