< draft-chunduri-isis-extended-sequence-no-tlv-03.txt   draft-chunduri-isis-extended-sequence-no-tlv-04.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: April 25, 2013 Ericsson Inc. Expires: July 22, 2013 Ericsson Inc.
N. Shen N. Shen
Cisco Systems, Inc. Cisco Systems, Inc.
October 22, 2012 January 18, 2013
IS-IS Extended Sequence number TLV IS-IS Extended Sequence number TLV
draft-chunduri-isis-extended-sequence-no-tlv-03 draft-chunduri-isis-extended-sequence-no-tlv-04
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 April 25, 2013. This Internet-Draft will expire on July 22, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Replay attacks and Impact on IS-IS networks . . . . . . . . . 4 2. Replay attacks and Impact on IS-IS networks . . . . . . . . . 4
2.1. Impact of Replays . . . . . . . . . . . . . . . . . . . . 4 2.1. Impact of Replays . . . . . . . . . . . . . . . . . . . . 4
3. Extended Sequence Number TLV . . . . . . . . . . . . . . . . . 5 3. Extended Sequence Number TLV . . . . . . . . . . . . . . . . . 5
3.1. Sequence Number Wrap . . . . . . . . . . . . . . . . . . . 6 3.1. Sequence Number Wrap . . . . . . . . . . . . . . . . . . . 6
4. Mechanism and Packet Encoding . . . . . . . . . . . . . . . . 6 4. Mechanism and Packet Encoding . . . . . . . . . . . . . . . . 7
4.1. IIHs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. IIHs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. SNPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. SNPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. CSNPs . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. CSNPs . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.2. PSNPs . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.2. PSNPs . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Backward Compatibility and Deployment . . . . . . . . . . . . 8 5. Backward Compatibility and Deployment . . . . . . . . . . . . 8
5.1. IIH and SNPs . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. IIH and SNPs . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Operational Consideration . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Appendix A.1 . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Appendix A.1 . . . . . . . . . . . . . . . . . . . . . . . 10
9.2. Appendix A.2 . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Appendix A.2 . . . . . . . . . . . . . . . . . . . . . . . 10
10. Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Operational/Implementation consideration . . . . . . . . . 11 10.1. Operational/Implementation consideration . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
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, IS-IS has been adopted
widely in various L2 and L3 routing deployment of the data centers widely in various L2 and L3 routing deployment of the data centers
for critical business operations. At the meantime the SDN-enabled for critical business operations. At the meantime the SDN-enabled
networks even though put more power to Internet applications and also networks even though put more power to Internet applications and also
make network management easier, it does raise the security make network management easier, it does raise the security
requirement of network routing infrastructure to another level. requirement of network routing infrastructure to another level.
This document defines Extended Sequence number (ESN) TLV to protect
Intermediate System to Intermediate System (IS-IS) PDUs from replay
attacks.
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,
Link State PDUs (LSPs) have sequence number in the LSP header as Link State PDUs (LSPs) have sequence number in the LSP header as
defined in [RFC1195], with which it can effectively mitigate the defined in [RFC1195], with which it can effectively mitigate the
intra-session replay attacks. But, LSPs are still susceptible to intra-session replay attacks. But, LSPs are still susceptible to
inter-session replay attacks. 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 The new ESN TLV defined here thwart these threats and can be deployed
with authentication mechanism as specified in [RFC5304] and in with authentication mechanism as specified in [RFC5304] and in
[RFC5310] for a more secure network. [RFC5310] for a more secure network.
Replay attacks can be effectively mitigated by deploying a group key Replay attacks can be effectively mitigated by deploying a group key
management protocol (being developed as defined in [I-D.yeung-g- management protocol (being developed as defined in [I-D.yeung-g-
ikev2] and [I-D.hartman-karp-mrkmp]) with a frequent key change ikev2] and [I-D.hartman-karp-mrkmp]) with a frequent key change
policy. Currently, there is no such mechanism defined for IS-IS. 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 Even if such a mechanism is defined, usage of this TLV can be helpful
to avoid replays before the keys are changed. to avoid replays before the keys are changed.
skipping to change at page 5, line 7 skipping to change at page 5, line 7
Today Link State PDUs (LSPs) have intra-session replay protection as Today Link State PDUs (LSPs) have intra-session replay protection as
LSP header contains 32-bit sequence number which is verified for LSP header contains 32-bit sequence number which is verified for
every received PDU against the local LSP database. But, if the key every received PDU against the local LSP database. But, if the key
is not changed, an adversary can cause an inter-session replay attack is not changed, an adversary can cause an inter-session replay attack
by replaying a old LSP with higher sequence number and fewer prefixes by replaying a old LSP with higher sequence number and fewer prefixes
or fewer adjacencies. This forces the receiver to accept and remove or fewer adjacencies. This forces the receiver to accept and remove
the routes from the routing table, which eventually causes traffic the routes from the routing table, which eventually causes traffic
disruption to those prefixes. The more common pre-conditions for disruption to those prefixes. The more common pre-conditions for
inter-session replay attacks with LSPs and the current in-built inter-session replay attacks with LSPs and the current in-built
recovery mechanism, have been discussed in details in KARP IS-IS gap recovery mechanism, have been discussed in details in Section 2.3.1.1
analysis document [I-D.chunduri-karp-is-is-gap-analysis]. of KARP IS-IS gap analysis document [I-D.chunduri-karp-is-is-gap-
analysis]. This document does not propose any solution to completely
mitigate the replay threat for LSPs as network can still recover
reliably after processing a disruptive reply.
In broadcast networks a replayed Complete Sequence Number PDU (CSNP) In broadcast networks a replayed Complete Sequence Number PDU (CSNP)
can force the receiver to request Partial Sequence Number PDU (PSNP) can force the receiver to request Partial Sequence Number PDU (PSNP)
in the network and similarly, a replayed PSNP can cause unnecessary in the network and similarly, a replayed PSNP can cause unnecessary
LSP flood in the network. LSP flood in the network.
Please refer KARP IS-IS gap analysis document for further details. Please refer KARP IS-IS gap analysis document for further details.
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 an 8 or 12 byte Value field. and a 12 byte Value field. This TLV is defined only for IIH and SNP
PDUs.
x CODE - TBD. x CODE - TBD.
x LENGTH - total length of the value field, which is 12 bytes for x LENGTH - total length of the value field, which is 12 bytes and
IIH, SNP PDUs and 8 bytes for LSPs. applicable for IIH and SNP PDUs.
x Value - 64-bit Extended Session Sequence Number (ESSN), which is x Value - 64-bit Extended Session Sequence Number (ESSN), which is
present for all IS-IS PDUs followed 32 bit monotonically increasing present for all IS-IS PDUs followed 32 bit monotonically increasing
per Packet Sequence Number (PSN). PSN is not required for LSPs. per Packet Sequence 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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type | | Type |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Session Sequence Number (High Order 32 Bits) | | Extended Session Sequence Number (High Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Session Sequence Number (Low Order 32 Bits) | | Extended Session Sequence Number (Low Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional) Packet Sequence Number (32 Bits) | | Packet Sequence Number (32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Extended Sequence Number (ESN) TLV Figure 1: Extended Sequence Number (ESN) TLV
The Extended Sequence Number (ESN) TLV Type is TBD. Please refer to The Extended Sequence Number (ESN) TLV Type is TBD. Please refer to
IANA Considerations, in Section 6 for more details. Length indicates IANA Considerations, in Section 6 for more details. Length indicates
the length of the value field; which is 12 bytes for IIH and SNP PDUs the length of the value field; which is 12 bytes for IIH and SNP
and 8 bytes for LSPs. PDUs.
In order to provide protection against both inter-session and intra- In order to provide protection against both inter-session and intra-
session replay attacks, the IS-IS Extended Session Sequence Number session replay attacks, the IS-IS Extended Session Sequence Number
(ESSN) is defined a 64-bits value; the value MUST contain ever (ESSN) is defined a 64-bits value; the value MUST contain ever
increasing number in all IS-IS PDUs including LSPs whenever it is increasing number in IIH and SNP PDUs whenever it is changed due any
changed due any situation as specified in Section 3.1. situation as specified in Section 3.1.
The 32-bit Packet Sequence Number (PSN) MUST be set and increase The 32-bit Packet Sequence Number (PSN) MUST be set and increase
monotonically for IIH or SNP PDUs sent by IS-IS node. Upon monotonically for IIH or SNP PDUs sent by IS-IS node. Upon
reception, the Packet Sequence number MUST be greater than the last reception, the Packet Sequence number MUST be greater than the last
sequence number in the IIH or SNP PDUs accepted from the sending sequence number in the IIH or SNP PDUs accepted from the sending
IS-IS node. Otherwise, the IIH or SNP PDU is considered as replayed IS-IS node. Otherwise, the IIH or SNP PDU is considered as replayed
PDU and dropped. PDU and dropped.
As LSPs contain 32-bit sequence number field already in the LSP The ESN TLV defined here is optional. The ESN TLV MAY present only
header, Packet Sequence Number in the ESN TLV MUST be omitted by in any IIH and SNP PDUs. If present and authentication is in use
setting the length field to 8 bytes and implementations continue to this TLV MUST be included as part of the authentication data to
refer the header sequence number for all encoding and validation calculate the digest. A sender MUST only transmit a single ESN TLV
purposes. in a IS-IS PDU.
The ESN TLV defined here is optional. The ESN TLV MAY present in any
IS-IS PDU. If present and authentication is in use this TLV MUST be
included as part of the authentication data to calculate the digest.
A sender MUST only transmit a single ESN TLV in a IS-IS PDU.
3.1. Sequence Number Wrap 3.1. Sequence Number Wrap
If the 32-bit Packet Sequence Number in ESN TLV and for LSPs the 32- If the 32-bit Packet Sequence Number in ESN TLV wraps; or session is
bit header sequence number wraps; or session is refreshed; or even refreshed; or even for the cold restarts the 64-bit ESSN value MUST
for the cold restarts the 64-bit ESSN value MUST be set higher than be set higher than the previous value. IS-IS implementations MAY use
the previous value. IS-IS implementations MAY use guidelines guidelines provided in Section 9 for accomplishing this.
provided in Section 9 for accomplishing this.
4. Mechanism and Packet Encoding 4. Mechanism and Packet Encoding
The ESN TLV defined in this document is optional and the encoding and The ESN TLV defined in this document is optional and the encoding and
decoding of this TLV in each IS-IS PDU is as detailed below. Also decoding of this TLV in each IS-IS PDU is as detailed below. Also
refer, when to ignore processing of the ESN TLV as described in refer, when to ignore processing of the ESN TLV as described in
Section 5 for appropriate operation in the face of legacy node(s) in Section 5 for appropriate operation in the face of legacy node(s) in
the network with out having this capability. the network with out having this capability.
4.1. IIHs 4.1. IIHs
skipping to change at page 8, line 7 skipping to change at page 8, line 15
should be used. should be used.
4.2.2. PSNPs 4.2.2. PSNPs
In both broadcast and P2P networks, PSNP ESN TLV information is In both broadcast and P2P networks, PSNP ESN TLV information is
maintained per adjacency (per level) similar to IIH ESN TLV maintained per adjacency (per level) similar to IIH ESN TLV
information. The procedure for encoding, verification and sequence information. The procedure for encoding, verification and sequence
number wrap scenarios are similar as explained in Section 4.1, except number wrap scenarios are similar as explained in Section 4.1, except
separate PSNP ESN TLV information should be used. separate PSNP ESN TLV information should be used.
4.3. LSPs
For LSPs, while originating, the 64-bit ESSN MUST always be started
with a non zero number and MAY use the guidelines as specified in
Section 9 for encoding this value.
While receiving, the 64-bit Extended Sequence Number MUST always be
either same or higher than the stored value in the LSP database.
This document does not specify any changes for the existing LSP
header 32-bit sequence number validation mechanism.
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. The deployment can be done for IS-IS without requiring a flag day. This feature can also be deployed for
links only, or for both IS-IS links and nodes in the networks. This the links in a certain area of the network where the maximum security
feature can also be deployed for the links in a certain area of the mechanism is needed, or it can be deployed for the entire network.
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 The implementation SHOULD allow the configuration of ESN TLV feature
on each IS-IS link level and on IS-IS node level with area/level on each IS-IS link level. The implementation SHOULD also allow
scope. The implementation SHOULD also allow operators to control the operators to control the configuration of 'send' and/or 'verify' the
configuration of 'send' and/or 'verify' the feature of IS-IS PDUs for feature of IS-IS PDUs for the links and for the node. In this
the links and for the node. In this document, the 'send' operation document, the 'send' operation is to include the ESN TLV in it's own
is to include the ESN TLV in it's own IS-IS PDUs; and the 'verify' IS-IS PDUs; and the 'verify' operation is to process the ESN TLV in
operation is to process the ESN TLV in the receiving IS-IS PDUs from the receiving IS-IS PDUs from neighbors.
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. 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
provisioning of 'verify' SHOULD be done in a timely fashion by the
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). When the router software is upgraded to include this and PSNP). When the router software is upgraded to include this
feature, the network operators can configure the IS-IS to 'send' the feature, the network operators can configure the IS-IS to 'send' the
ESN TLV in it's IIH PDUs and SNPs for those IS-IS interfaces on the ESN TLV in it's IIH PDUs and SNPs for those IS-IS interfaces on the
IS-IS area or level. When all the routers attached to the link or IS-IS area or level. When all the routers attached to the link or
links have been upgraded with this feature, network operators can links have been upgraded with this feature, network operators can
start to configure 'verify' on the IS-IS interfaces for all the start to configure 'verify' on the IS-IS interfaces for all the
routers sharing the same link(s). This way deployment can be done in routers sharing the same link(s). This way deployment can be done in
per link basis in the network. Please further refer Section 5.3 for per link basis in the network. The operators may decide to only
note on operational considerations at the time of 'verify' operation apply ESN TLV feature on some of the links in the network, or only on
in the network. The operators may decide to only apply ESN TLV their multi-access media links.
feature on some of the links in the network, or only on their multi-
access media links.
5.2. LSPs
On the node level with an area or level scope, ESN TLV involves the
IS-IS LSPs. This feature has to be done for the entire IS-IS area or
levels with the same flooding domain. The deployment and upgrade of
software to support ESN TLV can be gradual and from node to node.
When a node is upgraded to support this feature, the operators can
configure the node level 'send' in the desired area/level(s) to
include the ESN TLV in it's own LSPs. No 'verify' is enabled until
all the routers in the entire IS-IS area/level or entire network is
upgraded. Then the operators can configure the 'verify' for the
IS-IS node level from node to node. Please further refer Section 5.3
for note on operational considerations at the time of 'verify'
operation in the network. When all the nodes performs the 'verify'
of ESN TLVs, the node level ESN TLV feature is supported fully in the
network.
5.3. Operational Consideration
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. 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
provisioning of 'verify' SHOULD be done in a timely fashion by the
network operators.
6. IANA Considerations 6. IANA Considerations
This document requests that IANA allocate from the IS-IS TLV This document requests that IANA allocate from the IS-IS TLV
Codepoints Registry a new TLV, referred to as the "Extended Sequence Codepoints Registry a new TLV, referred to as the "Extended Sequence
Number" TLV, with the following attributes: IIH = y, LSP = y, SNP = Number" TLV, with the following attributes:
y, Purge = y.
Type Description IIH LSP SNP Purge
---- --------------------- --- --- --- -----
TBD ESN TLV Y N Y N
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]. 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. Acknowledgements 8. Acknowledgements
skipping to change at page 11, line 39 skipping to change at page 11, line 23
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
11.2. Informative References 11.2. Informative References
[I-D.chunduri-karp-is-is-gap-analysis] [I-D.chunduri-karp-is-is-gap-analysis]
Chunduri, U., Tian, A., and W. Lu, "KARP IS-IS security Chunduri, U., Tian, A., and W. Lu, "KARP IS-IS security
gap analysis", draft-chunduri-karp-is-is-gap-analysis-01 gap analysis", draft-chunduri-karp-is-is-gap-analysis-03
(work in progress), March 2012. (work in progress), October 2012.
[I-D.hartman-karp-mrkmp] [I-D.hartman-karp-mrkmp]
Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router
Key Management Protocol (MaRK)", Key Management Protocol (MaRK)",
draft-hartman-karp-mrkmp-05 (work in progress), draft-hartman-karp-mrkmp-05 (work in progress),
September 2012. September 2012.
[I-D.ietf-karp-threats-reqs] [I-D.ietf-karp-threats-reqs]
Lebovitz, G. and M. Bhatia, "Keying and Authentication for Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
Routing Protocols (KARP) Overview, Threats, and Authentication for Routing Protocols (KARP) Overview,
Requirements", draft-ietf-karp-threats-reqs-05 (work in Threats, and Requirements",
progress), May 2012. draft-ietf-karp-threats-reqs-07 (work in progress),
December 2012.
[I-D.ietf-ospf-security-extension-manual-keying] [I-D.ietf-ospf-security-extension-manual-keying]
Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Bhatia, M., Hartman, S., Zhang, D., and A. Lindem,
"Security Extension for OSPFv2 when using Manual Key "Security Extension for OSPFv2 when using Manual Key
Management", Management",
draft-ietf-ospf-security-extension-manual-keying-02 (work draft-ietf-ospf-security-extension-manual-keying-02 (work
in progress), April 2012. in progress), April 2012.
[I-D.weis-gdoi-mac-tek] [I-D.weis-gdoi-mac-tek]
Weis, B. and S. Rowles, "GDOI Generic Message Weis, B. and S. Rowles, "GDOI Generic Message
 End of changes. 28 change blocks. 
109 lines changed or deleted 75 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/