On Mon, 17 Nov 2008, Pradosh Mohapatra (pmohapat) wrote:
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.
SIDR was chartered to fulfill the security requirements established by the
rpsec working group. That group was able to set path origination as a
security requirement but failed to come to consensus of what sort of
additional path security should be required.
No one in the rpsec wg argued that additional path security is NOT
required, it was just setting the exact security requirements for security
for the AS_PATH past the origination AS that was contentious.
So everyone recognizes that the origination of a route to a prefix
is not sufficient. But it is necessary. It is the starting point of
every suggested BGP protection that provides more protection of the
AS_PATH. (That I have seen.)
So we'll get done with this (someday!) and we can continue with more work
to further protect the AS_PATH and this current work will be useful in the
meantime and the basis for the more work (i.e., not wasted).
--Sandy
| 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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
