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

On Wed, 6 Nov 2002 sandy@tislabs.com wrote:

> >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.

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

> >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?

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

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