Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833FA1A8799; Wed, 1 Apr 2015 15:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQvx7k0wAO1p; Wed, 1 Apr 2015 15:07:49 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7501A8773; Wed, 1 Apr 2015 15:07:48 -0700 (PDT) X-AuditID: c6180641-f790b6d000004359-24-551c09dc1be0 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id DF.42.17241.CD90C155; Wed, 1 Apr 2015 17:08:12 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0210.002; Wed, 1 Apr 2015 18:07:41 -0400 From: Uma Chunduri To: "Adam W. Montville" , The IESG , "secdir@ietf.org" , "draft-ietf-isis-extended-sequence-no-tlv.all@tools.ietf.org" Thread-Topic: Security review of draft-ietf-isis-extended-sequence-no-tlv-04 Thread-Index: AQHQbH/Zhsqwc8PAg0OvMaxLgCljg504XO/g Date: Wed, 1 Apr 2015 22:07:40 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F61E19F@eusaamb105.ericsson.se> References: <718D753F-E377-4197-9F01-C34C12EC5CA0@gmail.com> In-Reply-To: <718D753F-E377-4197-9F01-C34C12EC5CA0@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008633F61E19Feusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPrO4dTplQg2cnZCy2PGxjsdh38x27 xYw/E5ktPix8yOLA4rFz1l12jyVLfjJ5fLn8mS2AOYrLJiU1J7MstUjfLoEr49LB/YwF6xoZ K67MiG9gXJHbxcjJISFgIjH53A1mCFtM4sK99WxdjFwcQgJHGSXeP3/MBOEsY5T4Mn8uE0gV m4CexMepP9lBEiIC3xglfj6ezAKSEBbwlvjU3cYGYosI+EhsnvSYHcI2kth07iRYM4uAisS6 SxA1vAK+Ep8+ngVbLSRgI3Fs406wek4BW4l5OyBmMgKd9P3UGrBeZgFxiVtP5jNBnCogsWTP eaizRSVePv7HCmErSuzrnw40hwOoPl/i7XF2iFWCEidnPmGZwCgyC8mkWQhVs5BUQZToSCzY /YkNwtaWWLbwNTOMfebAYyZk8QWM7KsYOUqLU8ty040MNzECY+uYBJvjDsYFnywPMQpwMCrx 8D6QkA4VYk0sK67MPcQozcGiJM5bduVgiJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGjotC 4V3WG6cXNU8PfqIeLpyu8n17ytJ37GsyO+642U89lNqwsPx1m8yz49XPWT0XBMQ8Oxc+/8Dq z1JWUoJ3Ck+vMeVTPPBvedWpu1Ofn321t3kWR+i6tYY729dOOXnF2Pz7DJupiRKq/+XDolct OlghGqdyL+Ozov6iQrbTmq43z4V/vZzQqMRSnJFoqMVcVJwIALXdQE2OAgAA Archived-At: X-Mailman-Approved-At: Wed, 01 Apr 2015 15:11:11 -0700 Subject: Re: [secdir] Security review of draft-ietf-isis-extended-sequence-no-tlv-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 22:07:53 -0000 --_000_1B502206DFA0C544B7A60469152008633F61E19Feusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adam, Thanks for your review and suggestions. Please see my replies in-line [Uma]: -----Original Message----- From: Adam W. Montville [mailto:adam.w.montville@gmail.com] Sent: Wednesday, April 01, 2015 6:29 AM To: The IESG; secdir@ietf.org; draft-ietf-isis-extended-sequence-no-tlv.all= @tools.ietf.org 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 co= mments were written primarily for the benefit of the security area director= s. 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 (h= ello). 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 circumsta= nces. The structure of the sequence is defined as a new TLV called "ESN TL= V". 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 a= s 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, there= fore, "has" an ESSN, which is associated with a monotonically increasing PS= N. 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 pra= cticality. 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 prac= tical circumstance would the ESSN ever become that large; but, if that's th= e case, then it might be best to state so in the draft. [Uma]: As you stated though this is possible theoretically, it is almost im= practical if the right method of encoding is used. For every PDU only 32-bi= t PSN increases and only when it wraps ESSN value is incremented. There a= re two approaches specified in Appendix (only as mere guidelines) of this d= raft 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. 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 for= mat 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 al= l cases. Please note the approach for replay attack mitigation here is Ext= ended 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 "ev= er increasing" property is maintained, when 32-bit PSN is ever wrapped/cold= -restart cases as explained in section 3.1. 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 s= olution? [Uma]: As I said above sequence number mechanism is the chosen option to so= lve the problem. For example, IS-IS LSP PDU already has 32-bit sequence num= ber, which can effectively being used also for mitigating intra-session re= play attacks. The current method is to extend this approach to prevent int= er and intra session replay attacks for non-LSP PDUs. IMO, other possible = methods to solve this problem (as you mentioned time stamps, frequent key c= hanges through a key management protocol etc..) is beyond the scope of the = current work. Nits: There was at least one area of the text that could probably be clarified fo= r the sake of non-security-familiar folks. The paragraph in section 2.1 cou= ld be changed as follows, to make clear that the authenticated case of IIH = is where mitigation can be made. OLD At the time of adjacency bring up an IS sends IIH packet with empty neighbo= r list (TLV 6) and with or without the authentication information as per pr= ovisioned authentication mechanism. If this packet is replayed later on th= e broadcast network all ISes in the broadcast network can bounce the adjace= ncy to create a huge churn in the network. NEW When an adjacency is brought up an IS sends an IIH packet with an empty nei= ghbor list (TLV 6), which can be sent with or without authentication inform= ation. Packets can be replayed later on the broadcast network which may ca= use all ISes to bounce the adjacency, thus churning the network. Note that= mitigating replay is only possible when authentication information is pres= ent. [Uma]: Sure, I shall change the text as you suggested. Thank you. In general, I recommend reviewing the draft for clarity. Kind regards, Adam --_000_1B502206DFA0C544B7A60469152008633F61E19Feusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Adam,
 
