Re: [secdir] Security review of draft-ietf-isis-extended-sequence-no-tlv-04

[Uma Chunduri <[e-mail]>]

Hi Adam,

Thank you. My quick response in-line [Uma1]:

--
Uma C.

From: Adam W. Montville [mailto:[e-mail]]
Sent: Thursday, April 02, 2015 4:26 AM
To: Uma Chunduri
Cc: The IESG; [e-mail]; [e-mail]
Subject: Re: Security review of draft-ietf-isis-extended-sequence-no-tlv-04

Thanks for your response.  I have a few more comments inline.


On Apr 1, 2015, at 5:07 PM, Uma Chunduri <[e-mail]<mailto:[e-mail]>> wrote:

Hi Adam,

Thanks for your review and suggestions.
Please see my replies in-line [Uma]:

-----Original Message-----
From: Adam W. Montville [mailto:[e-mail]]
Sent: Wednesday, April 01, 2015 6:29 AM
To: The IESG; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Security review of draft-ietf-isis-extended-sequence-no-tlv-04

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.

[Uma]: As you stated though this is possible theoretically, it is almost impractical if the right method of encoding is used. For every PDU only 32-bit PSN  increases and only when it wraps ESSN value is incremented. There are two approaches specified in Appendix (only as mere guidelines) of this draft to encode ESSN (64-bit) value.  If timestamps are used (Appendix A.1) to encode this value I don’t see the possibility for this to happen before the lifetime of the router perhaps.


It would be useful to include such information in the draft, as it may not be readily clear to readers that the authors feel the 64-bit value is “intractable” in a sense.

[Uma1]: I shall add a reference to Appendix A.2 perhaps and clarification text surrounding the same.

However, in Appendix A.2, non-volatile storage (Page 7)  it’s clearly stated that –
    “If the non-volatile
   storage is ever repaired or upgraded such that the contents are lost,
   keys MUST be changed to prevent replay attacks.”



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).

[Uma]: Appendix only proposes to use timestamps as a potential approach to encode the ESSN field of the TLV to get the ever increasing property in all cases. Please  note the approach for replay attack mitigation here is Extended Sequence numbers as specified in the TLV. There could be and may be more mechanisms to solve the same problem at hand but those are beyond the scope of this document. There is *no negotiation* required with neighbor on how to encode this value. This is purely a local matter as long as the “ever increasing” property is maintained, when 32-bit PSN is ever wrapped/cold-restart cases as explained in section 3.1.

It may be the case that I have a less-than-complete understanding of the problem domain.  My understanding is that one of the mitigation circumstances pertains to IS-IS Hello, where neighbors are being brought up and sending IIH to others.  Does this not make it a neighborhood problem?
Even if all neighbors understand the “ever increasing” property, how would they understand which encoding is in place without some additional information?
[Uma1]: There is no need to understand the encoding by neighbor as long as it’s property is maintained (as receiver would verify the unsigned integer value).

It would probably be beneficial to provide some indication in the TLV as to how ESSN is encoded.  Alternatively, if there is a method to deduce the ever increasing property without knowing the ESSN encoding, that should be explained (or at least referenced, if explained elsewhere).

 [Uma1]:  I felt it’s clear - It’s an unsigned integer value per current text at the end of Section 3 (last paragraph). I shall work with you to finalize more clarifying text around this.