idnits 2.17.1 draft-ietf-karp-ops-model-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2013) is 4076 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-karp-crypto-key-table-06 == Outdated reference: A later version (-16) exists of draft-ietf-sidr-rtr-keying-01 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hartman 3 Internet-Draft Painless Security 4 Intended status: Informational D. Zhang 5 Expires: August 29, 2013 Huawei 6 February 25, 2013 8 Operations Model for Router Keying 9 draft-ietf-karp-ops-model-05.txt 11 Abstract 13 Developing an operational and management model for routing protocol 14 security that works across protocols will be critical to the success 15 of routing protocol security efforts. This document discusses issues 16 and begins to consider development of these models. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 29, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 54 3. Breakdown of KARP configuration . . . . . . . . . . . . . . . 5 55 3.1. Integrity of the Key Table . . . . . . . . . . . . . . . . 6 56 3.2. Management of Key Table . . . . . . . . . . . . . . . . . 6 57 3.3. Interactions with Automated Key Management . . . . . . . . 7 58 3.4. Virtual Routing and Forwarding Instances (VRFs) . . . . . 7 59 4. Credentials and Authorization . . . . . . . . . . . . . . . . 8 60 4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . . 9 61 4.1.1. Sharing Keys and Zones of Trust . . . . . . . . . . . 10 62 4.1.2. Key Separation and Protocol Design . . . . . . . . . . 10 63 4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 11 64 4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 12 65 4.4. The role of Central Servers . . . . . . . . . . . . . . . 12 66 5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 14 67 6. Administrator Involvement . . . . . . . . . . . . . . . . . . 16 68 6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 16 69 6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 16 70 7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . . 18 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 72 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 74 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 75 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 78 1. Introduction 80 The KARP working group is designing improvements to the cryptographic 81 authentication of IETF routing protocols. These improvements include 82 improvements to how integrity functions are handled within each 83 protocol as well as designing an automated key management solution. 85 This document discusses issues to consider when thinking about the 86 operational and management model for KARP. Each implementation will 87 take its own approach to management; this is one area for vendor 88 differentiation. However, it is desirable to have a common baseline 89 for the management objects allowing administrators, security 90 architects and protocol designers to understand what management 91 capabilities they can depend on in heterogeneous environments. 92 Similarly, designing and deploying the protocol will be easier with 93 thought paid to a common operational model. This will also help with 94 the design of NetConf schemas or MIBs later. 96 This document also gives recommendations for how management and 97 operations issues can be approached as protocols are revised and as 98 support is added for the key table [I-D.ietf-karp-crypto-key-table] 100 2. Requirements notation 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 3. Breakdown of KARP configuration 108 There are multiple ways of structuring configuration information. 109 One factor to consider is the scope of the configuration information. 110 Several protocols are peer-to-peer routing protocols where a 111 different key could potentially be used for each neighbor. Other 112 protocols require the same group key to be used for all nodes in an 113 administrative domain or routing area. In other cases, the same 114 group key needs to be used for all routers on an interface, but 115 different group keys can be used for each interface. 117 Within situations where a per-interface, per-area or per-peer key can 118 be used for manually configured long-term keys, that flexibility may 119 not be desirable from an operational standpoint. For example 120 consider OSPF [RFC2328]. Each OSPF link needs to use the same 121 authentication configuration, including the set of keys used for 122 reception and the set of keys used for transmission, but may use 123 different keys for different links. The most general management 124 model would be to configure keys per link. However for deployments 125 where the area uses the same key it would be strongly desirable to 126 configure the key as a property of the area. If the keys are 127 configured per-link, they can get out of sync. In order to support 128 generality of configuration and common operational situations, it 129 would be desirable to have some sort of inheritance where default 130 configurations are made per-area unless overridden per-interface. 132 As described in [I-D.ietf-karp-crypto-key-table], the cryptographic 133 keys are separated from the interface configuration into their own 134 configuration store. Each routing protocol is responsible for 135 defining the form of the Peer specification used by that protocol. 136 Thus each routing protocol needs to define the scope of keys. For 137 group keying, the Peer specification names the group. A protocol 138 could define a Peer specification indicating the key had a link scope 139 and also a Peer specification for scoping a key to a specific area. 140 For link-scoped keys it is generally best to define a single Peer 141 specification indicating the key has a link scope and to use 142 interface restrictions to restrict the key to the appropriate link. 144 Operational Requirements: KARP MUST support configuration of keys at 145 the most general scope for the underlying protocol; protocols 146 supporting per-peer keys MUST permit configuration of per-peer keys, 147 protocols supporting per-interface keys MUST support configuration of 148 per-interface keys, and so on. KARP MUST NOT permit configuration of 149 an inappropriate key scope. For example, configuration of separate 150 keys per interface MUST NOT be supported for a protocol requiring 151 per-area keys. This restriction can be enforced by rules specified 152 by each routing protocol for validating key table entries. 154 3.1. Integrity of the Key Table 156 The routing key table [I-D.ietf-karp-crypto-key-table] provides a 157 very general mechanism to abstract the storage of keys for routing 158 protocols. To avoid misconfiguration and simplify problem 159 determination, the router MUST verify the internal consistency of 160 entries added to the table. Routing protocols describe how their 161 protocol interacts with the key table including what validation MUSt 162 be performed. At a minimum, the router MUST verify: 164 o The cryptographic algorithms are valid for the protocol. 166 o The key derivation function is valid for the protocol. 168 o The direction is valid for the protocol; for example protocols 169 that require the same session key be used in both directions MUST 170 have a direction of both. 172 o The peer specification is consistent with the protocol. 174 Other checks are possible. For example the router could verify that 175 if a key is associated with a peer, that peer is a configured peer 176 for the specified protocol. However, this may be undesirable. It 177 may be desirable to load a key table when some peers have not yet 178 been configured. Also, it may be desirable to share portions of a 179 key table across devices even when their current configuration does 180 not require an adjacency with a particular peer in the interest of 181 uniform configuration or preparing for fail-over. 183 3.2. Management of Key Table 185 Several management operations will be quite common. For service 186 provider deployments the configuration management system can simply 187 update the key table. However, for smaller deployments, efficient 188 management operations are important. 190 As part of adding a new key it is typically desirable to set an 191 expiration time for an old key. The management interface SHOULD 192 provide a mechanism to easily update the expiration time for a 193 current key used with a given peer or interface. Also when adding a 194 key it is desirable to push the key out to nodes that will need it, 195 allowing use for receiving packets then later enabling transmit. 196 This can be accomplished automatically by providing a delay between 197 when a key becomes valid for reception and transmission. However, 198 some environments may not be able to predict when all the necessary 199 changes will be made. In these cases having a mechanism to enable a 200 key for sending is desirable. Management interfaces SHOULD provide 201 an easy mechanism to update the direction of an existing key or to 202 enable a disabled key. 204 3.3. Interactions with Automated Key Management 206 Consideration is required for how an automated key management 207 protocol will assign key IDs for group keys. All members of the 208 group may need to use the same key ID. This requires careful 209 coordination of global key IDs. Interactions with the peer key ID 210 field may make this easier; this requires additional study. 212 Automated key management protocols also assign keys for single peers. 213 If the key ID is global and needs to be coordinated between the 214 receiver and transmitter, then there is complexity in key management 215 protocols. 217 3.4. Virtual Routing and Forwarding Instances (VRFs) 219 Many core and enterprise routers support multiple routing instances. 220 For example a router serving multiple VPNs is likely to have a 221 forwarding/routing instance for each of these VPNs. Each VRF will 222 require its own routing key table. 224 4. Credentials and Authorization 226 Several methods for authentication have been proposed for KARP. The 227 simplest is preshared keys used directly as traffic keys. In this 228 mode, the traffic integrity keys are directly configured. This is 229 the mode supported by most of today's routing protocols. 231 As discussed in [I-D.polk-saag-rtg-auth-keytable], preshared keys can 232 be used as the input to a key derivation function (KDF) to generate 233 traffic keys. For example the TCP Authentication Option (TCP-AO) 234 [RFC5925] derives keys based on the initial TCP session state. 235 Typically a KDF will combine a long-term key with public inputs 236 exchanged as part of the protocol to form fresh session keys. a KDF 237 could potentially be used with some inputs that are configured along 238 with the long-term key. Also, it's possible that inputs to a KDF 239 will be private and exchanged as part of the protocol, although this 240 will be uncommon in KARP's uses of KDFs. 242 Preshared keys could also be used by an automated key management 243 protocol. In this mode, preshared keys would be used for 244 authentication. However traffic keys would be generated by some key 245 agreement mechanism or transported in a key encryption key derived 246 from the preshared key. This mode may provide better replay 247 protection. Also, in the absence of active attackers, key agreement 248 strategies such as Diffie-Hellman can be used to produce high-quality 249 traffic keys even from relatively weak preshared keys. 251 Public keys can be used for authentication. The design guide 252 [I-D.ietf-karp-design-guide] describes a mode in which routers have 253 the hashes of peer routers' public keys. In this mode, a traditional 254 public-key infrastructure is not required. The advantage of this 255 mode is that a router only contains its own keying material, limiting 256 the scope of a compromise. The disadvantage is that when a router is 257 added or deleted from the set of authorized routers, all routers that 258 peer need to be updated. Note that self-signed certificates are a 259 common way of communicating public-keys in this style of 260 authentication. 262 Certificates signed by a certification authority or some other PKI 263 could be used. The advantage of this approach is that routers may 264 not need to be directly updated when peers are added or removed. The 265 disadvantage is that more complexity and cost is required. 267 Each of these approaches has a different set of management and 268 operational requirements. Key differences include how authorization 269 is handled and how identity works. This section discusses these 270 differences. 272 4.1. Preshared Keys 274 In the protocol, manual preshared keys are either unnamed or named by 275 a small integer (typically 16 or 32 bits) key ID. Implementations 276 that support multiple keys for protocols that have no names for keys 277 need to try all possible keys before deciding a packet cannot be 278 validated [RFC4808]. Typically key IDs are names used by one group 279 or peer. 281 Manual preshared keys are often known by a group of peers rather than 282 just oneother peer. This is an interesting security property: unlike 283 with digitally signed messages or protocols where symmetric keys are 284 known only to two parties, it is impossible to identify the peer 285 sending a message cryptographically. However, it is possible to show 286 that the sender of a message is one of the parties who knows the 287 preshared key. Within the routing threat model the peer sending a 288 message can be identified only because peers are trusted and thus can 289 be assumed to correctly label the packets they send. This contrasts 290 with a protocol where cryptographic means such as digital signatures 291 are used to verify the origin of a message. As a consequence, 292 authorization is typically based on knowing the preshared key rather 293 than on being a particular peer. Note that once an authorization 294 decision is made, the peer can assert its identity; this identity is 295 trusted just as the routing information from the peer is trusted. 296 Doing an additional check for authorization based on the identity 297 included in the packet would provide little value: an attacker who 298 somehow had the key could claim the identity of an authorized peer 299 and an attacker without the key should be unable to claim the 300 identity of any peer. Such a check is not required by the KARP 301 threat model: inside attacks are not in scope. 303 Preshared keys used with key derivation function similarly to manual 304 preshared keys. However to form the actual traffic keys, session or 305 peer specific information is combined with the key. From an 306 authorization standpoint, the derivation key works the same as a 307 manual key. An additional routing protocol step or transport step 308 forms the key that is actually used. 310 Preshared keys that are used via automatic key management have not 311 been specified for KARP. Their naming and authorization may differ 312 from existing uses of preshared keys in routing protocols. In 313 particular, such keys may end up being known only by two peers. 314 Alternatively they may also be known by a group of peers. 315 Authorization could potentially be based on peer identity, although 316 it is likely that knowing the right key will be sufficient. There 317 does not appear to be a compelling reason to decouple the 318 authorization of a key for some purpose from authorization of peers 319 holding that key to perform the authorized function. 321 4.1.1. Sharing Keys and Zones of Trust 323 Care needs to be taken when symmetric keys are used for multiple 324 purposes. Consider the implications of using the same preshared key 325 for two interfaces: it becomes impossible to cryptographically 326 distinguish a router on one interface from a router on another 327 interface. So, a router that is trusted to participate in a routing 328 protocol on one interface becomes implicitly trusted for the other 329 interfaces that share the key. For many cases, such as link-state 330 routers in the same routing area, there is no significant advantage 331 that an attacker could gain from this trust within the KARP threat 332 model. However, distance-vector protocols, such as BGP and RIP, 333 permit routes to be filtered across a trust boundary. For these 334 protocols, participation in one interface might be more advantageous 335 than another. Operationally, when this trust distinction is 336 important to a deployment, different keys need to be used on each 337 side of the trust boundary. Key derivation can help prevent this 338 problem in cases of accidental misconfiguration. However, key 339 derivation cannot protect against a situation where a system was 340 incorrectly trusted to have the key used to perform the derivation. 341 This question of trust is important to the KARP threat model because 342 it is essential to determining whether a party is an insider for a 343 particular routing protocol. A customer router that is an an insider 344 for a BGP peering relationship with a service provider is not 345 typically an insider when considering the security of that service 346 provider's IGP. Similarly, To the extent that there are multiple 347 zones of trust and a routing protocol is determining whether a 348 particular router is within a certain zone, the question of untrusted 349 actors is within the scope of the routing threat model. 351 Key derivation can be part of a management solution to a desire to 352 have multiple keys for different zones of trust. A master key could 353 be combined with peer, link or area identifiers to form a router- 354 specific preshared key that is loaded onto routers. Provided that 355 the master key lives only on the management server and not the 356 individual routers, trust is preserved. However in many cases, 357 generating independent keys for the routers and storing the result is 358 more practical. If the master key were somehow compromised, all the 359 resulting keys would need to be changed. However if independent keys 360 are used, the scope of a compromise may be more limited. 362 4.1.2. Key Separation and Protocol Design 364 More subtle problems with key separation can appear in protocol 365 design. Two protocols that use the same traffic keys may work 366 together in unintended ways permitting one protocol to be used to 367 attack the other. Consider two hypothetical protocols. Protocol A 368 starts its messages with a set of extensions that are ignored if not 369 understood. Protocol B has a fixed header at the beginning of its 370 messages but ends messages with extension information. It may be 371 that the same message is valid both as part of protocol A and 372 protocol B. An attacker may be able to gain an advantage by getting a 373 router to generate this message with one protocol under situations 374 where the other protocol would not generate the message. This 375 hypothetical example is overly simplistic; real-world attacks 376 exploiting key separation weaknesses tend to be complicated and 377 involve specific properties of the cryptographic functions involved. 378 The key point is that whenever the same key is used in multiple 379 protocols, attacks may be possible. All the involved protocols need 380 to be analyzed to understand the scope of potential attacks. 382 Key separation attacks interact with the KARP operational model in a 383 number of ways. Administrators need to be aware of situations where 384 using the same manual traffic key with two different protocols (or 385 the same protocol in different contexts) creates attack 386 opportunities. Design teams should consider how their protocol might 387 interact with other routing protocols and describe any attacks 388 discovered so that administrators can understand the operational 389 implications. When designing automated key management or new 390 cryptographic authentication within routing protocols, we need to be 391 aware that administrators expect to be able to use the same preshared 392 keys in multiple contexts. As a result, we should use appropriate 393 key derivation functions so that different cryptographic keys are 394 used even when the same initial input key is used. 396 4.2. Asymmetric Keys 398 Outside of a PKI, public keys are expected to be known by the hash of 399 a key or (potentially self-signed) certificate. The Session 400 Description Protocol provides a standardized mechanism for naming 401 keys (in that case certificates) based on hashes (section 5 402 [RFC4572]). KARP SHOULD adopt this approach or another approach 403 already standardized within the IETF rather than inventing a new 404 mechanism for naming public keys. 406 A public key is typically expected to belong to one peer. As a peer 407 generates new keys and retires old keys, its public key may change. 408 For this reason, from a management standpoint, peers should be 409 thought of as associated with multiple public keys rather than as 410 containing a single public key hash as an attribute of the peer 411 object. 413 Authorization of public keys could be done either by key hash or by 414 peer identity. Performing authorizations by peer identity should 415 make it easier to update the key of a peer without risk of losing 416 authorizations for that peer. However management interfaces need to 417 be carefully designed to avoid making this extra level of indirection 418 complicated for operators. 420 4.3. Public Key Infrastructure 422 When a PKI is used, certificates are used. The certificate binds a 423 key to a name of a peer. The key management protocol is responsible 424 for exchanging certificates and validating them to a trust anchor. 426 Authorization needs to be done in terms of peer identities not in 427 terms of keys. One reason for this is that when a peer changes its 428 key, the new certificate needs to be sufficient for authentication to 429 continue functioning even though the key has never been seen before. 431 Potentially authorization could be performed in terms of groups of 432 peers rather than single peers. An advantage of this is that it may 433 be possible to add a new router with no authentication related 434 configuration of the peers of that router. For example, a domain 435 could decide that any router with a particular keyPurposeID signed by 436 the organization's certificate authority is permitted to join the 437 IGP. Just as in configurations where cryptographic authentication is 438 not used, automatic discovery of this router can establish 439 appropriate adjacencies. 441 Assuming that self-signed certificates are used by routers that wish 442 to use public keys but that do not need a PKI, then PKI and the 443 infrastructureless mode of public-key operation described in the 444 previous section can work well together. One router could identify 445 its peers based on names and use certificate validation. Another 446 router could use hashes of certificates. This could be very useful 447 for border routers between two organizations. Smaller organizations 448 could use public keys and larger organizations could use PKI. 450 4.4. The role of Central Servers 452 An area to explore is the role of central servers like RADIUS or 453 directories. As discussed in the design-guide, a system where keys 454 are pushed by a central management system is undesirable as an end 455 result for KARP. However central servers may play a role in 456 authorization and key rollover. For example a node could send a hash 457 of a public key to a RADIUS server. 459 If central servers do play a role it will be critical to make sure 460 that they are not required during routine operation or a cold-start 461 of a network. They are more likely to play a role in enrollment of 462 new peers or key migration/compromise. 464 Another area where central servers may play a role is for group key 465 agreement. As an example, [I-D.liu-ospfv3-automated-keying-req] 466 discusses the potential need for key agreement servers in OSPF. 467 Other routing protocols that use multicast or broadcast such as IS-IS 468 are likely to need a similar approach. Multicast key agreement 469 protocols need to allow operators to choose which key servers will 470 generate traffic keys. The quality of random numbers [RFC4086] is 471 likely to differ between systems. As a result, operators may have 472 preferences for where keys are generated. 474 5. Grouping Peers Together 476 One significant management consideration will be the grouping of 477 management objects necessary to determine who is authorized to act as 478 a peer for a given routing action. As discussed previously, the 479 following objects are potentially required: 481 o Key objects are required. Symmetric keys may be preshared and 482 knowledge of the key used as the decision factor in authorization. 483 Knowledge of the private key corresponding to Asymmetric public 484 keys may be used directly for authorization as well. During key 485 transitions more than one key may refer to a given peer. Group 486 preshared keys may refer to multiple peers. 488 o A peer is a router that this router might wish to communicate 489 with. Peers may be identified by names or keys. 491 o Groups of peers may be authorized for a given routing protocol. 493 Establishing a management model is difficult because of the complex 494 relationships between each set of objects. As discussed there may be 495 more than one key for a peer. However in the preshared key case, 496 there may be more than one peer for a key. This is true both for 497 group security association protocols such as an IGP or one-to-one 498 protocols where the same key is used administratively. In some of 499 these situations, it may be undesirable to explicitly enumerate the 500 peers in the configuration; for example IGP peers are auto-discovered 501 for broadcast links but not for non-broadcast multi-access links. 503 Peers may be identified either by name or key. If peers are 504 identified by key it is strongly desirable from an operational 505 standpoint to consider any peer identifiers or name to be a local 506 matter and not require the names or identifiers to be synchronized. 507 Obviously if peers are identified by names (for example with 508 certificates in a PKI), identifiers need to be synchronized between 509 the authorized peer and the peer making the authorization decision. 511 In many cases peers will explicitly be identified in routing protocol 512 configuration. In these cases it is possible to attach the 513 authorization information (keys or identifiers) to the peer's 514 configuration object. Two cases do not involve enumerating peers. 515 The first is the case where preshared keys are shared among a group 516 of peers. It is likely that this case can be treated from a 517 management standpoint as a single peer representing all the peers 518 that share the keys. The other case is one where certificates in a 519 PKI are used to introduce peers to a router. In this case, rather 520 than configuring peers, , the router needs to be configured with 521 information on what certificates represent acceptable peers. 523 Another consideration is what routing protocols share peers. For 524 example it may be common for LDP peers to also be peers of some other 525 routing protocol. Also, RSVP-TE may be associated with some TE-based 526 IGP. In some of these cases it would be desirable to use the same 527 authorization information for both routing protocols. 529 In order to develop a management model for authorization, the working 530 group needs to consider several questions. What protocols support 531 auto-discovery of peers? What protocols require more configuration 532 of a peer than simply the peer's authorization information and 533 network address? What management operations are going to be common 534 as security information for peers is configured and updated? What 535 operations will be common while performing key transitions or while 536 migrating to new security technologies? 538 6. Administrator Involvement 540 One key operational question is what areas will administrator 541 involvement be required. Likely areas where involvement may be 542 useful include enrollment of new peers. Fault recovery should also 543 be considered. 545 6.1. Enrollment 547 One area where the management of routing security needs to be 548 optimized is the deployment of a new router. In some cases a new 549 router may be deployed on an existing network where routing to 550 management servers is already available. In other cases, routers may 551 be deployed as part of connecting or creating a site. Here, the 552 router and infrastructure may not be available until the router has 553 securely authenticated. 555 In general, security configuration can be treated as an additional 556 configuration item that needs to be set up to establish service. 557 There is no significant security value in protecting routing protocol 558 keys more than administrative password or Authentication, 559 Authorization and Accounting (AAA) secrets that can be used to gain 560 login access to a router. These existing secrets can be used to make 561 configuration changes that impact routing protocols as much as 562 disclosure of a routing protocol key. Operators already have 563 procedures in place for these items. So, it is appropriate to use 564 similar procedures for routing protocol keys. It is reasonable to 565 improve existing configuration procedures and the routing protocol 566 procedures over time. However it is more desirable to deploy KARP 567 with security similar to that used for managing existing secrets than 568 to delay deploying KARP. 570 Operators MAY develop higher assurance procedures for dealing with 571 keys. For example, asymmetric keys can be generated on a router and 572 never exported from the router. Operators can evaluate the cost vs 573 security and availability tradeoffs of these procedures. 575 6.2. Handling Faults 577 Faults may interact with operational practice in at least two ways. 578 First, security solutions may introduce faults. For example if 579 certificates expire in a PKI, previous adjacencies may no longer 580 form. Operational practice will require a way of repairing these 581 errors. This may end up being very similar to repairing other faults 582 that can partition a network. 584 Notifications will play a critical role in avoiding security faults. 585 Implementations SHOULD use appropriate mechanisms to notify operators 586 as security resources are about to expire. Notifications can include 587 messages to consoles, logged events, SNMP traps, or notifications 588 within a routing protocol. One strategy is to have increasing 589 escalations of notifications. 591 Monitoring will also play an important role in avoiding security 592 faults such as certificate expiration. However, the protocols MUST 593 still have adequate operational mechanisms to recover from these 594 situations. Also, some faults, such as those resulting from a 595 compromise or actual attack on a facility are inherent and may not be 596 prevented. 598 A second class of faults is equipment faults that impact security. 599 For example if keys are stored on a router and never moved from that 600 device, failure of a router implies a need to update security 601 provisioning on the replacement router and its peers. 603 One approach, recommended by work on securing BGP 604 [I-D.ietf-sidr-rtr-keying] is to maintain the router's keying 605 material so that when a router is replaced the same keys can be used. 606 Router keys can be maintained on a central server. These approaches 607 permit the credentials of a router to be recovered. This provides 608 valuable options in case of hardware fault. The failing router can 609 be recovered without changing credentials on other routers or waiting 610 for keys to be certified. One disadvantage of this approach is that 611 even if public-key cryptography is used, the private keys are located 612 on more than just the router.; a system in which keys were generated 613 on a router and never exported from that router would typically make 614 it more difficult for an attacker to obtain the keys. For most 615 environments the ability to quickly replace a router justifies 616 maintaining keys centrally. 618 More generally keying is another item of configuration that needs to 619 be restored to restore service when equipment fails. Operators 620 typically perform the minimal configuration necessary to get a router 621 back in contact with the management server. The same would apply for 622 keys. Operators who do not maintain copies of key material for 623 performing key recovery on routers would need to perform a bit more 624 work to regain contact with the management server. It seems 625 reasonable to assume that management servers will be able to cause 626 keys to be generated or distributed sufficiently to fully restore 627 service. 629 7. Upgrade Considerations 631 It needs to be possible to deploy automated key management in an 632 organization without either having to disable existing security or 633 disrupting routing. As a result, it needs to be possible to perform 634 a phased upgrade from manual keying to automated key management. 635 This upgrade procedure needs to be easy and have a very low risk of 636 disrupting routing. Today, many operators do not update keys because 637 the perceived risk of an attack is lower than the complexity of and 638 update and risk of routing disruptions. 640 For peer-to-peer protocols such as BGP, this can be relatively easy. 641 First, code that supports automated key management needs to be loaded 642 on both peers. Then the adjacency can be upgraded. The 643 configuration can be updated to switch to automated key management 644 when the second router reboots. Alternatively, if the key management 645 protocols involved can detect that both peers now support automated 646 key management, then a key can potentially be negotiated for an 647 existing session. 649 The situation is more complex for organizations that have not 650 upgraded from TCP MD5 [RFC2385] to the TCP Authentication Option 651 [RFC5925]. Today, routers typically need to understand whether a 652 given peer supports TCP MD5 or TCP-AO before opening a TCP 653 connection. In addition, many implementations support grouping 654 configuration of related peers including security configuration 655 together. Implementations make it challenging to move from TCP-MD5 656 to TCP-AO before all peers in the group are ready. Operators 657 perceive it as high risk to update the configuration of a large 658 number of peers. One particularly risky situation is upgrading the 659 configuration of iBGP peers. 661 The situation is more complicated for multicast protocols. It's 662 typically not desirable to bring down an entire link to reconfigure 663 it as using automated key management. Two approaches should be 664 considered. One is to support key table rows supporting the 665 automated key management and manually configured keying for the same 666 link at the same time. Coordinating this may be challenging from an 667 operational standpoint. Another possibility is for the automated key 668 management protocol to actually select the same traffic key that is 669 being used manually. This could be accomplished by having an option 670 in the key management protocol to export the current manual group key 671 through the automated key management protocol. Then after all nodes 672 are configured with automated key management, manual key entries can 673 be removed. The next re-key after all nodes have manual entries 674 removed will generate a new fresh key. Group key management 675 protocols are RECOMMENDED to support an option to export existing 676 manual keys during initial deployment of automated key management. 678 8. Security Considerations 680 This document does not define a protocol. It does discuss the 681 operational and management implications of several security 682 technologies. 684 9. Acknowledgments 686 Funding for Sam Hartman's work on this memo is provided by Huawei. 688 The authors would like to thank Bill Atwood , Randy Bush, Wes George, 689 Gregory Lebovitz, and Russ White for valuable reviews. 691 10. References 693 10.1. Normative References 695 [I-D.ietf-karp-crypto-key-table] 696 Housley, R., Polk, T., Hartman, S., and D. Zhang, 697 "Database of Long-Lived Symmetric Cryptographic Keys", 698 draft-ietf-karp-crypto-key-table-06 (work in progress), 699 February 2013. 701 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 702 Requirement Levels", BCP 14, RFC 2119, March 1997. 704 10.2. Informative References 706 [I-D.ietf-karp-design-guide] 707 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 708 Routing Protocols (KARP) Design Guidelines", 709 draft-ietf-karp-design-guide-10 (work in progress), 710 December 2011. 712 [I-D.ietf-sidr-rtr-keying] 713 Turner, S., Patel, K., and R. Bush, "Router Keying for 714 BGPsec", draft-ietf-sidr-rtr-keying-01 (work in progress), 715 February 2013. 717 [I-D.liu-ospfv3-automated-keying-req] 718 Liu, Y., "OSPFv3 Automated Group Keying Requirements", 719 draft-liu-ospfv3-automated-keying-req-01 (work in 720 progress), July 2007. 722 [I-D.polk-saag-rtg-auth-keytable] 723 Polk, T. and R. Housley, "Routing Authentication Using A 724 Database of Long-Lived Cryptographic Keys", 725 draft-polk-saag-rtg-auth-keytable-05 (work in progress), 726 November 2010. 728 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 730 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 731 Signature Option", RFC 2385, August 1998. 733 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 734 Requirements for Security", BCP 106, RFC 4086, June 2005. 736 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 737 Transport Layer Security (TLS) Protocol in the Session 738 Description Protocol (SDP)", RFC 4572, July 2006. 740 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", 741 RFC 4808, March 2007. 743 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 744 Authentication Option", RFC 5925, June 2010. 746 Authors' Addresses 748 Sam Hartman 749 Painless Security 751 Email: hartmans-ietf@mit.edu 753 Dacheng Zhang 754 Huawei 756 Email: zhangdacheng@huawei.com