Thanks for your review and suggestions.
Please see my replies in-line [Uma]:
 <= /div>
-----Original Message= -----
From: Adam W. Montville [mail= to:adam.w.montville@gmail.com]
Sent: Wednesday, April 01, 2015 6:29 AM
To: The IESG; secdir@ietf.org; draft-ietf-isis-extended-sequence-no-tlv.all= @tools.ietf.org
Subject: Security review of draft-ietf-isis-extended-sequence-no-tlv-04
 <= /div>
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 writ= ten primarily for the benefit of the security area directors.
 <= /div>
This draft is ready w= ith issues.
 <= /div>
There are two circums= tances within IS-IS that are subject to replay attacks.  One can happe= n 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. 
 <= /div>
This draft proposes a= sequence to mitigate replay attacks in both circumstances.  The struc= ture of the sequence is defined as a new TLV called "ESN TLV".&nb= sp; 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 v= alue, which is non-zero and unsigned), and Packet Sequence Number (PSN; a 3= 2-bit value).  A given ESN is associated with a particular Protocol Data Unit (PDU).  A PDU, therefore, "h= as" an ESSN, which is associated with a monotonically increasing PSN.&= nbsp; If the PSN wraps or if the device needs to be restarted, then the nex= t ESSN must be larger than the previous ESSN.
 <= /div>
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 t= hat'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.
 <= /div>
[Uma]: As you stated though this is possible theoretically, it is almo= st 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 incremente= d. 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 t= he router perhaps.  However, in Appendix A.2, non-volatile storage (Page 7)  it’s clearly stated that –<= /div>
=     “= If the non-volatile
=    storage is ever repaired or upgraded such that the contents ar= e lost,
=    keys MUST be changed to prevent replay attacks.”<= /font>
 <= /div>
 <= /div>
 <= /div>
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= ). 
 <= /div>
[Uma]: Appendix only proposes to use timestamps as a potential approa= ch 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 h= ere is Extended Sequence numbers as specified in the TLV. There could be and may be more mechanisms to solve the same pr= oblem at hand but those are beyond the scope of this document. There is *no negotiation* required with neighbor on how to encode this value. Th= is is purely a local matter as long as the “ever increasing” property is maintained, when 32-bit PS= N is ever wrapped/cold-restart cases as explained in section 3.1.
 <= /div>
There may be valid op= erational reasons to favor a sequence over timestamps for replay mitigation= , but such considerations appear absent in this draft.  Is there a rea= son timestamps are being avoided as the replay mitigation solution?
 <= /div>
[Uma]: As I said above sequence number mechanism is the chosen option = to solve the problem. For example, IS-IS LSP PDU already has 32-bit sequenc= e number, which can effectively being used also for mitigating intra-sessi= on replay attacks.  The current method is to extend this approach to prevent inter and intra session replay= attacks for non-LSP PDUs.  IMO, other possible methods to solve this = problem (as you mentioned time stamps, frequent key changes through a key m= anagement protocol etc..) is beyond the scope of the current work.
 <= /div>
 <= /div>
Nits:
 <= /div>
There was at least on= e area of the text that could probably be clarified for the sake of non-sec= urity-familiar folks. The paragraph in section 2.1 could be changed as foll= ows, to make clear that the authenticated case of IIH is where mitigation can be made.
 <= /div>
OLD
At the time of adjace= ncy bring up an IS sends IIH packet with empty neighbor list (TLV 6) and wi= th or without the authentication information as per provisioned authenticat= ion 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.
 <= /div>
NEW
When an adjacency is = brought up an IS sends an IIH packet with an empty neighbor list (TLV 6), w= hich 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 in= formation is present.
 <= /div>
[Uma]: Sure, I shall change the text as you suggested. Thank you.
 <= /div>
In general, I recomme= nd reviewing the draft for clarity.
 <= /div>
Kind regards,<= /font>
 <= /div>
Adam
 <= /div> --_000_1B502206DFA0C544B7A60469152008633F61E19Feusaamb105erics_--