draft-ietf-karp-ops-model-04.txt   draft-ietf-karp-ops-model-05.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 25, 2013 Huawei Expires: August 29, 2013 Huawei
October 22, 2012 February 25, 2013
Operations Model for Router Keying Operations Model for Router Keying
draft-ietf-karp-ops-model-04.txt draft-ietf-karp-ops-model-05.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, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
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. Interactions with Automated Key Management . . . . . . . . 7 3.3. Interactions with Automated Key Management . . . . . . . . 7
3.4. 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.2. Key Separation and Protocol Design . . . . . . . . . . 10
4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 11 4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 11
4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . 13 5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 14
6. Administrator Involvement . . . . . . . . . . . . . . . . . . 15 6. Administrator Involvement . . . . . . . . . . . . . . . . . . 16
6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 15 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
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
skipping to change at page 4, line 5 skipping to change at page 3, line 23
operational and management model for KARP. Each implementation will operational and management model for KARP. Each implementation will
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
operations issues can be approached as protocols are revised and as
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
There are multiple ways of structuring configuration information. There are multiple ways of structuring configuration information.
One factor to consider is the scope of the configuration information. One factor to consider is the scope of the configuration information.
skipping to change at page 6, line 51 skipping to change at page 6, line 51
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. Management interfaces SHOULD provide
an easy mechanism to update the direction of an existing key or to
The key table's schema supports these operations. However equipment enable a disabled key.
can improve usability by providing convenient functions to effect
these common changes.
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
receiver and transmitter, then there is complexity in key management receiver and transmitter, then there is complexity in key management
protocols. protocols.
3.4. VRFs 3.4. Virtual Routing and Forwarding Instances (VRFs)
Many core and enterprise routers support multiple routing instances. Many core and enterprise routers support multiple routing instances.
For example a router serving multiple VPNs is likely to have a For example a router serving multiple VPNs is likely to have a
forwarding/routing instance for each of these VPNs. We need to forwarding/routing instance for each of these VPNs. Each VRF will
decide how the key table and other configuration information for KARP require its own routing key table.
interacts with this. The obvious first-order answer is that each
routing instance gets its own key table. However, we need to
consider how these instances interact with each other and confirm
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 most of 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
skipping to change at page 10, line 5 skipping to change at page 10, line 5
been specified for KARP. Their naming and authorization may differ been specified for KARP. Their naming and authorization may differ
from existing uses of preshared keys in routing protocols. In from existing uses of preshared keys in routing protocols. In
particular, such keys may end up being known only by two peers. particular, such keys may end up being known only by two peers.
Alternatively they may also be known by a group of peers. Alternatively they may also be known by a group of peers.
Authorization could potentially be based on peer identity, although Authorization could potentially be based on peer identity, although
it is likely that knowing the right key will be sufficient. There it is likely that knowing the right key will be sufficient. There
does not appear to be a compelling reason to decouple the does not appear to be a compelling reason to decouple the
authorization of a key for some purpose from authorization of peers authorization of a key for some purpose from authorization of peers
holding that key to perform the authorized function. holding that key to perform the authorized function.
4.1.1. Sharing Keys and Zones of Trust
Care needs to be taken when symmetric keys are used for multiple Care needs to be taken when symmetric keys are used for multiple
purposes. Consider the implications of using the same preshared key purposes. Consider the implications of using the same preshared key
for two interfaces: it becomes impossible to cryptographically for two interfaces: it becomes impossible to cryptographically
distinguish a router on one interface from a router on another distinguish a router on one interface from a router on another
interface. So, a router that is trusted to participate in a routing interface. So, a router that is trusted to participate in a routing
protocol on one interface becomes implicitly trusted for the other protocol on one interface becomes implicitly trusted for the other
interfaces that share the key. For many cases, such as link-state interfaces that share the key. For many cases, such as link-state
routers in the same routing area, there is no significant advantage routers in the same routing area, there is no significant advantage
that an attacker could gain from this trust within the KARP threat that an attacker could gain from this trust within the KARP threat
model. However, distance-vector protocols, such as BGP and RIP, model. However, distance-vector protocols, such as BGP and RIP,
permit routes to be filtered across a trust boundary. For these permit routes to be filtered across a trust boundary. For these
protocols, participation in one interface might be more advantageous protocols, participation in one interface might be more advantageous
than another. Operationally, when this trust distinction is than another. Operationally, when this trust distinction is
important to a deployment, different keys need to be used on each important to a deployment, different keys need to be used on each
side of the trust boundary. Key derivation can help prevent this side of the trust boundary. Key derivation can help prevent this
problem in cases of accidental misconfiguration. However, key problem in cases of accidental misconfiguration. However, key
derivation cannot protect against a situation where a system was derivation cannot protect against a situation where a system was
incorrectly trusted to have the key used to perform the derivation. incorrectly trusted to have the key used to perform the derivation.
To the extent that there are multiple zones of trust and a routing This question of trust is important to the KARP threat model because
protocol is determining whether a particular router is within a it is essential to determining whether a party is an insider for a
certain zone, the question of untrusted actors is within the scope of particular routing protocol. A customer router that is an an insider
the routing threat model. for a BGP peering relationship with a service provider is not
typically an insider when considering the security of that service
provider's IGP. Similarly, To the extent that there are multiple
zones of trust and a routing protocol is determining whether a
particular router is within a certain zone, the question of untrusted
actors is within the scope of the routing threat model.
Key derivation can be part of a management solution to a desire to Key derivation can be part of a management solution to a desire to
have multiple keys for different zones of trust. A master key could have multiple keys for different zones of trust. A master key could
be combined with peer, link or area identifiers to form a router- be combined with peer, link or area identifiers to form a router-
specific preshared key that is loaded onto routers. Provided that specific preshared key that is loaded onto routers. Provided that
the master key lives only on the management server and not the the master key lives only on the management server and not the
individual routers, trust is preserved. However in many cases, individual routers, trust is preserved. However in many cases,
generating independent keys for the routers and storing the result is generating independent keys for the routers and storing the result is
more practical. If the master key were somehow compromised, all the more practical. If the master key were somehow compromised, all the
resulting keys would need to be changed. However if independent keys resulting keys would need to be changed. However if independent keys
are used, the scope of a compromise may be more limited. are used, the scope of a compromise may be more limited.
4.1.2. Key Separation and Protocol Design
More subtle problems with key separation can appear in protocol More subtle problems with key separation can appear in protocol
design. Two protocols that use the same traffic keys may work design. Two protocols that use the same traffic keys may work
together in unintended ways permitting one protocol to be used to together in unintended ways permitting one protocol to be used to
attack the other. Consider two hypothetical protocols. Protocol A attack the other. Consider two hypothetical protocols. Protocol A
starts its messages with a set of extensions that are ignored if not starts its messages with a set of extensions that are ignored if not
understood. Protocol B has a fixed header at the beginning of its understood. Protocol B has a fixed header at the beginning of its
messages but ends messages with extension information. It may be messages but ends messages with extension information. It may be
that the same message is valid both as part of protocol A and that the same message is valid both as part of protocol A and
protocol B. An attacker may be able to gain an advantage by getting a protocol B. An attacker may be able to gain an advantage by getting a
router to generate this message with one protocol under situations router to generate this message with one protocol under situations
skipping to change at page 12, line 20 skipping to change at page 12, line 28
Potentially authorization could be performed in terms of groups of Potentially authorization could be performed in terms of groups of
peers rather than single peers. An advantage of this is that it may peers rather than single peers. An advantage of this is that it may
be possible to add a new router with no authentication related be possible to add a new router with no authentication related
configuration of the peers of that router. For example, a domain configuration of the peers of that router. For example, a domain
could decide that any router with a particular keyPurposeID signed by could decide that any router with a particular keyPurposeID signed by
the organization's certificate authority is permitted to join the the organization's certificate authority is permitted to join the
IGP. Just as in configurations where cryptographic authentication is IGP. Just as in configurations where cryptographic authentication is
not used, automatic discovery of this router can establish not used, automatic discovery of this router can establish
appropriate adjacencies. appropriate adjacencies.
Assuming that potentially self-signed certificates are used by Assuming that self-signed certificates are used by routers that wish
routers that wish to use public keys but that do not need a PKI, then to use public keys but that do not need a PKI, then PKI and the
PKI and the infrastructureless mode of public-key operation described infrastructureless mode of public-key operation described in the
in the previous section can work well together. One router could previous section can work well together. One router could identify
identify its peers based on names and use certificate validation. its peers based on names and use certificate validation. Another
Another router could use hashes of certificates. This could be very router could use hashes of certificates. This could be very useful
useful for border routers between two organizations. Smaller for border routers between two organizations. Smaller organizations
organizations could use public keys and larger organizations could could use public keys and larger organizations could use PKI.
use PKI.
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. As discussed in the design-guide, a system where keys directories. As discussed in the design-guide, a system where keys
are pushed by a central management system is undesirable as an end are pushed by a central management system is undesirable as an end
result for KARP. However central servers may play a role in result for KARP. However central servers may play a role in
authorization and key rollover. For example a node could send a hash authorization and key rollover. For example a node could send a hash
of a public key to a RADIUS server. of a public key to a RADIUS server.
If central servers do play a role it will be critical to make sure If central servers do play a role it will be critical to make sure
that they are not required during routine operation or a cold-start that they are not required during routine operation or a cold-start
of a network. They are more likely to play a role in enrollment of of a network. They are more likely to play a role in enrollment of
new peers or key migration/compromise. new peers or key migration/compromise.
Another area where central servers may play a role is for group key Another area where central servers may play a role is for group key
agreement. As an example, [I-D.liu-ospfv3-automated-keying-req] agreement. As an example, [I-D.liu-ospfv3-automated-keying-req]
discusses the potential need for key agreement servers in OSPF. discusses the potential need for key agreement servers in OSPF.
Other routing protocols that use multicast or broadcast such as IS-IS Other routing protocols that use multicast or broadcast such as IS-IS
are likely to need a similar approach. are likely to need a similar approach. Multicast key agreement
protocols need to allow operators to choose which key servers will
generate traffic keys. The quality of random numbers [RFC4086] is
likely to differ between systems. As a result, operators may have
preferences for where keys are generated.
5. Grouping Peers Together 5. Grouping Peers Together
One significant management consideration will be the grouping of One significant management consideration will be the grouping of
management objects necessary to determine who is authorized to act as management objects necessary to determine who is authorized to act as
a peer for a given routing action. As discussed previously, the a peer for a given routing action. As discussed previously, the
following objects are potentially required: following objects are potentially required:
o Key objects are required. Symmetric keys may be preshared. o Key objects are required. Symmetric keys may be preshared and
Asymmetric public keys may be used directly for authorization as knowledge of the key used as the decision factor in authorization.
well. During key transitions more than one key may refer to a Knowledge of the private key corresponding to Asymmetric public
given peer. Group preshared keys may refer to multiple peers. keys may be used directly for authorization as well. During key
transitions more than one key may refer to a given peer. Group
preshared keys may refer to multiple peers.
o A peer is a router that this router might wish to communicate o A peer is a router that this router might wish to communicate
with. Peers may be identified by names or keys. with. Peers may be identified by names or keys.
o Groups of peers may be authorized for a given routing protocol. o Groups of peers may be authorized for a given routing protocol.
Establishing a management model is difficult because of the complex Establishing a management model is difficult because of the complex
relationships between each set of objects. As discussed there may be relationships between each set of objects. As discussed there may be
more than one key for a peer. However in the preshared key case, more than one key for a peer. However in the preshared key case,
there may be more than one peer for a key. This is true both for there may be more than one peer for a key. This is true both for
group security association protocols such as an IGP or one-to-one group security association protocols such as an IGP or one-to-one
protocols where the same key is used administratively. In some of protocols where the same key is used administratively. In some of
these situations, it may be undesirable to explicitly enumerate the these situations, it may be undesirable to explicitly enumerate the
peers in the configuration; for example IGP peers are auto-discovered peers in the configuration; for example IGP peers are auto-discovered
for broadcast links but not for non-broadcast multi-access links. for broadcast links but not for non-broadcast multi-access links.
Peers may be identified either by name or key. If peers are Peers may be identified either by name or key. If peers are
identified by key it is probably strongly desirable from an identified by key it is strongly desirable from an operational
operational standpoint to consider any peer identifiers or name to be standpoint to consider any peer identifiers or name to be a local
a local matter and not require the names or identifiers to be matter and not require the names or identifiers to be synchronized.
synchronized. Obviously if peers are identified by names (for Obviously if peers are identified by names (for example with
example with certificates in a PKI), identifiers need to be certificates in a PKI), identifiers need to be synchronized between
synchronized between the authorized peer and the peer making the the authorized peer and the peer making the authorization decision.
authorization decision.
In many cases peers will explicitly be identified. In these cases it In many cases peers will explicitly be identified in routing protocol
is possible to attach the authorization information (keys or configuration. In these cases it is possible to attach the
identifiers) to the peer's configuration object. Two cases do not authorization information (keys or identifiers) to the peer's
involve enumerating peers. The first is the case where preshared configuration object. Two cases do not involve enumerating peers.
keys are shared among a group of peers. It is likely that this case The first is the case where preshared keys are shared among a group
can be treated from a management standpoint as a single peer of peers. It is likely that this case can be treated from a
representing all the peers that share the keys. The other case is management standpoint as a single peer representing all the peers
one where certificates in a PKI are used to introduce peers to a that share the keys. The other case is one where certificates in a
router. In this case, rather than configuring peers, , the router PKI are used to introduce peers to a router. In this case, rather
needs to be configured with information on what certificates than configuring peers, , the router needs to be configured with
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.
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
One key operational question is what areas will administrator One key operational question is what areas will administrator
involvement be required. Likely areas where involvement may be involvement be required. Likely areas where involvement may be
useful includes enrollment of new peers. Fault recovery should also useful include enrollment of new peers. Fault recovery should also
be considered. be considered.
6.1. Enrollment 6.1. Enrollment
One area where the management of routing security needs to be One area where the management of routing security needs to be
optimized is the deployment of a new router. In some cases a new optimized is the deployment of a new router. In some cases a new
router may be deployed on an existing network where routing to router may be deployed on an existing network where routing to
management servers is already available. In other cases, routers may management servers is already available. In other cases, routers may
be deployed as part of connecting or creating a site. Here, the be deployed as part of connecting or creating a site. Here, the
router and infrastructure may not be available until the router has router and infrastructure may not be available until the router has
securely authenticated. This problem is similar to the problem of securely authenticated.
getting initial configuration of routing instances onto the router.
However, especially in cases where asymmetric keys or per-peer
preshared keys are used, the configuration of other routers needs to
be modified to bring up the security association. Also, there has
been discussion of generating keys on routers and not allowing them
to leave devices. This also impacts what strategies are possible.
For example this might mean that routers need to be booted in a
secure environment where keys can be generated, and public keys
copied to a management server to push out the new public key to
potential peers. Then, the router needs to be packaged, moved to
where it will be deployed and set up.Alternatives are possible; it is
critical that we understand how what we propose impacts operators.
We need to work through examples with operators familiar with
specific real-world deployment practices and understand how proposed
security mechanisms will interact with these practices.
Initial discussions suggest that this will be one more configuration In general, security configuration can be treated as an additional
item that needs to be set up to establish service. There is no configuration item that needs to be set up to establish service.
significant security value in protecting routing protocol keys more There is no significant security value in protecting routing protocol
than administrative password or Authentication, Authorization and keys more than administrative password or Authentication,
Accounting (AAA) secrets that can be used to gain login access to a Authorization and Accounting (AAA) secrets that can be used to gain
router. These existing secrets can be used to make configuration login access to a router. These existing secrets can be used to make
changes that impact routing protocols as much as disclosure of a KARP configuration changes that impact routing protocols as much as
key. Operators already have procedures in place for these items. disclosure of a routing protocol key. Operators already have
So, it is appropriate to use similar procedures for KARP. It is procedures in place for these items. So, it is appropriate to use
reasonable to improve these procedures and the KARP-related similar procedures for routing protocol keys. It is reasonable to
improve existing configuration procedures and the routing protocol
procedures over time. However it is more desirable to deploy KARP procedures over time. However it is more desirable to deploy KARP
with security similar to that used for managing existing secrets than with security similar to that used for managing existing secrets than
to delay deploying KARP. to delay deploying KARP.
Operators that have existing procedures for managing hardware Operators MAY develop higher assurance procedures for dealing with
encryption devices such as VPN gateways MAY use those procedures for keys. For example, asymmetric keys can be generated on a router and
managing KARP keys. This MAY be used for example if cost savings in never exported from the router. Operators can evaluate the cost vs
terms of training and auditing justify the re-use of a procedure. security and availability tradeoffs of these procedures.
6.2. Handling Faults 6.2. Handling Faults
Faults may interact with operational practice in at least two ways. Faults may interact with operational practice in at least two ways.
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 repairing other faults
that is connecting a new site as the security fault may have that can partition a network.
partitioned the network. However, unlike a new deployment, the event
is unplanned. Strategies such as configuring a router and shipping
it to a site may not be appropriate for recovering a fault even
though they may be more useful for new deployments.
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 a 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. However, the protocols MUST
still have adequate operational mechanisms to recover from these still have adequate operational mechanisms to recover from these
situations. Also, some faults, such as those resulting from a situations. Also, some faults, such as those resulting from a
compromise or actual attack on a facility are inherent and may not be compromise or actual attack on a facility are inherent and may not be
prevented. 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. One option is to maintain a copy of the router's keys near material so that when a router is replaced the same keys can be used.
the router. For example, keys cys could be maintained on a USB Router keys can be maintained on a central server. These approaches
storage driver. Another approach is to maintain router keys on a permit the credentials of a router to be recovered. This provides
central server. These approaches permit the credentials of a router valuable options in case of hardware fault. The failing router can
to be recovered. This provides valuable options in case of hardware be recovered without changing credentials on other routers or waiting
fault. The failing router can be recovered without changing for keys to be certified. One disadvantage of this approach is that
credentials on other routers. One disadvantage of this approach is even if public-key cryptography is used, the private keys are located
that even if public-key cryptography is used, the private keys still on more than just the router.; a system in which keys were generated
need to leave the router. Exporting private keys increases the on a router and never exported from that router would typically make
chance that an attacker may be able to impersonate a router. In many it more difficult for an attacker to obtain the keys. For most
environments favoring the ability to quickly replace a router makes environments the ability to quickly replace a router justifies
sense. maintaining keys centrally.
More generally keying is another item of configuration that needs to More generally keying is another item of configuration that needs to
be restored to restore service when equipment fails. Operators be restored to restore service when equipment fails. Operators
typically perform the minimal configuration necessary to get a router typically perform the minimal configuration necessary to get a router
back in contact with the management server. The same would apply for back in contact with the management server. The same would apply for
keys. Operators who do not maintain copies of key material for keys. Operators who do not maintain copies of key material for
performing key recovery on routers would need to perform a bit more performing key recovery on routers would need to perform a bit more
work to regain contact with the management server. It seems work to regain contact with the management server. It seems
reasonable to assume that management servers will be able to cause reasonable to assume that management servers will be able to cause
keys to be generated or distributed sufficiently to fully restore keys to be generated or distributed sufficiently to fully restore
skipping to change at page 18, line 38 skipping to change at page 18, line 38
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
number of peers. One particularly risky situation is upgrading the number of peers. One particularly risky situation is upgrading the
configuration of iBGP peers. configuration of iBGP peers.
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 typically not desirable 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 supporting the considered. One is to support key table rows supporting the
automated key management and manually configured keying for the same automated key management and manually configured keying for the same
link at the same time. Coordinating this may be tricky. Another link at the same time. Coordinating this may be challenging from an
possibility is for the automated key management protocol to actually operational standpoint. Another possibility is for the automated key
select the same traffic key that is being used manually. This could management protocol to actually select the same traffic key that is
potentilaly be accomplished by having an option in the key management being used manually. This could be accomplished by having an option
protocol to export the current manual group key through the automated in the key management protocol to export the current manual group key
key management protocol. Then after all nodes are configured with through the automated key management protocol. Then after all nodes
automated key management, manual key entries can be removed. The are configured with automated key management, manual key entries can
next re-key after all nodes have manual entries removed will generate be removed. The next re-key after all nodes have manual entries
a new fresh key. removed will generate a new fresh key. Group key management
protocols are RECOMMENDED to support an option to export existing
manual keys during initial deployment of automated key management.
8. 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.
9. 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.
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-03 (work in progress), draft-ietf-karp-crypto-key-table-06 (work in progress),
June 2012. February 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),
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-00 (work in progress), BGPsec", draft-ietf-sidr-rtr-keying-01 (work in progress),
May 2012. February 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),
November 2010. November 2010.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006. Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5",
RFC 4808, March 2007. RFC 4808, March 2007.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010. Authentication Option", RFC 5925, June 2010.
 End of changes. 32 change blocks. 
123 lines changed or deleted 122 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/