Re: [RPSEC] BGP Security Requirements v08

[Stephen Kent <[e-mail]>]

At 3:05 PM -0400 7/18/07, Curtis Villamizar wrote:
>In message <p0624050fc2c3ec645621@[128.89.89.71]>
>Stephen Kent writes:
>> 
>>  >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).
>
>
>Steve,
>
>As a security guy wouldn't you consider relying on routing to protect
>secrets to be more than just a slightly bad idea?

WRT content disclosure one certainly ought not rely on the path for 
confidentiality. Hiwever, very little Internet traffic is encrypted 
today, so it still makes sense to consider this as a valid concern. 
Moreover, traffic analysis is a confidentiality concern for some 
folks, e.g., in the DoD. Avoding routes that would cause traffic to 
pass through an AS where TA might be effected is a reasonable goal as 
well.

>For secure applications you must always assume an insecure channel
>even if its in the same building.

I have no idea what you're saying above.

>With enough snooped data breaking some forms of encryption is
>possible so I know what you are getting at.

No, you don't :-).

>In terms of real world, it might be possible to divert information
>that is supposed to go to some major bank from some far away place and
>have a go at the SSL encryption but I suspect its orders of magnitudes
>easier to take over the client's Windows box and record keystrokes.

That's not what I am alluding to, so let's not waste time arguing 
over what you think I might have said, but didn't really say :-).

>  > 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.
>
>At what point do we set theory aside and look at whether we are
>addressing any sort of real world problem?  Is your answer "never"?

Sounds like you're asking if I have stopped beating my wife yet? :-)

SSL/TLS is very widely used, yet it's primary protection is against 
wiretapping attacks that rarely occur. (It also is supposed to 
provide authentication that we are connected the the site we think, 
but the PKI model used with browsers limits the ability to achieve 
that goal.) In reality, your credit card data is at much greater risk 
when it arrives at a web server vs. while it is in transit. I believe 
that the concerns we're addressing here are at least as valid as 
those addressed by TLS.


>  > 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.
>
>OK.  Lets have some specifics.  What deployment scenarios?  Where
>could transitive behaviour that only applies to selecting among
>incompletely authenticated results (and can be administratively
>disabled) lead to bad decisions?

In a message earlier this week I suggested that a likely deployment 
scenario might be that big ISPs are the early adopters, followed by 
their customers.  In such instances there are no intermediary ASes to 
worry about.

Your second question seems to be a mix of two things. Let try to 
re-phrase.: What bad thing might happen if an ISP uses partially 
verified data to select a path when the only paths he has for the 
NLRI in question are all unverified? You also add in a parenthetical 
allusion to the ability to administratively disable something, 
presumably you mean the ability to turn off checking the verified 
path data when it is only part of an overall path.

A bad thing that might happen is that the ISP might configure the 
router to automatically prefer any route that has at least SOME 
verified path components, an easy policy to express, but one that 
also is naive. Trying to express a more reasonable policy, e.g., one 
that take into account known "trusted" ASes and a mix of verified and 
unverified path elements is very complex.  We developed a set of 
policy controls that tried to do this a fee years ago, and decided 
that the result was so complex as to create more problems than it was 
worth. We decided that only a simple policy setting, i.e., my peer 
has security enabled or not, was easy enough to be practical.

It seems that many ISPs have trouble predicting the impact of route 
configuration choices today (c.f. RFC 4264 "BGP Wedgies"). I think it 
is not unreasonable to extrapolate this sort of experience with 
complexity to the routing security context and come the the 
conclusion that we ought not create an environment that makes it 
likely that folks will have the same problems.

Steve


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