Re: [RPSEC] BGP Security Requirements v08

[Stephen Kent <[e-mail]>]

At 11:44 AM -0400 7/18/07, Curtis Villamizar wrote:
>In message <p0624051cc2c286f29523@[128.89.89.71]>
>Stephen Kent writes:
>> 
>>  As a "security guy" I would not agree with your opening statement.
>>  We usually worry that mixing unverified info with verified info, in
>>  any context, is a recipe for trouble, as it encourages folks to
>>  accept the mixed info and treat it as verified.  You give an example
>>  of ISPs wanting to " ... distinguish their services as having
>>  somewhat more reliable routing due to the use of authentication ..."
>>  That is precisely the sort of claim most security folks would worry
>>  about :-).
>
>
>As a security guy, you could think of it as a different kind of (not
>very good) security across a known reliable ISP or a small set of
>known reliable ISPs.  A provider may peer with one or more ISPs who
>they know have excellent security practices and whose routing is known
>to be fairly robust.  An set of AS with those AS numbers only plus
>a set of authenticated AS would be more likely to deliver packets than
>an AS Path through unauthenticated AS of unknown reliability.

I think we are in agreement that, under some circumstances, one could 
make good use of path info that is a mix of verified data from 
unknown ASes, plus unverified data from known, trusted ASes. However, 
I also think it is fair to say that there are examples of incremental 
deployment where this is not a requirement. Moreover there are be 
cases where relying on trusted ASes will cause problems, not because 
the ASes are not trusted, but because people make mistakes and these 
mistakes are equivalent to some forms of attacks.

Given this mix of possible scenarios, it seems appropriate to allow 
for solutions that accommodate propagation of mixed (verified and 
unverified) path data, but not to mandate them. Hence a MUST here 
seems too stringent, as that is a mandate. SHOULD expresses a strong 
preference for solutions to accommodate this capability, and MAY is 
neutral.  That's why I believe MAY is appropriate.


>What we are talking about here is prevention of DOS, not protection of
>secrets.

DoS is the primary concern, but not the only one. Misrouting to 
effect active or passive wiretapping also was cited as a concern in 
RFC 4272 (BGP Security Vulnerabilities Analysis).

>Choosing a path that is extremely likely to be reliable but
>not guarenteed to be reliable in practice is clearly an improvement
>over choosing any available path.  It is the sole basis of most policy
>routing decisions today.

Choosing a path that is extremely likely to be reliable is obviously 
a goal, but having some verified info for a path does not, per se, 
make it "extremely reliable."

>My view on this is we can strive for perfection and get nothing at all
>or try to improve the current situation and get the work implemented
>with limited deployment in ISPs and due to being implemented the
>security community has it and can use it as they please.  My concern
>is that with no interest from ISPs it will be hard to get vendors to
>implement and it will never get PS status for lack of implementation.

I have to admit that whenever I hear someone argue that a proposed 
security approach is striving for perfection at the expense of 
practicality, I wince. Thus is a reasonable argument in principle, 
but very often folks disagree about what constitutes a practical (or 
impractical) solution, or a what constitutes reasonable threat model, 
etc.  So, let;s try to not go down this path as a basis for deciding 
about these requirements, as it is unlikely to be a fruitful wa to 
resolve our disagreements.

>It would be nice to hear from ISPs since I'm not at one.  If memory
>serves me, we had two opinions voiced.  One was that some sort of
>transitive property across non-authenticated AS was a necessary
>feature.  The other was that the storage overhead needed to be
>reasonable or ISPs who did not use the authentication would simply
>drop the attributes at their peerings.

The second argument you cited was not the principle one, but rather 
an example of why mandating this as a requirement might be 
problematic.  I think the argument I have made in this and previous 
messages is that there are a number of incremental deployment 
scenarios where the need for the sort of transitive property you cite 
is not needed, and there are scenarios where it could lead to bad 
decisions.

Steve


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