Working Group U. Chunduri Internet-Draft W. Lu Intended status: Standards Track A. Tian Expires: October 24, 2015 Ericsson Inc. N. Shen Cisco Systems, Inc. April 22, 2015 IS-IS Extended Sequence number TLV draft-ietf-isis-extended-sequence-no-tlv-06 Abstract This document defines Extended Sequence number TLV to protect Intermediate System to Intermediate System (IS-IS) PDUs from replay attacks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 24, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Chunduri, et al. Expires October 24, 2015 [Page 1] Internet-Draft IS-IS Extended Sequence number TLV April 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Replay attacks and Impact on IS-IS networks . . . . . . . . . 4 2.1. IIHs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. SNPs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Extended Sequence Number TLV . . . . . . . . . . . . . . . . 4 3.1. Sequence Number Wrap . . . . . . . . . . . . . . . . . . 5 4. Mechanism and Packet Encoding . . . . . . . . . . . . . . . . 6 4.1. IIHs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. SNPs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Backward Compatibility and Deployment . . . . . . . . . . . . 6 5.1. IIH and SNPs . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. ESSN Encoding Mechanisms . . . . . . . . . . . . . . 9 A.1. Using Timestamp . . . . . . . . . . . . . . . . . . . . . 9 A.2. Using Non-Volatile Storage . . . . . . . . . . . . . . . 10 Appendix B. Operational/Implementation consideration . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction With the rapid development of new data center infrastructures, due to its flexibility and scalability attributes, Intermediate System to Intermediate System (IS-IS, [ISO10589]) has been adopted widely in various L2/L3 routing and switching deployment of the data centers and for critical business operations. Also, while technologies such as Software Defined Networks (SDN) may improve network management and enable new applications, their use also has an effect on the security requirements of the routing infrastructure. A replayed IS-IS PDU can potentially cause many problems in the IS-IS networks ranging from bouncing adjacencies to black hole or even some form of Denial of Service (DoS) attacks as explained in Section 2. This problem is also discussed in security consideration section, in Chunduri, et al. Expires October 24, 2015 [Page 2] Internet-Draft IS-IS Extended Sequence number TLV April 2015 the context of cryptographic authentication work as described in [RFC5304] and in [RFC5310]. Currently, there is no mechanism to protect IS-IS HELLO PDUs (IIHs) and Sequence number PDUs (SNPs) from the replay attacks. However, Link State PDUs (LSPs) have sequence number in the LSP header as defined in [ISO10589], with which it can effectively mitigate the intra-session replay attacks. But, LSPs are still susceptible to inter-session replay attacks. This document defines Extended Sequence number (ESN) TLV to protect Intermediate System to Intermediate System (IS-IS) PDUs from replay attacks. The new ESN TLV defined here thwart these threats and can be deployed with authentication mechanism as specified in [RFC5304] and in [RFC5310] for a more secure network. Replay attacks can be effectively mitigated by deploying a group key management protocol (being developed as defined in [I-D.yeung- g-ikev2] and [I-D.hartman-karp-mrkmp]) with a frequent key change policy. Currently, there is no such mechanism defined for IS-IS. Even if such a mechanism is defined, usage of this TLV can be helpful to avoid replays before the keys are changed. Also, it is believed, even when such a key management system is deployed, there always will be some manual key based systems that co- exist with KMP (Key Management Protocol) based systems. The ESN TLV defined in this document is more helpful for such deployments. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2. Acronyms CSNP - Complete Sequence Number PDU ESN - Extended Sequence Number IIH - IS-IS Hello PDU IS - Intermediate System KMP - Key Management Protocol (auto key management) Chunduri, et al. Expires October 24, 2015 [Page 3] Internet-Draft IS-IS Extended Sequence number TLV April 2015 LSP - IS-IS Link State PDU MKM - Manual Key management Protocols PDU - Protocol Data Unit PSNP - Partial Sequence Number PDU SNP - Sequence Number PDU 2. Replay attacks and Impact on IS-IS networks Replaying a captured protocol packet to cause damage is a common threat for any protocol. Securing the packet with cryptographic authentication information alone cannot mitigate this threat completely. This section explains the replay attacks and the applicability of the same for each IS-IS PDU. 2.1. IIHs When an adjacency is brought up an IS sends an IIH packet with an empty neighbor list (TLV 6), which can be sent with or without authentication information. Packets can be replayed later on the broadcast network which may cause all ISes to bounce the adjacency, thus churning the network. Note that mitigating replay is only possible when authentication information is present. 2.2. LSPs Normal operation of the IS-IS update Process as specified in [ISO10589] provides timely recovery from all LSP replay attacks. Therefore the use of the extensions defined in this document are prohibited in LSPs. Further discussion of the vulnerability of LSPs to replay attacks can be found in [I-D.ietf- karp-isis-analysis]. 2.3. SNPs A replayed CSNP can result in the sending of unnecessary PSNPs on a given link. A replayed CSNP or PSNP can result in unnecessary LSP flooding on the link. 3. Extended Sequence Number TLV The Extended Sequence Number (ESN) TLV is composed of 1 octet for the Type, 1 octet that specifies the number of bytes in the Value field and a 12 byte Value field. This TLV is defined only for IIH and SNP PDUs. Chunduri, et al. Expires October 24, 2015 [Page 4] Internet-Draft IS-IS Extended Sequence number TLV April 2015 x CODE - 11. x LENGTH - total length of the value field, which is 12 bytes. x Value - 64-bit Extended Session Sequence Number (ESSN), which is followed by a 32 bit monotonically increasing per Packet Sequence Number (PSN). 0 1 2 3 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 +-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Session Sequence Number (High Order 32 Bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Session Sequence Number (Low Order 32 Bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Sequence Number (32 Bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Extended Sequence Number (ESN) TLV The ESN TLV defined here is optional. Though this is an optional TLV, this can be mandatory on a link when 'verify' mode is enabled as specified in Section 5.1. The ESN TLV MAY be present only in any IIH and SNP PDUs. A PDU with multiple ESN TLVs is invalid and MUST be discarded on receipt. The 64 bit ESSN MUST be non-zero and MUST contain ever increasing number whenever it is changed due any situation as specified in Section 3.1. Encoding the 64-bit unsigned integer ESSN value is a local matter and implementations MAY use one of the alternatives provided in Appendix A. Effectively, for each PDU which contains the ESN TLV the 96 bit unsigned integer value consisting of the 64 bit ESSN and 32 bit Packet Sequence Number (PSN) - where ESSN is the higher order 64 bits - MUST be greater than the most recently received value in a PDU of the same type originated by the same IS. 3.1. Sequence Number Wrap If the 32-bit Packet Sequence Number in ESN TLV wraps or for the cold restart of the router, the 64-bit ESSN value MUST be set higher than the previous value. IS-IS implementations MAY use guidelines provided in Appendix A for accomplishing this. Chunduri, et al. Expires October 24, 2015 [Page 5] Internet-Draft IS-IS Extended Sequence number TLV April 2015 4. Mechanism and Packet Encoding The encoding of ESN TLV in each applicable IS-IS PDU is detailed below. Please refer to Section 5 for appropriate operations on how to inter-op with legacy node(s) that do not support the extensions defined in this document. If the received PDU with ESN TLV is accepted then the stored value for the corresponding originator and PDU type MUST be updated with the latest value received. Please note that level information is included in the PDU type. 4.1. IIHs ESN TLV information is maintained for each type of IIH PDU being sent on a given circuit. The procedures for encoding, verification and sequence number wrap scenarios are explained in Section 3. 4.2. SNPs A separate CSNP/PSNP ESN TLV information is maintained per PDU type, per originator and per link. The procedures for encoding, verification and sequence number wrap scenarios are explained in Section 3. 5. Backward Compatibility and Deployment The implementation and deployment of the ESN TLV can be done to support backward compatibility and gradual deployment in the network without requiring a flag day. This feature can also be deployed for the links in a certain area of the network where the maximum security mechanism is needed, or it can be deployed for the entire network. The implementation SHOULD allow the configuration of ESN TLV feature on each IS-IS link level. The implementation SHOULD also allow operators to control the configuration of the 'send' and/or 'verify' feature of IS-IS PDUs for the links and for the node. In this document, the 'send' operation is to include the ESN TLV in its own IS-IS PDUs; and the 'verify' operation is to process the ESN TLV in the receiving IS-IS PDUs from neighbors. In the face of an adversary doing an active attack, it is possible to have inconsistent data view in the network, if there is a considerable delay in enabling ESN TLV 'verify' operation from first node to the last node in the network or all nodes of a particular LAN segment, where 'send' mode is configured. This can happen primarily because, replay PDUs can potentially be accepted by the nodes where 'verify' operation is still not provisioned at the time of the attack. To minimize such a window it is recommended that Chunduri, et al. Expires October 24, 2015 [Page 6] Internet-Draft IS-IS Extended Sequence number TLV April 2015 provisioning of 'verify' SHOULD be done in a timely fashion by the network operators. 5.1. IIH and SNPs On the link level, ESN TLV involves the IIH PDUs and SNPs (both CSNP and PSNP). The "send" and "verify" modes described above can be set independently on each link and in the case of a broadcast network independently for each level. To introduce ESN support without disrupting operations, ISs on a given interface are first configured to operate in 'send' mode. Once all routers operating on an interface are operating in 'send' mode 'verify' mode can be enabled on each IS. Once 'verify' mode is set for an interface all the IIH and SNP PDUs being sent on that interface MUST contain the ESN TLV. Any such PDU received without an ESN TLV MUST be discarded when 'verify' mode is enabled. Similarly, to safely disable ESN support on a link, 'verify' mode is disabled on all ISs on the link. Once all routers operating on an interface are disabled from 'verify' mode 'send' mode can be disabled on each IS. Please refer Section 5 for considerations on enabling or disabling 'verify' mode on all ISs on a link. 6. IANA Considerations A new TLV code point is assigned by IANA from the IS-IS TLV Codepoints Registry as defined in this document, referred to as the "Extended Sequence Number" TLV, with the following attributes: Type Description IIH LSP SNP Purge ---- --------------------- --- --- --- ----- 11 ESN TLV Y N Y N Figure 2: IS-IS Codepoints Registry Entry 7. Security Considerations This document describes a mechanism to the replay attack threat as discussed in the Security Considerations section of [RFC5304] and in [RFC5310]. If an adversary either does not forward the packets or delay the same as specified in Section 3.3 of [RFC6862], the mechanism specified in this document cannot mitigate those threats. Also some of the threats as specified in Section 2.3 of [I-D.ietf- karp-isis-analysis] are not addressable with ESN TLV as specified in this document. This document does not introduce any new security concerns to IS-IS or any other specifications referenced in this document. Chunduri, et al. Expires October 24, 2015 [Page 7] Internet-Draft IS-IS Extended Sequence number TLV April 2015 8. Contributors Authors would like to thank Les Ginsberg for his significant contribution in detailed reviews and suggestions. 9. Acknowledgements As some sort of sequence number mechanism to thwart protocol replays is a old mechanism, authors of this document do not make any claims on the originality of the overall protection idea described. Authors are thankful for the review and the valuable feedback provided by Acee Lindem and Joel Halpern. Thanks to Alia Atlas, Chris Hopps, Nevil Brownlee and Adam W. Montville for their reviews and suggestions during IESG directorate review. Authors would also thank Christer Holmberg, Ben Campbell, Barry Leiba, Stephen Farrell and Alvaro Retana for their reviews on this document. 10. References 10.1. Normative References [ISO10589] International Organization for Standardization, "Intermediate system to intermediate system intra-domain- routing routine information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO/ IEC 10589:2002, Second Edition, Nov. 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. 10.2. Informative References [I-D.hartman-karp-mrkmp] Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router Key Management Protocol (MaRK)", draft-hartman-karp- mrkmp-05 (work in progress), September 2012. [I-D.ietf-karp-isis-analysis] Chunduri, U., Tian, A., and W. Lu, "KARP IS-IS security analysis", draft-ietf-karp-isis-analysis-04 (work in progress), March 2015. Chunduri, et al. Expires October 24, 2015 [Page 8] Internet-Draft IS-IS Extended Sequence number TLV April 2015 [I-D.weis-gdoi-mac-tek] Weis, B. and S. Rowles, "GDOI Generic Message Authentication Code Policy", draft-weis-gdoi-mac-tek-03 (work in progress), September 2011. [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008. [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009. [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012. [RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements", RFC 6862, March 2013. [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, "Security Extension for OSPFv2 When Using Manual Key Management", RFC 7474, April 2015. Appendix A. ESSN Encoding Mechanisms IS-IS nodes implementing this specification SHOULD use available mechanisms to preserve the 64-bit Extended Session Sequence Number's strictly increasing property, whenever it is changed for the deployed life of the IS-IS node (including cold restarts). This Appendix provides only guidelines for achieving the same and implementations can resort to any similar method as far as strictly increasing property of the 64-bit ESSN in ESN TLV is maintained. A.1. Using Timestamp One mechanism for accomplishing this is by encoding 64-bit ESSN as system time represented in 64-bit unsigned integer value. This MAY be similar to the system timestamp encoding for NTP long format as defined in Appendix A.4 of [RFC5905]. New current time MAY be used when the IS-IS node loses its sequence number state including in Packet Sequence Number wrap scenarios. Implementations MUST make sure while encoding the 64-bit ESN value with current system time, it should not default to any previous value or some default node time of the system; especially after cold restarts or any other similar events. In general system time must be Chunduri, et al. Expires October 24, 2015 [Page 9] Internet-Draft IS-IS Extended Sequence number TLV April 2015 preserved across cold restarts in order for this mechanism to be feasible. One example of such implementation is to use a battery backed real-time clock (RTC). A.2. Using Non-Volatile Storage One other mechanism for accomplishing this would be similar to the one as specified in [RFC7474], to use the 64-bit ESSN as a wrap/boot count stored in non-volatile storage. This value is incremented anytime the IS-IS node loses its sequence number state including in Packet Sequence Number wrap scenarios. The drawback of this approach per Section 8 of [RFC7474], if used is applicable here. It requires the IS-IS implementation to be able to save its boot count in non-volatile storage. If the non-volatile storage is ever repaired or router hardware is upgraded such that the contents are lost, keys MUST be changed to prevent replay attacks. Appendix B. Operational/Implementation consideration Since the ESN is maintained per interface, per level and per PDU type, this scheme can be useful for monitoring the health of the IS- IS adjacency. A Packet Sequence Number skip on IIH can be recorded by the neighbors which can be used later to correlate with adjacency state changes over the interface. For instance in a multi-access media, all the neighbors have the skips from the same IIH sender or only one neighbor has the Packet Sequence Number skips can indicate completely different issues on the network. Effective usage of the TLV defined in this document for operational issues MAY also need more system information before making concrete conclusions and defining all that information is beyond the scope of this document. Authors' Addresses Uma Chunduri Ericsson Inc. 300 Holger Way, San Jose, California 95134 USA Phone: 408 750-5678 Email: uma.chunduri@ericsson.com Chunduri, et al. Expires October 24, 2015 [Page 10] Internet-Draft IS-IS Extended Sequence number TLV April 2015 Wenhu Lu Ericsson Inc. 300 Holger Way, San Jose, California 95134 USA Email: wenhu.lu@ericsson.com Albert Tian Ericsson Inc. 300 Holger Way, San Jose, California 95134 USA Phone: 408 750-5210 Email: albert.tian@ericsson.com Naiming Shen Cisco Systems, Inc. 225 West Tasman Drive, San Jose, California 95134 USA Email: naiming@cisco.com Chunduri, et al. Expires October 24, 2015 [Page 11]