Hi Marcelo,
Tnx for the comments, please see my comments below..
marcelo bagnulo braun wrote:
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.
The send spec describes just the X.509 IP address extension in the
section 6.3.1 RAC profile, and indirectly the Subject name and the
subjectAltName extension in the section 6.4.3 TA option.
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?
The incompliances between the RPKI and SEND are related to the X.509
extensions profile and their validation. Regarding the acception of the
RPKI certificate profile into SeND, there are two problematic
extensions, the EKU extension (as we already discussed) and the
subjectAltName extension. The send spec requires the usage of the
subjectAltName extension in order to match its contents with the Trust
Anchor option of the FQDN type (as described in the section 6.4.5 of the
send spec). But, since the RPKI is about the authorization and not about
the authentication, the subject names in RPKI are not intended to be
descriptive, and thus the RPKI certificate profile, i.e.
draft-ietf-sidr-res-certs-16 does not use/describe the subjectAltName
extension at all.
Regarding the validation routines, the rfc3779 extension validation
routine conflicts with the one described in the send spec. But together
with the RPKI certificate profile we can accept the rfc3779 extension
validation routine.
Contrary to the X.509 extensions and the validation routines, the
revocation is not a conflicting thing, it is just that the SeND lacks
the text describing how to incorporate the RPKI revocation into SeND.
With carefully chosen validity intervals for the RPKI certificates on
the lower tiers, i.e. at the SEND level, the CRL is not expected to
grow to large sizes, and it can fit well into the SEND messages.
Regarding the section 4.1. EKU extension, we will describe it more in
details, in collaboration with the sidr wg.
Ana
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
