Re: [RPSEC] BGP Security Requirements v08

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?

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

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

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.

> 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"?

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

This would not be the first routing activity of the IETF that was
great in theory but went nowhere because it had no practical
deployment scenario.  If it goes nowhere it is a waste of our time.

Curtis

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