Skip to main content

Last Call Review of draft-ietf-csi-sndp-prob-

Request Review of draft-ietf-csi-sndp-prob
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-12-01
Requested 2009-11-20
Authors Jean-Michel Combes , Suresh Krishnan , Greg Daley
Draft last updated 2009-12-03
Completed reviews Secdir Last Call review of -?? by Stephen Farrell
Assignment Reviewer Stephen Farrell
State Completed
Review review-ietf-csi-sndp-prob-secdir-lc-farrell-2009-12-03
Completed 2009-12-03
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

The draft is a generally well-written description of some issues with
securing neighbour discovery when proxies are involved. As a problem
statement draft I find it just fine.

I have two minor security comments and a few nits below.

1. The suggestion at the end of 4.2 that certificate serial number
or time field ordering be used to indicate relationships between
end entities seems very hacky. I'd suggest either deleting that
if its felt to be unlikely used, or else, if its actually
likely to be used, then documenting how it could actually work

2. 7.2 mentions "signed, non-repudiable certificates" which is a
horribly odd phrase. Hopefully that's just sloppy language.
(s/signed, non-repudiable//), but if not, then its a concern (the
concern being that non-repudiation in protocols is mythical).


1. 2nd last para of 3.1: fix word ordering in last sentence, think it
ought say:

 Such a message would be valid according to the SEND specification, if the
 Target Address and the source IPv6 address of the Neighbor Advertisement
 weren't different [RFC3971].

2. 2.2.4 1st para: similar word ordering, maybe:

 The router or CA may then be able to certify proxying for
 only a subset of the prefixes for which it is certified.

3. 1st sentence of 7.2: s/The certificagte delegation/Certificate