Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006

[Geoff Huston <gih@apnic.net>]

Resent for Francis Dupont, as his pointing was bounced by the him6 
list manager (non-member submission

======================

In your previous mail you wrote:

   > => I strongly disagree about the first point (the main threat of mip
   > is the remote redirection, time shifted attacks and similar things are
   > second order issues),

   i agree that the main threat is redirection attacks and this is
   reflected in 4218, but my point was that the most dificult attacks to
   prevent are the time-shifted attacks and this is why we end up with
   things like _periodic_ RR in mip and HBA/CGA in shim.

=> IMHO the periodic RR in mip is more to get the attacker staying
on the path than to defend against the steal of future addresses...
But the real issue here is about the method: in security one has to
provide a defense against main threats, *then* secondary threats, etc.
As perfect security is impossible one has to accept some remaining
vulnerabilities...
Here we are in trouble because the main threat is hard: the best known
defense, mutual strong authentication, is not deployable. So we get
poor mechanisms (like RR) and we try to improve them (like CBA) against
secondary threats when the main one still remains... I really like
to see shim far better than mip!

   If time shifted
   attacks were not an issue, we could have used cookies for instance or
   hash chains to protect the shim in conjuction the already existent
   routing based security (meaning the asumption that the routing system
   delivers packets to the rightful "owners" of the addresses)

=> again IMHO you miss the real issue...

   So, the hypothesis of 4218 and of mip security is of course as you say
   that the fundamental threat is redirection attacks, but also that time
   shifted attacks need to be prevented... agree with this?

=> no: I really prefer to get time shifted attacks as a remaining
vulnerability than redirection. Of course it should be better to
have none but it is enough hard to choose between acceptable level
of security and deployable solutions to be at least as possible
disturbed by secondary threats.

   >  and I don't fully agree with the second because
   > the only issue is the global PKI (ie., issuing client certificates is
   > again second order).

   global PKI is a big obstacle for deployment but imho the generation of
   client certificates it is also. I mean imagine having to create client
   certificate for every host in the internet. Imagine that for those, you
   need to verify the rightful ownership of the IP address included in the
   certificate. Technically this may be simple, but logistically, this
   requires a lot of effort imho

=> by a global PKI I mean global certification *and* registration
authorities. The problem is not technical at all even I don't believe
we know how to do it in a reasonable timeframe at this scale today.

Regards

Francis.Dupont@point6.net