[Roll] RtgDir review:

[Russ White <[e-mail]>]

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, and
sometimes on special request. 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-threats-00.txt
Reviewer: Russ White
Review Date: 16 January 2013
IETF LC End Date: unknown
Intended Status: Informational

Summary:

I have significant concerns about this document and recommend that the
Routing ADs discuss these issues further with the authors.

Comments:

Philosophically, this document seems to treat routing as an "entity,"
that operates by itself, independent of other systems, within a network.
In real networks, routing is primarily used to provide for forwarding,
so security should really be couched in terms of how breaches in routing
security impact forwarding. The direction taken in this draft leads to a
single end --the encryption of all routing information carried through
the network. I would really like to see routing security take a more
creative turn, seeing routing as a part of an overall system, rather
than as an end to end flow of information that must be secured in its
own right --as "just another data stream."

Specifically, the goals in section 3.4 would necessarily be resolvable
only through the use of some form encrypted transport of routing
information, which could easily overcome any possible low powered device
in complexity and difficulty. It seems, to me, a better overall goal
would be to ensure the routing database accurately reflects the actual
state of the network topology, allowing for any means that will reach
this goal, whether or not they include cryptography. A wider net is more
likely to produce a stronger set of available options.

The problems noted in section 4 are, in fact, countered with proposals
in sections 5 and 6 that only propse cryptographic mechanisms generally
planned around encrypting routing exchanges and/or signing routing
information on the wire, adding weight to my thoughts above. It seems,
to me, that sections 5 and 6 should be moved to a separate draft, so the
general overview of the problems and possible solutions are decoupled a
bit, to allow “breathing room,” for possible alternate solutions.

==
My one concern about section 3.2 is one of the implications carried in
the statement, “non-repudiation will involve providing some ability to
allow traceability or network management review of participants of the
routing process including the ability to determine the events and
actions leading to a particular routing state.”

This implies, at least to me, that the actual processing of routing
updates need to be logged in a way that prevents tampering at every
node, as well as the actual routing updates received, transmitted, and
otherwise handled by each node in the network — especially since routing
is not always atomic, but rather timing dependent. How this particular
“possible requirement,” might be implanted in a way that is practical.

==
The taxonomy in section 4 appears to be solid.

==
Overall, I found the writing style to be a bit opaque/obtuse — difficult
to read in parts, perhaps a little “research,” if that makes sense. Some
specific comments on the first few paragraphs are below, but I didn’t
spend a great deal of time working through specific grammar issues
throughout the entire document.

==
This document presents a framework for securing Routing Over LLNs (ROLL)...

Using an acronym to expand another acronym will probably confuse at
least some readers. LLNs also needs to be explained at it's first use.

==
Security, in essence, entails implementing measures to ensure controlled
state changes...

I'm not certain what's meant by "controlled," here, or how it relates to
security. Is "unsecured," information about state changes therefore
"uncontrolled?" Is "verifiable," what you're after here, or perhaps,
"authorized," or... ??

==
State changes would thereby involve proper authorization for actions,
authentication, and potentially confidentiality, but also proper order
of state changes through timeliness (since seriously delayed state
changes, such as commands or updates of routing tables, may negatively
impact system operation).

Perhaps something like:

Securing information about state changes would include ensuring devices
match their claimed role (authentication), transmitted state changes are
correct and allowed through policy (authorization), state changes are
only visible to authorized devices (confidentiality), and operations are
taken in the proper order (timeliness and atomicity).

==
An asset implies an important system component (including information,
process, or physical resource), the access to, corruption or loss of
which adversely affects the system. In network routing, assets lie in
the routing information, routing process, and node's physical resources.
 That is, the access to, corruption, or loss of these elements adversely
affects system routing.

Perhaps something like:

In the control plane context, an asset is information about the network,
processes used to manage and manipulate this data, and the physical
devices on which this data is stored and manipulated. The corruption or
loss of these assets may adversely impact the control plane of the network.

(Note you shouldn't imply any such breach "will," disrupt routing,
because  routing systems are, at base, designed to be resilient to
information loss and corruption. There are some situations where loss or
corruption will result in misrouted or lost data flows, but there are
others where it will not.)

==
In network routing, a point of access refers to the point of entry
facilitating  communication with or other interaction with a system
component in order to use system resources to either manipulate
information or gain knowledge of the information contained within the
system.

Perhaps something like:

Within the same context, a point of access is an interface or protocol
that facilitates interaction between control plane components.

==
Security of the routing protocol must be focused on the assets of the
routing nodes and the points of access of the information exchanges and
information storage that may permit routing compromise.

This sentence doesn't add to the flow of thought, so I would just remove it.

==
The identification of routing assets and points of access hence provides
a basis for the identification of associated threats and attacks.

Perhaps something like:

Identifying these assets and points of access will provide a basis for
enumerating the attack surface of the control plane.

==
This subsection identifies assets and points of access of a generic
routing  process with a level-0 data flow diagram [Yourdon1979]
revealing how the routing protocol interacts with its environment. In
particular, the use of the data flow diagram allows for a clear, concise
model of the routing functionality; it also has the benefit of showing
the manner in which nodes participate in the routing process, thus
providing context when later threats and attacks are considered.

Perhaps something like:

A level-0 data flow diagram [Yourdon1979] is used here to identify the
assets and points of access within a generic routing process. The use of
a data flow diagram allows for a clear and concise model of the way in
which routing nodes interact and process information, and hence provides
a context for threats and attacks.

Major Issues:

My primary concern is the general philosophy within the draft --see my
comments above. The working group may decide this philosophy is
acceptable/good, but it should be brought out onto the table and
discussed, and some explanation of why this path was chosen provided in
the draft, rather than assumed, IMHO.

Minor Issues:

Writing style, as indicated in my comments above.


==

HTH

:-)

Russ