idnits 2.17.1 draft-chunduri-isis-extended-sequence-no-tlv-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 9, 2012) is 4216 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: 'I-D.chunduri-karp-is-is-gap-analysis' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-karp-threats-reqs' is defined on line 501, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-msec-gdoi-update' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'I-D.weis-gdoi-mac-tek' is defined on line 519, but no explicit reference was found in the text == Unused Reference: 'RFC6518' is defined on line 534, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-chunduri-karp-is-is-gap-analysis-01 == Outdated reference: A later version (-07) exists of draft-ietf-karp-threats-reqs-05 == Outdated reference: A later version (-11) exists of draft-ietf-ospf-security-extension-manual-keying-02 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Working Group U. Chunduri 3 Internet-Draft W. Lu 4 Intended status: Standards Track A. Tian 5 Expires: April 12, 2013 Ericsson Inc. 6 N. Shen 7 Cisco Systems, Inc. 8 October 9, 2012 10 IS-IS Extended Sequence number TLV 11 draft-chunduri-isis-extended-sequence-no-tlv-02 13 Abstract 15 This document defines Extended Sequence number TLV to protect 16 Intermediate System to Intermediate System (IS-IS) PDUs from replay 17 attacks. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 12, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Replay attacks and Impact on IS-IS networks . . . . . . . . . 4 57 2.1. Replay attacks . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Impact of Replays . . . . . . . . . . . . . . . . . . . . 5 59 3. Extended Sequence Number TLV . . . . . . . . . . . . . . . . . 5 60 3.1. Sequence Number Wrap . . . . . . . . . . . . . . . . . . . 7 61 4. Mechanism and Packet Encoding . . . . . . . . . . . . . . . . 7 62 4.1. IIHs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.2. SNPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.2.1. CSNPs . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.2.2. PSNPs . . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.3. LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5. Backward Compatibility and Deployment . . . . . . . . . . . . 8 68 5.1. IIH and SNPs . . . . . . . . . . . . . . . . . . . . . . . 9 69 5.2. LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.3. Operational Consideration . . . . . . . . . . . . . . . . 9 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 74 9. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 9.1. Appendix A.1 . . . . . . . . . . . . . . . . . . . . . . . 10 76 9.2. Appendix A.2 . . . . . . . . . . . . . . . . . . . . . . . 11 77 10. Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 10.1. Operational/Implementation consideration . . . . . . . . . 11 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 81 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 With the rapid development of new data center infrastructures, due to 87 its flexibility and scalability attributes, IS-IS has been adopted 88 widely in various L2 and L3 routing deployment of the data centers 89 for critical business operations. At the meantime the SDN-enabled 90 networks even though put more power to Internet applications and also 91 make network management easier, it does raise the security 92 requirement of network routing infrastructure to another level. 94 This document defines Extended Sequence number (ESN) TLV to protect 95 Intermediate System to Intermediate System (IS-IS) PDUs from replay 96 attacks. 98 A replayed IS-IS PDU can potentially cause many problems in the IS-IS 99 networks ranging from bouncing adjacencies to black hole or even some 100 form of Denial of Service (DoS) attacks as explained in Section 2. 101 This problem is also discussed in security consideration section, in 102 the context of cryptographic authentication work as described in 103 [RFC5304] and in [RFC5310]. 105 Currently, there is no mechanism to protect IS-IS HELLO PDUs (IIHs) 106 and Sequence number PDUs (SNPs) from the replay attacks. However, 107 Link State PDUs (LSPs) have sequence number in the LSP header as 108 defined in [RFC1195], with which it can effectively mitigate the 109 intra-session replay attacks. But, LSPs are still susceptible to 110 inter-session replay attacks. 112 The new ESN TLV defined here thwart these threats and can be deployed 113 with authentication mechanism as specified in [RFC5304] and in 114 [RFC5310] for a more secure network. 116 Replay attacks can be effectively mitigated by deploying a group key 117 management protocol (similar to as defined in [I-D.weis-gdoi-mac- 118 tek], using GDOI [RFC6407]) with a frequent key change policy. 119 Currently, there is no such mechanism defined for IS-IS. Even if 120 such a mechanism is defined, usage of this TLV can be helpful to 121 avoid replays before the keys are changed. 123 Also, it is believed, even when such key management system is 124 deployed, there always will be some manual key based systems that co- 125 exist with KMP (Key Management Protocol) based systems. The ESN TLV 126 defined in this document is more helpful for such deployments. 128 1.1. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC2119]. 134 1.2. Acronyms 136 CSNP - Complete Sequence Number PDU 138 ESN - Extended Sequence Number 140 IIH - IS-IS Hello PDU 142 KMP - Key Management Protocol (auto key management) 144 LSP - IS-IS Link State PDU 146 MKM - Manual Key management Protocols 148 PDU - Protocol Data Unit 150 PSNP - Partial Sequence Number PDU 152 SNP - Sequence Number PDU 154 2. Replay attacks and Impact on IS-IS networks 156 This section explains the replay attacks and the applicability of the 157 same for IS-IS networks. Though this has been described in detail in 158 KARP IS-IS gap analysis document [I-D.chunduri-karp-is-is-gap- 159 analysis], it is being restated below for completeness. 161 2.1. Replay attacks 163 Replaying a captured protocol packet to cause damage is a common 164 threat for any protocol. Securing the packet with cryptographic 165 authentication information alone can not mitigate this threat 166 completely. 168 In intra-session replay attacks, a secured protocol packet of the 169 current session is replayed, can cause damage if there is no other 170 mechanism to confirm this is a replayed packet. 172 In inter-session replay attacks, captured packet from one of the 173 previous session can be replayed to cause the damage. IS-IS PDUs are 174 vulnerable to both these attacks as there is no sequence number 175 verification for IIH PDUs, SNP (both PSNP and CSNP) and limited 176 protection for LSPs. 178 2.2. Impact of Replays 180 At the time of adjacency bring up an IS sends IIH packet with empty 181 neighbor list (TLV 6) and with or with out the authentication 182 information as per provisioned authentication mechanism. If this 183 packet is replayed later on the broadcast network all ISes in the 184 broadcast network can bounce the adjacency to create a huge churn in 185 the network. 187 Today Link State PDUs (LSPs) have intra-session replay protection as 188 LSP header contains 32-bit sequence number which is verified for 189 every received PDU against the local LSP database. But, if the key 190 is not changed, an adversary can cause an inter-session replay attack 191 by replaying a old LSP with higher sequence number and fewer prefixes 192 or fewer adjacencies. This forces the receiver to accept and remove 193 the routes from the routing table, which eventually causes traffic 194 disruption to those prefixes. 196 In broadcast networks a replayed Complete Sequence Number PDU (CSNP) 197 can force the receiver to request Partial Sequence Number PDU (PSNP) 198 in the network and similarly, a replayed PSNP can cause unnecessary 199 LSP flood in the network. 201 Please refer KARP IS-IS gap analysis document for further details. 203 3. Extended Sequence Number TLV 205 The Extended Sequence Number (ESN) TLV is composed of 1 octet for the 206 Type, 1 octet that specifies the number of bytes in the Value field 207 and an 8 or 12 byte Value field. 209 x CODE - TBD. 211 x LENGTH - total length of the value field, which is 12 bytes for 212 IIH, SNP PDUs and 8 bytes for LSPs. 214 x Value - 64-bit Extended Session Sequence Number (ESSN), which is 215 present for all IS-IS PDUs followed 32 bit monotonically increasing 216 per Packet Sequence Number (PSN). PSN is not required for LSPs. 218 0 1 2 3 219 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 220 +-+-+-+-+-+-+-+-+ 221 | Type | 222 +-+-+-+-+-+-+-+-+ 223 | Length | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Extended Session Sequence Number (High Order 32 Bits) | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Extended Session Sequence Number (Low Order 32 Bits) | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | (optional) Packet Sequence Number (32 Bits) | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 1: Extended Sequence Number (ESN) TLV 234 The Extended Sequence Number (ESN) TLV Type is TBD. Please refer to 235 IANA Considerations, in Section 6 for more details. Length indicates 236 the length of the value field; which is 12 bytes for IIH and SNP PDUs 237 and 8 bytes for LSPs. 239 In order to provide protection against both inter-session and intra- 240 session replay attacks, the IS-IS Extended Session Sequence Number 241 (ESSN) is defined a 64-bits value; the value MUST contain ever 242 increasing number in all IS-IS PDUs including LSPs whenever it is 243 changed due any situation as specified in Section 3.1. 245 The 32-bit Packet Sequence Number (PSN) MUST be set and increase 246 monotonically for IIH or SNP PDUs sent by IS-IS node. Upon 247 reception, the Packet Sequence number MUST be greater than the last 248 sequence number in the IIH or SNP PDUs accepted from the sending 249 IS-IS node. Otherwise, the IIH or SNP PDU is considered as replayed 250 PDU and dropped. 252 As LSPs contain 32-bit sequence number field already in the LSP 253 header, Packet Sequence Number in the ESN TLV MUST be omitted by 254 setting the length field to 8 bytes and implementations continue to 255 refer the header sequence number for all encoding and validation 256 purposes. 258 The ESN TLV defined here is optional. The ESN TLV MAY present in any 259 IS-IS PDU. If present and authentication is in use this TLV MUST be 260 included as part of the authentication data to calculate the digest. 261 A sender MUST only transmit a single ESN TLV in a IS-IS PDU. 263 3.1. Sequence Number Wrap 265 If the 32-bit Packet Sequence Number in ESN TLV and for LSPs the 32- 266 bit header sequence number wraps; or session is refreshed; or even 267 for the cold restarts the 64-bit ESSN value MUST be set higher than 268 the previous value. IS-IS implementations MAY use guidelines 269 provided in Section 9 for accomplishing this. 271 4. Mechanism and Packet Encoding 273 The ESN TLV defined in this document is optional and the encoding and 274 decoding of this TLV in each IS-IS PDU is as detailed below. Also 275 refer, when to ignore processing of the ESN TLV as described in 276 Section 5 for appropriate operation in the face of legacy node(s) in 277 the network with out having this capability. 279 4.1. IIHs 281 The IIH ESN TLV information is maintained per IS-IS interface and per 282 level. For a broadcast interface, it can have two sets of ESN TLV 283 information, if the circuit belongs to both level-1 and level-2. For 284 point-to-point (P2P) interface, only one ESN TLV information is 285 needed. This TLV information can be maintained as part of the 286 adjacency state. 288 While transmitting, the 64-bit ESSN MUST always be started with a non 289 zero number and MAY use the guidelines as specified in Section 9 to 290 encode this 64-bit value. The 32-bit PSN starts from 1 and increases 291 monotonically for every subsequent PDU. 293 While receiving, the 64-bit ESSN MUST always be either same or higher 294 than the stored value in the adjacency state. Similarly, the 32-bit 295 PSN MUST be higher than the stored value in the adjacency state. If 296 the PDU is accepted then the adjacency state should be updated with 297 the last received IIH PDU's ESN TLV information. 299 For an adjacency refresh or the 32-bit PSN wrap the associated higher 300 order 64-bit ESSN MUST always be higher than the previous value and 301 the lower order 32-bit packet sequence number starts all over again. 303 4.2. SNPs 305 4.2.1. CSNPs 307 In broadcast networks, only Designated Intermediate System (DIS) CSNP 308 ESN TLV information is maintained per adjacency (per level) similar 309 to IIH ESN TLV information. The procedure for encoding, verification 310 and sequence number wrap scenarios are similar as explained in 311 Section 4.1, except separate DIS ESN TLV information should be used. 312 In case of DIS change all adjacencies in the broadcast network MUST 313 reflect new DIS's CSNP ESN TLV information in the adjacency and 314 should be used for encoding/verification. 316 In P2P networks, CSNP ESN TLV information is maintained per adjacency 317 similar to IIH ESN TLV information. The procedure for encoding, 318 verification and sequence number wrap scenarios are similar as 319 explained in Section 4.1, except separate CSNP ESN TLV information 320 should be used. 322 4.2.2. PSNPs 324 In both broadcast and P2P networks, PSNP ESN TLV information is 325 maintained per adjacency (per level) similar to IIH ESN TLV 326 information. The procedure for encoding, verification and sequence 327 number wrap scenarios are similar as explained in Section 4.1, except 328 separate PSNP ESN TLV information should be used. 330 4.3. LSPs 332 For LSPs, while originating, the 64-bit ESSN MUST always be started 333 with a non zero number and MAY use the guidelines as specified in 334 Section 9 for encoding this value. 336 While receiving, the 64-bit Extended Sequence Number MUST always be 337 either same or higher than the stored value in the LSP database. 338 This document does not specify any changes for the existing LSP 339 header 32-bit sequence number validation mechanism. 341 5. Backward Compatibility and Deployment 343 The implementation and deployment of the ESN TLV can be done to 344 support backward compatibility and gradual deployment in the network 345 without requiring a flag day. The deployment can be done for IS-IS 346 links only, or for both IS-IS links and nodes in the networks. This 347 feature can also be deployed for the links in a certain area of the 348 network where the maximum security mechanism is needed, or it can be 349 deployed for the entire network. 351 The implementation SHOULD allow the configuration of ESN TLV feature 352 on each IS-IS link level and on IS-IS node level with area/level 353 scope. The implementation SHOULD also allow operators to control the 354 configuration of 'send' and/or 'verify' the feature of IS-IS PDUs for 355 the links and for the node. In this document, the 'send' operation 356 is to include the ESN TLV in it's own IS-IS PDUs; and the 'verify' 357 operation is to process the ESN TLV in the receiving IS-IS PDUs from 358 neighbors. 360 5.1. IIH and SNPs 362 On the link level, ESN TLV involves the IIH PDUs and SNPs (both CSNP 363 and PSNP). When the router software is upgraded to include this 364 feature, the network operators can configure the IS-IS to 'send' the 365 ESN TLV in it's IIH PDUs and SNPs for those IS-IS interfaces on the 366 IS-IS area or level. When all the routers attached to the link or 367 links have been upgraded with this feature, network operators can 368 start to configure 'verify' on the IS-IS interfaces for all the 369 routers sharing the same link(s). This way deployment can be done in 370 per link basis in the network. The operators may decide to only 371 apply ESN TLV feature on some of the links in the network, or only on 372 their multi-access media links. 374 5.2. LSPs 376 On the node level with an area or level scope, ESN TLV involves the 377 IS-IS LSPs. This feature has to be done for the entire IS-IS area or 378 levels with the same flooding domain. The deployment and upgrade of 379 software to support ESN TLV can be gradual and from node to node. 380 When a node is upgraded to support this feature, the operators can 381 configure the node level 'send' in the desired area/level(s) to 382 include the ESN TLV in it's own LSPs. No 'verify' is enabled until 383 all the routers in the entire IS-IS area/level or entire network is 384 upgraded. Then the operators can configure the 'verify' for the 385 IS-IS node level from node to node. When all the nodes performs the 386 'verify' of ESN TLVs, the node level ESN TLV feature is supported 387 fully in the network. 389 5.3. Operational Consideration 391 In the face of an adversary doing an active attack, it is possible to 392 have inconsistent data view in the network, if there is a 393 considerable delay in enabling ESN TLV 'verify' operation from first 394 node to the last node in the network. This can happen primarily 395 because, replay PDUs can potentially be accepted by the nodes where 396 'verify' operation is still not provisioned at the time of the 397 attack. To minimize such a window it is recommended that 398 provisioning of 'verify' SHOULD be done in a timely fashion by the 399 network operators. 401 6. IANA Considerations 403 This document requests that IANA allocate from the IS-IS TLV 404 Codepoints Registry a new TLV, referred to as the "Extended Sequence 405 Number" TLV, with the following attributes: IIH = y, LSP = y, SNP = 406 y, Purge = y. 408 7. Security Considerations 410 This document describes a mechanism to the replay attack threat as 411 discussed in the Security Considerations section of [RFC5304] and in 412 [RFC5310]. This document does not introduce any new security 413 concerns to IS-IS or any other specifications referenced in this 414 document. 416 8. Acknowledgements 418 The authors of this document do not make any claims on the 419 originality of the ideas described. Authors are thankful for the 420 review and the valuable feedback provided by Acee Lindem, Joel 421 Halpern and Les Ginsberg. 423 9. Appendix A 425 IS-IS nodes implementing this specification SHOULD use available 426 mechanisms to preserve the 64-bit Extended Session Sequence Number's 427 strictly increasing property, when ever it is changed for the 428 deployed life of the IS-IS node (including cold restarts). 430 This Appendix provides only guidelines for achieving the same and 431 implementations can resort to any similar method as far as strictly 432 increasing property of the 64-bit ESSN in ESN TLV is maintained. 434 9.1. Appendix A.1 436 One mechanism for accomplishing this is by encoding 64-bit ESSN as 437 system time represented in 64-bit unsigned integer value. This MAY 438 be similar to the system timestamp encoding for NTP long format as 439 defined in Appendix A.4 of [RFC5905]. New current time MAY be used 440 when the IS-IS node loses its sequence number state including in 441 Packet Sequence Number wrap scenarios. 443 Implementations MUST make sure while encoding the 64-bit ESN value 444 with current system time, it should not default to any previous value 445 or some default node time of the system; especially after cold 446 restarts or any other similar events. In general system time must be 447 preserved across cold restarts in order for this mechanism to be 448 feasible. One example of such implementation is to use a battery 449 backed real-time clock (RTC). 451 9.2. Appendix A.2 453 One other mechanism for accomplishing this would be similar to the 454 one as specified in [I-D.ietf-ospf-security-extension-manual-keying], 455 to use the 64-bit ESSN as a wrap/boot count stored in non-volatile 456 storage. This value is incremented anytime the IS-IS node loses its 457 sequence number state including in Packet Sequence Number wrap 458 scenarios. 460 The drawback of this approach per Section 6 of [I-D.ietf-ospf- 461 security-extension-manual-keying], if used is applicable here. The 462 only drawback is, it requires the IS-IS implementation to be able to 463 save its boot count in non-volatile storage. If the non-volatile 464 storage is ever repaired or upgraded such that the contents are lost, 465 keys MUST be changed to prevent replay attacks. 467 10. Appendix B 469 10.1. Operational/Implementation consideration 471 Since the ESN is maintained per interface, per level and per PDU 472 type, this scheme can be useful for monitoring the health of the 473 IS-IS adjacency. A Packet Sequence Number skip on IIH can be 474 recorded by the neighbors which can be used later to correlate with 475 adjacency state changes over the interface. For instance in a multi- 476 access media, all the neighbors have the skips from the same IIH 477 sender or only one neighbor has the Packet Sequence Number skips can 478 indicate completely different issues on the network. 480 11. References 482 11.1. Normative References 484 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 485 dual environments", RFC 1195, December 1990. 487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", BCP 14, RFC 2119, March 1997. 490 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 491 Time Protocol Version 4: Protocol and Algorithms 492 Specification", RFC 5905, June 2010. 494 11.2. Informative References 496 [I-D.chunduri-karp-is-is-gap-analysis] 497 Chunduri, U., Tian, A., and W. Lu, "KARP IS-IS security 498 gap analysis", draft-chunduri-karp-is-is-gap-analysis-01 499 (work in progress), March 2012. 501 [I-D.ietf-karp-threats-reqs] 502 Lebovitz, G. and M. Bhatia, "Keying and Authentication for 503 Routing Protocols (KARP) Overview, Threats, and 504 Requirements", draft-ietf-karp-threats-reqs-05 (work in 505 progress), May 2012. 507 [I-D.ietf-msec-gdoi-update] 508 Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 509 of Interpretation", draft-ietf-msec-gdoi-update-11 (work 510 in progress), August 2011. 512 [I-D.ietf-ospf-security-extension-manual-keying] 513 Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, 514 "Security Extension for OSPFv2 when using Manual Key 515 Management", 516 draft-ietf-ospf-security-extension-manual-keying-02 (work 517 in progress), April 2012. 519 [I-D.weis-gdoi-mac-tek] 520 Weis, B. and S. Rowles, "GDOI Generic Message 521 Authentication Code Policy", draft-weis-gdoi-mac-tek-03 522 (work in progress), September 2011. 524 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 525 Authentication", RFC 5304, October 2008. 527 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 528 and M. Fanto, "IS-IS Generic Cryptographic 529 Authentication", RFC 5310, February 2009. 531 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 532 of Interpretation", RFC 6407, October 2011. 534 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 535 Routing Protocols (KARP) Design Guidelines", RFC 6518, 536 February 2012. 538 Authors' Addresses 540 Uma Chunduri 541 Ericsson Inc. 542 300 Holger Way, 543 San Jose, California 95134 544 USA 546 Phone: 408 750-5678 547 Email: uma.chunduri@ericsson.com 549 Wenhu Lu 550 Ericsson Inc. 551 300 Holger Way, 552 San Jose, California 95134 553 USA 555 Email: wenhu.lu@ericsson.com 557 Albert Tian 558 Ericsson Inc. 559 300 Holger Way, 560 San Jose, California 95134 561 USA 563 Phone: 408 750-5210 564 Email: albert.tian@ericsson.com 566 Naiming Shen 567 Cisco Systems, Inc. 568 225 West Tasman Drive, 569 San Jose, California 95134 570 USA 572 Email: naiming@cisco.com