idnits 2.17.1 draft-ietf-karp-ops-model-02.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 (April 26, 2012) is 4382 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-karp-design-guide-07 -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 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: October 28, 2012 Huawei 6 April 26, 2012 8 Operations Model for Router Keying 9 draft-ietf-karp-ops-model-02.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 April 25, 2012. 35 Copyright Notice 37 Copyright (c) 2011 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. Protocol Limitations from the Key Table . . . . . . . . . 7 58 3.4. VRFs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 4. Credentials and Authorization . . . . . . . . . . . . . . . . 9 60 4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . . 10 61 4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 12 62 4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 12 63 4.4. The role of Central Servers . . . . . . . . . . . . . . . 13 64 5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 14 65 6. Administrator Involvement . . . . . . . . . . . . . . . . . . 16 66 6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 16 67 6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 16 68 7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . . 18 69 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 19 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 71 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 73 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 74 11.2. Informative References . . . . . . . . . . . . . . . . . . 22 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 77 1. Introduction 79 The KARP working group is designing improvements to the cryptographic 80 authentication of IETF routing protocols. These improvements include 81 improvements to how integrity functions are handled within each 82 protocol as well as designing an automated key management solution. 84 This document discusses issues to consider when thinking about the 85 operational and management model for KARP. Each implementation will 86 take its own approach to management; this is one area for vendor 87 differentiation. However, it is desirable to have a common baseline 88 for the management objects allowing administrators, security 89 architects and protocol designers to understand what management 90 capabilities they can depend on in heterogeneous environments. 91 Similarly, designing and deploying the protocol will be easier with 92 thought paid to a common operational model. This will also help with 93 the design of NetConf schemas or MIBs later. 95 2. Requirements notation 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 3. Breakdown of KARP configuration 103 There are multiple ways of structuring configuration information. 104 One factor to consider is the scope of the configuration information. 105 Several protocols are peer-to-peer routing protocols where a 106 different key could potentially be used for each neighbor. Other 107 protocols require the same group key to be used for all nodes in an 108 administrative domain or routing area. In other cases, the same 109 group key needs to be used for all routers on an interface, but 110 different group keys can be used for each interface. 112 Within situations where a per-interface, per-area or per-peer key can 113 be used for manually configured long-term keys, that flexibility may 114 not be desirable from an operational standpoint. For example 115 consider OSPF [RFC2328]. Each OSPF link needs to use the same 116 authentication configuration, including the set of keys used for 117 reception and the set of keys used for transmission, but may use 118 different keys for different links. The most general management 119 model would be to configure keys per link. However for deployments 120 where the area uses the same key it would be strongly desirable to 121 configure the key as a property of the area. If the keys are 122 configured per-link, they can get out of sync. In order to support 123 generality of configuration and common operational situations, it 124 would be desirable to have some sort of inheritance where default 125 configurations are made per-area unless overridden per-interface. 127 As described in [I-D.housley-saag-crypto-key-table], the 128 cryptographic keys are separated from the interface configuration 129 into their own configuration store. This document should specify how 130 key selection interacts with the key table. One possible approach 131 would be to assume that all keys that permit use on a given interface 132 would be used on that interface with no additional configuration 133 steps. If this model is adopted then the key table draft should be 134 expanded to permit specification of domains and areas as well. It's 135 not clear why "all" is permitted as an interface specification in 136 this model; it seems unlikely that it would be desirable to use the 137 same set of keys for two different instances of an IGP or across 138 autonomous system boundaries. 140 Another model is that the interface specification in the key table is 141 a restriction that limits keys on top of other configuration enabling 142 them. Then a set of keys from the key table is attached to an 143 interface, area or routing domain using an additional configuration 144 step. This avoids the previous problems at the expense of 145 significant complexity of configuration. 147 Operational Requirements: KARP MUST support configuration of keys at 148 the most general scope for the underlying protocol; protocols 149 supporting per-peer keys MUST permit configuration of per-peer keys, 150 protocols supporting per-interface keys MUST support configuration of 151 per-interface keys, and so on. KARP MUST NOT permit configuration of 152 an inappropriate key scope. For example, configuration of separate 153 keys per interface MUST NOT be supported for a protocol requiring 154 per-area keys. 156 3.1. Integrity of the Key Table 158 The routing key table [I-D.housley-saag-crypto-key-table] provides a 159 very general mechanism to abstract the storage of keys for routing 160 protocols. To avoid misconfiguration and simplify problem 161 determination, the router MUST verify the internal consistency of 162 entries added to the table. 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 and interface specification is consistent with the 173 protocol. 175 Other checks are possible. For example the router could verify that 176 if a key is associated with a peer, that peer is a configured peer 177 for the specified protocol. However, this may be undesirable. It 178 may be desirable to load a key table when some peers have not yet 179 been configured. Also, it may be desirable to share portions of a 180 key table across devices even when their current configuration does 181 not require an adjacency with a particular peer in the interest of 182 uniform configuration or preparing for fail-over. 184 3.2. Management of Key Table 186 Several management operations will be quite common. For service 187 provider deployments the configuration management system can simply 188 update the key table. However, for smaller deployments, efficient 189 management operations are important. 191 As part of adding a new key it is typically desirable to set an 192 expiration time for an old key. The management interface SHOULD 193 provide a mechanism to easily update the expiration time for a 194 current key used with a given peer or interface. Also when adding a 195 key it is desirable to push the key out to nodes that will need it, 196 allowing use for receiving packets then later enabling transmit. 198 This can be accomplished automatically by providing a delay between 199 when a key becomes valid for reception and transmission. However, 200 some environments may not be able to predict when all the necessary 201 changes will be made. In these cases having a mechanism to enable a 202 key for sending is desirable. 204 3.3. Protocol Limitations from the Key Table 206 The format of the key table imposes a few limitations on routing 207 protocols. The first is that the key ID is 16 bits; some routing 208 protocols have 32-bit key identifiers. A key mapping table as 209 discussed in 4.1 of [I-D.polk-saag-rtg-auth-keytable] could be used 210 to map to the larger key identifier. However it's probably desirable 211 to either decide that only 16 bits of the key ID space is to be used 212 or to expand the identifier space in the key table. From a 213 management standpoint we need to make concrete requirements around 214 whether a key ID is per-protocol or whether subspaces in the key ID 215 space are reserved for each protocol. This is necessary so that 216 implementations from different vendors can be managed consistently. 218 The second requirement that the key table places is that the key ID 219 is scoped fairly broadly. At least within some protocols such as 220 OSPF, the key ID might only need to be unique per-link or per-peer. 221 That is, packets sent on two different interfaces could use key ID 32 222 even if the keys were different for these interfaces. An 223 implementation could use the interface and the key ID as a lookup to 224 find the right key. However, the key table draft requires that a key 225 ID be sufficient to look up a key, meaning that the key ID is a 226 globally scoped identifier. There is nothing wrong with this 227 restriction, but it does need to be noted when assigning key IDs for 228 a domain. 230 Consideration is required for how an automated key management 231 protocol will assign key IDs for group keys. All members of the 232 group may need to use the same key ID. This requires careful 233 coordination of global key IDs. Interactions with the peer key ID 234 field may make this easier; this requires additional study. 236 Automated key management protocols also assign keys for single peers. 237 If the key ID is global and needs to be coordinated between the 238 receiver and transmitter, then there is complexity in key management 239 protocols. 241 3.4. VRFs 243 Many core and enterprise routers support multiple routing instances. 244 For example a router serving multiple VPNs is likely to have a 245 forwarding/routing instance for each of these VPNs. We need to 246 decide how the key table and other configuration information for KARP 247 interacts with this. The obvious first-order answer is that each 248 routing instance gets its own key table. However, we need to 249 consider how these instances interact with each other and confirm 250 this makes sense. 252 4. Credentials and Authorization 254 Several methods for authentication have been proposed for KARP. The 255 simplest is preshared keys used directly as traffic keys. In this 256 mode, the traffic integrity keys are directly configured. This is 257 the mode supported by today's routing protocols. 259 As discussed in [I-D.polk-saag-rtg-auth-keytable], preshared keys can 260 be used as the input to a key derivation function (KDF) to generate 261 traffic keys. For example the TCP Authentication Option (TCP-AO) 262 [RFC5925] derives keys based on the initial TCP session state. 263 Typically a KDF will combine a long-term key with public inputs 264 exchanged as part of the protocol to form fresh session keys. a KDF 265 could potentially be used with some inputs that are configured along 266 with the long-term key. Also, it's possible that inputs to a KDF 267 will be private and exchanged as part of the protocol, although this 268 will be uncommon in KARP's uses of KDFs. 270 Preshared keys could also be used by an automated key management 271 protocol. In this mode, preshared keys would be used for 272 authentication. However traffic keys would be generated by some key 273 agreement mechanism or transported in a key encryption key derived 274 from the preshared key. This mode may provide better replay 275 protection. Also, in the absence of active attackers, key agreement 276 strategies such as Diffie-Hellman can be used to produce high-quality 277 traffic keys even from relatively weak preshared keys. 279 Public keys can be used for authentication. The design guide 280 [I-D.ietf-karp-design-guide] describes a mode in which routers have 281 the hashes of peer routers' public keys. In this mode, a traditional 282 public-key infrastructure is not required. The advantage of this 283 mode is that a router only contains its own keying material, limiting 284 the scope of a compromise. The disadvantage is that when a router is 285 added or deleted from the set of authorized routers, all routers that 286 peer need to be updated. Note that self-signed certificates are a 287 common way of communicating public-keys in this style of 288 authentication. 290 Certificates signed by a certification authority or some other PKI 291 could be used. The advantage of this approach is that routers may 292 not need to be directly updated when peers are added or removed. The 293 disadvantage is that more complexity and cost is required. 295 Each of these approaches has a different set of management and 296 operational requirements. Key differences include how authorization 297 is handled and how identity works. This section discusses these 298 differences. 300 4.1. Preshared Keys 302 In the protocol, manual preshared keys are either unnamed or named by 303 a small integer (typically 16 or 32 bits) key ID. Implementations 304 that support multiple keys for protocols that have no names for keys 305 need to try all possible keys before deciding a packet cannot be 306 validated [RFC4808]. Typically key IDs are names used by one group 307 or peer. 309 Manual preshared keys are often known by a group of peers rather than 310 just oneother peer. This is an interesting security property: unlike 311 with digitally signed messages or protocols where symmetric keys are 312 known only to two parties, it is impossible to identify the peer 313 sending a message cryptographically. However, it is possible to show 314 that the sender of a message is one of the parties who knows the 315 preshared key. Within the routing threat model the peer sending a 316 message can be identified only because peers are trusted and thus can 317 be assumed to correctly label the packets they send. This contrasts 318 with a protocol where cryptographic means such as digital signatures 319 are used to verify the origin of a message. As a consequence, 320 authorization is typically based on knowing the preshared key rather 321 than on being a particular peer. Note that once an authorization 322 decision is made, the peer can assert its identity; this identity is 323 trusted just as the routing information from the peer is trusted. 324 Doing an additional check for authorization based on the identity 325 included in the packet would provide little value: an attacker who 326 somehow had the key could claim the identity of an authorized peer 327 and an attacker without the key should be unable to claim the 328 identity of any peer. Such a check is not required by the KARP 329 threat model: inside attacks are not in scope. 331 Preshared keys used with key derivation function similarly to manual 332 preshared keys. However to form the actual traffic keys, session or 333 peer specific information is combined with the key. From an 334 authorization standpoint, the derivation key works the same as a 335 manual key. An additional routing protocol step or transport step 336 forms the key that is actually used. 338 Preshared keys that are used via automatic key management have not 339 been specified for KARP. Their naming and authorization may differ 340 from existing uses of preshared keys in routing protocols. In 341 particular, such keys may end up being known only by two peers. 342 Alternatively they may also be known by a group of peers. 343 Authorization could potentially be based on peer identity, although 344 it is likely that knowing the right key will be sufficient. There 345 does not appear to be a compelling reason to decouple the 346 authorization of a key for some purpose from authorization of peers 347 holding that key to perform the authorized function. 349 Care needs to be taken when symmetric keys are used for multiple 350 purposes. Consider the implications of using the same preshared key 351 for two interfaces: it becomes impossible to cryptographically 352 distinguish a router on one interface from a router on another 353 interface. So, a router that is trusted to participate in a routing 354 protocol on one interface becomes implicitly trusted for the other 355 interfaces that share the key. For many cases, such as link-state 356 routers in the same routing area, there is no significant advantage 357 that an attacker could gain from this trust within the KARP threat 358 model. However, distance-vector protocols, such as BGP and RIP, 359 permit routes to be filtered across a trust boundary. For these 360 protocols, participation in one interface might be more advantageous 361 than another. Operationally, when this trust distinction is 362 important to a deployment, different keys need to be used on each 363 side of the trust boundary. Key derivation can help prevent this 364 problem in cases of accidental misconfiguration. However, key 365 derivation cannot protect against a situation where a system was 366 incorrectly trusted to have the key used to perform the derivation. 367 To the extent that there are multiple zones of trust and a routing 368 protocol is determining whether a particular router is within a 369 certain zone, the question of untrusted actors is within the scope of 370 the routing threat model. 372 Key derivation can be part of a management solution to a desire to 373 have multiple keys for different zones of trust. A master key could 374 be combined with peer, link or area identifiers to form a router- 375 specific preshared key that is loaded onto routers. Provided that 376 the master key lives only on the management server and not the 377 individual routers, trust is preserved. However in many cases, 378 generating independent keys for the routers and storing the result is 379 more practical. If the master key were somehow compromised, all the 380 resulting keys would need to be changed. However if independent keys 381 are used, the scope of a compromise may be more limited. 383 More subtle problems with key separation can appear in protocol 384 design. Two protocols that use the same traffic keys may work 385 together in unintended ways permitting one protocol to be used to 386 attack the other. Consider two hypothetical protocols. Protocol A 387 starts its messages with a set of extensions that are ignored if not 388 understood. Protocol B has a fixed header at the beginning of its 389 messages but ends messages with extension information. It may be 390 that the same message is valid both as part of protocol A and 391 protocol B. An attacker may be able to gain an advantage by getting a 392 router to generate this message with one protocol under situations 393 where the other protocol would not generate the message. This 394 hypothetical example is overly simplistic; real-world attacks 395 exploiting key separation weaknesses tend to be complicated and 396 involve specific properties of the cryptographic functions involved. 398 The key point is that whenever the same key is used in multiple 399 protocols, attacks may be possible. All the involved protocols need 400 to be analyzed to understand the scope of potential attacks. 402 Key separation attacks interact with the KARP operational model in a 403 number of ways. Administrators need to be aware of situations where 404 using the same manual traffic key with two different protocols (or 405 the same protocol in different contexts) creates attack 406 opportunities. Design teams should consider how their protocol might 407 interact with other routing protocols and describe any attacks 408 discovered so that administrators can understand the operational 409 implications. When designing automated key management or new 410 cryptographic authentication within routing protocols, we need to be 411 aware that administrators expect to be able to use the same preshared 412 keys in multiple contexts. As a result, we should use appropriate 413 key derivation functions so that different cryptographic keys are 414 used even when the same initial input key is used. 416 4.2. Asymmetric Keys 418 Outside of a PKI, public keys are expected to be known by the hash of 419 a key or (potentially self-signed) certificate. The Session 420 Description Protocol provides a standardized mechanism for naming 421 keys (in that case certificates) based on hashes (section 5 422 [RFC4572]). KARP SHOULD adopt this approach or another approach 423 already standardized within the IETF rather than inventing a new 424 mechanism for naming public keys. 426 A public key is typically expected to belong to one peer. As a peer 427 generates new keys and retires old keys, its public key may change. 428 For this reason, from a management standpoint, peers should be 429 thought of as associated with multiple public keys rather than as 430 containing a single public key hash as an attribute of the peer 431 object. 433 Authorization of public keys could be done either by key hash or by 434 peer identity. Performing authorizations by peer identity should 435 make it easier to update the key of a peer without risk of losing 436 authorizations for that peer. However management interfaces need to 437 be carefully designed to avoid making this extra level of indirection 438 complicated for operators. 440 4.3. Public Key Infrastructure 442 When a PKI is used, certificates are used. The certificate binds a 443 key to a name of a peer. The key management protocol is responsible 444 for exchanging certificates and validating them to a trust anchor. 446 Authorization needs to be done in terms of peer identities not in 447 terms of keys. One reason for this is that when a peer changes its 448 key, the new certificate needs to be sufficient for authentication to 449 continue functioning even though the key has never been seen before. 451 Potentially authorization could be performed in terms of groups of 452 peers rather than single peers. An advantage of this is that it may 453 be possible to add a new router with no authentication related 454 configuration of the peers of that router. For example, a domain 455 could decide that any router with a particular keyPurposeID signed by 456 the organization's certificate authority is permitted to join the 457 IGP. Just as in configurations where cryptographic authentication is 458 not used, automatic discovery of this router can establish 459 appropriate adjacencies. 461 Assuming that potentially self-signed certificates are used by 462 routers that wish to use public keys but that do not need a PKI, then 463 PKI and the infrastructureless mode of public-key operation described 464 in the previous section can work well together. One router could 465 identify its peers based on names and use certificate validation. 466 Another router could use hashes of certificates. This could be very 467 useful for border routers between two organizations. Smaller 468 organizations could use public keys and larger organizations could 469 use PKI. 471 4.4. The role of Central Servers 473 An area to explore is the role of central servers like RADIUS or 474 directories. As discussed in the design-guide, a system where keys 475 are pushed by a central management system is undesirable as an end 476 result for KARP. However central servers may play a role in 477 authorization and key rollover. For example a node could send a hash 478 of a public key to a RADIUS server. 480 If central servers do play a role it will be critical to make sure 481 that they are not required during routine operation or a cold-start 482 of a network. They are more likely to play a role in enrollment of 483 new peers or key migration/compromise. 485 Another area where central servers may play a role is for group key 486 agreement. As an example, [I-D.liu-ospfv3-automated-keying-req] 487 discusses the potential need for key agreement servers in OSPF. 488 Other routing protocols that use multicast or broadcast such as IS-IS 489 are likely to need a similar approach. 491 5. Grouping Peers Together 493 One significant management consideration will be the grouping of 494 management objects necessary to determine who is authorized to act as 495 a peer for a given routing action. As discussed previously, the 496 following objects are potentially required: 498 o Key objects are required. Symmetric keys may be preshared. 499 Asymmetric public keys may be used directly for authorization as 500 well. During key transitions more than one key may refer to a 501 given peer. Group preshared keys may refer to multiple peers. 503 o A peer is a router that this router might wish to communicate 504 with. Peers may be identified by names or keys. 506 o Groups of peers may be authorized for a given routing protocol. 508 Establishing a management model is difficult because of the complex 509 relationships between each set of objects. As discussed there may be 510 more than one key for a peer. However in the preshared key case, 511 there may be more than one peer for a key. This is true both for 512 group security association protocols such as an IGP or one-to-one 513 protocols where the same key is used administratively. In some of 514 these situations, it may be undesirable to explicitly enumerate the 515 peers in the configuration; for example IGP peers are auto-discovered 516 for broadcast links but not for non-broadcast multi-access links. 518 Peers may be identified either by name or key. If peers are 519 identified by key it is probably strongly desirable from an 520 operational standpoint to consider any peer identifiers or name to be 521 a local matter and not require the names or identifiers to be 522 synchronized. Obviously if peers are identified by names (for 523 example with certificates in a PKI), identifiers need to be 524 synchronized between the authorized peer and the peer making the 525 authorization decision. 527 In many cases peers will explicitly be identified. In these cases it 528 is possible to attach the authorization information (keys or 529 identifiers) to the peer's configuration object. Two cases do not 530 involve enumerating peers. The first is the case where preshared 531 keys are shared among a group of peers. It is likely that this case 532 can be treated from a management standpoint as a single peer 533 representing all the peers that share the keys. The other case is 534 one where certificates in a PKI are used to introduce peers to a 535 router. In this case, rather than configuring peers, , the router 536 needs to be configured with information on what certificates 537 represent acceptable peers. 539 Another consideration is what routing protocols share peers. For 540 example it may be common for LDP peers to also be peers of some other 541 routing protocol. Also, RSVP-TE may be associated with some TE-based 542 IGP. In some of these cases it would be desirable to use the same 543 authorization information for both routing protocols. 545 In order to develop a management model for authorization, the working 546 group needs to consider several questions. What protocols support 547 auto-discovery of peers? What protocols require more configuration 548 of a peer than simply the peer's authorization information and 549 network address? What management operations are going to be common 550 as security information for peers is configured and updated? What 551 operations will be common while performing key transitions or while 552 migrating to new security technologies? 554 6. Administrator Involvement 556 One key operational question is what areas will administrator 557 involvement be required. Likely areas where involvement may be 558 useful includes enrollment of new peers. Fault recovery should also 559 be considered. 561 6.1. Enrollment 563 One area where the management of routing security needs to be 564 optimized is the deployment of a new router. In some cases a new 565 router may be deployed on an existing network where routing to 566 management servers is already available. In other cases, routers may 567 be deployed as part of connecting or creating a site. Here, the 568 router and infrastructure may not be available until the router has 569 securely authenticated. This problem is similar to the problem of 570 getting initial configuration of routing instances onto the router. 571 However, especially in cases where asymmetric keys or per-peer 572 preshared keys are used, the configuration of other routers needs to 573 be modified to bring up the security association. Also, there has 574 been discussion of generating keys on routers and not allowing them 575 to leave devices. This also impacts what strategies are possible. 576 For example this might mean that routers need to be booted in a 577 secure environment where keys can be generated, and public keys 578 copied to a management server to push out the new public key to 579 potential peers. Then, the router needs to be packaged, moved to 580 where it will be deployed and set up.Alternatives are possible; it is 581 critical that we understand how what we propose impacts operators. 583 We need to work through examples with operators familiar with 584 specific real-world deployment practices and understand how proposed 585 security mechanisms will interact with these practices. 587 6.2. Handling Faults 589 Faults may interact with operational practice in at least two ways. 590 First, security solutions may introduce faults. For example if 591 certificates expire in a PKI, previous adjacencies may no longer 592 form. Operational practice will require a way of repairing these 593 errors. This may end up being very similar to deploying a router 594 that is connecting a new site as the security fault may have 595 partitioned the network. However, unlike a new deployment, the event 596 is unplanned. Strategies such as configuring a router and shipping 597 it to a site may not be appropriate for recovering a fault even 598 though they may be more useful for new deployments. 600 Monitoring will play a critical role in avoiding security faults such 601 as certificate expiration. However, the protocols MUST still have 602 adequate operational mechanisms to recover from these situations. 603 Also, some faults, such as those resulting from a compromise or 604 actual attack on a facility are inherent and may not be prevented. 606 A second class of faults is equipment faults that impact security. 607 For example if keys are stored on a router and never moved from that 608 device, failure of a router implies a need to update security 609 provisioning on the replacement router and its peers. 611 To address these operational considerations, we should identify 612 circumstances surrounding recovery from today's faults and understand 613 how protocols will impact mechanisms used today. 615 7. Upgrade Considerations 617 It needs to be possible to deploy automated key management in an 618 organization without either having to disable existing security or 619 disrupting routing. As a result, it needs to be possible to perform 620 a phased upgrade from manual keying to automated key management. 622 For peer-to-peer protocols such as BGP, this is likely to be 623 relatively easy. First, code that supports automated key management 624 needs to be loaded on both peers. Then the adjacency can be 625 upgraded. The configuration can be updated to switch to automated 626 key management when the second router reboots. 628 The situation is more complicated for multicast protocols. It's 629 probably not reasonable to bring down an entire link to reconfigure 630 it as using automated key management. Two approaches should be 631 considered. One is to support key table rows from the automated key 632 management and manually configured for the same link at the same 633 time. Coordinating this may be tricky. Another possibility is for 634 the automated key management protocol to actually select the same 635 traffic key that is being used manually 637 8. Related Work 639 Discuss draft-housley-saag-*, draft-polk-saag-*, the discussions in 640 the KARP framework, etc. 642 9. Security Considerations 644 This document does not define a protocol. It does discuss the 645 operational and management implications of several security 646 technologies. 648 10. Acknowledgments 650 Funding for Sam Hartman's work on this memo is provided by Huawei. 652 The authors would like to thank Gregory Lebovitz, Russ White and Bill 653 Atwood for valuable reviews. 655 11. References 657 11.1. Normative References 659 [I-D.housley-saag-crypto-key-table] 660 Housley, R. and T. Polk, "Database of Long-Lived Symmetric 661 Cryptographic Keys", 662 draft-housley-saag-crypto-key-table-04 (work in progress), 663 October 2010. 665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 666 Requirement Levels", BCP 14, RFC 2119, March 1997. 668 11.2. Informative References 670 [I-D.ietf-karp-design-guide] 671 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 672 Routing Protocols (KARP) Design Guidelines", 673 draft-ietf-karp-design-guide-07 (work in progress), 674 October 2011. 676 [I-D.liu-ospfv3-automated-keying-req] 677 Liu, Y., "OSPFv3 Automated Group Keying Requirements", 678 draft-liu-ospfv3-automated-keying-req-01 (work in 679 progress), July 2007. 681 [I-D.polk-saag-rtg-auth-keytable] 682 Polk, T. and R. Housley, "Routing Authentication Using A 683 Database of Long-Lived Cryptographic Keys", 684 draft-polk-saag-rtg-auth-keytable-05 (work in progress), 685 November 2010. 687 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 689 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 690 Transport Layer Security (TLS) Protocol in the Session 691 Description Protocol (SDP)", RFC 4572, July 2006. 693 [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", 694 RFC 4808, March 2007. 696 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 697 Authentication Option", RFC 5925, June 2010. 699 Authors' Addresses 701 Sam Hartman 702 Painless Security 704 Email: hartmans-ietf@mit.edu 706 Dacheng Zhang 707 Huawei 709 Email: zhangdacheng@huawei.com