Subject: [Gen-art] Gen-ART review of draft-ietf-roll-security-framework-04

From: <[email-masked]>
Date: Mon, 17 Jan 2011 14:52:27 -0500

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-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; 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-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------

---

From: Adrian Farrel <[email-masked]>
Date: Mon, 17 Jan 2011 20:27:32 +0000

Hi David,

Thanks for continuing to discuss.

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

What did you have in mind?
Do you believe someone with a wrench might break into the router and steal the
routing table? :-)

The only access to the routing table is through the routing protocol and
management mechanisms. Given the scope, this draft only discusses the routing
protocol.

Maybe this is as simple as saying *why* the routing protocol would be protected,
rather than assuming that the protocol has to be protected?

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

I think that a robust response to partial loss of communication that impacts the
routing protocol should not be part of the routing protocol since the protocol
is possibly unable to communicate effectively.

Maybe the document should give an example of such a robust response. IMHO this
is about raising alarms to the operator.

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

Requirements for use (even for security) are surely vain! All we can do is
describe what constitutes a conformant implementation. We can supplement that by
saying that to avoid a specific security threat, an operator may/should/must use
a specific feature.

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

I'll leave the authors to comment on this. In general, I agree with "MUST
implement" and disagree with an unqualified "SHOULD use" (a qualification would
be "operators wishing to protect geographic information SHOULD use..."). I do
not agree with the "MUST NOT" in your final sentence. Operators MUST be free to
throw their money around in the street if they want to.

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

Cheers,
Adrian

---

From: <[email-masked]>
Date: Mon, 17 Jan 2011 16:07:14 -0500

Hi Adrian,

I think [D] is the most important of these open issues:

> > The stated
> > "SHOULD" requirement for privacy of geographic information is troubling, as the

As we apparently agree on "MUST implement", that would cause the "MUST NOT" workaround in the final sentence to become irrelevant.  The resulting requirements language would be "MUST implement" confidentiality and "SHOULD use" confidentiality with geographic information.

Beyond this, item [C] effectively asks that analogous clarification of implementation vs. use be carried out on the other requirements.

On further thought, the other two items may be nits:

[B]

> > > communication/connectivity,

> is about raising alarms to the operator.

The behavior of a routing protocol in only constructing routes based on what it can actually reach (e.g., based on currently visible advertisements) may be an example.

> > [A] I remain surprised that the forwarding table in each node is not considered to

If an attacker can get in and rewrite the forwarding table as she sees fit, the fact that the routing protocol is distributing correct routes becomes irrelevant ;-).  I think the countermeasures to protect the forwarding table are covered under physical device access and remote device access, but something still feels wrong about Figure 1 placing the forwarding table out of scope.

Thanks,
--David

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Monday, January 17, 2011 3:28 PM
> To: Black, David; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Gen-ART review of draft-ietf-roll-security-framework-04
> 
> Hi David,
>