Quoting "Pradosh Mohapatra (pmohapat)" <[EMAIL PROTECTED]>:
From the point of view of origin validation, prefixes with different
mask lens are treated as completely different route advertisements and
validated separately. So if a BGP speaker receives both 10.1.1/24 and
10.1/16, they are two separate prefixes, each undergoing the
validation check. If the rightful owner of 10.1/16 prefix block is
AS#1, I would expect AS#1 to have originated an ROA as {10.1/16,
max_length=24}. When the BGP speaker receives 10.1.0.0/16 with origin AS
1, that would be declared "valid". However when it receives 10.1.1/24
with origin AS 2, since the ASs do not match for the ROA found, it
would be declared "invalid". So that seems to take care of the issue
you raise.
The capability in any algorithm to distinguish between an update
due to path or origin change by legitimate owner's action vs.
that due to a hijack/misconfiguration attack would remain challenging
as long as RPKI adoption and creation of ROAs is partial.
The legitimate owner of 10.1/16 can be multi-homed to, say,
AS#1 and AS#2. They may have created a ROA for
10.1.0.0/16, Origin = AS#1, but may not have yet created a ROA
for 10.1.1.0/24, Origin = AS#2. There is also the lag issue.
They may have created the second ROA in the last few hours
and propagated an update with different origin (AS#2) shortly
after that, but the algorithm downloads ROAs only once every 24 hours.
So the algorithm fails to validate based on the currently known ROAs
at the BGP speaker.
During the evolution period of RPKI,
origin and path validation algorithms can benefit from combining
(prefix, origin AS) pairing information from different sources,
including trace data (e.g., routeviews, RIPE-RIS) and even
RPSL/SWIP route registration data from IRR/RADB.
This would be especially useful when there is incompleteness
in the ROA repository.
Some examples of ideas (research) along these lines:
http://www.cs.unm.edu/~treport/tr/06-06/pgbgp3.pdf
http://www.antd.nist.gov/~ksriram/NIST_BGP_Robustness.pdf
Sriram
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
