Re: [RPSEC] BGP Security Requirements v08

At 10:45 AM -0400 7/11/07, Russ White wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>>>  Why? Because if you can validate the originator and the first (second)
>>>  hop (the second entry in the AS Path), then you have a good bit more
>>>  assurance the destination is valid/etc, than if you just drop this
>>>  information out.
>>
>>  As many people have said (I recall particularly Danny McPherson at NANOG),
>>  a deliberate attack would just take the valid initial info and add
>>  invalid info to it.  So it is best to be cautious about the good bit
>>  more assurance.
>
>Right--the more information you have, the more assurance you have. Just
>the origination authorization is easy to fool. Including the second AS
>in the AS Path (the first hop) makes it harder to fool but still not
>impossible. As you add more path information, you add more assurance.
>
>So, I would say it's not an "all or nothing" affair, and retaining
>information through a non-supporting AS is useful.
>
>:-)
>
>Russ

I think it's a matter of what you security goals are.

	- If you want assurance that the traffic you are forwarding 
will NOT go through a certain AS, then any gap in the secured path 
undermines this goal, irrespective of the number of "good" hops on 
the path you receive.

	- If you assurance that the path you receive is one that will 
likely cause your traffic to be delivered, again the number of "good" 
hops on the path you receive is irrelevant, as an attacker could grab 
a valid long or short path and add themselves onto it.

So I'm not sure that one can generalize about the increased assurance 
afforded by a path with more hops that can be verified as accurate.

Also, I worry that it is asking a lot for an operator to try to take 
a mix of unauthenticated paths, authenticated paths, and partially 
authenticated paths and decide how to weight them in making a route 
selection. We have a fair number of examples in other areas where 
adding this sort of complexity leads to more config errors with 
adverse security implications.

Steve

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