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.

This document defines a certificate profile for use in the Secure  
Neighbor Discovery protocol for IPv6.  Starting from the RPKI cert  
profile, it adds some refinements for SEND, e.g., EKUs that authorize  
the subject to act in certain roles within SEND (router, proxy, host).

Overall, the document is reasonably well-written, but could benefit  
from more precision in its use of terminology.  There are a few points  
(noted below) where certificate processing rules are unclear.  With  
regard to the security considerations in particular, I would prefer if  
they stated the risks slightly more directly (text is suggested  
below), but in general, the authors address the major security concerns.

Detailed comments follow.

--Richard


Sec 2 Para 1
Suggest changing "authority over an" to "authorization to advertise an".

Sec 2 Para 2
Suggest rewording to avoid referring to SIDR WG (which is temporary).   
Suggested text: "The Resource Public Key Infrastructure (RPKI) is the  
global PKI that attests to allocation of IP address space."  Also,  
instead of "SIDR certificate profile", use "RPKI certificate profile".

Sec 2 Para 3, General
I'm confused by the several instances of the phrase "address owner" in  
the document (the phrase is not used in RFC 3971).  Do you mean "host"?

Sec 3 Para "End Entity"
This definition is incorrect.  Refer to RFC 4949.

Sec 4 Para 1
The RPKI profile should be applied in *addition* to the RFC 3971  
profile, right?  Please clarify.

Sec 4 Para 2
Why can there only be one RFC 3779 extensions?  It doesn't seem like  
there's a risk in including IPv4 space (e.g., for a dual-stack router  
that was vouching for IPv4 space in some other application?), or  
multiple extensions for IPv6 space.

Sec 5
This section should note that another deployment model (arguably the  
most likely) is a combination of these two, in which most resources  
are certified under the global RPKI, while some (e.g., ULAs) are  
certified under local TAs.

Sec 6 Para 4
The requirement for RFC 3779 extension seems to contradict the use of  
ETAs as Trust Anchor Material, i.e., the last sentence of the first  
paragraph in this section.

Sec 7 Para "The inclusion of ..." et seq.
It would be helpful for the document to specify how prefix matching  
should be done when validating these extensions.  Which of the  
following should the RP use?
-- Exact matching
-- Subset matching (RA within cert)
-- The weird subset/intersection algorithm that RFC 3971 defines
What prefix should the RP be matching against from SEND, per EKU?   
E.g., for id-kp-sendRouter, the RFC 3779 extension in the cert should  
match against any RAs the router emits.  It may be useful to refer to  
the ROA validation document [draft-ietf-sidr-roa-validation].

Sec 7 Para "Certificate-using applications..."
Suggest changing "Certificate-using applications" to "Relying Parties".

Sec 8
This section correctly identifies the main risk with these extensions  
(namely, issuance of certs with incorrect roles assigned), but it  
would be helpful to clarify the application-level impact of these bad  
issuances.  Suggested text:
"
Since a SEND certificate attest that its subject is authorized to play  
a given role in the SEND protocol, certificates that contain incorrect  
EKU values can enable some of the same attacks that SEND was meant to  
prevent.  For example, if a malicious host can obtain a certificate  
that authorizes it to act as a router for a given prefix, then it can  
masquerade as a router for that prefix, e.g., in order to attract  
traffic from local nodes.
"