I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-roll-security-framework-04.txt Reviewer: David L. Black Review Date: January 17, 2011 IESG Telechat date: January 20, 2011 Summary: This draft is on the right track, but has open issues, described in the review. The -04 draft is significantly improved over its prior version. However, the following issues from the Gen-ART review of the -03 draft remain open in the -04 draft: [A] I remain surprised that the forwarding table in each node is not considered to be an attack target (i.e., asset to be protected). [B] I did not see any discussion of: > In general, a > routing protocol should have a robust response to partial loss of > communication/connectivity, but > within defined limits (obviously a routing protocol is helpless against an > attacker who can disable > all inter-node communication). That sort of robust response is probably part of the routing protocol itself rather as opposed to being added security functionality that secures the routing protocol, but this should be discussed, especially as all of the security features that support availability have "MAY" requirements in Section 6.4. [C] The draft does not distinguish requirements for implementation from requirements for usage (e.g., "MUST implement" & "MAY use" is a reasonable combination). Distinguishing requirements for protocol design from those for protocol deployment/usage is a good idea in general. That's a contributing factor to the next issue. [D] The level of confidentiality requirements remains open: > - The confidentiality and privacy requirements are SHOULD. Unless there is a > good reason not to do so, they both should be "MUST implement" (use can > be configured and/or negotiated). As I understand the discussion in the draft, the appropriate requirements statements are "MUST implement" and "SHOULD use" under specific circumstances (e.g., when geographic information is in use). The stated "SHOULD" requirement for privacy of geographic information is troubling, as the use of "SHOULD" instead of "MUST implement" allows systems to be deployed that cannot be configured to provide that privacy. It may be possible to work around this by stating that geographic information MUST NOT be used when confidentiality protection is not implemented. In addition, I just noticed that the word "privacy" in this draft is not connected to the concept of confidentiality - that connection should be made. idnits 2.12.05 did not find any nits. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Monday, December 27, 2010 11:14 PM > To: [email protected]; [email protected]; > [email protected]; > [email protected]; [email protected]; General Area Review Team > Cc: Black, David; JP Vasseur; David Culler; Adrian Farrel > Subject: Gen-ART review of draft-ietf-roll-security-framework-03 > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-roll-security-framework-03.txt > Reviewer: David L. Black > Review Date: December 27, 2010 > IETF LC End Date: December 30, 2010 > IESG Telechat date: January 6, 2011 > > Summary: This draft is on the right track, but has open issues, described in > the review. > > This is a security framework draft that sets out a security framework for > routing in low power and > lossy networks starting from the tripartite CIA (Confidentiality, Integrity, > Availability) set of > security properties. While the draft is well-written, its security reasoning > is incomplete. For each > of the C, I, and A areas, Section 4 lacks an argument that the listed threats > and attacks are > comprehensive. In general, there is no linking of the threats and attacks to > the listed assets and > points of access (attack/threat targets) in Section 3.1. > > In addition, there are specific problems in each of the three areas: > > (1) The Confidentiality portion (section 4.1) is missing material on sniffing > and traffic analysis, > plus there is no argument made that deliberate exposure, sniffing and traffic > analysis cover all means > of breaching confidentiality. Beyond that, a definition of "deliberate > exposure" would help - I'm > inferring active malicious action by privileged actor that exposes > confidential information. > > (2) The Integrity portion (section 4.2) omits at least remote device access > for compromise as a > complement to physical device access, and for some reason, does not consider > the forwarding table > (output of the routing protocol) as a target of threats/attacks. > > (3) The Availability portion (section 4.3) fails to consider response to > communication degradation or > partial loss of connectivity. An attacker may be able to selectively impede > or disable communication > (e.g., deploy electromagnetic interference near a subset of the wireless > nodes). In general, a > routing protocol should have a robust response to partial loss of > communication/connectivity, but > within defined limits (obviously a routing protocol is helpless against an > attacker who can disable > all inter-node communication). > > The requirements specified in Section 6 have a number of issues: > - There is no discussion of why each requirement is specified as MUST, > SHOULD > or MAY. > - The draft does not distinguish requirements for implementation from > requirements > for usage (e.g., "MUST implement" & "MAY use" is a reasonable > combination). > - The confidentiality and privacy requirements are SHOULD. Unless there is a > good reason not to do so, they both should be "MUST implement" (use can > be configured and/or negotiated). This is an example of failure to > distinguish implementation and usage requirements. > problem in the draft, in that it fails to distinguish > - Section 6.5.1 contains some badly worded language on p.36 about routing > protocols > inheriting the security properties of link level security for the links > used. > The word "automatically" needs to be removed, and the text rewritten to > refer to security protocols instead of stating that use of AES and SHA-1 > algorithms suffice for confidentiality and integrity protection. In > case > it's not clear, they do not suffice: > - AES in ECB mode is weak, independent of key size. > - SHA-1 by itself is not a secure integrity check; it needs > to be keyed, and the details of how the key is used > matter. > - In my view, the near dismissal of all countermeasures to Byzantine attacks > on > p.37 is flawed. While the draft is correct that comprehensive > countermeasures > to Byzantine attacks are difficult and potentially > time/resource-consuming, > I believe the draft should recommend some common-sense sanity checks on > received data. A common form of Byzantine attack is administrative mis- > configuration; a reasonable level of sanity checks on received routing > data could help detect such mis-configurations before they cause serious > damage. > > Section 7 of the draft feels short, weak and incomplete to me. It should > either > be significantly expanded or removed. > > Nits: > > Last paragraph in 3.2 is very general to the level of boilerplate. > > In section 3.3's discussion of highly directional traffic, the use of "low > route cost" assumes a cost > or weight based routing. Use of the phrase "preferred route" would be more > general. > > Section 3.4, across the bottom of p.12 and the top of p.13 - this asserts > that topology is not and > cannot be confidential in practice. I think this was written too quickly. > Topology info can clearly > be kept confidential from a passive attacker who only listens to traffic, but > cannot be kept > confidential from insider attack where the adversary has compromised a node > authorized to participate > in routing. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > [email protected] Mobile: +1 (978) 394-7754 > ---------------------------------------------------- _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
