Jari Arkko <[EMAIL PROTECTED]> writes: > Well... while I'm an AAA guy myself, I really don't wish we need to > get AAA everywhere just to secure our LAN control signaling. I'd > like to concetrate also on infrastructureless methods.
Using Radius to escape 802.11b weaknesses is deployable for small LANs, I think. > > If I were to work on securing ND, I would leave the key obtention > > behind (be it AAA, IKE/JFK/LBJ, ABK, CGA) and concentrate on how AH > > and ESP are applied to ND messages and see with that how to solve the > > threat draft. I might have a look into that, probably. > > This on the other hand is an interesting issue. We may be > able to separate the keying part from the protection part, This is as natural as it gets. > even if the keying would take place without an infrastructure > as in CGA. E.g., a router could use the host's public CGA > key to encrypt a session key which it sends to the host, and > the host uses this key in AH/ESP to protect actual signaling. Two things here. One is that CGAs and address ownership were born out of very remote interactions, like in MN-CN across the whole network, while ND is happening on a link among neighbours; as such I think the infrastructure-less and infrastructure-based arguments apply a little less. The other is that I like a more equipotential perspective in ND, e.g. in your above keying procedure, swap 'host' with 'router'; after all, routers also act as neighbours. I would also like this activity to be only a little part of a greater "Securing Neighbour Discovery". For example, RFC 3041 is already securing the ND somehow: it provides privacy when Ethernet is used. > But the modifications necessary before ESP works well enough for ND > are pretty interesting. The basic problem we need to deal with > manually keyed ESP is dst address as a pointer to the SA; this needs > to change if manual keying is to be used. Aha, I was thinking that manual keying will create an SA similar to the ones created by automatic keying, but I might be wrong. > Another basic problem is inability to use *any* IP-based key > management protocol (including IKE) due to chicken-and-egg effect. Aha, this is interesting. This is why we should probably not address it. Allow someone else to solve it :-) > A third problem is that when the ND protection gets host specific - > as it should - we need some way of indicating individual SAs. Should it or shouldn't it? I would say that hosts should protect from routers and routers should protect from hosts. And hosts should protect from hosts, but we should not look into routers protecting from routers. > Also, the above discussion indicates that if we are to secure ND, we > need a requirements document first. Things are quite simple here, I think. Many of the requirements are in the threats draft. > It isn't clear to me whether everyone agrees that we need > infrastructureless, infrastructure-based, manually keyed etc. I don't know either who agrees and who doesn't. 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] --------------------------------------------------------------------
