Subject: Re: [RPSEC] BGP Requirements Draft

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

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

We are (I am) only discussing the path adjacency check here.

Even in the bounds of a path starting with a valid originator and finishing
with a transmitting peer, the path adjacency test does not ensure that every
AS  in between actually saw/touched/propagated/announced the route.

--Sandy

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

---

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

> AS  in between actually saw/touched/propagated/announced the route.

Can you show how proving an AS has touched a piece of routing 
information actually increases security, taking into consideration 
aggregation, filtering, and re-origination? Can you show how it allows 
some policy not allowed by other conceivable tests?

Remember, way back, I said I was willing to live with the wording 
stating that the second check is "more secure" than the first check, 
although I don't agree with it. In the interest of moving the draft 
forward, I'm still willing to leave that wording in. What I'm not 
willing to do is to state the BGP specification says things that it 
doesn't say--that a BGP speaker is remiss if the AS Path sent to a peer 
is reordered, for instance. In fact, we already know of one specific 
instance where the AS Path is reordered, in the case of an AS Set.

:-)

Russ

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