GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7211

Internet Engineering Task Force (IETF) S. Hartman Request for Comments: 7211 Painless Security Category: Informational D. Zhang ISSN: 2070-1721 Huawei Technologies Co. Ltd.

                                                             June 2014
                 Operations Model for Router Keying

Abstract

 The IETF is engaged in an effort to analyze the security of routing
 protocol authentication according to design guidelines discussed in
 RFC 6518, "Keying and Authentication for Routing Protocols (KARP)
 Design Guidelines".  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.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7211.

Hartman & Zhang Informational [Page 1] RFC 7211 Operations Model for Router Keying June 2014

Copyright Notice

 Copyright (c) 2014 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
 2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   3
 3.  Breakdown of KARP Configuration . . . . . . . . . . . . . . .   3
   3.1.  Integrity of the Key Table  . . . . . . . . . . . . . . .   5
   3.2.  Management of Key Table . . . . . . . . . . . . . . . . .   5
   3.3.  Interactions with Automated Key Management  . . . . . . .   6
   3.4.  Virtual Routing and Forwarding Instances (VRFs) . . . . .   6
 4.  Credentials and Authorization . . . . . . . . . . . . . . . .   6
   4.1.  Preshared Keys  . . . . . . . . . . . . . . . . . . . . .   8
     4.1.1.  Sharing Keys and Zones of Trust . . . . . . . . . . .   9
     4.1.2.  Key Separation and Protocol Design  . . . . . . . . .  10
   4.2.  Asymmetric Keys . . . . . . . . . . . . . . . . . . . . .  10
   4.3.  Public Key Infrastructure . . . . . . . . . . . . . . . .  11
   4.4.  The Role of Central Servers . . . . . . . . . . . . . . .  12
 5.  Grouping Peers Together . . . . . . . . . . . . . . . . . . .  12
 6.  Administrator Involvement . . . . . . . . . . . . . . . . . .  14
   6.1.  Enrollment  . . . . . . . . . . . . . . . . . . . . . . .  14
   6.2.  Handling Faults . . . . . . . . . . . . . . . . . . . . .  15
 7.  Upgrade Considerations  . . . . . . . . . . . . . . . . . . .  16
 8.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
 9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  17
 10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
   10.1.  Normative References . . . . . . . . . . . . . . . . . .  17
   10.2.  Informative References . . . . . . . . . . . . . . . . .  18

Hartman & Zhang Informational [Page 2] RFC 7211 Operations Model for Router Keying June 2014

1. Introduction

 The Keying and Authentication of Routing Protocols (KARP) working
 group is designing improvements to the cryptographic authentication
 of IETF routing protocols.  These improvements include enhancing how
 integrity functions are handled within each protocol as well as
 designing an automated key management solution.
 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 when
 thought is 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.
 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 [RFC7210].
 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 Section 4.4.  In addition, routers' roles affect how new routers
 are installed and how problems are handled; see Section 6.

2. Requirements Notation

 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 [RFC2119].

3. Breakdown of KARP Configuration

 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 [RFC7210] describes configuration needed for manual
 keying.  Configuration of automated key management is a work in
 progress.

Hartman & Zhang Informational [Page 3] RFC 7211 Operations Model for Router Keying June 2014

 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 that the same group key 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.
 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 [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 it 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.
 As described in [RFC7210], 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.
 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

Hartman & Zhang Informational [Page 4] RFC 7211 Operations Model for Router Keying June 2014

 entries.  As such, these implementation requirements are best
 addressed by care being taken in how routing protocols specify the
 use of the key tables.

3.1. Integrity of the Key Table

 The routing key table [RFC7210] 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:
 o  The cryptographic algorithms are valid for the protocol.
 o  The key derivation function is valid for the protocol.
 o  The direction is valid for the protocol.  For example, if a
    protocol requires the same session key be used in both directions,
    the direction field in the key table entry associated with the
    session key MUST be specified as "both".
 o  The peer specification is consistent with the protocol.
 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.

3.2. Management of Key Table

 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 for easy management
 of the router.

Hartman & Zhang Informational [Page 5] RFC 7211 Operations Model for Router Keying June 2014

 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 and then later for 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.
 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 unexpired key is available for them.  See
 Section 6.2 for a discussion of reporting and managing security
 faults including those related to key expiration.

3.3. Interactions with Automated Key Management

 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.
 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.

3.4. Virtual Routing and Forwarding Instances (VRFs)

 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.

4. Credentials and Authorization

 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.

Hartman & Zhang Informational [Page 6] RFC 7211 Operations Model for Router Keying June 2014

 As discussed in [RTG-AUTH], 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) [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.
 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.
 Public keys can be used for authentication within an automated key
 management protocol.  The KARP design guide [RFC6518] 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 in that set need to be updated.
 Note that self-signed certificates are a common way of communicating
 public keys in this style of authentication.
 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 are required.
 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.

Hartman & Zhang Informational [Page 7] RFC 7211 Operations Model for Router Keying June 2014

4.1. Preshared Keys

 In the protocol, manual preshared keys are either unnamed or named by
 a key ID (which is a small integer -- typically 16 or 32 bits).
 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 [RFC4808].  Typically key IDs are names used by
 one group or peer.
 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.
 Preshared keys used with key derivation work 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.
 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

Hartman & Zhang Informational [Page 8] RFC 7211 Operations Model for Router Keying June 2014

 be a compelling reason to decouple the authorization of a key for
 some purpose from the authorization of peers 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
 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 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.
 Key derivation can be part of a management solution for having
 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.

Hartman & Zhang Informational [Page 9] RFC 7211 Operations Model for Router Keying June 2014

4.1.2. Key Separation and Protocol Design

 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.
 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.

4.2. Asymmetric Keys

 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 of
 [RFC4572]).  KARP SHOULD adopt this approach or another approach
 already standardized within the IETF rather than inventing a new
 mechanism for naming public keys.
 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

