draft-ietf-karp-ops-model-05.txt   draft-ietf-karp-ops-model-06.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: August 29, 2013 Huawei Expires: November 21, 2013 Huawei
February 25, 2013 May 20, 2013
Operations Model for Router Keying Operations Model for Router Keying
draft-ietf-karp-ops-model-05.txt draft-ietf-karp-ops-model-06.txt
Abstract Abstract
Developing an operational and management model for routing protocol Developing an operational and management model for routing protocol
security that works across protocols will be critical to the success security that works across protocols will be critical to the success
of routing protocol security efforts. This document discusses issues of routing protocol security efforts. This document discusses issues
and begins to consider development of these models. and begins to consider development of these models.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 August 29, 2013. This Internet-Draft will expire on November 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
3. Breakdown of KARP configuration . . . . . . . . . . . . . . . 5 3. Breakdown of KARP configuration . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 3, line 24 skipping to change at page 3, line 24
take its own approach to management; this is one area for vendor take its own approach to management; this is one area for vendor
differentiation. However, it is desirable to have a common baseline differentiation. However, it is desirable to have a common baseline
for the management objects allowing administrators, security for the management objects allowing administrators, security
architects and protocol designers to understand what management architects and protocol designers to understand what management
capabilities they can depend on in heterogeneous environments. capabilities they can depend on in heterogeneous environments.
Similarly, designing and deploying the protocol will be easier with Similarly, designing and deploying the protocol will be easier with
thought paid to a common operational model. This will also help with thought paid to a common operational model. This will also help with
the design of NetConf schemas or MIBs later. the design of NetConf schemas or MIBs later.
This document also gives recommendations for how management and This document also gives recommendations for how management and
operations issues can be approached as protocols are revised and as operational issues can be approached as protocols are revised and as
support is added for the key table [I-D.ietf-karp-crypto-key-table] support is added for the key table [I-D.ietf-karp-crypto-key-table]
2. Requirements notation 2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Breakdown of KARP configuration 3. Breakdown of KARP configuration
skipping to change at page 6, line 12 skipping to change at page 6, line 12
per-area keys. This restriction can be enforced by rules specified per-area keys. This restriction can be enforced by rules specified
by each routing protocol for validating key table entries. by each routing protocol for validating key table entries.
3.1. Integrity of the Key Table 3.1. Integrity of the Key Table
The routing key table [I-D.ietf-karp-crypto-key-table] provides a The routing key table [I-D.ietf-karp-crypto-key-table] provides a
very general mechanism to abstract the storage of keys for routing very general mechanism to abstract the storage of keys for routing
protocols. To avoid misconfiguration and simplify problem protocols. To avoid misconfiguration and simplify problem
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 MUST
have a direction of both. have a direction of both.
skipping to change at page 6, line 39 skipping to change at page 6, line 39
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. uniform configuration or preparing for fail-over.
3.2. Management of Key Table 3.2. Management of Key Table
Several management operations will be quite common. For service Several management operations 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 are important. management operations that do not require a configuration management
system are important.
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. Management interfaces SHOULD provide
an easy mechanism to update the direction of an existing key or to an easy mechanism to update the direction of an existing key or to
enable a disabled key. enable a disabled key.
Implementations SHOULD permit a configuration in which if no
unexpired key is available, existing security associations continue
using the expired key with which they were established.
Implementations MUST support a configuration in which security
associations fail if no un-expired key is available for them. See
Section 6.2 for a discussion of security faults including those
related to key expiration.
3.3. Interactions with Automated Key Management 3.3. Interactions with Automated Key Management
Consideration is required for how an automated key management Consideration is required for how an automated key management
protocol will assign key IDs for group keys. All members of the protocol will assign key IDs for group keys. All members of the
group may need to use the same key ID. This requires careful group may need to use the same key ID. This requires careful
coordination of global key IDs. Interactions with the peer key ID coordination of global key IDs. Interactions with the peer key ID
field may make this easier; this requires additional study. field may make this easier; this requires additional study.
Automated key management protocols also assign keys for single peers. Automated key management protocols also assign keys for single peers.
If the key ID is global and needs to be coordinated between the If the key ID is global and needs to be coordinated between the
skipping to change at page 8, line 30 skipping to change at page 8, line 30
will be private and exchanged as part of the protocol, although this will be private and exchanged as part of the protocol, although this
will be uncommon in KARP's uses of KDFs. will be uncommon in KARP's uses of KDFs.
Preshared keys could also be used by an automated key management Preshared keys could also be used by an automated key management
protocol. In this mode, preshared keys would be used for protocol. In this mode, preshared keys would be used for
authentication. However traffic keys would be generated by some key authentication. However traffic keys would be generated by some key
agreement mechanism or transported in a key encryption key derived agreement mechanism or transported in a key encryption key derived
from the preshared key. This mode may provide better replay from the preshared key. This mode may provide better replay
protection. Also, in the absence of active attackers, key agreement protection. Also, in the absence of active attackers, key agreement
strategies such as Diffie-Hellman can be used to produce high-quality strategies such as Diffie-Hellman can be used to produce high-quality
traffic keys even from relatively weak preshared keys. traffic keys even from relatively weak preshared keys. These key-
agreement mechanisms are valuable even when active attackers are
present, although an active attacker can mount a man-in-the-middle
attack if the preshared key is sufficiently weak.
Public keys can be used for authentication. The design guide Public keys can be used for authentication within an automated key
[I-D.ietf-karp-design-guide] describes a mode in which routers have management protocol. The design guide [I-D.ietf-karp-design-guide]
the hashes of peer routers' public keys. In this mode, a traditional describes a mode in which routers have the hashes of peer routers'
public-key infrastructure is not required. The advantage of this public keys. In this mode, a traditional public-key infrastructure
mode is that a router only contains its own keying material, limiting is not required. The advantage of this mode is that a router only
the scope of a compromise. The disadvantage is that when a router is contains its own keying material, limiting the scope of a compromise.
added or deleted from the set of authorized routers, all routers that The disadvantage is that when a router is added or deleted from the
peer need to be updated. Note that self-signed certificates are a set of authorized routers, all routers that peer need to be updated.
common way of communicating public-keys in this style of Note that self-signed certificates are a common way of communicating
authentication. public-keys in this style of authentication.
Certificates signed by a certification authority or some other PKI Certificates signed by a certification authority or some other PKI
could be used. The advantage of this approach is that routers may could be used for authentication within an automated key management
not need to be directly updated when peers are added or removed. The protocol. The advantage of this approach is that routers may not
need to be directly updated when peers are added or removed. The
disadvantage is that more complexity and cost is required. disadvantage is that more complexity and cost is required.
Each of these approaches has a different set of management and Each of these approaches has a different set of management and
operational requirements. Key differences include how authorization operational requirements. Key differences include how authorization
is handled and how identity works. This section discusses these is handled and how identity works. This section discusses these
differences. differences.
4.1. Preshared Keys 4.1. Preshared Keys
In the protocol, manual preshared keys are either unnamed or named by In the protocol, manual preshared keys are either unnamed or named by
skipping to change at page 15, line 11 skipping to change at page 15, line 11
PKI are used to introduce peers to a router. In this case, rather PKI are used to introduce peers to a router. In this case, rather
than configuring peers, , the router needs to be configured with than configuring peers, , the router needs to be configured with
information on what certificates represent acceptable peers. information on what certificates represent acceptable peers.
Another consideration is what routing protocols share peers. For Another consideration is what routing protocols share peers. For
example it may be common for LDP peers to also be peers of some other example it may be common for LDP peers to also be peers of some other
routing protocol. Also, RSVP-TE may be associated with some TE-based routing protocol. Also, RSVP-TE may be associated with some TE-based
IGP. In some of these cases it would be desirable to use the same IGP. In some of these cases it would be desirable to use the same
authorization information for both routing protocols. authorization information for both routing protocols.
Finally, as discussed in Section 7, it is sometimes desirable to
override some aspect of the configuration for a peer in a group. As
an example, when rotating to a new key, it is desirable to be able to
roll that key out to each peer that will use the key even if in the
stable state the key is configured for a peer group.
In order to develop a management model for authorization, the working In order to develop a management model for authorization, the working
group needs to consider several questions. What protocols support group needs to consider several questions. What protocols support
auto-discovery of peers? What protocols require more configuration auto-discovery of peers? What protocols require more configuration
of a peer than simply the peer's authorization information and of a peer than simply the peer's authorization information and
network address? What management operations are going to be common network address? What management operations are going to be common
as security information for peers is configured and updated? What as security information for peers is configured and updated? What
operations will be common while performing key transitions or while operations will be common while performing key transitions or while
migrating to new security technologies? migrating to new security technologies?
6. Administrator Involvement 6. Administrator Involvement
skipping to change at page 17, line 10 skipping to change at page 17, line 10
that can partition a network. that can partition a network.
Notifications will play a critical role in avoiding security faults. Notifications will play a critical role in avoiding security faults.
Implementations SHOULD use appropriate mechanisms to notify operators Implementations SHOULD use appropriate mechanisms to notify operators
as security resources are about to expire. Notifications can include as security resources are about to expire. Notifications can include
messages to consoles, logged events, SNMP traps, or notifications messages to consoles, logged events, SNMP traps, or notifications
within a routing protocol. One strategy is to have increasing within a routing protocol. One strategy is to have increasing
escalations of notifications. escalations of notifications.
Monitoring will also play an important role in avoiding security Monitoring will also play an important role in avoiding security
faults such as certificate expiration. However, the protocols MUST faults such as certificate expiration. Some classes of security
still have adequate operational mechanisms to recover from these fault, including issues with certificates, will affect only key
situations. Also, some faults, such as those resulting from a management protocols. other security faults can affect routing
compromise or actual attack on a facility are inherent and may not be protocols directly. However, the protocols MUST still have adequate
prevented. operational mechanisms to recover from these situations. Also, some
faults, such as those resulting from a compromise or actual attack on
a facility are inherent and may not be prevented.
A second class of faults is equipment faults that impact security. A second class of faults is equipment faults that impact security.
For example if keys are stored on a router and never moved from that For example if keys are stored on a router and never moved from that
device, failure of a router implies a need to update security device, failure of a router implies a need to update security
provisioning on the replacement router and its peers. provisioning on the replacement router and its peers.
One approach, recommended by work on securing BGP One approach, recommended by work on securing BGP
[I-D.ietf-sidr-rtr-keying] is to maintain the router's keying [I-D.ietf-sidr-rtr-keying] is to maintain the router's keying
material so that when a router is replaced the same keys can be used. material so that when a router is replaced the same keys can be used.
Router keys can be maintained on a central server. These approaches Router keys can be maintained on a central server. These approaches
skipping to change at page 21, line 12 skipping to change at page 21, 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.
10. References 10. References
10.1. Normative References 10.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-06 (work in progress), draft-ietf-karp-crypto-key-table-07 (work in progress),
February 2013. March 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.
10.2. Informative References 10.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),
 End of changes. 14 change blocks. 
28 lines changed or deleted 49 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/