> -----Original Message-----
> From: George Michaelson [mailto:[email protected]]
> Sent: Tuesday, November 03, 2009 5:06 PM
>
>> From: "Sriram, Kotikalapudi" <[email protected]>
>> Date: 3 November 2009 4:00:14 AM AEDT
<snip>
>> In my understanding, ROA prefix is not a _covering_ aggregate if the
>> update prefix length exceeds maxlength, unless purposefully defined
>> otherwise.
>It would help if you gave an example here. We are lost in
>understanding your question.
<snip>
Thanks, George, for your responses to my previous email.
In the following, I elaborate on my thinking while stepping through several
validation use cases / examples,
and I have a new question as well towards the end.
(Later I will discuss with Terry Manderson about incorporating
these use cases also into our draft-manderson-sidr-usecases-01.txt;
these are not included there yet.)
Examples (Validation use cases):
Use case 1:
ROA: {129.6.0.0/16, maxlength = 18, AS49}
Update has {129.6.0.0/17, Origin = AS49}
Here the ROA prefix is a covering prefix for the update prefix -- this is
obvious.
Use case 2:
ROA: {129.6.0.0/16, maxlength = 18, AS49}
Update has {129.6.5.0/24, Origin = AS49}
(A) Do we still consider the ROA prefix a covering prefix for the update prefix?
Or, (B) Do we consider it not a covering ROA prefix because the update prefix
length is longer than the maxlength allowed in the ROA?
I think the answer is (A) for the following reasons (in a moment we will
enumerate additional use cases):
In use case 2, we want the validation result to be Invalid.
The algorithm will determine that the ROA prefix is a covering prefix
for the update prefix. But it will also determine that the ROA maxlength
is exceeded by the update prefix length; so the validation result is "Invalid."
In all use cases below, let us assume that we use definition (A) -
that is, ROA prefix is considered a covering match or covering aggregate
if the update prefix matches or is a more specific; the maxlength consideration
is deferred at this stage and will be applied separately as part of the
validation process.
Use case 3: HERE IS WHERE THE DISTINCTION IN "COVERING PREFIX or AGGREGATE"
DEFINITIONS BEGINS TO MATTER
ROA: {129.6.0.0/16, maxlength = 18, AS49}
Update has {129.6.5.0/24, Origin = AS42}
(Note: Different origin)
In use case 3, we want the validation result to be Invalid.
The algorithm will determine that the ROA prefix is a covering prefix
for the update prefix. But it will also determine that the ROA maxlength
is exceeded by the update prefix length,
and also determine that the origin is mismatched. So the result is "Invalid."
(Here, clearly, the suspicion is that of a subprefix hijack situation.)
Use case 4: Giving an AS the benefit of doubt (partial deployment)
ROA: {129.6.0.0/16, maxlength = 18, AS49} - not directly relevant for this use
case.
Update has {74.63.16.0/24, Origin = AS42}
(Note: Completely different prefix and origin - ROA listed is not
directly relevant anyway)
(Note: There is no ROA in the entire repository that validates or invalidates
this update. We give the AS42 the benefit of doubt during
partial deployment; probably it has not yet upgraded to RPKI capability!)
In use case 4, we want the validation result to be "Unknown".
The algorithm determines that a ROA with a covering prefix for the
update prefix DOES NOT exist.
So it concludes that possibly a ROA has not been registered yet.
The result of validation: "Unknown"
Use case 5: Here it is doubtful if "AS should be given the benefit of doubt"
ROA: {70.40.0.0/21, maxlength = 24, AS42}
Update has {74.63.16.0/24, Origin = AS42}
This use case is still a logical progression from previous use cases, but here
I have a NEW QUESTION that we have not considered so far (IMHO).
(Note: Completely different prefix, but origin is the same as in another ROA)
(Note: There is no ROA in the repository that has a covering prefix
or aggregate for the update prefix. So there is no ROA that
validates or invalidates this update. However, here we hesitate to give
the AS42 the benefit of doubt; because we have evidence by observing
another ROA that AS42 or its ISP has RPKI capability!)
I think your algorithm as well as that of
draft-pmohapat-sidr-pfx-validate-03.txt
will treat this update softly and the validation results will be
"Unknown" or "Not Found", respectively.
But I think we may want the validation result in this case to be "Invalid".
Question is: AS42 or its ISP evidently has RPKI capability;
so why did it register a ROA for one prefix (namely, 70.40.0.0/21)
that it originates but not for another prefix 74.63.16.0/24
which it is also trying to originate?
Caveat: AS42 might have been suballocated the prefix 74.63.16.0/24
from a different ISP who is clueless about RPKI. Is there a reasonable
case here for validation result to be "Unknown" or should the result be
"Invalid"?
I would like to request some discussion from the WG members on this question.
Sriram
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
