"James Kempf" <[EMAIL PROTECTED]> writes: > I've submitted a draft on securing neighbor discovery, > draft-kempf-secure-nd-00.txt.
Hi James. Thanks for providing the tandem threat-solution for ND. As before, I'll make a case against using crypto as a total solution for a fine-grained problem. Please note that I think I understand some of the merits of the ABK crypto-system (I still miss some details). The threat document points out valid security concerns with ND. IMHO, some are easy to deal with and some other are harder, but in any case not all require total application of the ABK mechanism, noting that even if ABK's are applied some simple threats still hold. Threat 3.1. Malicious Last Hop Router fools the victim into using it as a default router. If the legitimate AR uses the ABK system then the attacker AR can also use a similar ABK system, right? It might be argued that the attacker AR can not communicate with the MN because it can't be authenticated by the MN with an attacker NAS, fair enough. But in that case, if the MN already shares a secret with the NAS, why not using the same secret to authenticate the ND, thus questioning the need for a more complex system. Threat 3.2 Good Router Goes Bad is probably less particular to ND. When good router goes bad it's too bad. Threat 3.5 Bogus On-Link Prefix can be addressed by a smart legitimate access router sending RA's with the attacker-prefix with lifetime 0. A smart MN could even detect too many RA sequences infinity-0-infinity-0 and consider that subnet unreliable. Threat 3.7 DAD seems to be solved by using an ABK system if the legitimate node will verify the authenticity of RS's. Threat 3.8 is not addressed by the ABK, I think. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
