Re: [RPSEC] Re: draft-convery-bgpattack-00

>> (b) If someone finds an AS_PATH that ends in AS X, signed by AS X but
>> without including AS X's neighbor in the signature, then that someone
>> (call it AS N) can announce an AS_PATH that ends in "...., AS X, AS N"
>> without actually being a neighbor of AS_X.
>
>I don't see what this has to do with having a neighbor identifier in the
>update message. Since the AS path is different here, this situation
>should be caught in the AS path validation phase.

It would not be caught in the AS path validation phase.  N has a valid
signed path that ends in AS X, signed by AS X.  (We're presuming the
don't-include-neighbor-id-in-signature approach.)  AS N adds itself
to the path and signs that.  All signatures check.

>Also note that protecting against abuse by AS N (for instance, AS N
>claims to have the bast path to a destination that AS X really has the
>best path to) on the basis that AS N isn't a neighbor of AS X is too
>weak as it is not extremely unlikely ASes X and N peer.

"not extremely unlikely" == "likely"?  Why?

Think of the AS 7007 situation, where AS 7007 reduced every AS path
it got to nothing and sent out updates with an AS path of only "AS 7007".
Presume instead that it truncated the AS path down to some small subsequence,
say, the originating AS on the list.  Then it makes a new update,
with the AS path = (originatingAS, AS 7007).  AS 7007 is not a neighbor of
"originatingAS" for the most part, so this is a bogus AS path.  But
signature checking won't catch this unless each AS includes its AS
neighbor in what is signed.

BBN has a way of describing this - they say that the updates and signatures
mean "I am authorizing my neighbor AS Q to announce a route through me".

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec