Re: [CGA-EXT] about draft-krishnan-cgaext-send-cert-eku-03.txt

[marcelo bagnulo braun <[e-mail]>]

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
>
>