Hi Danny,
Thanks for the comments.
| A few specific things:
|
| 1) AS path origin-based policies alone are insufficient, as any
| targeted attack could most easily spoof the origin AS.
Yes, and that's why complete path attestation is still required and
needs to be addressed.
| 2) When I brought up the issue about targeted attacks John said this
| is meant to accommodate the 80/20 rule with route leaks, etc. When
| routes are leaked, which appears to be the most common 'hijack'
| case today, the origin is preserved. This wouldn't necessarily
| protect against that.
I am not quite sure I follow this. But if the origin is preserved and
the AS_PATH is not, it should again be addressed by path attestation.
|
| 3) No inherent ability in the current validation modes to prefer
| shorter validated prefixes over longer non- validated ones means
| that most hijacks would still prefer the hijacked more-specific
| prefix. Most actual hijacks, and even leaks such as the YouTube
| incident, are from more specific prefixes and given preference.
>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/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.
| 4) Requiring implementations to store prefixes in their respective
| Adj-RIB-In, even if they've been filtered, such that they're
| available if policies changes, is a bad idea. Instead, as Jeff
| suggested at the microphone, employing route refresh in these
| scenarios would be much more scalable.
|
| E.g., in the case of CTBC last week there were like 267k prefixes
| leaked that would have been stored and filtered, were these
| capabilities in place. This could easily become a DOS vector itself.
It's a trade-off. With route refresh mechanism, you will be forced to
send a route refresh request to each of your peerings when the policy
changes and receive all of the 267K prefixes again. That's not nice
from CPU viewpoint. Agree you can be clever about storing some hints
of which peers had sent you invalid routes and send the request to
them or build a prefix ORF based on what prefixes have database
updates etc..., but that's ugly. If you choose to store them, you are
storing them only from your configured peers. So it's not an unbounded
problem.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
