idnits 2.17.1 draft-atwood-karp-akam-rp-03.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 a Security Considerations section. 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 4070 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 1639, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-karp-crypto-key-table-06 == Outdated reference: A later version (-10) exists of draft-ietf-karp-ops-model-05 == Outdated reference: A later version (-06) exists of draft-mahesh-karp-rkmp-04 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 KARP W. Atwood 3 Internet-Draft R. Bangalore Somanatha 4 Intended status: Standards Track Concordia University/CSE 5 Expires: August 29, 2013 February 25, 2013 7 Automatic Key and Adjacency Management for Routing Protocols 8 draft-atwood-karp-akam-rp-03 10 Abstract 12 When tightening the security of the core routing infrastructure, two 13 steps are necessary. The first is to secure the routing protocols' 14 packets on the wire. The second is to ensure that the keying 15 material for the routing protocol exchanges is distributed only to 16 the appropriate routers. This document specifies requirements on 17 that distribution and proposes the use of a set of protocols to 18 achieve those requirements. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 29, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Keying Groups (Key Scopes) . . . . . . . . . . . . . . . . . . 4 57 2.1. Keying Groups . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Key Scopes . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1. Security Goals . . . . . . . . . . . . . . . . . . . . . . 6 61 3.2. Non-security Goals . . . . . . . . . . . . . . . . . . . . 6 62 4. High Level Design . . . . . . . . . . . . . . . . . . . . . . 7 63 4.1. Global View . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.2. Entities in the system . . . . . . . . . . . . . . . . . . 7 65 4.3. Protocol Operations . . . . . . . . . . . . . . . . . . . 9 66 5. Detailed Design . . . . . . . . . . . . . . . . . . . . . . . 10 67 5.1. System Design . . . . . . . . . . . . . . . . . . . . . . 11 68 5.1.1. Communication among the Entities . . . . . . . . . . . 11 69 5.1.2. Inner View of a GM . . . . . . . . . . . . . . . . . . 13 70 5.1.3. Hierarchical Design . . . . . . . . . . . . . . . . . 14 71 5.2. Protocol Design . . . . . . . . . . . . . . . . . . . . . 14 72 5.2.1. Step 1 - Initial Exchanges: GCKS, GM mutual 73 authentication . . . . . . . . . . . . . . . . . . . . 15 74 5.2.2. Step 2 - Key Management Message Exchanges between 75 GCKS, GM . . . . . . . . . . . . . . . . . . . . . . . 16 76 5.2.3. Step 3 - GM-GM mutual authentication . . . . . . . . . 19 77 5.2.4. Step 4 - Key Management Message Exchanges between 78 GMs . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 5.2.5. Variations for handling other Keying Groups . . . . . 22 80 6. Other Aspects of the Key Management Problem . . . . . . . . . 24 81 6.1. Key Updates . . . . . . . . . . . . . . . . . . . . . . . 24 82 6.2. Regular Key Updates . . . . . . . . . . . . . . . . . . . 26 83 6.2.1. Same key for the entire AD . . . . . . . . . . . . . . 26 84 6.2.2. Key per link . . . . . . . . . . . . . . . . . . . . . 26 85 6.2.3. Key per sending router . . . . . . . . . . . . . . . . 27 86 6.2.4. Key per sending router per interface . . . . . . . . . 27 87 6.2.5. Key per peer . . . . . . . . . . . . . . . . . . . . . 27 88 6.3. Router Installation/ Uninstallation . . . . . . . . . . . 27 89 6.3.1. Same key for the entire AD . . . . . . . . . . . . . . 28 90 6.3.2. Key per link . . . . . . . . . . . . . . . . . . . . . 28 91 6.3.3. Key per sending router . . . . . . . . . . . . . . . . 29 92 6.3.4. Key per sending router per interface . . . . . . . . . 29 93 6.3.5. Key per peer . . . . . . . . . . . . . . . . . . . . . 29 94 6.4. Router Reboots . . . . . . . . . . . . . . . . . . . . . . 29 95 6.5. Scalability . . . . . . . . . . . . . . . . . . . . . . . 32 96 6.6. Option to Turn Off Adjacency Management . . . . . . . . . 33 97 6.7. Incremental Deployment . . . . . . . . . . . . . . . . . . 34 98 6.8. Smooth Key Rollover . . . . . . . . . . . . . . . . . . . 34 99 6.9. Eliminating Single Point of Failure . . . . . . . . . . . 35 100 7. An Alternate Mechanism for Transporting the Messages . . . . . 35 101 8. Detailed Packet Formats . . . . . . . . . . . . . . . . . . . 35 102 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 103 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 104 11. Change History (RFC Editor: Delete Before Publishing) . . . . 36 105 12. Needs Work in Next Draft (RFC Editor: Delete Before 106 Publishing) . . . . . . . . . . . . . . . . . . . . . . . . . 36 107 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 108 13.1. Normative References . . . . . . . . . . . . . . . . . . . 37 109 13.2. Informative References . . . . . . . . . . . . . . . . . . 37 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 112 1. Introduction 114 Within the Keying and Authentication for Routing Protocols working 115 group, there are several goals: 117 o Determining how to update the security of existing routing 118 protocols, and guiding this work; 119 o Development of automated mechanisms for management of the keying 120 material. 122 Within the second goal, protocols and procedures for creating shared 123 keys for specific environments have been developed 124 [I-D.hartman-karp-mrkmp][I-D.mahesh-karp-rkmp][I-D.tran-karp-mrmp], 125 under the assumption that the end points of the exchanges (the 126 routers) are entitled to enter into the conversation, i.e., that they 127 can prove that they are who they say they are. However, these 128 documents provide no mechanism to assess or ensure that the end 129 points are entitled to be neighbors. 131 In addition, requirements for an operations and management model are 132 specified in [I-D.ietf-karp-ops-model]. 134 This document addresses this issue of policy distribution for 135 automatic key management and adjacency management in secure routing 136 protocols. In particular, it addresses the need to ensure that 137 keying material is distributed only to routers that legitimately form 138 part of the "neighbor set" of a particular speaking router. 140 1.1. Terminology 142 Autonomous System ... 144 Administrative Domain ... 146 Traffic Encryption Key (TEK) ... 148 2. Keying Groups (Key Scopes) 150 2.1. Keying Groups 152 In an AD, all routers having the same TEK can be referred to as 153 forming a 'keying group'. We can have routers forming a 'keying 154 group' as follows: 156 A group per AD - This is the most coarsely grained category of 157 keying group where all routers in an AD share the same traffic 158 key. Hence the incoming and outgoing keys for protecting 159 control traffic on all routers are the same. This is the case 160 typically in usage today with manual keying. 161 A group per link - Here, all routers sharing a link share the key 162 for that link. The routers could have different keys on their 163 different interfaces, and share them with the other routers 164 connected to those respective links. 165 A group per sending router - This category is more finely grained 166 compared to the previous two cases; each router uses a 167 different key to secure its outgoing control traffic. 168 A group per sending router per interface - This is the most finely 169 grained category wherein each router has a different key for 170 each of its interfaces, which in turn is different from the 171 keys used by other routers to secure their outgoing traffic. 172 A group per peer router - This category is strictly for unicast 173 communication wherein peer routers share keys for their 174 interaction. There is one outgoing key corresponding to each 175 router in every pair of routers. These keys can be 176 established through a unicast key management protocol such as 177 IKE [RFC2409] or IKEv2 [RFC5996]. 179 2.2. Key Scopes 181 Alternatively, keying groups can be viewed from another perspective. 182 Instead of looking at the granularity of keying from the point of 183 view of the members, we can look at it from the point of view of the 184 keys. This can be referred to as 'key scope'. 186 The key scopes corresponding to the above categories of keying groups 187 in the same order could be defined as follows: 189 Same key for the entire AD - all routers in the domain share the 190 same key. 191 Key per link - all routers on a link share the same key. 192 Key per sending router - each router has a different key to secure 193 its outgoing control traffic. 194 Key per sending router per interface - each router uses different 195 keys for each of its interfaces, which in turn are different 196 from the keys used by the other routers for securing their 197 outgoing traffic. 198 Key per peer router - there exist two keys corresponding to every 199 pair of routers. 201 3. Problem Statement 203 The overall aim of this document is to specify an overall system for 204 automated key management, which will eliminate the disadvantages of 205 the manual method of key updating. The basic function of this 206 automated system is to distribute and enforce the key management 207 policies of the administrative domain. In accordance with these 208 policies, secure generation and distribution of keys will be 209 effected. The system will also enable key updates at regular 210 intervals so as to protect against both active intruders and passive 211 intruders who could be eavesdropping the traffic after having gained 212 access to the keys secretly. 214 Along with these basic goals, a key management system should satisfy 215 an additional set of requirements. These requirements ensure among 216 other things, security, easy deployment, robustness and scalability. 217 We have compiled this set after referring to the KARP Design Guide 218 [RFC6518], the KARP Threats and Requirements Guide 219 [I-D.ietf-karp-threats-reqs] and the PIM-SM "security on the wire" 220 specification [RFC5796]. 222 3.1. Security Goals 224 1. Peer authentication for unicast and authentication of all 225 members of the group for multicast protocols. 226 2. Message authentication, which includes data origin 227 authentication and message integrity. 228 3. Protection of the system from replay attacks. 229 4. Peer liveness. 230 5. Secrecy of key management messages. 231 6. Authorization to ensure that only authorized routers get the 232 keys. 233 7. Adjacency management, which implies ensuring the legitimacy of 234 neighbor relationships of each router. Also providing an option 235 to turn off adjacency management if required. 236 8. Ensuring Perfect Forward Security (PFS) and Perfect Backward 237 Security (PBS). 238 9. Resistance to man-in-the-middle attacks. 239 10. Resistance to DoS attacks. 240 11. Usage of strong keys; those that are unpredictable and are of 241 sufficient length. 243 3.2. Non-security Goals 245 1. Ability to handle various categories of keying groups depending 246 on the security level required. 248 2. Possibility for easy and incremental deployment. 249 3. Smooth key rollover. 250 4. Robustness across router reboots. 251 5. Scalable design. 252 6. Single key management architecture accommodating both unicast and 253 multicast systems. 255 4. High Level Design 257 In this section, we propose an architecture for an automated key 258 management and adjacency management system. In order to build this 259 framework, we have reused parts of some existing proposals and fitted 260 them into their correct places in the overall architecture. We have 261 then extended/ modified them so as to handle the key management 262 issues that the previous proposals have assumed to be in place. 264 Our design deals with securing the control traffic of routers within 265 an AD. 267 4.1. Global View 269 The main entities in our system are the following: 271 1. Administrator 272 2. Policy Server 273 3. GCKS 274 4. Standby GCKS 275 5. GMs 277 These entities and their functions are explained in the next section. 279 4.2. Entities in the system 281 The entities are based on those in GSAKMP. The difference is that 282 the Group Owner in GSAKMP has been replaced by a Policy Server, and 283 the Subordinate GC/KS has been replaced by a Standby GCKS in our 284 design. We have chosen the term 'Policy Server' in order to be 285 consistent with RFC 3740 [RFC3740], and the term 'Standby GCKS' since 286 it is not a subordinate in our design and is a standby that is 287 capable of performing all operations performed by the active GCKS. 288 Our design conforms to the Multicast Group Security Architecture 289 [RFC3740]. 291 The network administrator makes configurations for the Policy Server 292 and the GCKS. Security policies go to the policy server, and 293 configurations related to the AD go to the GCKS. 295 Policy Server is the entity that manages security policies for the 296 AD. The behavior of the policy server we describe here draws 297 contents from and is very similar to the 'Group Owner' in GSAKMP. 298 The security policies include general policies such as authorization 299 details for the GCKS, access control for the GMs, rekey intervals, as 300 well as other specific policies that may be necessary for the group. 301 These policies are put together into a 'Policy Token' [RFC4535] and 302 sent to the GCKS. 304 The GCKS is either a router or a server chosen by the administrator 305 as the group controller. It is the entity whose major function is 306 key management and adjacency management. The GCKS should also ensure 307 that the security policies in the policy token are enforced. This 308 implies that whenever a GM requests keys from the GCKS, the GCKS 309 should enforce access control for the GM according to the terms 310 specified in the policy token. The administrator configures the GCKS 311 with information such as the type of keying group to be enforced for 312 the AD and the adjacencies for each router in the AD corresponding to 313 a particular routing protocol (or a set of similar routing 314 protocols). This last point is due to our proposal that there could 315 be one instance of a GCKS per routing protocol or a set of similar 316 routing protocols. This is in fact necessary because GCKS is the 317 entity that should ensure adjacency management, and adjacencies may 318 be defined differently for different routing protocols. Also, 319 according to [I-D.ietf-karp-ops-model] , "KARP must not permit 320 configuration of an inappropriate key scope". This means that each 321 routing protocol could have a different requirement of key scope and 322 that needs to be satisfied. The GCKS may also generate, distribute 323 and update keys, depending on the type of keying group to be enforced 324 in the AD. 326 The standby GCKS is an entity that is always kept in sync with the 327 active GCKS, ready to take over at any time should the active fail. 328 This design eliminates the possibility of a single point of failure 329 in a centralized system. 331 GMs are the group member routers that communicate with each other as 332 well as with the GCKS. When they request keys from the GCKS, they 333 are given the keys along with the policy token. GMs are required to 334 check the rules specified in the policy token to determine if the 335 GCKS is authorized to act in that role. Each GM has a Local Key 336 Server (LKS) [atwo2009:AKM]. It is a key generation and storage 337 entity within the GM. A GM may sometimes be required to generate 338 keys itself depending on the category of keying group being enforced. 339 This kind of design ensures that the architecture is distributed in 340 the sense that key management responsibility is divided between the 341 GCKS and the LKSes. 343 From the description above, it can be seen that the architecture we 344 propose is a balance between a completely centralized model and a 345 completely distributed one, developed by picking the plus points of 346 both types. It defines the concept of a GCKS, which is a centralized 347 entity, as well as the concept of a LKS, which is distributed as 348 being one entity per router. The design tries to bring in the 349 advantages of both models. A centralized entity is considered 350 necessary mainly to make adjacency management possible. In the 351 absence of a central controller that has information about the 352 adjacencies of each router in the AD, individual routers will not be 353 able to establish the legitimacy of their neighbors. Adjacency 354 management is especially important since we are dealing with control 355 packets, which are usually exchanged with immediate neighbors. At 356 the same time, loading the centralized entity with multiple 357 responsibilities may lead to its failure. Hence we have a localized 358 entity that can take up some of the functions of the central 359 controller as and when the need arises. This enhances scalability, 360 which is so important in a key management system. Another factor 361 leading to scalability is the presence of the standby GCKS. A 362 centralized system could have the disadvantage of having a single 363 point of failure. Our design tries to eliminate this by defining a 364 standby for the central controller that is always kept in sync with 365 it, ready to take over at any time. 367 4.3. Protocol Operations 369 The operations of key management and adjacency management occur at 370 two different levels. To ensure scalability of the system, as many 371 operations as possible need to take place among adjacent routers. 372 However, to ensure overall control, policies needs to be set 373 centrally for the entire AD. 375 We recognize two types of groups, which represent the two levels of 376 operation: 378 o a group consisting of the GCKS and all the routers (called group 379 members or GMs); 380 o many small groups, each consisting of a set of adjacent routers. 382 The overall operation proceeds in four steps: 384 1. Establishment of a secure path between each GM and the GCKS. 385 2. Exchange of policy information between each GM and the GCKS. 386 This policy information defines the key management approach and 387 parameters and the adjacency management approach and parameters. 388 3. Establishment of a secure path between pairs of adjacent GMs, 389 where the legitimacy of the adjacency was established in step 2; 391 4. (if required) Exchange or generation of the shared key (and other 392 security parameters) that will be used to protect the routing 393 protocol packets. 395 If the key scope corresponds to "same key for the entire AD", then 396 the key management policy in step 2 could be "use this key", where 397 "this key" is the same for all GMs, and is sent as a parameter along 398 with the policy. In this case, the key generation in step 4 is not 399 necessary. 401 If the key scope corresponds to "key per link", then the key may be 402 mutually determined by the routers on that link, or a "local" GCKS 403 may be elected and assume the task of generating the key, which will 404 then be distributed on the secure paths established in step 3. 406 If the key scope corresponds to "key per sending router" or "key per 407 sending router per interface", then the sending router assumes the 408 responsibility for generating and distributing the key(s) that it 409 will use to send its routing protocol traffic. In the first case, 410 each router maintains (n+1) keys, one for each neighbor, for incoming 411 traffic from that neighbor, and one key for outgoing traffic. In the 412 second case, each router maintains (n+k) keys, where "k" is the 413 number of interfaces. 415 Similarly, if the key scope coresponds to "same key for the entire 416 AD", then the adjacency management policy is probably "accept any 417 router that claims to be your neighbor" or "accept any router that 418 presents a valid router identification string". 420 For other key scopes, the authentication part of step 3 will have to 421 confirm that a match exists between what is presented by the neighbor 422 router and what is specified in the adjacency management policy 423 information. 425 If IPsec is to be used to protect the routing protocol packets, 426 negotiation of the Security Parameter Index (SPI) to be used will be 427 done as part of step 4. This has to be mutually negotiated among the 428 users of a particular key, because it cannot be arbitrarily set by 429 any particular member of the group of adjacent routers. (This is in 430 contrast with a two-party Security Association, where the SPI can be 431 safely set by the (single) receiver of the incoming packets.) 432 However, in the case where a single key is being used for the entire 433 AD, the SPI may be dictated by the GCKS 435 5. Detailed Design 437 This section provides a detailed description of the automated key and 438 adjacency management system. This is followed by the details of the 439 communication among the various entities of the system. 441 5.1. System Design 443 This section provides a detailed description of the architecture, 444 showing also the communication among the different entities. 446 5.1.1. Communication among the Entities 448 Figure 1 gives a closer view of the entities in our design as 449 described previously and shows the interactions among them. 451 ----------------- 452 | Policy Server | 453 ----------------- 454 ^ | 455 Security / | 456 Policies / | 457 / | 458 / | 459 ----------------- | 460 | Administrator | | Security 461 ----------------- | Policies 462 \ | 463 Config- \ | 464 urations \ | 465 \ | 466 v v 467 ----------------- ---------------- 468 | GCKS (Group | Synchronization | Standby GCKS | 469 | Controller |<--------------->| | 470 | Key Server | | | 471 ----------------- ---------------- 472 | | 473 Step 1 | | Step 1 474 followed by | | followed by 475 Step 2 | | Step 2 476 ----------- ---------------- 477 | | 478 | | 479 --------------- --------------- 480 | GM 1 (Group | | GM 2 | 481 | Member) | Step 3 | | 482 | | followed by | | 483 | also hosts | Step 4 | also hosts | 484 | an LKS |<---------------->| an LKS | 485 | (Local Key | | | 486 | Server) | | | 487 --------------- --------------- 489 Figure 1: Communication between the entities 491 Basically there is a centralized GCKS in the system and localized 492 LKS, local to each GM router. The GCKS and the LKS have the ability 493 to generate SA parameters through a KMP, and to store them in a key 494 store. The different scenarios to be considered and the steps of 495 communication are described in this section and the next. 497 5.1.2. Inner View of a GM 499 Figure 2 shows an inner view of a GM with interactions among the KMP, 500 a routing protocol and the LKS. 502 ----------------------- 503 | KMP (Key Management | 504 | Protocol) | 505 ----------------------- 506 ^ | \ - SA parameters related to TEK 507 - request for an | | -------- (Traffic Encryption Key) 508 initial key | | \ 509 - request to change | | v 510 the key (if | | -------------------------- 511 required) | | | LKS (Local Key Server) | 512 | | | | 513 | | | -------------- | 514 | | | | Key Store | | 515 | | - notification | -------------- | 516 | | of new keys -------------------------- 517 | | / 518 | | / - SA parameters related 519 | | ----------- to TEK 520 | | / 521 | v v 522 ------------------- 523 | RP (Routing | 524 | Protocol) | 525 ------------------- 527 Figure 2: Inside view of a GM 529 Initially the routing protocol requests keys from the KMP to secure 530 its control traffic. This starts the communication between the GM 531 and the GCKS through the KMP, as shown by the numbered steps in 532 Figure 1. The key generation policy specified by the GCKS is 533 transferred to the GM. Then the keys are generated by the LKS of the 534 GM, and stored into a key store hosted by the LKS. The KMP notifies 535 the routing protocol that new keys are available for its use as shown 536 in Figure 2. The routing protocol then retrieves the keys from the 537 key store. For some categories of keying groups, the LKS is given 538 the keys directly by the GCKS. For others, it may negotiate the keys 539 with its neighbors. These cases are explored in detail in the 540 sections that follow. 542 The proposed KMP runs between the GCKS and the GMs, and among the GMs 543 themselves. The KMP messages need to be protected, and this can be 544 achieved by running a protocol prior to it to derive keys to protect 545 it. This is similar to the manner in which GDOI messages are 546 protected by keys generated by a phase 1 protocol such as IKE. 548 5.1.3. Hierarchical Design 550 The design we propose is a hierarchical one. There are two kinds of 551 groups that can be formed here (not to be confused with keying 552 groups). The first kind is the one formed by the GCKS with each GM 553 in the AD. The second kind is the one formed among the GMs. The 554 design can be seen as comprised of 5 main steps. The steps together 555 help ensure key and adjacency management in a secure manner. 557 Step 1 - Mutual authentication between the GCKS and each GM in the 558 AD. 559 Step 2 - Communication between the GCKS and each GM in the AD for 560 secure distribution of policies and keys. 561 Step 3 - Inter-GM authentication. 562 Step 4 - Communication among the GMs themselves for key 563 distribution. 564 Step 5 - The actual transfer of routing protocol control packets 565 using the keys derived through the previous four steps. 567 Each step is dependant on the previous ones leading to a hierarchy 568 and ensuring modularity of design. Our design concentrates on steps 569 1 through 4 in order to enable a secure step 5. 571 The details of each of these steps are explained in the next section. 573 5.2. Protocol Design 575 In this section, we give a detailed description of our proposal for a 576 protocol that serves as a solution to the key management problem 577 outlined in Section 3. To summarise, the intention is to develop a 578 protocol for an automated key management system such that all the 579 requirements listed in Section 3 are satisfied. 581 We have seen the set of entities in the proposed design in Section 4. 582 Now we shall see the exact messages exchanged among them so that the 583 keys required for securing routing protocol control traffic can be 584 generated and distributed to the appropriate routers. 586 Initially the administrator configures security rules on the Policy 587 Server, and configuration parameters on the GCKS. The security rules 588 have among other things, access control rules related to GMs, and 589 authorization rules related to the GCKS. The configuration 590 parameters include among other things, the key scope information 591 pertaining to the AD and adjacency information corresponding to each 592 router in the AD. If required, the Policy Server generates other 593 security policies relevant to the group and puts them together into a 594 policy token. This policy token is sent to the GCKS. 596 Once this is done, steps 1, 2, 3 and 4 as outlined in Section 5.1.3 597 follow. Step 1 is for GCKS-GM authentication, step 2 is for key and/ 598 or policy transfer from the GCKS to each GM, step 3 is for GM-GM 599 authentication, and step 4 is for key exchange between GMs that need 600 to communicate with each other. Steps 2 and 4 have small variations 601 depending on the key scope being enforced for the AD. 603 Steps 1 and 2 are based on the GDOI GROUPKEY-PULL protocol [RFC6407]. 604 However, step 2 in our case is an extension of GROUPKEY-PULL in the 605 sense that it accommodates various cases of keying groups and 606 adjacency management as well. Steps 3 and 4 have been designed such 607 that GROUPKEY-PULL has been extended to inter-GM communication. 609 Now we shall look at each of these steps in detail. 611 5.2.1. Step 1 - Initial Exchanges: GCKS, GM mutual authentication 613 Initially, when a routing protocol instance wishes to start 614 communication, be it unicast or multicast communication, it informs 615 the same to the KMP instance on the router. This information is 616 communicated by the KMP instance from that router to the KMP instance 617 on the router or server it believes to be the GCKS. At this point, 618 the GCKS needs the identity of the requesting router in order to 619 authenticate it. The requesting router also has to authenticate the 620 GCKS. Any of the ISAKMP group of unicast protocols could be used for 621 step 1 communication between the GCKS and each router that requests 622 keys from it. IKE/ IKEv2 is an example of such a protocol. This 623 protocol provides peer authentication, and parameters for an SA 624 including a key to help provide confidentiality and message integrity 625 for the next step where the actual traffic keys would be generated. 626 We call the key derived in this phase as SKEYID_a (term taken from 627 GDOI). It is assumed that the routers have agreed upon a way to 628 establish their identity during authentication, either through pre- 629 shared keys, asymmetric keys or certificates. If peer authentication 630 is successful, the router becomes a GM. 632 As already mentioned, GM stands for 'Group Member'. When talking 633 about the GCKS-GM interactions, 'group' typically means the entire 634 set of GMs in the AD. When talking about the GM-GM interactions, 635 'group' typically means the sending router and some set of its 636 neighbors. This set may include all of its neighbors or only a 637 subset, depending on the key scope in use. For example, when the key 638 scope is per link, a 'group' may refer to all routers sharing a link. 639 This will become evident as we see the GM-GM interactions shortly. 641 5.2.1.1. Message Exchanges for Step 1 643 The protocol message exchanges for this step are the standard IKE 644 exchanges since we propose using IKE for this step. We would like to 645 mention at this point that whenever we say IKE, we intend to refer to 646 IKE or IKEv2, unless explicitly stated otherwise. 648 5.2.2. Step 2 - Key Management Message Exchanges between GCKS, GM 650 This is the step where the KMP takes over. The goal of the KMP is to 651 provide parameters for an SA to be eventually used by a routing 652 protocol to secure its control traffic. 654 Messages in this step are secured by the key generated by the step 1 655 protocol, that is, SKEYID_a. This key helps achieve authentication 656 and confidentiality for step 2. For step 2, we have taken most of 657 the messages from GROUPKEY-PULL protocol of GDOI. However, there are 658 some modifications and important addition of functionality in our 659 case, with the GCKS passing additional information to the GMs. We 660 shall see this in this section. 662 We shall initially look at the KMP details for one of the finely 663 grained cases of keying groups, namely, the group per sending router. 664 This is a flavor of multicast communication. Soon after this we will 665 see the small variations necessary in order to handle the other 666 categories of keying groups. 668 In step 2, the (each) GM makes requests from the GCKS through the KMP 669 for SA parameters required to secure its control traffic. In the 670 request to the GCKS, the GM specifies the identity of the routing 671 protocol for which it needs the keys. Although the GCKS 672 corresponding to the routing protocol would have already been 673 selected in step 1, specifying the routing protocol id again here 674 helps to handle the case where the same GCKS may be used for a 675 category of similar routing protocols. 677 When the GCKS receives this request from the GM, it checks to verify 678 if the GM can be given access to key related information according to 679 the rules in the policy token. If the checks fail, the communication 680 with the GM should not be continued. The exact behavior can be 681 determined from the rules in the policy token. If the checks 682 succeed, the GCKS delivers to the GM the following information: 684 o SA policy corresponding to the TEK. This could include the actual 685 SA parameters as well depending on the category of keying group 686 being enforced. The TEK is the traffic key whose scope could be 687 anything among those described under key scopes in Section 2. The 688 SA policy includes policy information about SA parameters. This 689 could include information pertaining to the algorithms, the TEK, 690 the SPI and other parameters. For the category of keying group 691 being discussed now, that is, the key per sending router, the 692 exact TEK and SA parameters are not delivered by the GCKS to the 693 GM. Only rules pertaining to their generation are handed down. 694 The actual SA parameters are generated by the GM itself soon after 695 step 2 so that the GCKS is not overloaded. 696 o A certificate signed with the private key of the GCKS. This is to 697 be used by the GM for authentication purposes when it communicates 698 with neighboring GMs and with the GCKS for any SA updates in 699 future. 700 o The policy token information received by the GCKS from the Policy 701 Server. As already mentioned, this includes authorization and 702 access control related information. This is read by the GM in 703 order to authorize the GCKS and verify if it is entitled to 704 perform the role of GCKS. 705 o The key scope being enforced in the AD. This configuration is 706 made by the administrator on the GCKS and is pushed to the GM. 707 This is necessary so that the GM knows whether to expect the 708 traffic keys from the GCKS, or whether it needs to generate them 709 itself. 710 o The adjacency information, which includes details of all 711 legitimate neighbors on all interfaces of the GM and not only the 712 neighbors online at that point of time. This is in order to avoid 713 a DoS attack on the GCKS that could result if the GMs started 714 querying the GCKS for every router coming up, especially during 715 the boot up sequence, to know if it is a legitimate neighbor. 716 Also, this ensures completeness of information. It even helps 717 eliminate spoofing attacks where a legitimate neighbor may appear 718 on an interface other than the one it was supposed to appear on. 719 The adjacency information is used by the GM to know the set of 720 authorized neighbors with which it should communicate during steps 721 3 and 4. 723 5.2.2.1. Message Exchanges for Step 2 725 The protocol message exchanges for step 2 are shown in Figure 3. 727 GM->GCKS: HDR*, HASH(1), Ni, RP_ID (1) 728 GCKS->GM: HDR*, HASH(2), Nr, SA, CERT, K_SCOPE, PT, ADJ (2) 729 GM->GCKS: HDR*, HASH(3) (3) 731 Figure 3: Message exchanges for Step 2 733 In the message exchanges, HDR is an ISAKMP header payload. It has a 734 message id M-ID. The '*' indicates that the message contents 735 following the header are encrypted. The encryption is done with 736 SKEYID_a. This ensures authentication (since the key is a secret 737 generated in step 1 and can be possessed only by the GCKS and the GM 738 with which the step 1 has been carried out) as well as secrecy (due 739 to the encryption). Hashes are used for ensuring message integrity 740 and data origin authentication; this will be explained shortly. 742 In exchange (1), the GM requests SA information from the GCKS to 743 protect its control traffic corresponding to the routing protocol 744 whose id is given by RP_ID. Ni is a nonce used to protect against 745 replay attacks as well as to ensure liveness of the GM. 747 In exchange (2), the GCKS initially confirms from the rules in the 748 policy token that the GM can be given SA information. It also 749 verifies the freshness of the nonce Ni. If this is successful, the 750 GCKS proceeds to deliver to the GM the following information: 752 o SA policy corresponding to the TEK - through the parameter SA 753 o A signed certificate - CERT 754 o Key Scope - K_SCOPE 755 o Policy token - PT 756 o Adjacency information - ADJ 758 The details of these pieces of information have already been 759 explained. Nr is a nonce used for replay protection and to ensure 760 liveness of the GCKS. 762 In exchange (3), the GM initially verifies freshness of the nonce Nr 763 so as to detect a replay attack. It then proceeds to confirm the 764 authorization of the GCKS by referring to the policy token. If the 765 GCKS is an authorized entity, the GM uses the key scope information 766 to know how to proceed with respect to key generation. The adjacency 767 list is used to note the list of legitimate neighbors and the allowed 768 interfaces on which they can appear online. Once this is done, the 769 GM sends an acknowledgement. This acknowledgement includes a hash 770 for integrity purposes. If the GCKS is not authorized, the GM needs 771 to end the communication with the GCKS. The behavior in such cases 772 can be determined by the policies specified in the policy token. 774 The hashes are pseudorandom functions (prf) computed as shown in 775 Figure 4. 777 HASH(1) = prf(SKEYID_a, M-ID | Ni | RP_ID) 778 HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA | CERT | K_SCOPE | 779 PT | ADJ) 780 HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b) 782 Figure 4: Hashes used in Step 2 784 According to [RFC6407], "Each HASH calculation is a pseudo-random 785 function ("prf") over the message ID (M-ID) from the ISAKMP header 786 concatenated with the entire message that follows the hash including 787 all payload headers, but excluding any padding added for encryption." 788 SKEYID_a is included in the hashes to ensure that both parties have 789 the step 1 key. The hashes include the nonces from previous messages 790 to ensure that both the parties have the exchanged nonces. This is 791 used for data origin authentication purposes. Hence Ni_b and Nr_b 792 refer to Ni and Nr from exchanges (1) and (2) respectively. 794 An important function of hashes is to provide message integrity. The 795 receiver computes the hash of the received message and compares it 796 with the hash value received to determine whether the message has 797 been tampered with or not. 799 Once the GM has received this information, it generates the TEK and 800 determines the parameters to be used for its outgoing SA. Here the 801 functionality of the LKS of the GM as a generator of keys comes into 802 play. Since the key scope being discussed now is one key per sending 803 router, the LKS of each GM generates one TEK. The key generation is 804 to be followed by key information exchange with legitimate neighbors 805 so that the incoming SAs can be determined. It is to be noted that 806 this key generation can even be done at the beginning of step 4 once 807 the inter-GM mutual authentication has happened in step 3. 809 5.2.3. Step 3 - GM-GM mutual authentication 811 After the GM generates TEK based information, before exchanging it 812 with its neighbors, it needs to ensure that a secure TEK exchange can 813 take place. This is done in step 3 by each GM engaging in a unicast 814 communication with each of its legitimate neighbors through any of 815 the ISAKMP group of unicast key management protocols, such as IKE. 816 This protocol provides peer authentication as well as a secret key to 817 provide confidentiality, authentication and message integrity for 818 step 4, which is the actual TEK exchange step. We call this secret 819 key as SKEYID_b. The legitimate neighbors are determined by 820 referring to the adjacency information given by the GCKS to the GM in 821 step 2. During peer authentication in step 3, the certificate given 822 to the GM by the GCKS could be used. 824 5.2.3.1. Message Exchanges for Step 3 826 The protocol message exchanges for this step are the standard IKE 827 exchanges since we propose using IKE for this step. 829 5.2.4. Step 4 - Key Management Message Exchanges between GMs 831 This is the step where the TEK information is exchanged between GMs 832 that need to communicate with each other. Unicast communication is 833 anyway between two peers. For multicast communication, since we are 834 dealing with control traffic only, and control traffic is typically 835 link-local, each router on a link needs to be aware of the TEK of all 836 other routers on the same link. These legitimate neighbors are 837 determined from the adjacency information received from the GCKS. 838 The LKS of the corresponding GMs communicate to exchange their TEK 839 information in order to help them populate their incoming and 840 outgoing SAs. 842 Messages in this step are secured by the key generated by the step 3 843 protocol, that is, SKEYID_b. This key helps provide authentication 844 as well as confidentiality. 846 In step 4, the LKS of the GM pushes the SA information corresponding 847 to its TEK to each of its neighbors. The LKS also requests TEK 848 information from its neighbors. Each of the neighbors then sends its 849 outgoing TEK information and this is maintained as an incoming key on 850 the querying LKS. As a result of step 4, all GMs have the TEK 851 information corresponding to all their neighbors so that a secure 852 control traffic exchange can start. 854 5.2.4.1. Message Exchanges for Step 4 856 The message exchanges for Step 4 are shown in Figure 5. 858 GMi->GMr: HDR*, HASH(4), N1, CERT1 (4) 859 GMr->GMi: HDR*, HASH(5), N2, CERT2 (5) 860 GMi->GMr: HDR*, HASH(6), SA1, KD1, KREQ (6) 861 GMr->GMi: HDR*, HASH(7), SA2, KD2 (7) 863 Figure 5: Message exchanges for Step 4 865 GMi and GMr depict the initiator and the responder GMs respectively. 867 The message exchanges in this step are similar to those in step 2 in 868 that the HDR is an ISAKMP header payload with a message id M-ID. The 869 '*' indicates that the message contents following the header are 870 encrypted. The encryption is now done with the key SKEYID_b derived 871 in step 3. This ensures both authentication and secrecy. Hashes are 872 used for ensuring message integrity and data origin authentication. 873 Nonces are used to resist replay attacks and to ensure peer liveness. 875 In exchanges (4) and (5), we show mutual authentication between GMs 876 through the certificates received from the GCKS in step 2. CERT1 is 877 the certificate received by GMi and CERT2 is the one received by GMr 878 from the GCKS. Authentication would have happened in step 3 so 879 exchanges (4) and (5) can be eliminated. They have been shown here 880 for the sake of completeness. 882 In exchange (6), the initiator GM communicates to its neighbor its 883 outgoing SA parameters in SA1 as well as the outgoing TEK information 884 explicitly in KD1. This is the TEK that it will be using henceforth 885 to secure its control packets. It also requests the outgoing SA 886 information from the neighboring GM so that it can be installed as 887 incoming SA information on the querying GM. This request is 888 represented by KREQ, which stands for Key Request. 890 In exchange (7), the neighboring GM responds with its outgoing SA 891 information in SA2 as well as the TEK in KD2. This will be the TEK 892 the neighboring GM will use henceforth to secure its control packets. 894 As already mentioned, the nonces N1 and N2 help provide replay 895 protection and a confirmation that the peer is alive. 897 The hashes are pseudorandom functions computed as shown in Figure 6. 899 HASH(4) = prf(SKEYID_b, M-ID | N1 | CERT1) 900 HASH(5) = prf(SKEYID_b, M-ID | N1_b | N2 | CERT2) 901 HASH(6) = prf(SKEYID_b, M-ID | N1_b | N2_b | SA1 | KD1 | KREQ) 902 HASH(7) = prf(SKEYID_b, M-ID | N1_b | N2_b | SA2 | KD2) 904 Figure 6: Hashes used in Step 4 906 Hash computation is similar to that explained in step 2. In step 4 907 hashes are computed by applying a pseudorandom function to the key 908 SKEYID_b, along with the message id concatenated with the message 909 contents following the hash. Also, nonces from a message exchange 910 are included in the hash computation of the subsequent exchanges in 911 order to ensure that both parties have the nonces just exchanged. 912 This helps in data origin authentication. Hence N1_b and N2_b refer 913 to N1 and N2 in exchanges (4) and (5) respectively. Hashes are very 914 essential to ensure message integrity and to confirm that the 915 messages have not been modified (possibly by an intruder) during 916 transit. 918 All information received by the LKS of a GM from the GCKS as well as 919 from neighboring LKSes is written to stable storage persistent across 920 reboots. This can be effectively used to avoid flooding the GCKS 921 with requests on a router reboot. This is one of the advantages of 922 the proposed design over GDOI [RFC6407], where, when routers reboot 923 they come back up with no information and the GCKS is flooded with 924 requests. The routing protocol is notified by the KMP about the new 925 SA being available in the key table for it to protect its control 926 traffic. 928 The routing protocol security mechanism would store the incoming and 929 outgoing SA information, and the adjacency information into the 930 relevant databases. 932 As we can see, confidentiality and authentication has been ensured 933 for all steps by means of secret keys and certificates. 935 In the following section, we shall see the small variations required 936 in the basic protocol design proposed above, in order to handle the 937 various categories of keying groups. 939 5.2.5. Variations for handling other Keying Groups 941 We have seen the different granularities possible for a keying group, 942 that is, the different key scopes, in Section 2. We have also seen 943 that the design proposed in Section 5.2 is able to handle the keying 944 group where there is a separate key per sending router. This has 945 been achieved by each router generating its own key, which would be 946 the same for all its interfaces. Hence each router has a different 947 SA for outgoing traffic and multiple SAs for incoming traffic, one 948 corresponding to each neighbor. It is to be noted here that the key 949 generation being done locally could have a small possibility of two 950 routers ending up with the same key when they generate it randomly. 951 However, if a good random number generator is used for key 952 generation, the probability of ending up with the same key is 953 drastically reduced. This extremely small possibility can be ignored 954 since the method more importantly has the advantages that it reduces 955 the load on the GCKS. Also the GCKS does not have the need to be 956 aware of the individual keys of each router. This could be 957 considered as a case of tradeoff. 959 In this section, we shall see how the remaining cases of keying 960 groups can be handled. They can actually be handled by minor 961 variations to the basic design. In essence, these variations can be 962 implemented by the GM interpreting the key scope information given to 963 it by the GCKS in step 2, and thereby knowing whether to expect keys 964 from the GCKS or to derive them itself. This also makes the GM aware 965 of the path to be followed. As we shall see, in a majority of cases 966 it is step 4 that gets slightly altered. 968 Same key for the entire AD - Let us take the most coarsely grained 969 case, namely, a keying group per AD. Since all routers have 970 to share the same key (TEK), the centralized GCKS is the one 971 that should generate it. Every GM gets the TEK and other SA 972 parameters directly from the GCKS in step 2. The TEK 973 information received from the GCKS can be stored as both the 974 outgoing as well as the incoming key since all GMs share the 975 same key. Therefore, step 4 can be eliminated. However, step 976 3, which involves GMs authenticating neighboring GMs is 977 necessary before the GMs can start exchanging control packets. 979 In essence, this variation of key scope can be implemented by 980 the GM interpreting the key scope information given to it from 981 the GCKS in step 2, and thereby knowing that it should expect 982 the TEK from the GCKS (TEK is also received in the same step). 983 Key per link - This is another flavor of keying groups wherein 984 there exists a TEK per link, that is, a key is shared by all 985 routers sharing a link. This can be handled in a manner 986 similar to the single key per router case described as far as 987 steps 1, 2 and 3 are concerned. However, there is a slight 988 variation required in step 4. Previously, the LKS of each GM 989 generated a single key to be used on all interfaces of the GM. 990 However in this case, an LKS needs to generate as many TEKs as 991 the number of its interfaces by interacting with the neighbors 992 on the respective links. This is done by GMs on a link 993 interacting to derive a TEK and other SA parameters through 994 any of the mutual key agreement protocols. Some examples of 995 protocols that could be used for this purpose are MRKMP 996 [I-D.hartman-karp-mrkmp], group Diffie-Hellman, and the STS 997 protocol. Since MRKMP specifies how keys can be generated and 998 distributed on a LAN by electing a GCKS, it can be used for 999 TEK generation for the case where the key scope is per link. 1000 The TEK and the other SA parameters generated are stored by 1001 all LKSes sharing the link as the outgoing and incoming 1002 parameters on that particular link. This procedure is 1003 repeated by all GMs for all their links in turn. 1004 Key per sending router per interface - The only difference here 1005 when compared to the separate key per router case is that in 1006 that case, each GM generates a single TEK to be used on all of 1007 its interfaces, whereas, here each GM generates a different 1008 TEK for each of its interfaces. In step 4, it gives each 1009 neighbor the TEK that it plans to use on the connecting link 1010 between them. 1011 Key per peer - This is the last category of keying groups. This 1012 refers to unicast communication where peer routers exchange 1013 control packets. Here the SA parameters corresponding to the 1014 traffic key TEK and the TEK itself can be generated using a 1015 unicast key management protocol such as IKE or even KMPRP. 1016 However, an important point to note here is that adjacency 1017 management is necessary even for this case since routers 1018 should exchange keys only with legitimate neighbors. This can 1019 be achieved only by having a central authority that is aware 1020 of all valid adjacencies. Our design handles this. Steps 1, 1021 2 and 3 of the design are sufficient. The key derived in step 1022 3, namely, SKEYID_b serves as the TEK. 1024 We have mentioned that the SA parameters along with the TEK are 1025 either delivered to the GMs by the GCKS (for the single key per AD 1026 case) or generated by the GMs themselves, possibly through 1027 interactions with other GMs (for the other keying groups, depending 1028 on the particular category). A parameter that could have a slightly 1029 different behavior is the SPI. This is also one of the parameters of 1030 an SA. However the range of SPIs to be used in an AD could be 1031 decided by the administrator. Whatever be the category of keying 1032 group, it could so happen that the administrator chooses to have the 1033 same SPI for all GMs. In this case, the GCKS could deliver the SPI 1034 to the GMs along with the policy for the remaining parameters of the 1035 SA. It could also be that the administrator wants each GM to use a 1036 different SPI for its outgoing traffic. In this case, the GCKS 1037 should not be overloaded with the task of generating a different SPI 1038 for each GM. GMs should generate the SPI themselves, possibly with 1039 communication with other GMs. If that happens, even for the single 1040 key per AD category of keying groups, the SPI is generated by the 1041 GMs, although the TEK may be obtained from the GCKS (since the TEK is 1042 to be the same for all GMs for this category of key scope). In other 1043 words, the key scope may be different from the scope of the SPI used 1044 in the AD. Our design is flexible enough to handle this since the SA 1045 policy handed down by the GCKS to the GMs would indicate to the GM 1046 the exact steps to be followed. 1048 In all cases of keying groups, the LKS stores SA information to 1049 persistent storage to be used across reboots. Keys are stored into 1050 the key table [I-D.ietf-karp-crypto-key-table] and the KMP informs 1051 the same to the routing protocol, which would start using the keys to 1052 secure its control traffic. This is the step 5 mentioned in the 1053 explanation of the concept of hierarchical design in Section 5.1.3. 1055 6. Other Aspects of the Key Management Problem 1057 In this section, we address some of the other important aspects of 1058 the key management problem. Firstly we show how this automated 1059 system allows key updates to be done as frequently as desired. Soon 1060 after that, we show how various good-to-have features have been 1061 incorporated in the proposed design. Some of these features are 1062 scalability, incremental deployment ability, effective handling of 1063 router reboots and smooth key rollover. Addition of these features 1064 would help in achieving the requirements stated in Section 3. 1066 6.1. Key Updates 1068 Keys used by the routing protocols to secure their traffic need to be 1069 updated at regular intervals. They may have to be updated at other 1070 non-specific times as well depending on the requirement. There are a 1071 couple of reasons why key updates are required: 1073 o As a good practice in order to protect against passive intruders 1074 who could have obtained access to the keys and could be 1075 eavesdropping the traffic. 1076 o Whenever a new member comes up on a link, in order to ensure PBS. 1077 This means that the new member should not be able to get access to 1078 keys currently being used on the link since that could mean that 1079 the member can comprehend old messages exchanged on the link when 1080 it was not part of it. 1081 o Whenever a member leaves, in order to ensure PFS. This means that 1082 going forward, even if the old member manages to get hold of 1083 messages exchanged among the remaining members on the same link, 1084 it should not be able to comprehend them. 1086 One of the important points to be noted here is that PFS and PBS can 1087 be achieved very easily and in a straight forward way for unicast 1088 communication. Unicast communication involves a pair of routers that 1089 share keys for securing their traffic. Every pair of routers derives 1090 its own set of keys and those keys are known only to that particular 1091 pair of routers. Hence a change in any one of the members of the 1092 pair of routers would mean that the old keys are no longer valid and 1093 new keys are derived for communication. This automatically takes 1094 care of PFS and PBS. When a router, say R1, is uninstalled, the keys 1095 used by the other routers for pairwise (unicast) communication with 1096 R1 are no longer used. This ensures PFS. When a new router, say R2, 1097 is installed, all routers engaging in a unicast communication with it 1098 derive new pairwise keys with it. This ensures PBS. 1100 For multicast communication, key updates are essential on a router 1101 uninstallation or an installation to ensure PFS and PBS respectively. 1102 This is because in multicast communication, multiple routers share 1103 the same key and a key remains valid even if one of the routers 1104 involved in the communication is changed. To achieve PFS and PBS, 1105 keys have to be updated so that the leaving or entering routers do 1106 not have access to information they are not entitled to. 1108 We now have to determine what are the keys that need to be updated. 1109 For regular updates, it is quite obvious that the traffic keys of all 1110 the routers would have to be changed. The other case to consider is 1111 when the routers in an AD change, either due to an installation or an 1112 uninstallation. It is interesting to note that when the same traffic 1113 key is used for the entire AD, that key should be changed, leading to 1114 the effect of changing the keys for all the routers. However, for 1115 all other key scopes, only the keys corresponding to the neighbors of 1116 the leaving/ entering router need to be changed. This is because as 1117 far as control traffic is concerned, routers have knowledge of the 1118 keys of their neighbors only. Of course the adjacencies and hence 1119 the neighbors, may be defined differently for the various routing 1120 protocols. 1122 One of the major problems with the manual method of key management is 1123 that keys cannot be updated as frequently as desired. This is due to 1124 the lack of authorized people to carry out the task. This issue can 1125 be easily overcome by an automated key management system. Let us see 1126 how these two cases of regular rekey and a rekey on a router 1127 installation/ uninstallation can be handled by the automated key 1128 management system we propose. 1130 6.2. Regular Key Updates 1132 In this section, we discuss how our design for automated key 1133 management aids key updates at regular intervals. The interval at 1134 which key updates are to be done is determined from the policies 1135 handed down by the Policy Server entity described in Section 4.2. 1136 These policies are handed down by the Policy Server to the GCKS in 1137 the form of a policy token, which in turn is handed down by the GCKS 1138 to the GMs in Step 2 of the protocol as explained in Section 5.2. We 1139 now need to see how key updates for all variations of keying groups 1140 can be addressed. As we shall see, when all routers in the AD share 1141 the same traffic key, the centralized GCKS is the generator of the 1142 new key, whereas in all other cases, the GMs generate the new keys 1143 appropriately. This is in fact similar to the process of initial key 1144 generation described in Section 5.2. 1146 6.2.1. Same key for the entire AD 1148 First, let us take the case of having a single key for the entire AD. 1149 Here, when a rekey is required, the GCKS generates the new traffic 1150 key and unicasts it to each individual GM. This ensures that all GMs 1151 share the same new TEK after the rekey. As an alternative to 1152 transferring the new TEK through unicast communication, the GCKS and 1153 all GMs in the AD could share a key called a 'TEK Encryption Key'. 1154 This key could be used by the GCKS for encrypting the new TEK 1155 derived, and multicasting to all GMs. The advantage of this approach 1156 over the unicast method is that it eliminates the need to have 1157 multiple key update messages sent out by the GCKS, one corresponding 1158 to each GM. This in turn reduces the network traffic. However, the 1159 downside to the multicast approach is the overhead of maintaining a 1160 group key (and appropriately updating it) just for the rekey 1161 purposes. This is a case of tradeoff. 1163 6.2.2. Key per link 1165 In this category of keying group, routers sharing a link also share 1166 the traffic key for that link. Here when a TEK update is required, 1167 GMs on a link execute one of the key agreement protocols such as 1168 MRKMP, group Diffie-Hellman or the STS protocol to derive a new TEK. 1169 This is similar to the manner in which they interact to derive the 1170 initial TEK for the link. The interval after which the TEK should be 1171 changed is of course determined from the policy token. 1173 6.2.3. Key per sending router 1175 In this case, every router has a different TEK that it uses for 1176 securing its control traffic. When a rekey is required, each GM 1177 generates a new TEK individually and then communicates the same to 1178 all its neighbors. The neighbors update the incoming TEK information 1179 corresponding to that router in their databases. 1181 6.2.4. Key per sending router per interface 1183 This case is very similar to the previous one. The only difference 1184 is that here, each GM generates as many new TEKs as the number of its 1185 interfaces, one per interface. The GM then communicates to each of 1186 its neighbors the TEK it plans to use on the interface corresponding 1187 to that particular neighbor. 1189 6.2.5. Key per peer 1191 This is the unicast case. Keys can be updated just by every pair of 1192 routers executing a unicast key management protocol such as IKE. 1194 In all the above cases, the LKS updates the key store as well as its 1195 persistent storage with the updated key information. The KMP 1196 notifies the routing protocol of a change in the keys used to secure 1197 the control traffic. 1199 6.3. Router Installation/ Uninstallation 1201 Along with the regular key updates, keys need to be updated even when 1202 an existing router is uninstalled or a new router is installed. 1203 These are for PFS and PBS purposes respectively as already explained 1204 in Section 6.1. There are a couple of differences between key 1205 updates in these cases when compared with the regular key updates. 1207 o Regular traffic key updates require that the traffic keys 1208 corresponding to all routers in the AD be updated. However, key 1209 updates on a router removal or addition require only the keys 1210 corresponding to the neighbors of the leaving or entering router 1211 to be changed. This is because routers have knowledge of the keys 1212 corresponding to their neighbors only as far as control traffic is 1213 concerned. But if it so happens that the same traffic key is 1214 being used for all routers in the AD, then a change in the key 1215 automatically implies that the key gets changed for all the 1216 routers. 1218 o Regular key updates are done at intervals determined from the 1219 policy token given by the Policy Server. However, key updates on 1220 a router removal or addition are done based on instructions given 1221 by the GCKS in such a situation. This is because routers in the 1222 AD (other than the GCKS) would not be aware of the fact that a 1223 particular router is either installed or uninstalled. 1225 Apart from these differences, the process of key updates during a 1226 router change is very similar to the regular key updates. We shall 1227 now discuss briefly how key updates on a router change can be handled 1228 for each of the categories of keying groups. 1230 6.3.1. Same key for the entire AD 1232 For this category of key scope, the same traffic key is shared by all 1233 routers in the AD. When a router is removed or a new router is 1234 installed, the GCKS derives a new TEK and unicasts it to each of the 1235 routers in the AD. 1237 As an alternative to transferring the new key through unicast method, 1238 the GCKS and all GMs could share a key called the 'TEK Encryption 1239 Key'. If this option is followed, first of all, the TEK Encryption 1240 Key would have to be changed on a router change. Then for the case 1241 of router installation, the GCKS multicasts the new TEK Encryption 1242 Key, encrypted in the old key to all existing routers. It then 1243 unicasts the new TEK Encryption Key to the newly installed router. 1244 After this, the GCKS derives a new TEK and multicasts it to all the 1245 routers after encrypting it in the new TEK Encryption Key. This can 1246 be decoded by the new router as well since it now possesses the 1247 latest TEK Encryption Key. For the case of router uninstallation, the 1248 GCKS changes the TEK Encryption Key and unicasts it to all the 1249 remaining routers. The new TEK Encryption Key cannot be multicast in 1250 this case since the old router would also be able to decrypt it. 1251 Changing of the TEK would be the same as for router installation. 1252 The new TEK is sent in a multicast message to all routers encrypted 1253 in the new TEK Encryption Key. 1255 When compared with the unicast method of key updates, this multicast 1256 method has the advantage of low bandwidth consumption. However the 1257 disadvantage of the multicast method is that an extra key, the TEK 1258 Encryption Key, now needs to be maintained and updated accurately. 1259 So the exact method chosen depends on the administrator. 1261 6.3.2. Key per link 1263 For this case, on a router installation or an uninstallation, the 1264 GCKS informs the neighbors of that router. These routers interact 1265 with each other (and with the new router if it is a case of router 1266 installation) and derive a new traffic key for that particular link 1267 where the neighbor change has occurred. Any of the mutual key 1268 agreement protocols such as MRKMP, group Diffie-Hellman or the STS 1269 protocol can be used. 1271 6.3.3. Key per sending router 1273 Here again the GCKS appropriately informs the neighbors of the 1274 affected router. Each such neighbor runs a randomized key generation 1275 algorithm to derive a new traffic key and communicates the key to its 1276 neighbors. This is very similar to the case of regular key updates. 1278 6.3.4. Key per sending router per interface 1280 This category of keying group can also be handled in an easy manner. 1281 The GCKS informs the neighbors of the affected router. Each such 1282 router derives a new traffic key for that interface on which the 1283 neighbor change has occurred. The router then communicates the new 1284 key to its new set of neighbors on that particular interface. 1286 6.3.5. Key per peer 1288 As already explained, key updates on a router change are not valid 1289 for unicast communication. This is because in unicast communication, 1290 a key is shared by only two routers. A router addition or a removal 1291 results in a change in a particular pair (or pairs) of routers. 1292 Hence new keys are anyway derived to be shared by the new pair. Thus 1293 this can be considered as an automatic update of keys without any 1294 explicit processing. 1296 6.4. Router Reboots 1298 Router reboots form a very important case to be considered in any 1299 design pertaining to networks. Especially in a centralized 1300 architecture, care should be taken to prevent the central entity from 1301 being stormed with requests when multiple routers happen to reboot 1302 almost simultaneously. In our architecture, it is the persistent 1303 storage of the distributed LKS that plays a major role on a router 1304 reboot. As already seen the LKS of each GM writes to persistent 1305 storage some configuration and policy information such as the key 1306 scope, adjacencies, SAs, the traffic keys corresponding to itself and 1307 its neighbors, certificate received from the GCKS, and the policy 1308 token. Hence on a GM reboot, the LKS retrieves information from the 1309 persistent storage. This is an extremely important feature since it 1310 avoids the GCKS being flooded with requests for information when 1311 multiple routers in the AD happen to reboot. 1313 However, information retrieval from the persistent storage may not 1314 always be sufficient. Occasionally a rekey could have happened when 1315 a router was down. This could have been either a regular rekey or a 1316 rekey due to a router installation or removal. These cases should be 1317 dealt with in an appropriate manner so as to ensure that the rebooted 1318 router gets the latest SA and adjacency information. 1320 In order to handle these cases, a router needs to query its neighbors 1321 on a reboot. This is done as soon as the router has rebooted and 1322 read the relevant information from its persistent store. The 1323 neighbors communicate their traffic key and SA information to the 1324 rebooted router. Depending on this information as well as the key 1325 scope information retrieved from the persistent storage, the rebooted 1326 router can handle a rekey appropriately. This interaction with the 1327 neighbors for the different cases of key scopes is explained below: 1329 Same key for the entire AD - To handle this case, a router gets the 1330 TEK related information initially from one of its neighbors. 1331 It compares this key with the key corresponding to that 1332 neighbor (which is the same as its own key since the same key 1333 is shared by all routers in the AD) as retrieved from the 1334 persistent storage. If the two keys match, then it is evident 1335 that no rekey has happened on the neighbor. Since the key 1336 scope is such that the same key is used for the entire AD, it 1337 can be concluded that there has been no rekey in the AD. 1338 Hence the rebooted router need not do anything else. If the 1339 keys are in mismatch, the rebooted router concludes that a 1340 rekey has happened in the AD, either due to a regular key 1341 update or due to a key update based on a router change. In 1342 either case, the router changes its outgoing traffic key to be 1343 the same as the new one got from its neighbor. This helps 1344 maintain consistency of all traffic keys across the AD. 1345 Key per link - For this case, the rebooted router queries its 1346 neighbors in turn, one neighbor on each of its links. Again 1347 it compares the traffic key received from its neighbor with 1348 the corresponding information retrieved from its persistent 1349 store. If the two keys match, it means that there has been no 1350 rekey on that link. If the keys are in mismatch, it means 1351 that a rekey has happened on the link. The rebooted router 1352 then changes its own outgoing traffic key on that link to be 1353 the same as the new key got from the neighbor. In either 1354 case, the router proceeds with querying its neighbors on its 1355 remaining links. This is different from the previous case 1356 where a single key was used by all routers in the AD. This is 1357 because in the key per link case, determining whether a rekey 1358 has happened on a particular link does not help determine the 1359 status on other links. Hence at least one neighbor on each 1360 link has to be queried. 1362 Key per sending router - For this case, the rebooted router starts 1363 by querying one neighbor on each of its interfaces. If the 1364 traffic keys of all the queried neighbors are the same as the 1365 corresponding keys retrieved from the persistent storage of 1366 the rebooted router, there is nothing to be done. If there is 1367 at least one neighbor whose key has changed, the rebooted 1368 router changes its own key and communicates it to its 1369 neighbors. The rebooted router can stop querying its 1370 neighbors at this point. An interesting observation here is 1371 that a neighbor's key could have changed either due to a 1372 regular rekey or due to an installation/ uninstallation of its 1373 neighboring router. This neighboring router may or may not be 1374 a common neighbor to the rebooted router. Since the exact 1375 situation cannot be determined, the rebooted router just goes 1376 ahead with its key change once it sees that the key of its 1377 neighbor has changed. This should be fine since an extra key 1378 update is not harmful. 1379 Key per sending router per interface - This case is similar to the 1380 key per link case. The rebooted router queries one neighbor 1381 per interface and compares the traffic key information 1382 received with the corresponding information from the 1383 persistent key store. If the keys match, there has been 1384 neither a regular update nor a router change on that 1385 interface. If the keys do not match, it means that there has 1386 been a key update either as part of a regular rekey or due to 1387 a neighbor change on that interface. Hence the rebooted 1388 router derives a new traffic key for that interface and 1389 communicates the same to its neighbors on that interface. The 1390 router then proceeds with querying its neighbors on the 1391 remaining interfaces to determine whether the keys used on its 1392 remaining interfaces are required to be changed or not. 1393 Key per peer - This category of keying group represents unicast 1394 communication. Here when a router comes back up after a 1395 reboot, it queries its counterpart for the traffic keys 1396 corresponding to this pair of routers. Since for unicast 1397 communication, a pair of routers together derives traffic 1398 keys, new keys for this pair would not be available as yet 1399 even though a regular rekey interval may have passed when the 1400 router was down. Therefore the two routers could engage in a 1401 unicast key management protocol such as IKE to derive new 1402 traffic keys or could decide to proceed with using the old 1403 keys itself till the next rekey interval has passed. 1405 The method described above helps ensure that in a majority of cases, 1406 rekeys that could have happened when a router was down are handled. 1407 There are a couple of cases to be considered as yet. 1409 Firstly, the rebooted router should verify whether the adjacencies as 1410 retrieved from its persistent storage are accurate still. They could 1411 now be stale due to the fact that a router could have been installed/ 1412 uninstalled when it was rebooting. 1414 Secondly, in the discussion above regarding the ways in which reboots 1415 can be handled for the different categories of keying groups, we have 1416 mentioned that a router queries only one neighbor in some cases and 1417 one neighbor per link or interface in other cases. A situation could 1418 arise wherein the queried neighbor itself had gone through a reboot 1419 resulting in its own key being stale. This in turn would mean that 1420 the querying router cannot rely on the information got from this 1421 single neighbor. 1423 One way in which both of these issues could be addressed is for the 1424 rebooted router to query the GCKS to get the updated information. 1425 However we do not want the GCKS to be flooded with requests from the 1426 various routers in the AD. Hence there are two layers of protection 1427 designed as follows: 1429 o As already explained, the rebooted router retrieves information 1430 from its persistent store. It then queries its neighbors and 1431 appropriately changes its keys or realises that a key update is 1432 not required. 1433 o Once this is done, in order to query the GCKS, the rebooted router 1434 chooses a random time interval so as to avoid clashes with other 1435 routers querying the GCKS. 1437 Due to the randomness introduced, chances of the GCKS being flooded 1438 with requests are reduced. The GCKS when queried, could give the 1439 router information corresponding to its new adjacencies, probably the 1440 time of change of its adjacencies and any other relevant rekey 1441 information. This enables the rebooted router to know whether its 1442 traffic keys are stale or not. 1444 Another fine point here is that very rarely the rekey process could 1445 be in progress when the router comes up. This is a corner case and 1446 is being left for future work. 1448 6.5. Scalability 1450 Any system that has widespread deployment should be designed keeping 1451 the scalability feature in mind. If scalability is overlooked during 1452 the design phase, the system would fail on high loads when actually 1453 deployed. 1455 We have designed the automated key management system so as to make it 1456 scalable. We have already mentioned that we are limiting the scope 1457 of our problem to key and adjacency management within an AD. Even 1458 within an AD since the number of routers is not fixed, the system 1459 should be able to handle a variable/ large number of routers. The 1460 proposed protocol involves a set of GCKS-GM interactions and a set of 1461 GM-GM interactions. The GM-GM communication is only among 1462 neighboring GMs and hence scalability is not an issue for that. Even 1463 for the GCKS-GM communication in the normal case, there should not be 1464 any issue since all GMs are not installed or turned on at the same 1465 time. However, a situation to be considered is when the GMs reboot. 1466 It could so happen that due to a power outage, all GMs in the AD go 1467 down and come back up at approximately the same time. It is 1468 extremely important to ensure that the GCKS is not stormed with 1469 requests at this point. 1471 Our proposal handles this case in a couple of ways. Firstly we have 1472 seen that the LKS of each GM maintains a stable storage. All 1473 important pieces of information, such as the ones got from the GCKS 1474 and from the neighboring GMs are written to this storage, which is 1475 persistent across reboots. Hence a GM after a reboot, reads 1476 information directly from its persistent storage thereby preventing 1477 the GCKS from being flooded with requests. Secondly after retrieving 1478 information from the local storage, when the GMs need to query the 1479 GCKS itself, they do so by starting a timer and querying at a random 1480 time interval. This plays a major role in preventing the GCKS from 1481 being overloaded thereby leading to scalability. 1483 Another factor that enables partial distribution of functionality 1484 thereby enhancing scalability is the presence of the Standby GCKS. 1485 If a situation arises such that the active GCKS fails (which could be 1486 due to an overload), the Standby GCKS would immediately take over the 1487 functionality of the active one. This eliminates a single point of 1488 failure and hence allows the system to withstand higher loads, or 1489 more number of GMs in the AD. 1491 6.6. Option to Turn Off Adjacency Management 1493 We have already discussed why it is important for an automated key 1494 management system to manage adjacencies well. In fact, this is 1495 because routing protocol updates are usually exchanged with 1496 neighbors, which in turn leads to the requirement that communicating 1497 routers should be legitimate neighbors. It is a good practice to 1498 have adjacency management turned on in a network so that for any 1499 router, only its legitimate neighbors and all of its legitimate 1500 neighbors get to know the keys it uses for securing its control 1501 traffic. 1503 However, sometimes an administrator may decide to turn off adjacency 1504 checks because his network of routers is probably too small and the 1505 extra overhead is not required. This would mean that any router is 1506 then allowed to query for and receive the traffic keys of any other 1507 router in the network even though the routers may not be neighbors. 1508 If adjacency management is turned off, even routing protocols would 1509 respond to all control packets without performing adjacency checks. 1510 This definitely reduces security in the network. 1512 If the key scope is such that the same traffic key is used throughout 1513 the AD, not much harm is caused if a router gives its key information 1514 to any other router in the AD since all routers share the same key. 1515 Of course mutual authentication of the routers should happen in order 1516 to know if the routers are valid members of the AD. However, an 1517 administrator could use the key per sender model, for example, and 1518 turn off adjacency management. The administrator then relies on the 1519 physical adjacency to ensure that a router far away from another 1520 router does not query it for keys. 1522 6.7. Incremental Deployment 1524 Whenever a new system is to be deployed in the real world, the ease 1525 with which that can be done is of utmost importance. Network 1526 operators may not be ready to switch over to a new system if it is 1527 not easy to deploy it. Also, operators using a certain setup, when 1528 switching over to a new one would usually want to deploy the new 1529 system on an incremental basis. This would help them detect problems 1530 in the new system, if any, and then decide whether to completely move 1531 to the new model or not. We have designed our automated key 1532 management system keeping this requirement in mind. The model we 1533 have proposed can be deployed on a per interface basis. This means 1534 that initially GMs could be manually configured with the TEKs for 1535 some of their interfaces, and made to run the key management protocol 1536 to derive TEKs corresponding to the other interfaces. This is for 1537 the case of separate key per interface of each router. The other 1538 cases of keying groups can be handled in a similar manner. Secondly, 1539 the new system can be used to provide TEKs for one routing protocol 1540 at a time. This again makes the transition from the manual method of 1541 configuration to the automated method smooth. 1543 6.8. Smooth Key Rollover 1545 Whenever the TEK is changed, smooth key rollover should be ensured so 1546 that no packets are dropped during the process of key transitions. 1547 In order to achieve this, while transitioning from the old key to the 1548 new one, for a short duration routers have to accept messages secured 1549 using either key. This allows for the time delay involved in the new 1550 keys being received by all routers participating in that particular 1551 communication. After a certain time period as determined by a timer, 1552 the old key information could be cleared. For smooth key rollover in 1553 multicast communication, these points have been explained in more 1554 detail in [RFC5374]. For unicast communication, either this method 1555 could be followed or the two participating routers could exchange new 1556 keys and acknowledge the receipt of the keys just before beginning to 1557 use them. 1559 6.9. Eliminating Single Point of Failure 1561 The proposed design for key management describes the use of a 1562 centralized GCKS as the controller and co-ordinator for the entire 1563 AD. In any centralized system, there is a possibility of having a 1564 single point of failure. In such a system, if the central entity 1565 goes down, it could so happen that the entire system stops 1566 functioning due to loss of important data. This can be avoided by 1567 having a backup entity to take over when the primary controller goes 1568 down. This is precisely what is proposed in our design in 1569 Section 4.2. We propose maintaining a Standby GCKS, which is always 1570 kept in sync with the primary GCKS. This can be done by correctly 1571 syncing all data from the active to the standby at regular intervals. 1572 The appropriate interval could be determined by the policies handed 1573 down by the Policy Server to the GCKS. Whenever the active goes 1574 down, the standby can immediately take over its responsibility 1575 thereby preventing any interruption in the functioning of the system. 1576 This introduces a certain degree of distribution of functionality and 1577 hence can successfully eliminate a single point of failure. 1579 7. An Alternate Mechanism for Transporting the Messages 1581 It is possible that TCP-AO could provide a suitable vehicle for the 1582 necessary message exchanges. This will be explored in detail in the 1583 next revision of this document. 1585 8. Detailed Packet Formats 1587 TBD 1589 9. IANA Considerations 1591 This document has no actions for IANA. 1593 10. Acknowledgements 1594 11. Change History (RFC Editor: Delete Before Publishing) 1596 [NOTE TO RFC EDITOR: this section for use during I-D stage only. 1597 Please remove before publishing as RFC.] 1599 atwood-karp-akam-rp-03 1601 o changed focus to be on policy for key and adjacency management, 1602 instead of on the key and adjacency management itself 1603 o Proposed that TCP-AO might serve as a suitable vehicle for the 1604 exchanges 1605 o 1607 atwood-karp-akam-rp-02 1609 o Inserted ASCII art for figures and hashes 1610 o Resolved internal cross-references 1611 o Resolved external citations 1613 atwood-karp-akam-rp-01 1615 o copied in the rest of the relevant material from Revathi's thesis 1616 o added overview material on protocol operations 1618 atwood-karp-akam-rp-00 (original submission, based on Revathi's 1619 thesis) 1621 o copied in some sections of the thesis that are relevant to the 1622 specification. 1624 12. Needs Work in Next Draft (RFC Editor: Delete Before Publishing) 1626 [NOTE TO RFC EDITOR: this section for use during I-D stage only. 1627 Please remove before publishing as RFC.] 1629 List of stuff that still needs work 1630 o 1631 o Determine if TCP-AO is a viable platform for this work 1632 o Create the section on packet formats 1633 o 1634 o 1636 13. References 1637 13.1. Normative References 1639 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1640 Requirement Levels", BCP 14, RFC 2119, March 1997. 1642 13.2. Informative References 1644 [I-D.hartman-karp-mrkmp] 1645 Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router 1646 Key Management Protocol (MaRK)", 1647 draft-hartman-karp-mrkmp-05 (work in progress), 1648 September 2012. 1650 [I-D.ietf-karp-crypto-key-table] 1651 Housley, R., Polk, T., Hartman, S., and D. Zhang, 1652 "Database of Long-Lived Symmetric Cryptographic Keys", 1653 draft-ietf-karp-crypto-key-table-06 (work in progress), 1654 February 2013. 1656 [I-D.ietf-karp-ops-model] 1657 Hartman, S. and D. Zhang, "Operations Model for Router 1658 Keying", draft-ietf-karp-ops-model-05 (work in progress), 1659 February 2013. 1661 [I-D.ietf-karp-threats-reqs] 1662 Lebovitz, G., Bhatia, M., and B. Weis, "Keying and 1663 Authentication for Routing Protocols (KARP) Overview, 1664 Threats, and Requirements", 1665 draft-ietf-karp-threats-reqs-07 (work in progress), 1666 December 2012. 1668 [I-D.mahesh-karp-rkmp] 1669 Jethanandani, M., Weis, B., Patel, K., Zhang, D., Hartman, 1670 S., Chunduri, U., Tian, A., and J. Touch, "Negotiation for 1671 Keying Pairwise Routing Protocols in IKEv2", 1672 draft-mahesh-karp-rkmp-04 (work in progress), 1673 February 2013. 1675 [I-D.tran-karp-mrmp] 1676 Tran, P. and B. Weis, "The Use of G-IKEv2 for Multicast 1677 Router Key Management", draft-tran-karp-mrmp-02 (work in 1678 progress), October 2012. 1680 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1681 (IKE)", RFC 2409, November 1998. 1683 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 1684 Architecture", RFC 3740, March 2004. 1686 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 1687 "GSAKMP: Group Secure Association Key Management 1688 Protocol", RFC 4535, June 2006. 1690 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 1691 Extensions to the Security Architecture for the Internet 1692 Protocol", RFC 5374, November 2008. 1694 [RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and 1695 Confidentiality in Protocol Independent Multicast Sparse 1696 Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010. 1698 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1699 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1700 RFC 5996, September 2010. 1702 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 1703 of Interpretation", RFC 6407, October 2011. 1705 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 1706 Routing Protocols (KARP) Design Guidelines", RFC 6518, 1707 February 2012. 1709 [atwo2009:AKM] 1710 Atwood, J., "Automated Key Management for Router Updates", 1711 October 2009. 1713 Authors' Addresses 1715 William Atwood 1716 Concordia University/CSE 1717 1455 de Maisonneuve Blvd, West 1718 Montreal, QC H3G 1M8 1719 Canada 1721 Phone: +1(514)848-2424 ext3046 1722 Email: william.atwood@concordia.ca 1723 URI: http://users.encs.concordia.ca/~bill 1724 Revathi Bangalore Somanatha 1725 Concordia University/CSE 1726 1455 de Maisonneuve Blvd, West 1727 Montreal, QC H3G 1M8 1728 Canada 1730 Email: revathi.bs@gmail.com