Hartman & Zhang Informational [Page 10] RFC 7211 Operations Model for Router Keying June 2014

 thought of as associated with multiple public keys rather than as
 containing a single public-key hash as an attribute of the peer
 object.
 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.

4.3. Public Key Infrastructure

 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.
 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.
 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.
 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
 "infrastructure-less" 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.
 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 the validation of address
 ownership.  Adapting these practices to routing protocol
 authentication is outside the scope of this document.

Hartman & Zhang Informational [Page 11] RFC 7211 Operations Model for Router Keying June 2014

4.4. The Role of Central Servers

 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.
 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.
 Another area where central servers may play a role is for group key
 agreement.  As an example, [OSPF-AUTO] 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 [RFC4086] is likely to differ between systems.  As
 a result, operators may have preferences for where keys are
 generated.

5. Grouping Peers Together

 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:
 o  Key objects are required.  Symmetric keys may be preshared, and
    knowledge of the key may be 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.
 o  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.
 o  Objects representing peer groups are required.  Groups of peers
    may be authorized for a given routing protocol.

Hartman & Zhang Informational [Page 12] RFC 7211 Operations Model for Router Keying June 2014

 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.
 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 names to be a local
 matter and not require the identifiers or names 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.
 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.
 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 - Traffic Engineering (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.
 Finally, as discussed in Section 7, it is sometimes desirable to
 override some aspect of the configuration for a peer in a group.  As
 an example, when rotating to a new key, it is desirable to be able to
 roll that key out to each peer that will use the key, even if in the
 stable state the key is configured for a peer group.
 In order to develop a management model for authorization, the working
 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

Hartman & Zhang Informational [Page 13] RFC 7211 Operations Model for Router Keying June 2014

 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?

6. Administrator Involvement

 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.

6.1. Enrollment

 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.
 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.
 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 the availability tradeoffs of these procedures.

Hartman & Zhang Informational [Page 14] RFC 7211 Operations Model for Router Keying June 2014

6.2. Handling Faults

 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.
 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, Simple Network Management
 Protocol (SNMP) traps, or notifications within a routing protocol.
 One strategy is to have increasing escalations of notifications.
 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.
 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.
 One approach, recommended by work on securing BGP [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.
 More generally, keying is another item of configuration that needs to
 be restored to reestablish service when equipment fails.  Operators
 typically perform the minimal configuration necessary to get a router

Hartman & Zhang Informational [Page 15] RFC 7211 Operations Model for Router Keying June 2014

 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.

7. Upgrade Considerations

 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.
 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.
 The situation is more complex for organizations that have not
 upgraded from TCP MD5 [RFC2385] to the TCP Authentication Option
 [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 (including security configuration) of related peers
 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 Internal BGP (iBGP) peers.
 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 that enable the

Hartman & Zhang Informational [Page 16] RFC 7211 Operations Model for Router Keying June 2014

 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.

8. Security Considerations

 This document does not define a protocol.  It does discuss the
 operational and management implications of several security
 technologies.
 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 [RFC7210].  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; otherwise, 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.

9. Acknowledgments

 Funding for Sam Hartman's work on this memo is provided by Huawei.
 The authors would like to thank Bill Atwood, Randy Bush, Wes George,
 Gregory Lebovitz, and Russ White for valuable reviews.

10. References

10.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC7210]  Housley, R., Polk, T., Hartman, S., and D. Zhang,
            "Database of Long-Lived Symmetric Cryptographic Keys", RFC
            7210, April 2014.

Hartman & Zhang Informational [Page 17] RFC 7211 Operations Model for Router Keying June 2014

10.2. Informative References

 [KEYING]   Turner, S., Patel, K., and R. Bush, "Router Keying for
            BGPsec", Work in Progress, May 2014.
 [OSPF-AUTO]
            Liu, Y., "OSPFv3 Automated Group Keying Requirements",
            Work in Progress, July 2007.
 [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
 [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
            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
            Transport Layer Security (TLS) Protocol in the Session
            Description Protocol (SDP)", RFC 4572, July 2006.
 [RFC4808]  Bellovin, S., "Key Change Strategies for TCP-MD5", RFC
            4808, March 2007.
 [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
            Authentication Option", RFC 5925, June 2010.
 [RFC6518]  Lebovitz, G. and M. Bhatia, "Keying and Authentication for
            Routing Protocols (KARP) Design Guidelines", RFC 6518,
            February 2012.
 [RTG-AUTH] Polk, T. and R. Housley, "Routing Authentication Using A
            Database of Long-Lived Cryptographic Keys", Work in
            Progress, November 2010.

Authors' Addresses

 Sam Hartman
 Painless Security
 EMail: hartmans-ietf@mit.edu
 Dacheng Zhang
 Huawei Technologies Co. Ltd.
 EMail: zhangdacheng@huawei.com

Hartman & Zhang Informational [Page 18]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7211.txt · Last modified: 2014/06/17 23:09 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki