draft-ietf-karp-ops-model-02.txt   draft-ietf-karp-ops-model-03.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: October 28, 2012 Huawei Expires: January 13, 2013 Huawei
April 26, 2012 July 12, 2012
Operations Model for Router Keying Operations Model for Router Keying
draft-ietf-karp-ops-model-02.txt draft-ietf-karp-ops-model-03.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 April 25, 2012. This Internet-Draft will expire on January 13, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
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. Protocol Limitations from the Key Table . . . . . . . . . 7 3.3. Interactions with Automated Key Management . . . . . . . . 7
3.4. VRFs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. VRFs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Credentials and Authorization . . . . . . . . . . . . . . . . 9 4. Credentials and Authorization . . . . . . . . . . . . . . . . 8
4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 12 4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 11
4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 12 4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 11
4.4. The role of Central Servers . . . . . . . . . . . . . . . 13 4.4. The role of Central Servers . . . . . . . . . . . . . . . 12
5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 14 5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 13
6. Administrator Involvement . . . . . . . . . . . . . . . . . . 16 6. Administrator Involvement . . . . . . . . . . . . . . . . . . 15
6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 16 6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 15
7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . . 18 7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . . 17
8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The KARP working group is designing improvements to the cryptographic The KARP working group is designing improvements to the cryptographic
authentication of IETF routing protocols. These improvements include authentication of IETF routing protocols. These improvements include
improvements to how integrity functions are handled within each improvements to how integrity functions are handled within each
protocol as well as designing an automated key management solution. protocol as well as designing an automated key management solution.
This document discusses issues to consider when thinking about the This document discusses issues to consider when thinking about the
operational and management model for KARP. Each implementation will operational and management model for KARP. Each implementation will
skipping to change at page 5, line 31 skipping to change at page 5, line 31
reception and the set of keys used for transmission, but may use reception and the set of keys used for transmission, but may use
different keys for different links. The most general management different keys for different links. The most general management
model would be to configure keys per link. However for deployments model would be to configure keys per link. However for deployments
where the area uses the same key it would be strongly desirable to where the area uses the same key it would be strongly desirable to
configure the key as a property of the area. If the keys are configure the key as a property of the area. If the keys are
configured per-link, they can get out of sync. In order to support configured per-link, they can get out of sync. In order to support
generality of configuration and common operational situations, it generality of configuration and common operational situations, it
would be desirable to have some sort of inheritance where default would be desirable to have some sort of inheritance where default
configurations are made per-area unless overridden per-interface. configurations are made per-area unless overridden per-interface.
As described in [I-D.housley-saag-crypto-key-table], the As described in [I-D.ietf-karp-crypto-key-table], the cryptographic
cryptographic keys are separated from the interface configuration keys are separated from the interface configuration into their own
into their own configuration store. This document should specify how configuration store. Each routing protocol is responsible for
key selection interacts with the key table. One possible approach defining the form of the Peer specification used by that protocol.
would be to assume that all keys that permit use on a given interface Thus each routing protocol needs to define the scope of keys. For
would be used on that interface with no additional configuration group keying, the Peer specification names the group. A protocol
steps. If this model is adopted then the key table draft should be could define a Peer specification indicating the key had a link scope
expanded to permit specification of domains and areas as well. It's and also a Peer specification for scoping a key to a specific area.
not clear why "all" is permitted as an interface specification in For link-scoped keys it is generally best to define a single Peer
this model; it seems unlikely that it would be desirable to use the specification indicating the key has a link scope and to use
same set of keys for two different instances of an IGP or across interface restrictions to restrict the key to the appropriate link.
autonomous system boundaries.
Another model is that the interface specification in the key table is
a restriction that limits keys on top of other configuration enabling
them. Then a set of keys from the key table is attached to an
interface, area or routing domain using an additional configuration
step. This avoids the previous problems at the expense of
significant complexity of configuration.
Operational Requirements: KARP MUST support configuration of keys at Operational Requirements: KARP MUST support configuration of keys at
the most general scope for the underlying protocol; protocols the most general scope for the underlying protocol; protocols
supporting per-peer keys MUST permit configuration of per-peer keys, supporting per-peer keys MUST permit configuration of per-peer keys,
protocols supporting per-interface keys MUST support configuration of protocols supporting per-interface keys MUST support configuration of
per-interface keys, and so on. KARP MUST NOT permit configuration of per-interface keys, and so on. KARP MUST NOT permit configuration of
an inappropriate key scope. For example, configuration of separate an inappropriate key scope. For example, configuration of separate
keys per interface MUST NOT be supported for a protocol requiring keys per interface MUST NOT be supported for a protocol requiring
per-area keys. per-area keys. This restriction can be enforced by rules specified
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.housley-saag-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. At a minimum, the router MUST verify: entries added to the table. Routing protocols describe how their
protocol interacts with the key table including what validation MUSt
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.
o The peer and interface specification is consistent with the o The peer specification is consistent with the protocol.
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. uniform configuration or preparing for fail-over.
skipping to change at page 7, line 4 skipping to change at page 6, line 47
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 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. key for sending is desirable.
3.3. Protocol Limitations from the Key Table The key table's schema supports these operations. However equipment
can improve usability by providing convenient functions to effect
The format of the key table imposes a few limitations on routing these common changes.
protocols. The first is that the key ID is 16 bits; some routing
protocols have 32-bit key identifiers. A key mapping table as
discussed in 4.1 of [I-D.polk-saag-rtg-auth-keytable] could be used
to map to the larger key identifier. However it's probably desirable
to either decide that only 16 bits of the key ID space is to be used
or to expand the identifier space in the key table. From a
management standpoint we need to make concrete requirements around
whether a key ID is per-protocol or whether subspaces in the key ID
space are reserved for each protocol. This is necessary so that
implementations from different vendors can be managed consistently.
The second requirement that the key table places is that the key ID 3.3. Interactions with Automated Key Management
is scoped fairly broadly. At least within some protocols such as
OSPF, the key ID might only need to be unique per-link or per-peer.
That is, packets sent on two different interfaces could use key ID 32
even if the keys were different for these interfaces. An
implementation could use the interface and the key ID as a lookup to
find the right key. However, the key table draft requires that a key
ID be sufficient to look up a key, meaning that the key ID is a
globally scoped identifier. There is nothing wrong with this
restriction, but it does need to be noted when assigning key IDs for
a domain.
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
receiver and transmitter, then there is complexity in key management receiver and transmitter, then there is complexity in key management
skipping to change at page 9, line 10 skipping to change at page 8, line 10
interacts with this. The obvious first-order answer is that each interacts with this. The obvious first-order answer is that each
routing instance gets its own key table. However, we need to routing instance gets its own key table. However, we need to
consider how these instances interact with each other and confirm consider how these instances interact with each other and confirm
this makes sense. this makes sense.
4. Credentials and Authorization 4. Credentials and Authorization
Several methods for authentication have been proposed for KARP. The Several methods for authentication have been proposed for KARP. The
simplest is preshared keys used directly as traffic keys. In this simplest is preshared keys used directly as traffic keys. In this
mode, the traffic integrity keys are directly configured. This is mode, the traffic integrity keys are directly configured. This is
the mode supported by today's routing protocols. the mode supported by most of today's routing protocols.
As discussed in [I-D.polk-saag-rtg-auth-keytable], preshared keys can As discussed in [I-D.polk-saag-rtg-auth-keytable], preshared keys can
be used as the input to a key derivation function (KDF) to generate be used as the input to a key derivation function (KDF) to generate
traffic keys. For example the TCP Authentication Option (TCP-AO) traffic keys. For example the TCP Authentication Option (TCP-AO)
[RFC5925] derives keys based on the initial TCP session state. [RFC5925] derives keys based on the initial TCP session state.
Typically a KDF will combine a long-term key with public inputs Typically a KDF will combine a long-term key with public inputs
exchanged as part of the protocol to form fresh session keys. a KDF exchanged as part of the protocol to form fresh session keys. a KDF
could potentially be used with some inputs that are configured along could potentially be used with some inputs that are configured along
with the long-term key. Also, it's possible that inputs to a KDF with the long-term key. Also, it's possible that inputs to a KDF
will be private and exchanged as part of the protocol, although this will be private and exchanged as part of the protocol, although this
skipping to change at page 16, line 51 skipping to change at page 15, line 51
First, security solutions may introduce faults. For example if First, security solutions may introduce faults. For example if
certificates expire in a PKI, previous adjacencies may no longer certificates expire in a PKI, previous adjacencies may no longer
form. Operational practice will require a way of repairing these form. Operational practice will require a way of repairing these
errors. This may end up being very similar to deploying a router errors. This may end up being very similar to deploying a router
that is connecting a new site as the security fault may have that is connecting a new site as the security fault may have
partitioned the network. However, unlike a new deployment, the event partitioned the network. However, unlike a new deployment, the event
is unplanned. Strategies such as configuring a router and shipping is unplanned. Strategies such as configuring a router and shipping
it to a site may not be appropriate for recovering a fault even it to a site may not be appropriate for recovering a fault even
though they may be more useful for new deployments. though they may be more useful for new deployments.
Monitoring will play a critical role in avoiding security faults such Notifications will play a critical role in avoiding security faults.
as certificate expiration. However, the protocols MUST still have Implementations SHOULD use appropriate mechanisms to notify operators
adequate operational mechanisms to recover from these situations. as security resources are about to expire. Notifications can include
Also, some faults, such as those resulting from a compromise or messages to consoles, logged events, SNMP traps, or notifications
actual attack on a facility are inherent and may not be prevented. within a routing protocol. One strategy is to have increasing
escalations of notifications.
Monitoring will also play a important role in avoiding security
faults such as certificate expiration. However, the protocols MUST
still have adequate 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.
To address these operational considerations, we should identify To address these operational considerations, we should identify
circumstances surrounding recovery from today's faults and understand circumstances surrounding recovery from today's faults and understand
how protocols will impact mechanisms used today. how protocols will impact mechanisms used today.
7. Upgrade Considerations 7. Upgrade Considerations
It needs to be possible to deploy automated key management in an It needs to be possible to deploy automated key management in an
organization without either having to disable existing security or organization without either having to disable existing security or
disrupting routing. As a result, it needs to be possible to perform disrupting routing. As a result, it needs to be possible to perform
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
disrupting routing. Today, many operators do not update keys because
the perceived risk of an attack is lower than the complexity of and
update and risk of routing disruptions.
For peer-to-peer protocols such as BGP, this is likely to be For peer-to-peer protocols such as BGP, this can be relatively easy.
relatively easy. First, code that supports automated key management First, code that supports automated key management needs to be loaded
needs to be loaded on both peers. Then the adjacency can be on both peers. Then the adjacency can be upgraded. The
upgraded. The configuration can be updated to switch to automated configuration can be updated to switch to automated key management
key management when the second router reboots. when the second router reboots. Alternatively, if the key management
protocols involved can detect that both peers now support automated
key management, then a key can potentially be negotiated for an
existing session.
The situation is more complicated for multicast protocols. It's The situation is more complicated for multicast protocols. It's
probably not reasonable to bring down an entire link to reconfigure probably not reasonable to bring down an entire link to reconfigure
it as using automated key management. Two approaches should be it as using automated key management. Two approaches should be
considered. One is to support key table rows from the automated key considered. One is to support key table rows supporting the
management and manually configured for the same link at the same automated key management and manually configured keying for the same
time. Coordinating this may be tricky. Another possibility is for link at the same time. Coordinating this may be tricky. Another
the automated key management protocol to actually select the same possibility is for the automated key management protocol to actually
traffic key that is being used manually select the same traffic key that is being used manually. This could
potentilaly be accomplished by having an option in the key management
8. Related Work protocol to export the current manual group key through the automated
key management protocol. Then after all nodes are configured with
Discuss draft-housley-saag-*, draft-polk-saag-*, the discussions in automated key management, manual key entries can be removed. The
the KARP framework, etc. next re-key after all nodes have manual entries removed will generate
a new fresh key.
9. Security Considerations 8. Security Considerations
This document does not define a protocol. It does discuss the This document does not define a protocol. It does discuss the
operational and management implications of several security operational and management implications of several security
technologies. technologies.
10. Acknowledgments 9. Acknowledgments
Funding for Sam Hartman's work on this memo is provided by Huawei. Funding for Sam Hartman's work on this memo is provided by Huawei.
The authors would like to thank Gregory Lebovitz, Russ White and Bill The authors would like to thank Gregory Lebovitz, Russ White and Bill
Atwood for valuable reviews. Atwood for valuable reviews.
11. References 10. References
11.1. Normative References 10.1. Normative References
[I-D.housley-saag-crypto-key-table] [I-D.ietf-karp-crypto-key-table]
Housley, R. and T. Polk, "Database of Long-Lived Symmetric Housley, R., Polk, T., Hartman, S., and D. Zhang,
Cryptographic Keys", "Database of Long-Lived Symmetric Cryptographic Keys",
draft-housley-saag-crypto-key-table-04 (work in progress), draft-ietf-karp-crypto-key-table-03 (work in progress),
October 2010. June 2012.
[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 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-07 (work in progress), draft-ietf-karp-design-guide-10 (work in progress),
October 2011. December 2011.
[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. 26 change blocks. 
105 lines changed or deleted 93 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/