Subject: [RTG-DIR] RtgDir review: draft-ietf-roll-security-framework-03

From: Russ White <[email-masked]>
Date: Mon, 10 Jan 2011 10:57:40 -0500

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review. The purpose
of the review is to provide assistance to the Routing ADs. For more
information about the Routing Directorate, please see
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-roll-security-framework-03
Reviewer: Russ White
Review Date: 10 Jan 2011
Intended Status: Informational

Summary:

I have some minor concerns about this document that I think should be
resolved before publication.

Comments:

This draft is well written and very readable; I didn't find any spelling
or editorial nits. Thanks for the hard work! There are some places I
have questions, though I consider all of them minor, and therefore not
blocks to the publication of an informational draft.

==
5.1.3

"The only means of fully countering a traffic analysis attack is through
the use of tunneling (encapsulation) where encryption is applied across
the entirety of the original packet source/destination addresses."

Wouldn't injecting false information into the stream also counter this
sort of attack? IE, the point here is to use traffic patterns to
discover information by inference, or rather use metadata to infer data.
Injecting information ignored by the system itself into the data stream
is one traditional means used to obfuscate the metadata.

OTOH, I don't know if this sort of defense is really acceptable in a low
power/lossy network of the type described here.

==
4.1.1 & 4.1.2

It might be useful to explain what sort of damage could be done through
routing exchange and routing information exposures... Is there a
particular reason the topology is to be considered "secret?" IE, what's
the security risk to someone knowing what the logical topology looks like?

==
5.2.2

The counter to overclaiming and misclaiming may employ: comparison with
historical routing/topology data; designs which restrict realizable
network topologies."

I'm not certain how these two countermeasures would work within a
dynamic routing environment. How can a new link (not historically
available) coming up be differentiated from an overclaim? If you
restrict the possible set of topologies to a subset of what is
physically or logically possible, aren't you limiting the uses of the
network over the long term? Won't an attacker know to stay within these
bounds when forming the attack?

==

Russ