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.