Hi,
good work
I think this is in good shape, but i am really far from being an expert
on this (as my question below reflect)
I have some comments and questions.
2. Introduction
Secure Neighbor Discovery [RFC3971] Utilizes X.509v3 certificates for
performing router authorization. It uses the X.509 extension for IP
addresses to verify whether the router is authorized to advertise the
mentioned IP addresses.
s/addresses/prefixes
The SEND specification does not describe the set of extensions that
need to be supported
This is strictly true, right? I mean section 6.3.1. Router
Authorization Certificate Profile of the send spec does define the cert
profile.
4.1. Extended Key Usage Values
The inclusion of the router authorization value indicates that the
certificate has been issued for allowing the router to advertise
prefix(es) that are mentioned using the X.509 extensions for IP
addresses and AS identifiers [RFC3779]
I understnad that this means that the router is auhtorized to advertise
the prefix included in the RADV ND message, right?
I think this shoudl be described more explicitly, I mean, the main
contribution of the draft is to define these EKU, so it should if very
precisely, right? would these apply to DHCP prefix delegation for instance?
The inclusion of the owner authorization value indicates that the
certificate has been issued for allowing the node to use the
address(es) or prefix(es) that are mentioned using the X.509
extensions for IP addresses and AS identifiers [RFC3779]
i am not sure what do you mean about this
Are you aiming for the case we use SEND with non cga addresses? If so,
it should be more clearly stated. In particualr, i fail to understnad
why a host could announce more that one address i.e. why prefixes are
acceptbale. Maybe describing thesecould help
then the draft reads:
Inclusion of multiple values indicates that the certified public key
is appropriate for use by a node performing more than one of these
functions.
send-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) TBA1 }
id-kp-sendRouter OBJECT IDENTIFIER ::= { send-kp 1 }
id-kp-sendProxy OBJECT IDENTIFIER ::= { send-kp 2 }
id-kp-sendOwner OBJECT IDENTIFIER ::= { send-kp 3 }
I don't understnad what do you mean by the data strcuture you include
here... could you clarify? (is it just an example? if, so, please tag it
as one)
then...
Certificate-using applications MAY require the extended key usage
extension to be present in a certificate, and they MAY require a
particular KeyPurposeId value to be present (such as id-kp-sendRouter
or id-kp-sendProxy)
where are these keypurposeid are defined?
maybe additng a reference would be useful
then it reads
5. Backward Compatibility
The disadvantages of this model are related to the fact that the SEND
specification was developed before the standardization of the RPKI.
Hence, SEND is not completely compliant with the RPKI specifications
since it defines its own IP prefix validation routine and it is not
suitable for the use with CRLs, while the RPKI suports only CRLs.
This means that SEND implementations supporting this profile will not
be able to interoperate with legacy SEND implementations.
I don't fully understnad the implications of this
I mean, what needs to be changed in a current send implementation to be
compatible with this new format?
I mean, the optimal would be that current send implementations accept
RPKI certs but skip the new extensions and that new send implementations
are able to read the new extensions defined by this document. is this
not possible?
I am missing the part where you actually defines the EKU values for the
3 usages you have defined... wouldn't this be in the IANA cosiderations
part of the draft? If not, shouldn't this be somehwere else? I mean, i
understnad you are assigning 3 values of a registry for that usage? Or
does this work in a different way?
Regards, marcelo
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
