[sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : RPKI Validation Reconsidered Authors : Geoff Huston George Michaelson Carlos M. Martinez Tim Bruijnzeels Andrew Lee Newton Daniel Shaw Filename: draft-ietf-sidr-rpki-validation-reconsidered-06.txt Pages : 12 Date: 2016-07-08 Abstract: This document proposes an update to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the RPKI, while retaining essential security features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-validation-reconsidered-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-06.txt
Dear WG, After receiving some feedback on the previous version and discussion with co-authors, this version: - Does not reject 'over-claiming' EE certificates, but uses VRS-IP/AS there as well - Includes text to update ROA validation (in short requires that all prefixes are in VRS-IP of the EE) - Includes a request to the authors of the bgpsec-rpki-profile document. The reason why the change that I proposed to reject EE certificates has been reverted is that: - This way the validation algorithm is consistent between CA and EE certificates - Even though ROAs still require that *all* prefixes are contained in the VRS-IP, there may be other future use cases of EE certificates where a VRS-IP/AS that is smaller than the resources contained in the extensions. Stephen Kent comment on -04 of this document saying that it should not attempt to update the BGPSec Router Certificate I-D because it's not an RFC, just yet. It's currently in IESG Processing. The current document therefore has a request and some suggestion to the authors to change the document (in which case the section can be deleted in the next (hopefully final) version of this document. I don't mind either way. Maybe the chairs have an idea about what the best process is. But in either case we would like to ask the BGPSec Router Certificate authors to review the included text. Thanks, Tim > On 08 Jul 2016, at 11:19, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Secure Inter-Domain Routing of the IETF. > >Title : RPKI Validation Reconsidered >Authors : Geoff Huston > George Michaelson > Carlos M. Martinez > Tim Bruijnzeels > Andrew Lee Newton > Daniel Shaw > Filename: draft-ietf-sidr-rpki-validation-reconsidered-06.txt > Pages : 12 > Date: 2016-07-08 > > Abstract: > This document proposes an update to the certificate validation > procedure specified in RFC 6487 that reduces aspects of operational > fragility in the management of certificates in the RPKI, while > retaining essential security features. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-validation-reconsidered-06 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-06.txt
> On Jul 08, 2016, at 05:35, Tim Bruijnzeels wrote: > > Stephen Kent comment on -04 of this document saying that it should not > attempt to update the BGPSec Router Certificate I-D because it's not an RFC, > just yet. It's currently in IESG Processing. The current document therefore > has a request and some suggestion to the authors to change the document (in > which case the section can be deleted in the next (hopefully final) version > of this document. > > I don't mind either way. Maybe the chairs have an idea about what the best > process is. But in either case we would like to ask the BGPSec Router > Certificate authors to review the included text. Tim, Just so I’m following along: - This draft replaces the text in RFC 6487 s7.2 so should rpki-validation-reconsidered draft include the “Updates: 6487 (if approved)” header? My understanding is that the proposal is that all RPKI validators follow these new steps so that would make sense process wise. - bgpsec-pki-profiles s3.3 currently refers to RFC 6487 s7 for validation procedures and technically if rpki-validation-reconsidered updates RFC 6487 when bgpsec-pki-profiles refers to RFC 6487 it includes those references so I wouldn’t necessarily have to add a explicit reference to rpki-validation-reconsidered … but people will forget this and miss the update and I know Wes hates chasing references ;) So, to drive this point home we could do the following tweak in addition to adding your suggested bullet and separate-certificate per ASN suggestion: OLD: The validation procedure used for BGPsec Router Certificates is identical to the validation procedure described in Section 7 of [RFC6487], but using the constraints applied come from this specification. NEW: The validation procedure used for BGPsec Router Certificates is identical to the validation procedure described in Section 7 of [ID.sidr-rpki-validation-reconsidered], but using the constraints applied come from this specification. Note I’d probably also add ID.idr-rpki-validation-reconsidered to the required reading list in the terminology section :/ spt ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-06.txt
> On Jul 08, 2016, at 09:00, Sean Turner wrote: > > >> On Jul 08, 2016, at 05:35, Tim Bruijnzeels wrote: >> >> Stephen Kent comment on -04 of this document saying that it should not >> attempt to update the BGPSec Router Certificate I-D because it's not an RFC, >> just yet. It's currently in IESG Processing. The current document therefore >> has a request and some suggestion to the authors to change the document (in >> which case the section can be deleted in the next (hopefully final) version >> of this document. >> >> I don't mind either way. Maybe the chairs have an idea about what the best >> process is. But in either case we would like to ask the BGPSec Router >> Certificate authors to review the included text. > > Tim, > > Just so I’m following along: > > - This draft replaces the text in RFC 6487 s7.2 so should > rpki-validation-reconsidered draft include the “Updates: 6487 (if approved)” > header? My understanding is that the proposal is that all RPKI validators > follow these new steps so that would make sense process wise. I would like to propose that sidr-rpki-validation-reconsidered include an updates header, i.e., “Updates: 6487 (if approved)”, be included on the 1st page of the draft in the appropriate location. Of the options presented in the change below for sidr-bgpsec-pki-profiles, I’d like to rely on the change proposed above and not make the OLD/NEW changes I proposed below, i.e., I am suggesting making no changes to the introductory text in s3.3 of sidr-bgpsec-pki-profiles to refer to sidr-rpki-validation-reconsidered because it’s an unnecessary change. Steve’s suggested some other edits a a result of this thread and rpki-validation-reconsidered, so if the chairs direct me I can upload a new version of sidr-bgpsec-pki-profiles. Since AD review hasn’t really happened yet, maybe we can treat these as late, but timely WGLC comments? spt > - bgpsec-pki-profiles s3.3 currently refers to RFC 6487 s7 for validation > procedures and technically if rpki-validation-reconsidered updates RFC 6487 > when bgpsec-pki-profiles refers to RFC 6487 it includes those references so I > wouldn’t necessarily have to add a explicit reference to > rpki-validation-reconsidered … but people will forget this and miss the > update and I know Wes hates chasing references ;) So, to drive this point > home we could do the following tweak in addition to adding your suggested > bullet and separate-certificate per ASN suggestion: > > OLD: > > The validation procedure used for BGPsec Router Certificates is > identical to the validation procedure described in Section 7 of > [RFC6487], but using the constraints applied come from this > specification. > > NEW: > > The validation procedure used for BGPsec Router Certificates is > identical to the validation procedure described in Section 7 of > [ID.sidr-rpki-validation-reconsidered], but using the constraints > applied come from this specification. > > Note I’d probably also add ID.idr-rpki-validation-reconsidered to the > required reading list in the terminology section :/ > > spt ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-06.txt
Speaking as regular ol’ member:
> On Jul 15, 2016, at 1:28 PM, Stephen Kent wrote:
>
> Tim,
>
> I reviewed the -06 version and am attaching a pdf of the MS Word file with
> suggested edits. I can send you the word file itself if you wish.
>
> I have provided text to my co-author, Sean, to include in the
> bgpsec-pki-profile doc to address your concern. I suggested the following
> text at the beginning of section 3 :
>
>The validation procedure used for BGPsec Router Certificates is
>identical to the validation procedure described in Section 7 of
>[RFC6487]
> (and any RFC that updates this procedure)
> , but using the
>constraints applied come from this specification.
I can’t parse “but using the constraints applied come from this specification”.
Can you clarify?
>
>
> Sean added an implementation considerations section which I suggest will say:
>
>Operators MAY choose to issue separate BGPsec Router Certificates for
>different ASNs. Doing so may prevent a BGPsec Router Certificate from
>becoming invalid if one of the ASNs is removed from any superior CA
> certificate
>along the path to a trust anchor.
I quibble about this wording. why do you say “may”? Is it because if the ASN
in one of the separate router certificates is one of the ASNs that is removed,
then it still becomes invalid?
I think you mean:
This document permits the operator to include a list of ASNs in a BGPsec Router
Certificate.
In that case, the router certificate would become invalid if any one of the
ASNs is removed
from any superior CA certificate along the path to a trust anchor. Operators
MAY choose
to avoid this possibility by issuing a separate BGPsec Router Certificate for
each distinct
ASN, so that the router certificates for ASNs that are retained in the superior
CA certificate
would remain valid.
I’m not sure you meant a normative “MAY choose” ("there are reasons, to make this choice”) or “could possibly choose”
>
>
> I hope these changes avoid the need to say anything about router certs in
> your doc.
>
> I'm not sure there is a need to change the ROA spec. If we agree that all
> prefixes in the ROA MUST be contained in the EE cert for that ROA, then the
> current text in the ROA spec does not need to change.
Well……
The ROA RFC says validation of the ROA must satisfy:
o The IP address delegation extension [RFC3779] is present in the
end-entity (EE) certificate (contained within the ROA), and each
IP address prefix(es) in the ROA is contained within the set of IP
addresses specified by the EE certificate's IP address delegation
extension.
If the EE certificate and the ROA mention a /18, and a /19 is removed from a
“superior CA certificate”, then there is/are only a /19 of the EE certificate
that is/are VRP. And every prefix in the ROA is still contained in the EE
cert, so this validation step is satisfied. What does this ROA now authorized?
How would it be applied in BGP route validation?
—Sandy, speaking as regular ol’ member
>
> Steve
>
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-06.txt
Sandy,
I can’t parse “but using the constraints applied come from this specification”.
Can you clarify?
The text I supplied for the replacement validation alg were based on the
original text, whenever possible. Unfortunately, the original text
refers to sections of 6487 implicitly as "this specification". Thus, in
the new document we need to explicitly note that the indicated
constraints on certs (e.g., required/prohibited extensions, etc.) are in
the relevant parts of 6487.
Sean added an implementation considerations section which I suggest will say:
Operators MAY choose to issue separate BGPsec Router Certificates for
different ASNs. Doing so may prevent a BGPsec Router Certificate from
becoming invalid if one of the ASNs is removed from any superior CA
certificate
along the path to a trust anchor.
I quibble about this wording. why do you say “may”? Is it because if the ASN
in one of the separate router certificates is one of the ASNs that is removed,
then it still becomes invalid?
I think you mean:
This document permits the operator to include a list of ASNs in a BGPsec Router
Certificate.
In that case, the router certificate would become invalid if any one of the
ASNs is removed
from any superior CA certificate along the path to a trust anchor. Operators
MAY choose
to avoid this possibility by issuing a separate BGPsec Router Certificate for
each distinct
ASN, so that the router certificates for ASNs that are retained in the superior
CA certificate
would remain valid.
I prefer your text. Nice job.
I’m not sure you meant a normative “MAY choose” ("there are reasons, to make this choice”) or “could possibly choose”
I'm not picky about the case of the MAY here.
I hope these changes avoid the need to say anything about router certs in your
doc.
I'm not sure there is a need to change the ROA spec. If we agree that all
prefixes in the ROA MUST be contained in the EE cert for that ROA, then the
current text in the ROA spec does not need to change.
Well……
The ROA RFC says validation of the ROA must satisfy:
o The IP address delegation extension [RFC3779] is present in the
end-entity (EE) certificate (contained within the ROA), and each
IP address prefix(es) in the ROA is contained within the set of IP
addresses specified by the EE certificate's IP address delegation
extension.
If the EE certificate and the ROA mention a /18, and a /19 is removed from a
“superior CA certificate”, then there is/are only a /19 of the EE certificate
that is/are VRP. And every prefix in the ROA is still contained in the EE
cert, so this validation step is satisfied. What does this ROA now authorized?
How would it be applied in BGP route validation?
I see your point. yes, the ROA spec does need to be modified.
Steve
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
