Skip to main content

Last Call Review of draft-ietf-isis-extended-sequence-no-tlv-04

Request Review of draft-ietf-isis-extended-sequence-no-tlv
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-04-08
Requested 2015-03-19
Authors Uma Chunduri , Wenhu Lu , Albert Tian , Naiming Shen
I-D last updated 2015-04-02
Completed reviews Genart Last Call review of -05 by Christer Holmberg (diff)
Genart Telechat review of -06 by Christer Holmberg
Secdir Last Call review of -04 by Adam W. Montville (diff)
Opsdir Last Call review of -04 by Nevil Brownlee (diff)
Assignment Reviewer Adam W. Montville
State Completed
Request Last Call review on draft-ietf-isis-extended-sequence-no-tlv by Security Area Directorate Assigned
Reviewed revision 04 (document currently at 06)
Result Has issues
Completed 2015-04-02
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.

This draft is ready with issues.

There are two circumstances within IS-IS that are subject to replay attacks. 
One can happen when adjacencies are brought up and an IS sends an IIH (hello). 
The other circumstance pertains to replaying CSNP, which may cause replay of
PSNP and thus cause LSP flooding.

This draft proposes a sequence to mitigate replay attacks in both
circumstances.  The structure of the sequence is defined as a new TLV called
"ESN TLV".  It constists of the three fields, Type, Length, and Value, where
Value is to be interpreted as two separate fields.  These two fields are known
as Extended Session Sequence Number (ESSN; a 64-bit value, which is non-zero
and unsigned), and Packet Sequence Number (PSN; a 32-bit value).  A given ESN
is associated with a particular Protocol Data Unit (PDU).  A PDU, therefore,
"has" an ESSN, which is associated with a monotonically increasing PSN.  If the
PSN wraps or if the device needs to be restarted, then the next ESSN must be
larger than the previous ESSN.

This is where I see a potential issue, but maybe I'm missing a limit of
practicality.  What happens when the ESSN is at 2^64-1 and needs to increment? 
Granted that's a large number, so it might be the case that under no practical
circumstance would the ESSN ever become that large; but, if that's the case,
then it might be best to state so in the draft.

In the Appendix, the draft also goes into how timestamps may be leveraged
(which are potentially more effective at mitigating replay attacks than are
sequences), but does not clearly indicate how neighbors would negotiate the use
of timestamps or how exactly the timestamps would be used or which format then
must be used (a suggestion to look at RFC5905 is made).

There may be valid operational reasons to favor a sequence over timestamps for
replay mitigation, but such considerations appear absent in this draft.  Is
there a reason timestamps are being avoided as the replay mitigation solution?


There was at least one area of the text that could probably be clarified for
the sake of non-security-familiar folks. The paragraph in section 2.1 could be
changed as follows, to make clear that the authenticated case of IIH is where
mitigation can be made.

At the time of adjacency bring up an IS sends IIH packet with empty neighbor
list (TLV 6) and with or without the authentication information as per
provisioned authentication mechanism.  If this packet is replayed later on the
broadcast network all ISes in the broadcast network can bounce the adjacency to
create a huge churn in the network.

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.

In general, I recommend reviewing the draft for clarity.

Kind regards,