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

From: [email-masked]
Date: Wed, 6 Nov 2002 12:37:37 -0500 (EST)

>> (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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 7 Nov 2002 15:03:16 +0100 (CET)

> to the path and signs that.  All signatures check.

Ah, I see now. I was under the impression including the destination AS
was only relevant to the update message and not to the signing of the
path. I see a few ways around this:

- include all neighbors in one signature: more costly in terms of
  memory, less in processing
- don't include the AS for peering neighbors but only transit neighbors
  in the signature. Then peers don't get to announce the route any
  further, which is good, mostly. Customers of the peer would have to
  accept the route without a signature, though.
- make some kind of virtual AS group

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

Because there is simply a lot of peering. The peering relationship is
one where both parties benefit from not having to send traffic over more
expensive link. It doesn't mean they trust each other. (If you _don't_
trust someone it may even be better to peer because then you know which
stuff is theirs.)

Iljitsch