Ana Kukec escribió:
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)
right, but my question is what happens when a current send node receives
a cert with the EKU? does it fails, or does it just skipe the option
takes the cert as valid?
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.
So, this seems to psoe two problems:
- first, that a current send node will not accept as valid a cert
without the subjectAltname, right? While this is not optimal, we may be
able to live with that
- second, how does a send node uses the subjectAltName? i mean does the
send node needs this information to validate the anchor point? If so,
how do we deal with this?
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.
not sure waht do you mean here... can we still use the send validation
routing? Or we need to change the send nodes to do the new 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.
right, but do we need to specify the revocation routines as well?
I would like to understnad if we need to update rfc3971 to support this,
i understnad we do. I am not sure i fully understnad what are the
updates that are needed to rfc3971... could you elaborate on this?
regards, marcelo
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
