< draft-ietf-isis-extended-sequence-no-tlv-05.txt   draft-ietf-isis-extended-sequence-no-tlv-06.txt >
Working Group U. Chunduri Working Group U. Chunduri
Internet-Draft W. Lu Internet-Draft W. Lu
Intended status: Standards Track A. Tian Intended status: Standards Track A. Tian
Expires: October 9, 2015 Ericsson Inc. Expires: October 24, 2015 Ericsson Inc.
N. Shen N. Shen
Cisco Systems, Inc. Cisco Systems, Inc.
April 7, 2015 April 22, 2015
IS-IS Extended Sequence number TLV IS-IS Extended Sequence number TLV
draft-ietf-isis-extended-sequence-no-tlv-05 draft-ietf-isis-extended-sequence-no-tlv-06
Abstract Abstract
This document defines Extended Sequence number TLV to protect This document defines Extended Sequence number TLV to protect
Intermediate System to Intermediate System (IS-IS) PDUs from replay Intermediate System to Intermediate System (IS-IS) PDUs from replay
attacks. attacks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 9, 2015. This Internet-Draft will expire on October 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
2.3. SNPs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. SNPs . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Extended Sequence Number TLV . . . . . . . . . . . . . . . . 4 3. Extended Sequence Number TLV . . . . . . . . . . . . . . . . 4
3.1. Sequence Number Wrap . . . . . . . . . . . . . . . . . . 5 3.1. Sequence Number Wrap . . . . . . . . . . . . . . . . . . 5
4. Mechanism and Packet Encoding . . . . . . . . . . . . . . . . 6 4. Mechanism and Packet Encoding . . . . . . . . . . . . . . . . 6
4.1. IIHs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. IIHs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. SNPs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. SNPs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Backward Compatibility and Deployment . . . . . . . . . . . . 6 5. Backward Compatibility and Deployment . . . . . . . . . . . . 6
5.1. IIH and SNPs . . . . . . . . . . . . . . . . . . . . . . 7 5.1. IIH and SNPs . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Appendix A.1 . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Appendix A.2 . . . . . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8
11. Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . 9 Appendix A. ESSN Encoding Mechanisms . . . . . . . . . . . . . . 9
11.1. Operational/Implementation consideration . . . . . . . . 9 A.1. Using Timestamp . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 A.2. Using Non-Volatile Storage . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 9 Appendix B. Operational/Implementation consideration . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
With the rapid development of new data center infrastructures, due to With the rapid development of new data center infrastructures, due to
its flexibility and scalability attributes, IS-IS has been adopted its flexibility and scalability attributes, Intermediate System to
widely in various L2/L3 routing and switching deployment of the data Intermediate System (IS-IS, [ISO10589]) has been adopted widely
centers and for critical business operations. Also, while in various L2/L3 routing and switching deployment of the data centers
technologies such as Software Defined Networks (SDN) may improve and for critical business operations. Also, while technologies such
network management and enable new applications, their use also has an as Software Defined Networks (SDN) may improve network management and
effect on the security requirements of the routing infrastructure. 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 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 networks ranging from bouncing adjacencies to black hole or even some
form of Denial of Service (DoS) attacks as explained in Section 2. form of Denial of Service (DoS) attacks as explained in Section 2.
This problem is also discussed in security consideration section, in This problem is also discussed in security consideration section, in
the context of cryptographic authentication work as described in the context of cryptographic authentication work as described in
[RFC5304] and in [RFC5310]. [RFC5304] and in [RFC5310].
Currently, there is no mechanism to protect IS-IS HELLO PDUs (IIHs) Currently, there is no mechanism to protect IS-IS HELLO PDUs (IIHs)
and Sequence number PDUs (SNPs) from the replay attacks. However, and Sequence number PDUs (SNPs) from the replay attacks. However,
skipping to change at page 3, line 48 skipping to change at page 3, line 48
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Acronyms 1.2. Acronyms
CSNP - Complete Sequence Number PDU CSNP - Complete Sequence Number PDU
ESN - Extended Sequence Number ESN - Extended Sequence Number
IIH - IS-IS Hello PDU IIH - IS-IS Hello PDU
KMP - Key Management Protocol (auto key management) IS - Intermediate System
KMP - Key Management Protocol (auto key management)
LSP - IS-IS Link State PDU LSP - IS-IS Link State PDU
MKM - Manual Key management Protocols MKM - Manual Key management Protocols
PDU - Protocol Data Unit PDU - Protocol Data Unit
PSNP - Partial Sequence Number PDU PSNP - Partial Sequence Number PDU
SNP - Sequence Number PDU SNP - Sequence Number PDU
2. Replay attacks and Impact on IS-IS networks 2. Replay attacks and Impact on IS-IS networks
skipping to change at page 4, line 51 skipping to change at page 5, line 5
given link. A replayed CSNP or PSNP can result in unnecessary LSP given link. A replayed CSNP or PSNP can result in unnecessary LSP
flooding on the link. flooding on the link.
3. Extended Sequence Number TLV 3. Extended Sequence Number TLV
The Extended Sequence Number (ESN) TLV is composed of 1 octet for the 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 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 and a 12 byte Value field. This TLV is defined only for IIH and SNP
PDUs. PDUs.
x CODE - TBD. x CODE - 11.
x LENGTH - total length of the value field, which is 12 bytes. x LENGTH - total length of the value field, which is 12 bytes.
x Value - 64-bit Extended Session Sequence Number (ESSN), which is x Value - 64-bit Extended Session Sequence Number (ESSN), which is
followed by a 32 bit monotonically increasing per Packet Sequence followed by a 32 bit monotonically increasing per Packet Sequence
Number (PSN). Number (PSN).
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 5, line 37 skipping to change at page 5, line 39
The ESN TLV defined here is optional. Though this is an optional 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 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 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 and SNP PDUs. A PDU with multiple ESN TLVs is invalid and MUST be
discarded on receipt. discarded on receipt.
The 64 bit ESSN MUST be non-zero and MUST contain ever increasing The 64 bit ESSN MUST be non-zero and MUST contain ever increasing
number whenever it is changed due any situation as specified in number whenever it is changed due any situation as specified in
Section 3.1. Encoding the 64-bit unsigned integer ESSN value is a Section 3.1. Encoding the 64-bit unsigned integer ESSN value is a
local matter and implementations MAY use one of the alternatives local matter and implementations MAY use one of the alternatives
provided in Section 10. Effectively, for each PDU which contains the provided in Appendix A. Effectively, for each PDU which contains the
ESN TLV the 96 bit unsigned integer value consisting of the 64 bit 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 ESSN and 32 bit Packet Sequence Number (PSN) - where ESSN is the
higher order 64 bits - MUST be greater than the most recently 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. received value in a PDU of the same type originated by the same IS.
3.1. Sequence Number Wrap 3.1. Sequence Number Wrap
If the 32-bit Packet Sequence Number in ESN TLV wraps or for the cold 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 restart of the router, the 64-bit ESSN value MUST be set higher than
the previous value. IS-IS implementations MAY use guidelines the previous value. IS-IS implementations MAY use guidelines
provided in Section 10 for accomplishing this. provided in Appendix A for accomplishing this.
4. Mechanism and Packet Encoding 4. Mechanism and Packet Encoding
The encoding of ESN TLV in each applicable IS-IS PDU is detailed The encoding of ESN TLV in each applicable IS-IS PDU is detailed
below. Please refer to Section 5 for appropriate operations on how below. Please refer to Section 5 for appropriate operations on how
to inter-op with legacy node(s) that do not support the extensions 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 defined in this document. If the received PDU with ESN TLV is
accepted then the stored value for the corresponding originator and accepted then the stored value for the corresponding originator and
PDU type MUST be updated with the latest value received. Please note PDU type MUST be updated with the latest value received. Please note
that level information is included in the PDU type. that level information is included in the PDU type.
skipping to change at page 6, line 38 skipping to change at page 6, line 38
5. Backward Compatibility and Deployment 5. Backward Compatibility and Deployment
The implementation and deployment of the ESN TLV can be done to The implementation and deployment of the ESN TLV can be done to
support backward compatibility and gradual deployment in the network support backward compatibility and gradual deployment in the network
without requiring a flag day. This feature can also be deployed for 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 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. mechanism is needed, or it can be deployed for the entire network.
The implementation SHOULD allow the configuration of ESN TLV feature The implementation SHOULD allow the configuration of ESN TLV feature
on each IS-IS link level. The implementation SHOULD also allow on each IS-IS link level. The implementation SHOULD also allow
operators to control the configuration of 'send' and/or 'verify' the 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 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 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 IS-IS PDUs; and the 'verify' operation is to process the ESN TLV in
the receiving IS-IS PDUs from neighbors. the receiving IS-IS PDUs from neighbors.
In the face of an adversary doing an active attack, it is possible to 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 have inconsistent data view in the network, if there is a
considerable delay in enabling ESN TLV 'verify' operation from first considerable delay in enabling ESN TLV 'verify' operation from first
node to the last node in the network. This can happen primarily 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 because, replay PDUs can potentially be accepted by the nodes where
'verify' operation is still not provisioned at the time of the 'verify' operation is still not provisioned at the time of the
attack. To minimize such a window it is recommended that attack. To minimize such a window it is recommended that
provisioning of 'verify' SHOULD be done in a timely fashion by the provisioning of 'verify' SHOULD be done in a timely fashion by the
network operators. network operators.
5.1. IIH and SNPs 5.1. IIH and SNPs
On the link level, ESN TLV involves the IIH PDUs and SNPs (both CSNP 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 and PSNP). The "send" and "verify" modes described above can be set
skipping to change at page 7, line 27 skipping to change at page 7, line 29
interface MUST contain the ESN TLV. Any such PDU received without an interface MUST contain the ESN TLV. Any such PDU received without an
ESN TLV MUST be discarded when 'verify' mode is enabled. Similarly, ESN TLV MUST be discarded when 'verify' mode is enabled. Similarly,
to safely disable ESN support on a link, 'verify' mode is disabled on 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 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. disabled from 'verify' mode 'send' mode can be disabled on each IS.
Please refer Section 5 for considerations on enabling or disabling Please refer Section 5 for considerations on enabling or disabling
'verify' mode on all ISs on a link. 'verify' mode on all ISs on a link.
6. IANA Considerations 6. IANA Considerations
This document requests that IANA allocate from the IS-IS TLV A new TLV code point is assigned by IANA from the IS-IS TLV
Codepoints Registry a new TLV, referred to as the "Extended Sequence Codepoints Registry as defined in this document, referred to as the
Number" TLV, with the following attributes: "Extended Sequence Number" TLV, with the following attributes:
Type Description IIH LSP SNP Purge Type Description IIH LSP SNP Purge
---- --------------------- --- --- --- ----- ---- --------------------- --- --- --- -----
TBD ESN TLV Y N Y N 11 ESN TLV Y N Y N
Figure 2: IS-IS Codepoints Registry Entry Figure 2: IS-IS Codepoints Registry Entry
7. Security Considerations 7. Security Considerations
This document describes a mechanism to the replay attack threat as This document describes a mechanism to the replay attack threat as
discussed in the Security Considerations section of [RFC5304] and in discussed in the Security Considerations section of [RFC5304] and in
[RFC5310]. This document does not introduce any new security [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 concerns to IS-IS or any other specifications referenced in this
document. document.
8. Contributors 8. Contributors
Authors would like to thank Les Ginsberg for his significant Authors would like to thank Les Ginsberg for his significant
contribution in detailed reviews and suggestions. contribution in detailed reviews and suggestions.
9. Acknowledgements 9. Acknowledgements
As some sort of sequence number mechanism to thwart protocol replays As some sort of sequence number mechanism to thwart protocol replays
is a old mechanism, authors of this document do not make any claims is a old mechanism, authors of this document do not make any claims
on the originality of the overall protection idea described. Authors on the originality of the overall protection idea described. Authors
are thankful for the review and the valuable feedback provided by are thankful for the review and the valuable feedback provided by
Acee Lindem and Joel Halpern. Thanks to Alia Atlas, Chris Hopps, Acee Lindem and Joel Halpern. Thanks to Alia Atlas, Chris Hopps,
Nevil Brownlee and Adam W. Montville for their reviews and Nevil Brownlee and Adam W. Montville for their reviews and
suggestions during IESG directorate review. 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. Appendix A 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.
[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 IS-IS nodes implementing this specification SHOULD use available
mechanisms to preserve the 64-bit Extended Session Sequence Number's mechanisms to preserve the 64-bit Extended Session Sequence Number's
strictly increasing property, whenever it is changed for the deployed strictly increasing property, whenever it is changed for the deployed
life of the IS-IS node (including cold restarts). life of the IS-IS node (including cold restarts).
This Appendix provides only guidelines for achieving the same and This Appendix provides only guidelines for achieving the same and
implementations can resort to any similar method as far as strictly implementations can resort to any similar method as far as strictly
increasing property of the 64-bit ESSN in ESN TLV is maintained. increasing property of the 64-bit ESSN in ESN TLV is maintained.
10.1. Appendix A.1 A.1. Using Timestamp
One mechanism for accomplishing this is by encoding 64-bit ESSN as One mechanism for accomplishing this is by encoding 64-bit ESSN as
system time represented in 64-bit unsigned integer value. This MAY system time represented in 64-bit unsigned integer value. This MAY
be similar to the system timestamp encoding for NTP long format as 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 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 when the IS-IS node loses its sequence number state including in
Packet Sequence Number wrap scenarios. Packet Sequence Number wrap scenarios.
Implementations MUST make sure while encoding the 64-bit ESN value Implementations MUST make sure while encoding the 64-bit ESN value
with current system time, it should not default to any previous value with current system time, it should not default to any previous value
or some default node time of the system; especially after cold or some default node time of the system; especially after cold
restarts or any other similar events. In general system time must be restarts or any other similar events. In general system time must be
preserved across cold restarts in order for this mechanism to be preserved across cold restarts in order for this mechanism to be
feasible. One example of such implementation is to use a battery feasible. One example of such implementation is to use a battery
backed real-time clock (RTC). backed real-time clock (RTC).
10.2. Appendix A.2 A.2. Using Non-Volatile Storage
One other mechanism for accomplishing this would be similar to the One other mechanism for accomplishing this would be similar to the
one as specified in [I-D.ietf-ospf-security-extension-manual-keying], one as specified in [RFC7474], to use the 64-bit ESSN as a wrap/boot
to use the 64-bit ESSN as a wrap/boot count stored in non-volatile count stored in non-volatile storage. This value is incremented
storage. This value is incremented anytime the IS-IS node loses its anytime the IS-IS node loses its sequence number state including in
sequence number state including in Packet Sequence Number wrap Packet Sequence Number wrap scenarios.
scenarios.
The drawback of this approach per Section 6 of [I-D.ietf-ospf- The drawback of this approach per Section 8 of [RFC7474], if used is
security-extension-manual-keying], if used is applicable here. The applicable here. It requires the IS-IS implementation to be able to
only drawback is, it requires the IS-IS implementation to be able to
save its boot count in non-volatile storage. If the non-volatile save its boot count in non-volatile storage. If the non-volatile
storage is ever repaired or upgraded such that the contents are lost, storage is ever repaired or router hardware is upgraded such that the
keys MUST be changed to prevent replay attacks. contents are lost, keys MUST be changed to prevent replay attacks.
11. Appendix B
11.1. Operational/Implementation consideration Appendix B. Operational/Implementation consideration
Since the ESN is maintained per interface, per level and per PDU 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- 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 IS adjacency. A Packet Sequence Number skip on IIH can be recorded
by the neighbors which can be used later to correlate with adjacency by the neighbors which can be used later to correlate with adjacency
state changes over the interface. For instance in a multi-access state changes over the interface. For instance in a multi-access
media, all the neighbors have the skips from the same IIH sender or media, all the neighbors have the skips from the same IIH sender or
only one neighbor has the Packet Sequence Number skips can indicate only one neighbor has the Packet Sequence Number skips can indicate
completely different issues on the network. Effective usage of the completely different issues on the network. Effective usage of the
TLV defined in this document for operational issues MAY also need TLV defined in this document for operational issues MAY also need
more system information before making concrete conclusions and more system information before making concrete conclusions and
defining all that information is beyond the scope of this document. defining all that information is beyond the scope of this document.
12. References
12.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.
12.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-03 (work in
progress), September 2014.
[I-D.ietf-ospf-security-extension-manual-keying]
Bhatia, M., Hartman, S., Zhang, D., and A. Lindem,
"Security Extension for OSPFv2 when using Manual Key
Management", draft-ietf-ospf-security-extension-manual-
keying-11 (work in progress), November 2014.
[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.
Authors' Addresses Authors' Addresses
Uma Chunduri Uma Chunduri
Ericsson Inc. Ericsson Inc.
300 Holger Way, 300 Holger Way,
San Jose, California 95134 San Jose, California 95134
USA USA
Phone: 408 750-5678 Phone: 408 750-5678
Email: uma.chunduri@ericsson.com Email: uma.chunduri@ericsson.com
 End of changes. 27 change blocks. 
100 lines changed or deleted 108 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/