Re: Residual threats in draft-savola-v6ops-6to4-security-02.txt?

[Brian E Carpenter <brc@zurich.ibm.com>]

below...

Pekka Savola wrote:
> 
> Responding to a very old post..
> 
> On Wed, 16 Jul 2003, Christian Huitema wrote:
> > In fact, the document could get some editing.
> 
> I certainly agree it could be clearer :-)
> 
> > We should adopt a
> > structure "by threat", in which for each thread we describe the attack,
> > note the existing mitigation, discuss whether other additional
> > mitigations should be implemented, and conclude by the qualification of
> > the residual threat.
> 
> But I'm not sure what you mean especially with the first two.  Could you
> create an example threat based on the structure you'd propose to make us
> see the difference?
> 
> > We also need to agree on some qualification level.  We discussed that on
> > the list, but basically it is a matter of comparing the situation with
> > 6to4 to the situation without. If the mitigations are sufficient to make
> > the situation no worse with 6to4 than with the existing IPv4 Internet,
> > then the threat should not considered critical. This forces us to decide
> > a question, what is the level we compare to. For example, a lot is said
> > about address spoofing, but addresses can in practice be spoofed
> > today...
> 
> Yes, it's very important to decide this.  That's what I tried to raise in
> the v6ops security session in Vienna, but apparently there are no silver
> bullets which make it easier for you to consider what is the acceptable
> level of security.
> 
> (.. and more importantly, whether it would warrant scrapping 6to4, trying
> to fix it somehow, documenting mitigation methods, encouraging folks to
> use different kind of mechanisms or what..)

Not just because it's my baby, but I don't see any realistic prospect of
"scrapping" it at this point. Even if the IETF declared it Historic,
it wouldn't go away.

I don't think there is any realistic fix. IP address fields are spoofable,
and this is just an example, with some negative consequences.

So I think documenting the methods of mitigation is the only option
in practice. Of course, if someone comes up with another low-configuration
solution for hopping over uncooperative ISPs, that's fine too. That's
where the recent conversation about tunnel brokers came from.

   Brian

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <brc@zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK