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

From: [email-masked]
Date: Wed, 6 Nov 2002 09:36:13 -0500 (EST)

>Wouldn't AS X be the only one who can successfully send an update with
>AS X as the first/last AS in the AS path? If AS Y took this update and
>announced it then either it would have to add AS Y as per RFC 1771 and
>the path and thus the entire update would be different, or it wouldn't
>and a very simple sanity check would fail.

(a) See recent discussion on idr list about whether AS's always, always,
always add their own AS to the AS_PATH before transmitting updates.

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

--Sandy
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 6 Nov 2002 10:13:30 -0500

Please note that since I haven't had a chance to read s-bgp I may
have missed some of the intricacies of this thread.

> always add their own AS to the AS_PATH before transmitting updates.

The only typical (and extremely a-typical at that) example of this
situation is with a route server.

Given what route servers are used for (typically, inter-domain proxying
of routing policy), it is likely that in an environment where 
certificates are used that each route server peer will delegate some
form of signing authority to the server where that authority isn't
*exactly* the same as the peer itself.

Thus, I authorize the server to sign my updates (which I have already
signed) with something weaker that says that "I am authorized to
transparently proxy this route.  Once you validate me, ignore me."

Or, in other words, the signing would be bound to the originating
peer's update - a co-signature if you will.

-- 
Jeff Haas 
NextHop Technologies

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 6 Nov 2002 17:09:58 +0100 (CET)

> always add their own AS to the AS_PATH before transmitting updates.

I can't be sure from memory that this is required as per the RFC, but if
it isn't strictly required than not doing it is so rare that it
shouldn't be hard to either mandate it should or have some special
processing/manual configuration for the exceptions.

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

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.