Subject: Re: [RPSEC] BGP Requirements Draft

From: Sandy Murphy <[email-masked]>
Date: Mon, 26 Sep 2005 09:06:36 -0400 (EDT)

>Reordering the AS Path
>...
>As for removal,

No.  I am not talking about reordering or removal.

You are advocating for a check that would ensure that the path contained
valid adjacencies and against a check that would ensure that the AS's
in the path had all touched and passed the route.

That means that the receiver knows only that the path represents
valid peerings.  There's no indication that the sender ever got the
path suffix to which it added its own AS in an UPDATE at all.  And you can
look back at some examples I posted in the list earlier this year.

So someone connected to 1239, and 1239 has a peering with 7018, could get
a route that said
12/8, 1239 7018
and it would pass the peering adjacency test
as would
15/8, 1239 7018
204/8, 1239 7018
123.0.0.0/24, 1239 7018
x.y.w.z/24, 1239 7018
etc etc etc

The path adjacency check would work for any prefix in the world.
It doesn't matter if 7018 ever announced that prefix to 1239.
Since you are checking adjacencies only, you aren't checking if 7018
announced the prefix to 1239.  Just that there's a peering, so it is 
not an impossible path, and who knows,  that path might just work!

--Sandy

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

---

From: Russ White <[email-masked]>
Date: Mon, 26 Sep 2005 09:16:38 -0400

> look back at some examples I posted in the list earlier this year.

Actually, this isn't true.... First, elsewhere, the requirements draft 
states that the originator must also be verified/authorized/etc. Second, 
the requirements draft states that any security system proposed 
should/must require each speaker to check that the AS of the 
transmitting peer is in the AS Path as received.

> So someone connected to 1239, and 1239 has a peering with 7018, could get

In other words, what you're saying is that if you have this:

A---B---C
     +---D---E

And A advertises X to B, B can readvertise it to C or D, and E can't 
tell the difference, since there's no way to not allow B to readvertise 
the route to D, from A's perspective. Isn't this what you just said is 
outside the spec, so we can't do anything about it?

If you're saying that B can claim A has sent anything it wants to, this 
isn't true. The origin AS must be valid (as per the requirements 
document), which disallows this attack.

:-)

Russ

- -- 
[email-masked] CCIE <>< Grace Alone

---

From: Paul Jakma <[email-masked]>
Date: Mon, 26 Sep 2005 14:38:23 +0100 (IST)

> It doesn't matter if 7018 ever announced that prefix to 1239. Since 
> you are checking adjacencies only, you aren't checking if 7018 
> announced the prefix to 1239.  Just that there's a peering, so it 
> is not an impossible path, and who knows, that path might just 
> work!

Isn't the counter proposal also going check that 7018 is allowed to 
announce the prefixes concerned? Ie the "would work for any prefix in 
the world" part is not true.

Further, the counter proposal also would have 7018 declare exactly 
who is allowed to carry traffic for it, so my understanding is that 
$SOMEONE would see that 7018 did not authorise 1239 to carry traffic 
to it.

OTOH, if 7018 *did* authorise 1239 to carry traffic to it then what 
exactly is the problem with the example above? :)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Huh?