idnits 2.17.1 draft-hartman-karp-mrkmp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 21 instances of too long lines in the document, the longest one being 26 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 6, 2012) is 4248 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 3547 (Obsoleted by RFC 6407) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-06) exists of draft-mahesh-karp-rkmp-01 == Outdated reference: A later version (-02) exists of draft-tran-karp-mrmp-01 == Outdated reference: A later version (-16) exists of draft-yeung-g-ikev2-04 -- Obsolete informational reference (is this intentional?): RFC 1142 (Obsoleted by RFC 7142) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hartman 3 Internet-Draft Painless Security 4 Intended status: Informational D. Zhang 5 Expires: March 10, 2013 Huawei Technologies co. ltd 6 G. Lebovitz 7 Juniper Networks, Inc. 8 September 6, 2012 10 Multicast Router Key Management Protocol (MaRK) 11 draft-hartman-karp-mrkmp-05 13 Abstract 15 Several routing protocols engage in one-to-many communication. In 16 order to authenticate these communications using symmetric 17 cryptography, a group key needs to be established. This 18 specification defines a group protocol for establishing and managing 19 such keys. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 10, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.2. Relationship to IKEv2 . . . . . . . . . . . . . . . . . . 4 64 1.3. Relationship to GDOI . . . . . . . . . . . . . . . . . . . 5 65 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. Types of Keys . . . . . . . . . . . . . . . . . . . . . . 5 67 2.1.1. Key Encryption Key . . . . . . . . . . . . . . . . . . 6 68 2.1.2. Protocol Master Keys . . . . . . . . . . . . . . . . . 7 69 2.2. GCKS Election . . . . . . . . . . . . . . . . . . . . . . 8 70 2.3. Initial Exchange . . . . . . . . . . . . . . . . . . . . . 9 71 2.4. Group Join Exchange . . . . . . . . . . . . . . . . . . . 9 72 2.5. Group Key Management . . . . . . . . . . . . . . . . . . . 10 73 3. GKCS Election . . . . . . . . . . . . . . . . . . . . . . . . 10 74 3.1. A new GCKS is Elected . . . . . . . . . . . . . . . . . . 12 75 3.1.1. Parameters, Timers, and Events . . . . . . . . . . . . 12 76 3.1.2. Initial . . . . . . . . . . . . . . . . . . . . . . . 14 77 3.1.3. Validate . . . . . . . . . . . . . . . . . . . . . . . 15 78 3.1.4. GCKS2 . . . . . . . . . . . . . . . . . . . . . . . . 16 79 3.1.5. GCKS . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 3.1.6. Member . . . . . . . . . . . . . . . . . . . . . . . . 18 81 3.1.7. Follower . . . . . . . . . . . . . . . . . . . . . . . 18 82 3.2. Merging Partitioned Networks . . . . . . . . . . . . . . . 19 83 3.3. Operations on Receiving a Packet . . . . . . . . . . . . . 20 84 4. Key Download Payload . . . . . . . . . . . . . . . . . . . . . 21 85 5. Initial Exchanges Details . . . . . . . . . . . . . . . . . . 21 86 6. Group Management Unicast Exchanges . . . . . . . . . . . . . . 22 87 6.1. Group Join Exchange . . . . . . . . . . . . . . . . . . . 22 88 7. Group Key Management Operation . . . . . . . . . . . . . . . . 22 89 7.1. General operation . . . . . . . . . . . . . . . . . . . . 22 90 7.2. Out of Sequence Space . . . . . . . . . . . . . . . . . . 22 91 7.3. Changing the Active GCKS . . . . . . . . . . . . . . . . . 23 92 7.4. Reboot Cases . . . . . . . . . . . . . . . . . . . . . . . 23 93 8. Interface to Routing Protocol . . . . . . . . . . . . . . . . 23 94 8.1. Joining a Group . . . . . . . . . . . . . . . . . . . . . 23 95 8.2. Priority Adjustment . . . . . . . . . . . . . . . . . . . 24 96 8.3. Leaving a Group . . . . . . . . . . . . . . . . . . . . . 24 97 8.4. Out of Sequence Space . . . . . . . . . . . . . . . . . . 24 98 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 99 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 101 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 102 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 105 1. Introduction 107 Many routing protocols such as OSPF [RFC2328] and IS-IS [RFC1142] use 108 a one-to-many or multicast model of communications. The same message 109 is sent to a number of recipients. 111 These protocols have cryptographic authentication mechanisms that use 112 a key shared among all members of a communicating group in order to 113 protect messages sent within that group. From a security standpoint, 114 all routers in a group are considered equal. Protecting against a 115 misbehaving router that is part of the group is out of scope for this 116 protocol. 118 Routers need to be provisioned with some credentials for a one-to-one 119 authentication protocol. Preshared keys or asymmetric keys and an 120 authorization list are expected to be common deployments. 122 The members of a group elect a Group Controller/Key Server (GCKS). 123 Potentially any member of the group may act as a GCKS. Since 124 protecting against misbehaving routers is out of scope, there is no 125 need to protect against an entity that is not currently the GCKS 126 impersonating the GCKS. 128 To prove membership in the group, a router authenticates using its 129 provisioned credentials to the current GCKS. If successful, the 130 router is given the current key material for the group. Group size 131 is relatively small and need for forced eviction of members is rare. 132 If a GCKS needs to evict a member, then it can simply re-authenticate 133 with the existing members and provide them new key material. 135 1.1. Terminology 137 GCKS (Group Controller/Key Server): a GCKS is a particular group 138 member which establishes security associations among other authorized 139 group members which it serves. 141 group: a group specified in this document is a set of routers, called 142 group members, which are located on a single broadcast domain/ link/ 143 NBMA segment and use a one-to-many or multicast model of 144 communication. 146 1.2. Relationship to IKEv2 148 IKEv2 [RFC4306] provides a protocol for authenticating IPsec security 149 associations between two peers. It currently provides no group 150 keying. IKEv2 is attractive as a basis for this protocol because 151 while it is much simpler than IKE [RFC2409], it provides all the 152 needed flexibility in one-to-one authentication. 154 IKev2 is expanded to support authentication of routers 155 in[I-D.mahesh-karp-rkmp]. That dspecification describes how IKEv2 156 can be used for unicast routing protocols. This specification is 157 part of expanding that work to cover multicast routing. 159 1.3. Relationship to GDOI 161 [RFC3547] provides a protocol that is structurally very similar to 162 this one. As specified, IKE can be used to provide phase 1 163 authentication to a GCKS. After that, GDOI provides phase 2 messages 164 to establish key-encryption keys and traffic keys. After the phase 2 165 exchange, additional key management operations can be accomplished 166 via GDOI messages sent within the group. 168 In [I-D.yeung-g-ikev2] a group management approach is defined for 169 IKEv2. This approach is extended in [I-D.tran-karp-mrmp] to provide 170 for management of routing messages. This specification ats as a 171 companion to that specification, providing an election protocol and 172 some of the interactions with routing protocols. 174 2. Overview 176 2.1. Types of Keys 178 MaRK manipulates several different types of symmetric keys: 180 PSK (Pre-Shared Key) : PSKs are pair-wise unique keys used for 181 authenticating one router to another during the initial exchange. 182 These keys are configured by some mechanism such as manual 183 configuration or a management application outside of the scope of 184 MaRK. 186 Peer key management key: Routers share a key with the GCKS that is 187 a result of the RP_INIT exchange. 189 KEK (Key Encryption Key): A KEK is a key used to encrypt group key 190 management messages to the current members of a group. A KEK is 191 learned as the product of establishing an MaRK association or 192 through a group key management message encrypted in a previous 193 KEK. A KEK has an explicit expiration but may also be retired by 194 a message encrypted in the KEK sent by the GCKS. 196 Protocol master key: A protocol master key is the key exported by 197 MaRK for use by a routing protocol such as OSPF or IS-IS. The 198 Protocol master key is the key that would be manually configured 199 if a routing protocol is used without key management. This key is 200 distinguished from the 'transport key' (see next) in that this 201 Protocol Master Key may be used in a cryptographic operation in 202 order to derive a specific transport key. 204 Transport key: A transport key is the key used to integrity 205 protect routing messages in a protocol such as IS-IS or OSPF. In 206 today's routing protocol cryptographic authentication mechanisms 207 the transport key is the same as the protocol master key. A 208 disadvantage of this approach is that replay prevention is 209 challenging with this design. Ideally some key derivation step 210 would be used to establish a fresh transport key among all the 211 participants in the group. 213 2.1.1. Key Encryption Key 215 When a router wishes to join a group, the router performs the RP_INIT 216 and RP_AUTH exchange with a GCKS. If the exchanges are successful, 217 the router can establish an association with a specific group. Part 218 of that association will be delivery of a KEK and associated 219 parameters. 221 Group key management messages are sent to a group address rather than 222 unicast to an individual peer. The authenticity, integrity and 223 confidentiality of group key management messages need to be protected 224 with the KEK. 226 As part of establishing the association, the router joining the group 227 is given an valid period( which is identified by a start time point 228 and an expire time point) for the KEK. A group key management 229 message may establish a new KEK with new parameters. 231 From time to time, a GCKS may wish to either force early expiration 232 of a KEK or allow a KEK to expire. Protocol master keys are 233 permitted to be valid for somewhat longer than the KEK that created 234 them so as to avoid disrupting routing when this happens. When a KEK 235 is retired or expires without being replaced by a new KEK announced 236 in the old KEK, the group members delete that KEK. Unless local 237 policy configuration dictates otherwise, the group member will 238 perform a new initial exchange to the GCKS in order to establish a 239 new KEK. This solution is useful for enforcing "forward security" in 240 the cases where a router is no longer authorized to be part of the 241 group. That is, only valid group members can obtain the new KEK 242 while the ones which have leaven the group will be rejected. 244 Other mechanisms such as LKH (section 5.4 [RFC2627]) could be used to 245 permit removal of a group member while avoiding new initial 246 authentications. However these mechanisms come at a complexity cost 247 that is not justified for a small number of routers participating in 248 a single multicast link. 250 2.1.2. Protocol Master Keys 252 Current routing protocols directly use the protocol master key to 253 protect the integrity of messages. One advantage for this approach 254 is that the initial hello messages used for discovery and capability 255 exchange can be protected using the same mechanism as other messages. 256 Typically a sequence number is used for replay detection. Without 257 changing the key, the existing protocols are vulnerable to a number 258 of serious denial of service attacks from replays. 260 The MaRK can solve this replay problem by changing the protocol 261 master key whenever a peer is about to exhaust its sequence number 262 space or whenever a peer loses information about what sequence 263 numbers it used. This could potentially involve changing the 264 protocol master key whenever a router reboots that was part of the 265 group using the current protocol master key. Since key changes will 266 not disrupt active adjacencies and can be accomplished relatively 267 quickly, this is not expected to be a huge problem. Note that after 268 one key change, others routers can boot without causing additional 269 key changes; a flurry of key changes would not be required if several 270 routers reboot near each other. 272 Another approach would be to separate the protocol master key from 273 the transport keys. For example the transport key used by a given 274 peer could be a fresh key derived from the protocol master key and 275 nonces announced by that peer. Some secure mechanism would be 276 provisioned to enable one to confirm that the peer's announcement of 277 its nonce was fresh and authentic; this mechanism would almost 278 certainly involve some form of interaction with the router wishing to 279 guarantee freshness in order to resistant, e.g., replay attacks. 280 There are two key advantages of this separation between transport 281 keys and protocol master keys. The first is that the interaction 282 between the MaRK and routing protocol can be simplified 283 significantly. The second is that even when manually configured 284 protocol master keys are used, replay and adequate DOS protection can 285 be achieved. 287 A simple compare between the keys described in this section is 288 provided in the following table. 290 +-----------+------------+-------------+---------+----------------------+ 291 | Keys |KMP usage |Bootstrapping| Group vs| Other | 292 | |vs. RP usage|vs. Traffic | Pair-Wis| | 293 +-----------+------------+-------------+---------+----------------------+ 294 |Pre-Shared |KMP usage |Bootstrapping|Pair-Wise|Distributed in an out-| 295 |Keys | | | |of-band way | 296 +-----------+------------+-------------+---------+----------------------+ 297 |Key |KMP usage |Bootstrapping|Group |For GCKS to | 298 |Encryption | | | |distribute protocol | 299 |Key | | | |master keys | 300 +-----------+------------+-------------+---------+----------------------+ 301 |Protocol |KMP usage |Bootstrapping|Group |Used by group | 302 |Master Key |or Both |or Both | |members to secure | 303 | | | | |routng packets or | 304 | | | | |generate traffic keys | 305 +-----------+------------+-------------+---------+----------------------+ 306 |Transport |RP usage |Traffic |Group |Used by group | 307 |Key | | | |members to secure | 308 | | | | |routing packets | 309 +-----------+------------+-------------+---------+----------------------+ 311 2.2. GCKS Election 313 Before a MaRK system actually starts working, the routers in the 314 multicast group need to elect a GCKS so that they can obtain 315 cryptographic keys to secure subsequent exchanges of routing 316 information. MaRK specifies an election protocol that dynamically 317 assigns the responsibility of key management to one of the group 318 members. Note that there are already announcer-electing mechanisms 319 provided in some routing protocols (e.g., OSPF and IS-IS). However, 320 much involvement between a MaRK system and a routing protocol 321 implementation will be introduced if the MaRK system reuses the 322 announcer-electing mechanism for the election of the GCKS. The state 323 machine of the routing protocol also has to be modified. For 324 instance, in OSPF, after a DR has been elected, routers need to halt 325 their OSPF executions, and carry out the initial exchange to 326 authenticate the DR and collect the keys for subsequent 327 communications. After this step, the routers need to re-start their 328 OSPF state machines so as to exchange routing information. As a 329 consequence of such cases, an individual GCKS electing solution 330 within MaRK is preferable. 332 Each router has a GCKS priority. Higher priorities are more 333 preferred GCKSes. As discussed in Section 8, the routing protocol 334 can influence the GCKS election protocol by manipulating the priority 335 so that it is likely that the same router will be the announcer for 336 the routing protocol and the GCKS. Even if two different routers are 337 elected as the announcer and GCKS, then the routing protocol and MaRK 338 will function correctly. 340 A key design goal of the election protocol is to maximize the chance 341 that some router permitted to take on the role of GCKS will be 342 elected to that role even when attackers are injecting messages into 343 the election process. The election process can be attacked to cause 344 a router other than the most preferred router to be elected. 346 2.3. Initial Exchange 348 The initial exchange is based on IKEv2's IKE_SA_INIT and IKE_SA_AUTH 349 exchanges. During this exchange, an initiating router attempts to 350 authenticate to the router it believes is a GCKS for a group that the 351 initiating router wants to join. Messages are unicast from the 352 initiator to the responding GCKS. Unicast MaRK messages form a 353 request/response protocol; the party sending the messages is 354 responsible for retransmissions. 356 The initial exchange provides capability negotiation, specifically 357 including supported cryptographic suites for the key management 358 protocol. Identification of the initiator and responder is also 359 exchanged. A symmetric key is established to protect integrity, 360 confidentiality and authenticity of the subsequent key management 361 messages. While routing security does not typically require 362 confidentiality, the key management protocol does because keys are 363 exchanged and these must be protected. 365 Then the identities of each party are cryptographically verified. 366 This can be done using, e.g., a preshared key, asymmetric keys or 367 self-signing certificates. Other mechanisms may be added as a future 368 extension. 370 The authentication exchange also provides an opportunity to join a 371 group as part of the initial exchange. In the typical case, a router 372 can obtain the needed key material for a group in two round-trips. 374 2.4. Group Join Exchange 376 The primary purpose of the unicast MaRK messages is to get an 377 initiator the information it needs to join a group and participate in 378 a routing protocol. The initiator can contact a GCKS to apply to 379 join a group that the GCKS manages. In the case a GCKS manages 380 multiple groups concurrently, the initiator can additionally provide 381 a group identifier to indicate which particular group it intends to 382 join. 384 The responder performs several checks. First, the responder confirms 385 that the responder is currently acting as GCKS for the group in 386 question. Then, the responder confirms that the initiator is 387 permitted to join the group. If these checks pass, then the 388 responder provides a key download payload to the initiator encrypted 389 in the peer key management key. As discussed in Section 2.1.2, the 390 GCKS MUST change the protocol master key if a router was part of the 391 group under the current protocol master key and reboots. In this 392 case, the GCKS SHOULD provide the new and old protocol master key to 393 the initiator, setting the validity times for the old key to permit 394 reception but not transmission. The GCKS MUST use the mechanism in 395 the next section to flood the new key to the rest of the group. 397 A group association created by this exchange may last beyond the 398 unicast MaRK association used to create it. Once membership in a 399 group is established, resources are not required to maintain the 400 unicast association with the GCKS. 402 2.5. Group Key Management 404 After the establishment of a group, a KEK is shared by the GCKS and 405 all the other group members. Using the KEK, the GCKS can securely 406 send multicast messages to the group in order to, for example, update 407 the set of protocol master keys, revoke the KEK, or initiate new 408 group join exchanges. 410 Typically, a protocol master key may be changed for the purpose of 411 replay protection or as a result of KEK update. The KEK needs to be 412 updated whenever a new GCKS is elected or whenever it is 413 administratively desirable to change the keys. For example, after an 414 employee leaves an organization it might not be wise to keep using 415 the KEKs (and any other keys) that the employee has accessed. A KEK 416 update is also required whenever forward security is desired: 417 whenever the authorization of who is permitted to be in a group 418 changes and the GCKS needs to make sure that the router is no longer 419 participating. Most authorization changes such as removing a router 420 from service do not require forward security in practical 421 deployments. 423 3. GKCS Election 425 After a successful GCKS election process, a single router is selected 426 to act as the GCKS for a group. Similar with other popular announcer 427 electing mechanisms (e.g., VRRP, HSRP), in MaRK, only GCKSes use 428 multicast to periodically send Advertisement messages. Such 429 advertisements can be used as heart beat packets to indicate the 430 aliveness of GCKSes. In addition, a state machine with six states 431 (Initial, Validate, GCKS, GCKS2, Follower, and Member) is specified 432 for GCKS election. When a router is initially connected to a 433 multicast network, its state is set as Initial. The router then 434 sends a multicast initial advertisement. If a GCKS is working on the 435 network, it will reply to the router with an advertisement. After 436 receiving the advertisement from the GCKS, the router will try to 437 register with the GCKS using the initial exchange. Typically this 438 registration will succeed, and the state of the router is transferred 439 to Member. After a certain period, if the router still does not 440 receive any advertisement from a GCKS or other group members, the 441 router then believes there is no other group member on the network 442 and sets its state as GCKS. If during the period the router does not 443 receive any advertisement from a GCKS but receives advertisements 444 from other more preferred routers on the network, the router believes 445 that the group is involved in a GCKS election process. The router 446 then puts these routers into its candidate list. When the timer to 447 end the Initial state expires, the router tries to authenticate the 448 most preferred router in the candidate list and validate whether it 449 can be a GCKS. If the validation result is positive, the router then 450 transfer its state to Member, and the router being validated 451 transfers its state to GCKS. 453 In the absence of attacks, this process functions similar to 454 designated router election protocols in existing routing protocols. 455 Because the election process happens before group keys are 456 established, the initial election process is not integrity-protected. 457 An attacker can inject fake GCKS announcements or initial 458 announcements from fake routers that are more preferred than any 459 router actually in the group. Such attacks can create a denial of 460 service situation. If the election process does not converge within 461 the expected time, or if an authentication attempt fails, then the 462 group is probably under attack. A new state called GCKS2 is 463 introduced. A router permitted to be the GCKS can enter the GCKS2 464 state after failing to validate a received announcement in the 465 expected time. GCKS2 is used to increase the convergence speed while 466 the system is under attack. If an initial router receives a GCKS2 467 announcement, the initial router can authenticate and validate the 468 sender, and transfer its own state to Follower, similar to how it 469 would respond to a GCKS announcement. GCKS2 routers attempt to 470 validate each other and to use the resulting security keys to 471 establish a router to act as GCKS. The GCKS2 state does not generate 472 protocol master keys: until the election result in a GCKS only keying 473 material needed for the election is produced. In the subsequent 474 election, the router will wait for the election results from its 475 GCKS2 router until its GCKS2 end timer expires. In this way, the 476 authenticated entities generate a tree structure and avoid generating 477 large amount of KEKs and protocol master keys when a adversary keeps 478 sending fake GCKS announcements to disrupt election. 480 Apart from the initialization of a multicast group, the fail-over of 481 a GCKS can also trigger an election process. For instance, if a 482 router does not receive the heart beat advertisement for a certain 483 period, it will transfer its state to Initial and try to elect a new 484 one. In a GCKS electing process, a router has to stay in the Initial 485 state until a new GCKS is allocated. Particularly, the router first 486 sends its initial advertisement with its priority and waits for a 487 certain period. During the period, if a router receives an initial 488 advertisement which consists of a lower priority, the router then 489 sends the advertisement again with a limited rate. After period, if 490 the router does not find any router with a higher priority, it 491 announces itself as the GCKS. If two routers have the same priority, 492 the one with the lowest IP source address used for messages on the 493 link will be the GCKS. After a router transfers its state to GCKS, 494 it will reply to the initial advertisements from other routers with 495 GCKS advertisements, even when the initial advertisements consist of 496 higher priorities than its priority. This approach guarantees that a 497 GCKS will not be changed frequently after it has been elected. After 498 receiving the GCKS advertisement of the new elected GCKS, other 499 routers transfer their states to Member. However, if a GCKS G1 500 receives a GCKS advertisement from another router G2 and G2 is a more 501 preferred GCKS, G1 follows the procedure in Section 3.2. 503 If a node in state member fails to perform an initial exchange with 504 the router it believes to be GCKS, it resets its state to initial but 505 ignores advertisements from that router. This way an attacker cannot 506 disrupt communications indefinitely by masquerading as a GCKS. 508 3.1. A new GCKS is Elected 510 This section is a detailed description of the election process. 512 In the following discussion, the packets are identified by all upper 513 case characters. 515 3.1.1. Parameters, Timers, and Events 517 Before going into detailed discussion, several parameters are 518 introduced: 520 o Initial_Anno_Interval, which is the time interval between 521 INITIAL_ANNOUNCEMENTS ). 523 o Initial_End_Interval, which is the time interval to transfer the 524 state of a router from Initial to GCKS/Validate if it does not 525 receive any GCKS or GCKS2 announcement on the link ). 527 o Validate_End_Interval, which is the time interval for a router to 528 transfer its state from Validate to GCKS2 if it does not find any 529 other more preferred router ). 531 o GCKS_Down_Interval, which is the time interval for a Member router 532 to declare a GCKS router is down ). 534 o GCKS2_Down_Interval, which is the time interval for a Follower 535 router to declare a GCKS2 router is down ). 537 o GCKS2_End_Interval, which is the time interval for a router to 538 transfer its state from GCKS2 to GCKS if it does not find any 539 other more preferred router ). 541 o GCKS_Anno_Interval, which is the time interval between 542 GCKS_ANNOUNCEMENTS ). 544 o GCKS2_Anno_Interval, which is the time interval between 545 GCKS2_ANNOUNCEMENTS ). 547 Correspondingly, each router in MaRK has several timers, 548 Initial_Anno_Timer, Initial_End_Timer, Validate_End_Timer, 549 GCKS_Down_Timer, GCKS2_Down_Timer, GCKS2_End_Timer, GCKS_Anno_Timer, 550 GCKS2_Anno_Timer. Initial_Anno_Timer fires to trigger sending of an 551 INITIAL_ANNOUNCEMENT based on Initial_Announcement_Interval. 552 Initial_End_Timer fires to trigger the transition of a router state 553 from Initial to some other state. Validate_End_Timer fires to 554 trigger the transition of a router state from Validate to GCKS2. 555 GCKS_Down_Timer fires when no GCKS_ANNOUNCEMENT has been heard for 556 GCKS_Down_Interval. GCKS2_Down_Timer fires when no 557 GCKS2_ANNOUNCEMENT has not been heard for GCKS2_Down_Interval. 558 GCKS2_End_Timer fires to trigger the transition of the state of a 559 router from GCKS2 to GCKS. GCKS_Anno_Timer fires to trigger sending 560 of a GCKS_ANNOUNCEMENT based on GCKS_Announcement_Interval. 561 GCKS2_Anno_Timer fires to trigger sending of a GCKS2_ANNOUNCEMENT 562 based on GCKS2_Anno_Interval. 564 During an election process, a MaRK router may have to deal with 565 following types of events: 567 o X_Anno_Received: an X_ANNOUNCEMENT is received. 569 o Requester_Validated: have authenticated and validated against a 570 some router who believes we should be a GCKS or GCKS2. 572 o GCKS_Validated: a remote entity has been authenticated and 573 validated to be a GCKS router. 575 o GCKS2_Validated: a remote entity has been authenticated and 576 validated to be a GCKS2 router. 578 o Referral_Validated: have authenticated and validated against a 579 candidate who is not a GCKS router but knows one is . 581 o Referral2_Validated: have authenticated and validated against a 582 candidate who knows a GCKS2 router. 584 o Authentication/Validation_Failed: the remote entity fails in the 585 authentication or cannot be either a GCKS/GCKS2 or a referral. 587 o X_Timer_Expired: the timer of type X expired. 589 o KEK_Expired: we have no valid KEK. 591 3.1.2. Initial 593 The timers utilized in this state are Initial_Anno_Timer and 594 Initial_End_Timer. 596 On entry: 598 o Send an INITIAL_ANNOUNCEMENT. 600 o Set the Initial_Anno_Timer with Initial_Anno_Interval. 602 o Set the Initial_End_Timer with Initial_End_Interval. 604 Events: 606 o Initial_Anno_Timer_Expired: send an INITIAL_ANNOUNCEMENT and reset 607 the Initial_Anno_Timer. 609 o Initial_Anno_Received: if the sender of the announcement is more 610 preferred, add the entity into the candidate list; if less 611 preferred, send an INITIAL_ANNOUNCEMENT with a limited rate. 613 o GCKS_Anno_Received: add the sender of the announcement to the 614 candidate list; set the the Validate_End_Timer with the remaining 615 period of Initial_End_Interval; transfer to validate. 617 o GCKS2_Anno_Received: add the sender of the announcement to 618 candidate list; set the Validate_End_Timer with the remaining 619 period of Initial_End_Interval; transfer to validate. 621 o Requester_Validated: If the requester is looking for a GCKS router 622 and the local policy permits, transfer the state to GCKS2 and set 623 GCKS2_End_Interval to time remaining on Initial_End_timer. 625 o Initial_End_Timer_Expired: if there are candidates, transfer the 626 state to Validate. If there is no entry in the candidate list, 627 transfer to GCKS. 629 3.1.3. Validate 631 The timer utilized in this state is Validate_End_Timer. 633 Entering this state means that there is a router which potential 634 could be a GCKS. The purpose of this state is to confirm that it is 635 able to establish a security association with that router and that 636 router's policy permits it to be a GCKS for this group. The two 637 normal paths through the state machine are Initial leading to GCKS 638 for the most preferred router and Initial leading to Validate leading 639 to Member for other routers. 641 On entry: 643 o Authenticate and validate the most preferred entry in the 644 candidate list. 646 o If Validate_End_timer has more time than Validate_end_Interval, 647 set Validate_End_timer to Validate_End_interval. 649 Events: 651 o GCKS_Validated: transfer the state to Member. 653 o GCKS2_Validated: Transfer the state to Follower. 655 o Referral_Validated: perform the authentication/validation on the 656 recommended node; move the referring from the candidate list to 657 the black list for Blacklist_Interval. 659 o Referral2_Validated: perform the authentication/validation on the 660 recommended node; move the referring node from the candidate list 661 to the black list for Blacklist_Interval. 663 o Requester_Validated: If the requester is looking for a GCKS/GCKS2 664 router and the local policy permits, transfer the state to GCKS2. 666 o Validation_Failed: move the router being validated from the 667 candidate list to black list for Blacklist_interval. 669 o Initial_Anno_Received: if the sender of the announcement is more 670 preferred, add the router into the candidate list; if less 671 preferred, send an INITIAL_ANNOUNCEMENT with a limited rate. 673 o GCKS_Anno_Received: add the router sending the announcement into 674 the candidate list and perform authentication against that entity. 676 o GCKS2_Anno_Received: add the router sending the announcement into 677 the candidate list and start the authentication/validation against 678 that entity. 680 o Validate_End_Timer_Expired: transfer the state to GCKS2. 682 3.1.4. GCKS2 684 The timers utilized in this state include GCKS2_Anno_Timer and 685 GCKS2_End_Timer. 687 Whe a router transfers its state from Validate to GCKS2, it is 688 indicated that there has been some authentication/validation problem 689 or another node is behaving in a manner inconsistent with the 690 election state. In this case, the purpose of the GCKS2 state is to 691 establish sufficient security keys to integrity protect the election 692 process. In addition, it is possible for a router to enter this 693 state during normal operations if the router being elected GCKS gets 694 an authentication request before Initial_End_timer expires. In this 695 case, the router will transfer its state to GCKS if no more preferred 696 GCKS candidate is found within a limited period. 698 On entry: 700 o Send an GCSK2_ANNOUNCEMENT. 702 o Set the GCKS2_Anno_Timer with GCKS2_Anno_Interval. 704 o Set the the GCKS2_End_Timer with GCKS2_End_Interval unless it was 705 set on entry transferring from Initial. 707 Events: 709 o GCKS_Anno_Received: add to candidate list; start authentication/ 710 validation. 712 o GCKS2_Anno_Received: if more preferred, add to candidate list, 713 start authentication/validation. If less preferred, send 714 GCKS2_ANNOUNCEMENT if rate limiting is permitted. 716 o GCKS_Validated: Transfer to member state; flood KEK to the 717 associated followers. 719 o GCKS2_Validated: Transfer the state to Follower; flood KEK to the 720 associated followers. 722 o Referral_Validated: Perform authentication and validation on the 723 recommended node; move the referring node from the candidate list 724 to the black list for Blacklist_Interval. 726 o Referral2_Validated: if the recommended GCKS2 is more preferred, 727 perform authentication and validation on the recommended node; 728 move the referring from the candidate list to the black list for 729 Blacklist_Interval. 731 o Requester_Validated: if the requester is looking for a GCKS2, 732 distribute KEK. 734 o Validation_Failed: move the router being validated from the 735 candidate list to black list for Blacklist_interval. 737 o GCKS2_End_Timer_Expired: transition the state to GCKS. 739 o GCKS2_Anno_Timer_Expired: send a GCKS2_ANNOUNCEMENT. 741 3.1.5. GCKS 743 The timer utilized in this state is GCKS_Anno_Timer. 745 On entry: 747 o Senda GCKS_ANNOUNCEMENT. 749 o Set the GCKS_Anno_Timer with GCKS_Anno_Interval. 751 o Generate protocol keys; if needed, generate KEK. 753 Events: 755 o GCKS_Anno_Timer_Expired: send a GCKS_ANNOUNCEMENT. 757 o Initial_Anno_Received: send an GCKS_ANNOUNCEMENT immediately if 758 the rate limiting is permitted. 760 o GCKS2_Anno_Received: send an GCKS_ANNOUNCEMENT immediately if the 761 rate limiting is permitted. 763 o GCKS_Anno_Received: if the sender is more preferred, add to 764 candidate list and start authentication/validation; Otherwise, 765 send an GCKS_ANNOUNCEMENT immediately if the rate limiting is 766 permitted. 768 o GCKS_Validated: start network merging operations as what is 769 illustrated in Section 3.2. 771 o Requester_Validated: If the requester is looking for a GCKS 772 router, distribute KEK and protocol master keys; if the requester 773 is another GCKS, start network merging operations as what is 774 illustrated in Section 3.2. 776 3.1.6. Member 778 The timer utilized in this state is GCKS_Down_Timer. 780 On entry: 782 o Set the GCKS_Down_Timer with GCKS_Down_Interval. 784 Events: 786 o GCKS_Down_Timer_Expired: Transfer the state into Initial. 788 o GCKS_Anno_Received: reset GCKS_Down_Timer. 790 o Requester_Validated: if the requester is legal, recommend the GCKS 791 router to it. 793 3.1.7. Follower 795 The timer utilized in this state is GCKS2_Down_Timer. 797 On entry: 799 o Set the GCKS2_Down_Timer with GCKS2_Down_Interval. 801 Events: 803 o GCKS2_Down_Timer_Expired: Transfer the state into Initial. 805 o GCKS2_Anno_Received: reset GCKS2_Down_Timer. 807 o GCKS_Anno_Received: Add the announcer to the candidate list and 808 start validation. 810 o Requester_Validated: if the requester is legal, recommend the 811 GCKS2 router to it. 813 o GCKS_Validated: Transfer the state to member. 815 The following diagram illustrates the rules of transiting the states 816 introduced this section. 818 +---------------------------------------------+ 819 | +-----------+ | 820 | +---->| | | 821 | | | Follower |--+ | 822 | | +--| | | | 823 | | | +-----------+ | | 824 +----------+ | | +-----------+ | +----------+ | 825 | |-+ +->| | +->| |<-+ 826 | Validate |<----->| Initial |<----| Member | 827 | | +->| |<-+ | |<-+ 828 +----------+ | +-----------+ | +----------+ | 829 | | | +----------+ | 830 | | +->| | | 831 | | +-----------+ | GCKS | | 832 | +->| |---->| | | 833 | | GCKS2 | +----------+ | 834 +------------>| |-------------------+ 835 +-----------+ 837 3.2. Merging Partitioned Networks 839 Whenever a GCKS finds that a more preferred router is also acting as 840 a GCKS for the same group, then the group is partitioned. Typically 841 if there is already an active GCKS for a group, even if a more 842 preferred router joins the group, the GCKS will not change. Two 843 situations can result in multiple GCKSes active for a group. The 844 first is that members of the group do not share common authentication 845 credentials. The second is that the group was previously partitioned 846 so that some nodes could not see election messages from other nodes. 847 After the problem resulting in the partition is fixed, then both 848 active GCKSes will see each others election announcements. The group 849 needs to merge. 851 The less preferred GCKS performs a unicast mark_merge_sa unicast key 852 management message to the more preferred GCKS. In this message the 853 less preferred GCKS includes its key download payload, so the more 854 preferred GCKS learns the protocol master keys of the less preferred 855 GCKS. 857 The more preferred GCKS generates a new key download payload 858 including a KEK and the union of all the protocol master keys. The 859 GCKS SHOULD mark the existing protocol master keys as expiring for 860 usage in transmitted packets in a relatively short time. The GCKS 861 SHOULD introduce a new protocol master key. This key download 862 payload is returned to the less preferred GCKS and is sent out in the 863 current KEK using a group key management message. 865 The less preferred GCKS sends the received key download payload 866 encrypted in its existing KEK and retransmit the message for several 867 times according to its local policy. After all retransmissions of 868 this payload the less preferred GCKS sets its state to member. 870 As a result of this procedure, members learn the protocol master keys 871 of both GCKSes and converge on a single KEK and GCKS. Changing the 872 protocol master keys during a merge is important for protocols that 873 use the protocol master key as a transport key. The new GCKS does 874 not know which routers have joined the group with the other GCKS. 875 Therefore, it could not correctly detect one of these routers 876 rebooting and change the protocol master key at that point. If the 877 key is changed as part of the merge, replays are handled. 879 3.3. Operations on Receiving a Packet 881 When a router attempts to join an election process, it may have a 882 valid KEK. For instance, when a GCKS cannot work properly, the 883 routers on the link need to transfer their state to Initial and raise 884 an election to find a new valid GCKS. If there is still a valid KEK 885 shared by the router, they can use the KEK to secure the packets 886 transmitted during the election until a new KEK is distributed by the 887 new GCKS. A router holding the valid KEK is regarded to be more 888 preferred than a router which doesn't have the key. By using the 889 KEK, it is able to prevent an attacker from disturbing the election 890 process by broadcasting fake announcements. Therefore, after an 891 initial router does not find any more preferred router holding the 892 valid key, it then can transfer its state to GCKS directly. 894 Therefore, the operations on receiving a packet are as follows: 896 o Check the blacklist. If the sender of the packet is on the 897 blacklist, discard the packet. 899 o If the state is GCKS, accept the packet and generate an event. 900 GCKS announcements need to be excepted in GCKS state for merges to 901 work. 903 o If there is a KEK that is not expired, check the packet integrity 904 against any matching KEK. 906 o If no KEK matches or if the integrity fails to validate, discard 907 the packet. 909 o If there is no KEK at all or the KEK integrity check passed, 910 process the packet and generate an event. 912 It is notable this approach limits the scope of the election within 913 the routers managed by the failed GCKS. If there are routers newly 914 accessing the link during the election, no router with a KEK will 915 process their packets. However these routers can process packets 916 from routers with the KEK. In many cases one of the routers with a 917 KEK will be elected GCKS and the other routers can authenticate and 918 join. In the worst case, two independent GCKSes will be elected and 919 then merge. 921 4. Key Download Payload 923 What all is actually in the message you get at the end of phase 1 924 exchange (the RP_AUTH Exchange) and that is sent out periodically 925 during group key management. 927 For the KEK, this needs to include the key itself, the algorithm 928 (presumably drawn from the IKEv2 symmetric algorithms), key ID, group 929 ID transmit start time, receive start time, and expire time. 931 The protocol master keys include the key, an algorithm ID, the key ID 932 and thelifetimes. 934 5. Initial Exchanges Details 936 Simiilar with [I-D.tran-karp-mrmp], in MRKMP, when two routers needs 937 to authenticate each other, they need to perform the initial 938 exchanges defined in [I-D.mahesh-karp-rkmp] . For example, when a 939 router intends to join a group, it needs to firstly perform a RP 940 Initial (RP_INIT) Exchange with the GCKS of the group. RP_INIT is 941 identical to the IKE_SA_INIT exchange defined in Internet Key 942 Exchange Protocol Version 2 [RFC5996], after which the router and the 943 GCKS can communicate privately. Note that at this point the network 944 devices have not identified their peer. For the details of this 945 exchange, refer to IKE_SA_INIT in Internet Key Exchange Protocol 946 Version 2 [RFC5996]. 948 Router GCKS 949 -------------------- ------------------ 950 HDR, SAi1, KEi, Ni --> 951 <-- HDR, SAr1, KEr, Nr, [CERTREQ,] 953 RP_INIT 955 The router and the GCKS then needs to perform an RP_AUTH exchange 956 defined in [I-D.mahesh-karp-rkmp]. At the successful conclusion of 957 the exchange, the router is adopted as a group member and obtains 958 keying material (e.g., the KEK and protocol master key) to securely 959 communicate with other group members. 961 Router GCKS 962 -------------------- ------------------ 963 HDR, SK {IDi, [CERT,] [CERTREQ,] 964 [IDr,] AUTH, SArpi} --> 965 <-- HDR, SK {IDr, [CERT,] AUTH, 966 SArpr} 967 RP_AUTH 969 6. Group Management Unicast Exchanges 971 6.1. Group Join Exchange 973 If a router receives a group join exchange for a group for which it 974 is not the GCKS, it MUST return a notification. If it knows the GCKS 975 for the group then it returns MaRK_WRONG_GCKS including the address 976 of the GCKS or GCKS2 in the notification payload along with an 977 indication of whether the router is a GCKS or GCKS2. The initiator 978 tries the group join exchange (probably with a new initial exchange) 979 with the indicated router. If the responder does not know the GCKS 980 for the group, either because it is not a member of the group or 981 because its GCKS election state is initial, it returns the 982 MaRK_GCKS_UNKNOWN notification. 984 7. Group Key Management Operation 986 7.1. General operation 988 Periodically the GCKS will send out an update message encrypted in 989 the current KEK including the current group key download payload and 990 parameters. If a new KEK is about to be valid for receiving 991 messages, this is included. Any protocol master keys that are valid 992 for sending or receiving SHOULD be included. 994 If a previous KEK is still valid for sending, then an update message 995 is sent encrypted in the old KEK. This message MUST include the new 996 KEK. This message SHOULD include the protocol master keys. 998 7.2. Out of Sequence Space 1000 A member of a group can also use the unicast exchange to request a 1001 GCKS to change a protocol master key, on the occasions, for example, 1002 where the member is going to exhaust its sequence space of the 1003 associated routing protocol. For protocols where the protocol master 1004 key is the same as the transport key, it is critical that no two 1005 messages be sent by the same router with the same sequence number and 1006 protocol master key. The sequence number space is finite. So if a 1007 router is running low on available sequence space it needs to request 1008 a new protocol master key be generated. 1010 7.3. Changing the Active GCKS 1012 When a GCKS finds a more preferred router announcing itself as a 1013 GCKS, it will forward its privilege to another one in the following 1014 conditions. The operations are introduced in Section 3.2. 1016 When a GCKS cannot work properly, it will just stop sending the 1017 GCKS_ANNOUNCEMENT. Then after a certain time period, a new GCKS 1018 election process will be raised. 1020 7.4. Reboot Cases 1022 After a reboot, a router in a group will lost the state information 1023 about the group (e.g., protocol master keys, traffic keys, the 1024 sequence numbers used by GCKS). Therefore, the router needs to find 1025 and authenticate the GCKS, and apply to join the group. If the GCKS 1026 finds that the router is already a group member, the GCKS will update 1027 the transport keys (and the protocol master keys if necessary) used 1028 in the group first in order to avoid inter-session replay attacks. 1030 8. Interface to Routing Protocol 1032 This section describes signaling between MaRK and the routing 1033 protocol. The primary communication between these protocols is that 1034 MaRK populates rows in the key table making protocol master keys 1035 available to the routing protocol. However additional signaling is 1036 also required from the routing protocol to MaRK. This section 1037 discusses that signaling. All required communication from MaRK to 1038 the routing protocol can be accomplished by manipulating the key 1039 table. However an implementation MAY wish to signal MaRK failures to 1040 the routing protocol in order to provide consistent management 1041 feedback. 1043 8.1. Joining a Group 1045 When a routing protocol instance wishes to begin communicating on a 1046 multicast group, it signals a group join event to MaRK. This event 1047 includes the identity of the group as well as this router's priority 1048 for being a GCKS for the group. When MaRK receives this event, it 1049 starts MaRK for this group and attempts to find a GCKS. 1051 8.2. Priority Adjustment 1053 It is desirable that the GCKS function track the functions within a 1054 routing protocol. For example for protocols such as OSPF that 1055 designate a router on a link to manage adjacencies for that link, it 1056 would be desirable for the GCKS role to be assigned to that router. 1057 The routing protocol provides a priority input to the GCKS election 1058 process. Initially the routing protocol should map any priority 1059 mechanism within the routing protocol to the GCKS election procedure 1060 so that routers favored as announcer for a link will also be favored 1061 as a GCKS. 1063 However, the routing protocol SHOULD also dynamically manipulate the 1064 GCKS election priority based on what happens within the routing 1065 protocol. The router actually elected as the announcer SHOULD have a 1066 GCKS election priority higher than any other group member. 1067 Typically, by the time the routing protocol is able to elect an 1068 announcer, a GCKS will already be chosen. However, if a GCKS 1069 election is triggered when the routing protocol is already 1070 operational, then the election can choose the routing protocol's 1071 announcer. 1073 8.3. Leaving a Group 1075 If a routing protocol terminates on an interface, MaRK implementation 1076 on the router needs to be notified that group is no longer joined. 1077 MaRK MUST stop participating in the GCKS election process, stop 1078 monitoring for key management messages and if the current router is a 1079 GCKS, stop acting in that role. 1081 8.4. Out of Sequence Space 1083 If a routing protocol is running out its sequence space, the MaRK 1084 implementation on the router needs to be notified. The MaRK 1085 implementation then needs to contact the GCKS to request the update 1086 of the transport keys (and the protocol master keys if necessary). 1088 9. Security Considerations 1090 This protocol is intended to protect against attackers who are not 1091 properly authorized mounting a integrity or availability attack on 1092 the system. All parties who are authorized to be part of a given 1093 group are equivalent; group members impersonating each other, 1094 impacting availability or integrity are all out of scope for this 1095 threat model. Protecting confidentiality of key material against 1096 parties not authorized for membership in a given group is in scope as 1097 it would directly lead to an attack on integrity or availability. 1099 Protecting confidentiality of group policy or routing data is not 1100 required. Attackers are assumed to be able to insert and observe 1101 packets. Even if attackers can modify and suppress packets, 1102 integrity should not be impacted. Minimizing the availability impact 1103 against attackers who can modify and suppress packets is strongly 1104 desirable, although there are limits to this defense. It is 1105 important that a member of one group not be able to impact another 1106 group. 1108 Significant complexity results from the election protocol. In order 1109 to support arbitrary authentication mechanisms including preshared 1110 keys, the election protocol itself is not signed. At least before 1111 group keys are established, the election protocol is not integrity 1112 protected. Later authentication can establish integrity, but 1113 managing availability attacks on the election protocol requires 1114 significant analysis. 1116 An attacker who can suppress packets sent to the group can create a 1117 denial of service condition. One attack is to suppress GCKS election 1118 packets and cause two routers to believe they are both the GCKS for 1119 the group. If the least preferred router never hears the GCKS 1120 advertisement from the more preferred router, then the group will 1121 remain partitioned. Such an attacker is likely to be able to mount 1122 more direct denial of service, for example suppressing the actual 1123 routing protocol packets. 1125 The election protocol has been designed to try and resist denial of 1126 service conditions. However, the election protocol maintains state 1127 in the form of a candidate list and black list. An attacker can 1128 consume state by generating fake election announcements. An 1129 implementation can discard state if it has insufficient resources. 1130 However, if legitimate routers are discarded from the candidate list, 1131 the protocol may take longer to converge or may not converge. If 1132 entries are removed from the black list, then more resources may be 1133 spent on attackers. So the solution has some residual denial of 1134 service possibilities. The election protocol requires significant 1135 analysis to confirm it meets its design goals. 1137 The security of the election protocol depends on the denial of 1138 service resistance of the authentication protocol. It is important 1139 that an attacker not be able to cause an authentication to fail by 1140 injecting a packet. So, rather than failing an authentication if a 1141 bad packet is received, an implementation needs to wait and see if a 1142 good packet appears in some timeout. 1144 The security of the system as a whole depends on the pair-wise 1145 security between the router currently in the GCKS role and the other 1146 routers in the group. Since any router can potentially act as GCKS, 1147 the pair-wise security between all members of the group is critical 1148 to the security of the system. In practical deployments, information 1149 used by the router acting as GCKS to authorize a member joining the 1150 group will be configured by some management application. In these 1151 deployments, the security of the system depends on the management 1152 application correctly maintaining this information on all routers 1153 potentially in the group. 1155 10. Acknowledgements 1157 The funding for Sam Hartman's work on this document is provided by 1158 Huawei. 1160 XXX add the list of people in the lunch time group unless they are 1161 willing to be listed as authors. 1163 11. References 1165 11.1. Normative References 1167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1168 Requirement Levels", BCP 14, RFC 2119, March 1997. 1170 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1171 (IKE)", RFC 2409, November 1998. 1173 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 1174 Group Domain of Interpretation", RFC 3547, July 2003. 1176 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1177 RFC 4306, December 2005. 1179 11.2. Informative References 1181 [I-D.mahesh-karp-rkmp] 1182 Jethanandani, M., Weis, B., Patel, K., Zhang, D., and S. 1183 Hartman, "Key Management for Pairwise Routing Protocol", 1184 draft-mahesh-karp-rkmp-01 (work in progress), March 2012. 1186 [I-D.tran-karp-mrmp] 1187 Tran, P. and B. Weis, "The Use of G-IKEv2 for Multicast 1188 Router Key Management", draft-tran-karp-mrmp-01 (work in 1189 progress), March 2012. 1191 [I-D.yeung-g-ikev2] 1192 Rowles, S., Yeung, A., Tran, P., and Y. Nir, "Group Key 1193 Management using IKEv2", draft-yeung-g-ikev2-04 (work in 1194 progress), March 2012. 1196 [RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", 1197 RFC 1142, February 1990. 1199 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1201 [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for 1202 Multicast: Issues and Architectures", RFC 2627, June 1999. 1204 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1205 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1206 RFC 5996, September 2010. 1208 Authors' Addresses 1210 Sam Hartman 1211 Painless Security 1213 Email: hartmans-ietf@mit.edu 1215 Dacheng Zhang 1216 Huawei Technologies co. ltd 1217 Huawei Building No.3 Xinxi Rd., Shang-Di Information Industrial Base Hai-Dian District, Beijing 1218 China 1220 Email: zhangdacheng@huawei.com 1222 Gregory Lebovitz 1223 Juniper Networks, Inc. 1224 1194 North Mathilda Ave. 1225 Sunnyvale, California 94089-1206 1226 USA 1228 Email: gregory.ietf@gmail.com