Geoff,
About my Question (3), let us discuss this a bit more carefully with an example.
There is this ROA: {10.0.0.0/24, AS64499} that we wish to validate.
It is signed with Certificate 3, which has the following certificate path to
the TA:
Certificate 1: It lists {10.0.0.0/12, AS64501, AS64505, AS64509} (TA
certificate)
Certificate 2: It lists {10.0.0.0/22, AS64501, AS64505, AS64511}
Certificate 3: It lists {10.0.0.0/20, AS64501, AS64505}
Note: Certificate 1 is the TA certificate.
It is clear that following the current (RFC 3779) method,
Certificates 2 and 3 are invalid, and it follows that the ROA is invalid.
Now, there are two methods that we may enumerate for a modified (or alternate)
validation proposal:
Method A (more conservative but less robust relative to Method B below):
Step 1: Ask what certificate is used to sign the RAO? Answer: Certificate 3.
Step 2: Do the resources in Certificate 3 subsume the prefix in the ROA?
Answer: YES,
because "the INR of interest" 10.0.0.0/24 in the ROA is subsumed by
an INR 10.0.0.0/20 in Certificate 3. OK, now proceed to validate Certificate 3.
Note that "the INR of interest" in Certificate 3 is 10.0.0.0/20.
Step 3: Ask if the resources in Certificate 2 subsume "the INR of interest" in
Certificate 3?
Answer: NO, because "the INR of interest" 10.0.0.0/20 in Certificate 3 is NOT
subsumed
by an INR in the parent Certificate 2.
(Note: The parent Certificate 2 has a more specific prefix 10.0.0.0/22.)
Step 4: Since the certificate chain "validation" failed at Step 3, declare the
ROA
being considered as "Invalid" for the prefix-origin pair {10.0.0.0/24, AS64499}
.
Method B (less conservative but more robust relative to Method A above):
Step 1: Ask what certificate is used to sign the RAO? Answer: Certificate 3.
Step 2: Set "the given INR" as 10.0.0.0/24. That is the INR in the ROA for
which
validation is being sought.
[Note: "The given INR" remains a constant in the steps that follow.
We just *stay focused on this given INR* for the rest of the validation process
below.
This is the main difference compared to method A.]
Step 3: Do the resources in Certificate 3 subsume the "the given INR"
10.0.0.0/24?
Answer: YES, because the given INR 1.0.0.0/24 is subsumed by an INR 10.0.0.0/20
in Certificate 3.
Step 4: Do the resources in Certificate 2 subsume the "the given INR"
10.0.0.0/24?
Answer: YES, because the given INR 1.0.0.0/24 is subsumed by an INR 10.0.0.0/22
in Certificate 2.
Step 5: Do the resources in Certificate 1 subsume the "the given INR"
10.0.0.0/24?
Answer: YES, because the given INR 10.0.0.0/24 is subsumed by an INR
10.0.0.0/12 in Certificate 1.
Step 6: Since the certificate chain "validation" passed at each step above
for "the given INR" 10.0.0.0/24, declare the ROA being considered
as "Valid" for the prefix-origin pair {10.0.0.0/24, AS64499} .
So Method A produces an "Invalid" result for the ROA,
whereas Method B yields a "Valid" result.
I hope the difference between Methods A and B is clear.
In Method A, "the INR of interest" at level x must be subsumed by an INR at
level x+1.
But in Method B, only "the given INR" (e.g., a prefix in a ROA or an ASN in a
router certificate)
is the steady focus, and what is required is that "the given INR" must be
subsumed
by resources listed in the certificate at each level (1, 2, 3, ..., n).
The description on your Slide #18 falls short of describing precisely
either Method A or Method B. From your Slide #14, it seems evident that you are
proposing Method B; am I right?
(In terms of language and clarity, the notion of calling a certificate "valid"
is misleading when in fact all that is being checked is merely
whether a given INR is subsumed in it.)
Sriram
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
