One document matched: draft-ietf-karp-ops-model-10.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY design-guide PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-karp-design-guide.xml'>
<!ENTITY ospf-auto PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.liu-ospfv3-automated-keying-req.xml'>
<!ENTITY keytable PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-karp-crypto-key-table.xml'>
<!ENTITY polk PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.polk-saag-rtg-auth-keytable.xml'>
<!ENTITY RFC4552 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4552.xml'>
<!ENTITY rfc4808 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4808.xml'>
<!ENTITY rfc4572 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4572.xml'>
<!ENTITY RFC2328 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328.xml'>
<!ENTITY RFC2154 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2154.xml'>
<!ENTITY RFC5709 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5709.xml'>
<!ENTITY RFC5925 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5925.xml'>
]>
<rfc category="info" ipr="trust200902" docName="draft-ietf-karp-ops-model-10.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>Operations Model for Router Keying</title>
<author initials="S." surname="Hartman" fullname="Sam Hartman">
<organization>Painless Security</organization>
<address>
<email>hartmans-ietf@mit.edu</email>
</address>
</author>
<author initials="D." surname="Zhang" fullname="Dacheng Zhang">
<organization>Huawei</organization>
<address>
<email>zhangdacheng@huawei.com</email>
</address>
</author>
<date/>
<abstract>
<t>The IETF is engaged in an effort to analyze security of routing protocol authentication according to design guidelines discussed in RFC 6518. Developing an operational and management model for routing protocol security that works with all the routing protocols will be critical to the deployability of these efforts. This document gives recommendations to operators and implementors regarding management and operation of router authentication. These recommendations will also assist protocol designers in understanding management issues they will face.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Keying and Authentication of Routing Protocols (KARP) working group is designing improvements to the cryptographic authentication of IETF routing protocols. These improvements include improvements to how integrity functions are handled within each protocol as well as designing an automated key management solution.</t>
<t>This document discusses issues to consider when thinking
about the operational and management model for KARP. Each
implementation will take its own approach to management; this is
one area for vendor differentiation. However, it is desirable to
have a common baseline for the management objects allowing
administrators, security architects and protocol designers to
understand what management capabilities they can depend on in
heterogeneous environments. Similarly, designing and deploying
the protocol will be easier with thought paid to a common
operational model. This will also help with the design of
NetConf schemas or MIBs later. This document provides recommendations to help establish such a baseline.</t>
<t>This document also gives recommendations for how management and operational issues can be approached as protocols are revised and as support is added for the key table <xref target="I-D.ietf-karp-crypto-key-table"/>.</t>
<t>Routing security faces interesting challenges not present with some other security domains. routers need to function in order to establish network connectivity. As a result, centralized services cannot typically be used for authentication or other security tasks; see <xref target="central"></xref>. In addition, routers' roles affect how new routers are installed and how problems are handleded; see <xref target="admin"></xref>.</t>
</section>
<section title="Requirements notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>.</t>
</section>
<section title="Breakdown of KARP configuration">
<t>Routing authentication configuration includes configuration of key material used to authenticate routers as well as parameters needed to use these keys. Configuration also includes information necessary to use an automated key management protocol to configure router keying. The key table <xref target="I-D.ietf-karp-crypto-key-table"></xref> describes configuration needed for manual keying. Configuration of automated key management is a work in progress.</t>
<t>There are multiple ways of structuring configuration
information. One factor to consider is the scope of the
configuration information. Several protocols are peer-to-peer routing protocols where
a different key could potentially be used for each
neighbor. Other protocols require the same group key to be used
for all nodes in an administrative domain or routing area. In
other cases, the same group key needs to be used for all routers
on an interface, but different group keys can be used for each
interface.</t>
<t> Within situations where a per-interface,
per-area or per-peer key can be used for manually configured
long-term keys, that flexibility may not
be desirable from an operational standpoint. For example
consider OSPF <xref target="RFC2328"/>. Each router on an OSPF link needs to use the same
authentication configuration, including the set of keys used for
reception and the set of keys used for transmission, but may use
different keys for different links. The most general management
model would be to configure keys per link. However for
deployments 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 configured per-link, they can get out of
sync. In order to support generality of configuration and common
operational situations, it would be desirable to have some sort of inheritance
where default configurations are made per-area unless overridden
per-interface.</t>
<t>As described in <xref
target="I-D.ietf-karp-crypto-key-table"/>, the cryptographic
keys are separated from the interface configuration into their
own configuration store. Each routing protocol is responsible for defining the form of the Peer specification used by that protocol. Thus each routing protocol needs to define the scope of keys. For group keying, the Peer specification names the group. A protocol could define a Peer specification indicating the key had a link scope and also a Peer specification for scoping a key to a specific area. For link-scoped keys it is generally best to define a single Peer specification indicating the key has a link scope and to use interface restrictions to restrict the key to the appropriate link.</t>
<t>Operational
Requirements: implementations of this model MUST support configuration of keys at the
most general scope for the underlying protocol; protocols
supporting per-peer keys MUST permit configuration of per-peer
keys, protocols supporting per-interface keys MUST support
configuration of per-interface keys, and so on for any additional scopes. Implementations MUST NOT
permit configuration of an inappropriate key scope. For example,
configuration of separate keys per interface would be inappropriate
to support for a protocol requiring per-area keys. This restriction can be enforced by rules specified by each routing protocol for validating key table entries. As such these implementation requirements are best addressed by care being taken in how routing protocols specify the use of the key tables.</t>
<section title="Integrity of the Key Table">
<t>The routing key table <xref
target="I-D.ietf-karp-crypto-key-table"/> provides a very
general mechanism to abstract the storage of keys for routing
protocols. To avoid misconfiguration and simplify problem
determination, the router MUST verify the internal consistency
of 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:
<list style="symbols">
<t>The cryptographic algorithms are valid for the
protocol.</t>
<t>The key derivation function is valid for the protocol.</t>
<t>The direction is valid for the protocol; for example
protocols that require the same session key be used in
both directions REQUIRE have a direction of both be specified in the key table entry.</t>
<t>The peer specification is consistent with
the protocol.</t>
</list>
</t>
<t>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 for the specified protocol. However, this may
be undesirable. It 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 key table across devices even
when their current configuration does not require an adjacency
with a particular peer in the interest of uniform
configuration or preparing for fail-over. For these reasons, these additional checks are generally undesirable.</t>
</section>
<section title="Management of Key Table">
<t>Several management interfaces will be quite common. For
service provider deployments the configuration management
system can simply update the key table. However, for smaller
deployments, efficient management interfaces that do not require a configuration management system are
important. In these environments configuration interfaces (such as web interfaces and command-line interfaces) provided directly by the router will be important to easy management of the router.</t>
<t>As part of adding a new key it is typically desirable to
set an expiration time for an old key. The management
interface SHOULD provide a mechanism to easily update the
expiration time for 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, allowing use for receiving
packets then later enabling transmit. This can be accomplished
automatically by providing a delay between when a key becomes
valid for reception and transmission. However, 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 key for sending is desirable. The management interface SHOULD provide an easy mechanism to update the direction of an existing key or to enable a disabled key.</t>
<t>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 <xref target="FAULT"/> for a discussion of reporting and managing security faults including those related to key expiration.</t>
</section>
<section title="Interactions with Automated Key Management">
<t>Consideration is required for how an automated key
management protocol will assign key IDs for group keys. All
members of the group may need to use the same key ID. This
requires careful coordination of global key IDs. Interactions
with the peer key ID field may make this easier; this requires
additional study.</t>
<t>Automated key management protocols also assign keys for single peers. If the key ID is global and needs to be coordinated between the receiver and transmitter, then there is complexity in key management protocols that can be avoided if key IDs are not global.</t>
</section>
<section title="Virtual Routing and Forwarding Instances (VRFs)">
<t>Many core and enterprise routers support multiple routing
instances. For example a router serving multiple VPNs is
likely to have a forwarding/routing instance for each of these
VPNs. Each VRF will require its own routing key table.</t>
</section>
</section>
<section title="Credentials and Authorization">
<t>Several methods for authentication have been proposed for
KARP. The simplest is preshared keys used directly as traffic
keys. In this mode, the traffic integrity keys are directly
configured. This is the mode supported by most of today's routing
protocols.</t>
<t>As discussed in <xref
target="I-D.polk-saag-rtg-auth-keytable"/>, preshared keys can be used as the input to a key derivation
function (KDF) to generate traffic keys. For example the TCP
Authentication Option (TCP-AO) <xref target="RFC5925"/> derives
keys based on the initial TCP session state. 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 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
will be private and exchanged as part of the protocol, although
this will be uncommon in KARP's uses of KDFs. </t>
<t>Preshared keys could also be used by an automated key
management protocol. In this mode, preshared keys would be used
for authentication. However traffic keys would be
generated by some key agreement mechanism or transported in a key encryption key derived from the preshared key. This mode may provide better replay protection. Also,
in the absence of active attackers, key agreement strategies
such as Diffie-Hellman can be used to produce high-quality
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.</t>
<t>Public keys can be used for authentication within an automated key management protocol. The design guide
<xref target="I-D.ietf-karp-design-guide"/> describes a mode in which routers
have the hashes of peer routers' public keys. In this mode, a
traditional public-key infrastructure is not required. The
advantage of this mode is that a router only contains its own
keying material, limiting the scope of a compromise. The
disadvantage is that when a router is added or deleted from the
set of authorized routers, all routers that peer need to be
updated. Note that self-signed certificates are a common way of
communicating public-keys in this style of authentication.</t>
<t>Certificates signed by a certification authority or some
other PKI could be used for authentication within an automated key management 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.</t>
<t>Each of these approaches has a different set of management
and operational requirements. Key differences include how
authorization is handled and how identity works. This section
discusses these differences.</t>
<section anchor="PRESHARED" title="Preshared Keys">
<t>In the protocol, manual preshared keys are either unnamed
or named by a small integer (typically 16 or 32 bits) key
ID. Implementations that support multiple keys for protocols
that have no names for keys need to try all possible keys
before deciding a packet cannot be validated <xref
target="RFC4808"/>. Typically key IDs are names used by one group or peer.</t>
<t>Manual preshared keys are often known by a group of peers
rather than just one other peer. This is an interesting
security property:
unlike with digitally signed messages or protocols where
symmetric keys are known only to two parties, it is impossible to identify the peer sending a message
cryptographically. However, it is possible to show that the
sender of a message is one of the parties who knows the
preshared key. Within the routing threat
model the peer sending a message can be identified only
because peers are trusted and thus can be assumed to correctly
label the packets they send. This contrasts with a protocol
where cryptographic means such as digital signatures are used
to verify the origin of a message. As a consequence,
authorization is typically based on knowing the preshared key
rather than on being a particular peer. Note that once an
authorization decision is made, the peer can assert its
identity; this identity is trusted just as the routing
information from the peer is trusted. Doing an additional
check for authorization based on the identity included in the
packet would provide little value: an attacker who somehow had
the key could claim the identity of an authorized peer and an
attacker without the key should be unable to claim the
identity of any peer. Such a check is not required by the KARP
threat model: inside attacks are not in scope.</t>
<t>Preshared keys used with key derivation function similarly
to manual preshared keys. However to form the actual traffic
keys, session or peer specific information is combined with
the key. From an authorization standpoint, the derivation key
works the same as a manual key. An additional routing protocol
step or transport step forms the key that is actually used.</t>
<t>Preshared keys that are used via automatic key management
have not yet been specified for KARP although ongoing work suggests they will be needed. Their naming
and authorization may differ from existing uses of preshared
keys in routing protocols. In particular, such keys may end
up being known only by two peers. Alternatively they may also
be known by a group of peers. Authorization could potentially
be based on peer identity, although it is likely that knowing
the right key will be sufficient. There does not appear to be
a compelling reason to decouple the authorization of a key for
some purpose from authorization of peers holding that key to
perform the authorized function.</t>
<section title="Sharing Keys and Zones of Trust">
<t>Care needs to be taken when symmetric keys are used for
multiple purposes. Consider the implications of using the same
preshared key for two interfaces: it becomes impossible to
cryptographically distinguish a router on one interface from a router on another
interface. So, a router that is trusted to participate in a
routing protocol on one interface becomes implicitly trusted
for the other interfaces that share the key. For many cases,
such as link-state routers in the same routing area, there is
no significant advantage that an attacker could gain from this
trust within the KARP threat model. However, other protocols such as BGP and RIP, permit routes to be filtered
across a trust boundary. For these protocols, participation in
one interface might be more advantageous than
another. Operationally, when this trust distinction is
important to a deployment, different keys need to be used on
each side of the trust boundary. Key derivation can help
prevent this problem in cases of accidental
misconfiguration. However, key derivation cannot protect
against a situation where a system was incorrectly trusted to
have the key used to perform the derivation. This question of trust is important to the KARP threat model because it is essential to determining whether a party is an insider for a particular routing protocol. A customer router that is an an insider 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.</t>
<t>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 be combined with peer, link or area
identifiers to form a router-specific preshared key that is
loaded onto routers. Provided that the master key lives only
on the management server and not the individual routers, trust
is preserved. However in many cases, generating independent
keys for the routers and storing the result is more
practical. If the master key were somehow compromised, all the
resulting keys would need to be changed. However if
independent keys are used, the scope of a compromise may be
more limited.</t>
</section>
<section title="Key Separation and Protocol Design">
<t>More subtle problems with key separation can appear in protocol design. Two protocols that use the same traffic keys may work together in unintended ways permitting one protocol to be used to attack the other. Consider two hypothetical protocols. Protocol A 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 messages but ends messages with extension information. It may be 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 router to generate this message with one protocol under situations where the other protocol would not generate the message. This hypothetical example is overly simplistic; real-world attacks exploiting key separation weaknesses tend to be complicated and involve specific properties of the cryptographic functions involved. The key point is that whenever the same key is used in multiple protocols, attacks may be possible. All the involved protocols need to be analyzed to understand the scope of potential attacks. </t>
<t>Key separation attacks interact with the KARP operational model in a number of ways. Administrators need to be aware of situations where using the same manual traffic key with two different protocols (or the same protocol in different contexts) creates attack opportunities. Design teams should consider how their protocol might interact with other routing protocols and describe any attacks discovered so that administrators can understand the operational implications. When designing automated key management or new cryptographic authentication within routing protocols, we need to be aware that administrators expect to be able to use the same preshared keys in multiple contexts. As a result, we should use appropriate key derivation functions so that different cryptographic keys are used even when the same initial input key is used.</t>
</section></section>
<section title="Asymmetric Keys">
<t>Outside of a PKI, public keys are expected to be known by
the hash of a key or (potentially self-signed)
certificate. The Session Description Protocol provides a
standardized mechanism for naming keys (in that case
certificates) based on hashes (section 5 <xref
target="RFC4572"/>). KARP SHOULD adopt this approach
or another approach already standardized within the IETF
rather than inventing a new mechanism for naming public
keys.</t>
<t>A public key is typically expected to belong to one
peer. As a peer generates new keys and retires old keys, its
public key may change. For this reason, from a management
standpoint, peers should be thought of as associated with
multiple public keys rather than as containing a single public
key hash as an attribute of the peer object.</t>
<t>Authorization of public keys could be done either by key
hash or by peer identity. Performing authorizations by peer
identity should make it easier to update the key of a peer
without risk of losing authorizations for that peer. However
management interfaces need to be carefully designed to avoid
making this extra level of indirection complicated for
operators.</t>
</section>
<section title="Public Key Infrastructure">
<t>When a PKI is used, certificates are used. The certificate
binds a key to a name of a peer. The key management protocol
is responsible for exchanging certificates and validating them
to a trust anchor. </t>
<t>Authorization needs to be done in terms of peer identities
not in terms of keys. One reason for this is that when a peer
changes its key, the new certificate needs to be sufficient
for authentication to continue functioning even though the key
has never been seen before. </t>
<t>Potentially authorization could be performed in terms of
groups of peers rather than single peers. An advantage of this
is that it may be possible to add a new router with no
authentication related configuration of the peers of that
router. For example, a domain could decide that any router
with a particular keyPurposeID signed by the organization's
certificate authority is permitted to join the IGP. Just as in
configurations where cryptographic authentication is not used,
automatic discovery of this router can establish appropriate
adjacencies.</t>
<t>Assuming that self-signed certificates are used
by routers that wish to use public keys but that do not need a
PKI, then PKI and the infrastructureless mode of public-key
operation described in the previous section can work well
together. One router could identify its peers based on names
and use certificate validation. Another router could use
hashes of certificates. This could be very useful for border
routers between two organizations. Smaller organizations could
use public keys and larger organizations could use PKI.</t>
<t>A PKI has significant operational concerns including certification practices, handling revocation and operational practices around certificate validation. The Routing PKI (RPKI) has addressed these concerns within the scope of BGP and validation of address ownership. Adapting these practices to routing protocol authentication is outside the scope of this document.</t>
</section>
<section anchor="central" title="The role of Central Servers">
<t>An area to explore is the role of central servers like
RADIUS or directories. Routers need to securely operate in order to provide network routing services. Routers cannot generally contact a central server while establishing routing because the router might not have a functioning route to the central service until after routing is established. As a result, a system where keys are pushed by a central management system is an undesirable result for router keying. However central servers
may play a role in authorization and key rollover. For example
a node could send a hash of a public key to a RADIUS
server. </t>
<t>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 of a network. They are more likely to play a
role in enrollment of new peers or key migration/compromise.</t>
<t>Another area where central servers may play a role is for group key agreement. As an example, <xref target="I-D.liu-ospfv3-automated-keying-req"/> discusses the potential need for key agreement servers in OSPF. Other routing protocols that use multicast or broadcast such as IS-IS 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 <xref target="RFC4086"/> is likely to differ between systems. As a result, operators may have preferences for where keys are generated.</t>
</section>
</section>
<section title="Grouping Peers Together">
<t>One significant management consideration will be the grouping
of management objects necessary to determine who is authorized
to act as a peer for a given routing action. As discussed
previously, the following objects are potentially required:<list
style="symbols">
<t>Key objects are required. Symmetric keys may be
preshared and knowledge of the key used as the decision factor in authorization. Knowledge of the private key corresponding to Asymmetric public 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.</t>
<t>Peer objects are required. A peer is a router that this router might wish to
communicate with. Peers may be identified by names or keys.</t>
<t>Objects representing peer groups are required. Groups of peers may be authorized for a given routing protocol.</t>
</list>
</t>
<t>Establishing a management model is difficult because of the
complex relationships between each set of objects. As discussed
there may be 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 group security association protocols
such as an IGP or one-to-one protocols where the same key is
used administratively. In some of these situations, it may be
undesirable to explicitly enumerate the peers in the
configuration; for example IGP peers are auto-discovered for
broadcast links but not for non-broadcast multi-access
links.</t>
<t>Peers may be identified either by name or key. If peers are
identified by key it is strongly desirable from an
operational standpoint to consider any peer identifiers or name
to be a local matter and not require the names or identifiers to
be synchronized. Obviously if peers are identified by names (for
example with certificates in a PKI), identifiers need to be
synchronized between the authorized peer and the peer making the
authorization decision. </t>
<t>In many cases peers will explicitly be identified in routing protocol configuration. In these
cases it is possible to attach the authorization information
(keys or identifiers) to the peer's configuration object. Two
cases do not involve enumerating peers. The first is the case
where preshared keys are shared among a group of peers. It is
likely that this case can be treated from a management
standpoint as a single peer representing all the peers that
share the keys. The other case is one where certificates in a
PKI are used to introduce peers to a router. In this case,
rather than configuring peers, , the router needs to be
configured with information on which certificates represent
acceptable peers.</t>
<t>Another consideration is which routing protocols share
peers. For 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 IGP. In some of these cases it
would be desirable to use the same authorization information for
both routing protocols.</t>
<t>Finally, as discussed in <xref target="UPGRADE"/>, 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.</t>
<t>In order to develop a management model for authorization, the
working group needs to consider several questions. What
protocols support auto-discovery of peers? What protocols
require more configuration of a peer than simply the peer's
authorization information and network address? What management
operations are going to be common as security information for
peers is configured and updated? What operations will be common
while performing key transitions or while migrating to new
security technologies?</t>
</section>
<section anchor="admin" title="Administrator Involvement">
<t>One key operational question is what areas will administrator
involvement be required. Likely areas where involvement may be
useful include enrollment of new peers. Fault recovery should
also be considered.</t>
<section title="Enrollment">
<t>One area where the management of routing security needs to
be optimized is the deployment of a new router. In some cases
a new router may be deployed on an existing network where
routing to management servers is already available. In other
cases, routers may be deployed as part of connecting or
creating a site. Here, the router and infrastructure may not
be available until the router has securely authenticated. </t>
<t>In general, security configuration can be treated as an additional
configuration item that needs to be set up to establish
service. There is no significant security value in protecting
routing protocol keys more than administrative password or
Authentication, Authorization and Accounting (AAA) secrets
that can be used to gain login access to a router. These
existing secrets can be used to make configuration changes
that impact routing protocols as much as disclosure of a routing protocol
key. Operators
already have procedures in place for these items. So, it is
appropriate to use 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 with security similar to that used for managing existing
secrets than to delay deploying KARP.</t>
<t>Operators MAY develop higher assurance procedures for dealing with keys. For example, asymmetric keys can be generated on a router and never exported from the router. Operators can evaluate the cost vs security and availability tradeoffs of these procedures.</t>
</section>
<section anchor="FAULT" title="Handling Faults">
<t>Faults may interact with operational practice in at least
two ways. First, security solutions may introduce faults. For
example if certificates expire in a PKI, previous adjacencies
may no longer form. Operational practice will require a way of
repairing these errors. This may end up being very similar to
repairing other faults that can partition a network.</t>
<t>Notifications will play a critical role in avoiding security faults. Implementations SHOULD use appropriate mechanisms to notify operators as security resources are about to expire. Notifications can include messages to consoles, logged events, SNMP traps, or notifications within a routing protocol. One strategy is to have increasing escalations of notifications.</t>
<t>Monitoring will also play an important role in avoiding security
faults such as certificate expiration. Some classes of security fault, including issues with certificates, will affect only key management protocols. other security faults can affect routing protocols directly. 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.</t>
<t>A second class of faults is equipment faults that impact
security. For example if keys are stored on a router and never
exported from that device, failure of a router implies a need to
update security provisioning on the replacement router and its
peers.</t>
<t>One approach, recommended by work on securing BGP <xref
target="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. Router keys can be maintained on a
central server. These approaches permit the credentials of a
router to be recovered. This provides valuable options in case
of hardware fault. The failing router can be recovered without
changing credentials on other routers or waiting for keys to
be certified. One disadvantage of
this approach is that even if public-key cryptography is used,
the private keys are located on more than just the router. a
system in which keys were generated on a router and never
exported from that router would typically make it more
difficult for an attacker to obtain the keys. For most environments the ability to
quickly replace a router justifies maintaining keys
centrally. </t>
<t>More generally keying is another item of configuration that needs to be restored to restore service when equipment fails. Operators typically perform the minimal configuration necessary to get a router back in contact with the management server. The same would apply for keys. Operators who do not maintain copies of key material for performing key recovery on routers would need to perform a bit more work to regain contact with the management server. It seems reasonable to assume that management servers will be able to cause keys to be generated or distributed sufficiently to fully restore service.</t>
</section>
</section>
<section anchor="UPGRADE" title="Upgrade Considerations">
<t>It needs to be possible to deploy automated key management in
an organization without either having to disable existing
security or disrupting routing. As a result, it needs to be
possible to perform 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 cost of an update combined with the potential cost of routing disruptions during the update. Even when a routing protocol has technical mechanisms that permit an update with no disruption in service, there is still a potential cost of service disruptions as operational procedures and practices need to correctly use the technical mechanisms.</t>
<t>For peer-to-peer protocols such as BGP, upgrading to automated key management can be
relatively easy. First, code that supports automated key
management needs to be loaded on both peers. Then the adjacency
can be upgraded. The configuration can be updated to switch to
automated key management 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.</t>
<t>The situation is more complex for organizations that have not
upgraded from TCP MD5 <xref target="RFC2385" /> to the TCP
Authentication Option <xref target="RFC5925" />. Today, routers
typically need to understand whether a given peer supports TCP
MD5 or TCP-AO before opening a TCP connection. In addition, many
implementations support grouping configuration of related peers
including security configuration together. Implementations make
it challenging to move from TCP-MD5 to TCP-AO before all peers
in the group are ready. Operators perceive it as high risk to
update the configuration of a large number of peers. One
particularly risky situation is upgrading the configuration of
iBGP peers.</t>
<t>The situation is more complicated for multicast
protocols. It's typically not desirable to bring down an entire
link to reconfigure it as using automated key management. Two
approaches should be considered. One is to support key table
rows supporting the automated key management and manually configured
keying for the same link at the same time. Coordinating this may be
challenging from an operational standpoint. Another possibility is for the automated key management
protocol to actually select the same traffic key that is being
used manually. This could be accomplished by having an option in
the key management protocol to export the current manual group
key through the automated key management protocol. Then after
all nodes are configured with automated key management, manual
key entries can be removed. The next re-key after all nodes have
manual entries 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.</t>
</section>
<section title="Security Considerations">
<t>This document does not define a protocol. It does discuss the operational and management implications of several security technologies.</t>
<t>Close synchronization of time can impact the security of routing protocols in a number of ways. Time is used to control when keys MAY begin being used and when they MUST NOT be used any longer as described in <xref target="I-D.ietf-karp-crypto-key-table" />. Routers need to
have tight enough time synchronization that receivers permit a key
to be utilized for validation prior to the first use of that key for generation of integrity-protected messages or
availability will be impacted.
If time synchronization is too loose, then a key can be used beyond its intended lifetime. The Network Time Protocol (NTP) can be used to provide time synchronization. For some protocols, time synchronization is also important for replay detection.</t>
</section>
<section title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
<section title="Acknowledgments">
<t>Funding for Sam Hartman's work on this memo is provided by Huawei.</t>
<t>The authors would like to thank Bill
Atwood , Randy Bush, Wes George, Gregory Lebovitz, and Russ White
for valuable reviews.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&keytable;
</references>
<references title="Informative References">
&ospf-auto;
&design-guide;
&RFC2328;
&rfc4808;
&rfc4572;
&polk;
&RFC5925;
<?rfc include='http://xml.resource.org/public/rfc/bibxml3//reference.I-D.ietf-sidr-rtr-keying'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml//reference.RFC.2385'?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml//reference.RFC.4086'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 03:17:55 |