Alex/Jari,
> 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.
>
RFC 3041 has a "security by obscurity" facet to it. It really isn't
security, it's more address privacy.
> > 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 :-)
>
Well, this is where L2 AAA might come in. Or the use of preconfigured
keys via a roaming agreement.
Things get easier if you build on existing business relationships and
technical infrastructure between ISPs.
> > 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.
>
Isn't the issue here the same as in the CN/MN SA problem with BUs?
Why should two hosts on a link have to establish an IPsec SA in order
to secure their ND signaling?
> > It isn't clear to me whether everyone agrees that we need
> > infrastructureless, infrastructure-based, manually keyed etc.
>
Well, I do care in so far as I want the solution to work within the
existing
ISP infrastructure as much as possible. I'm primarily concerned with
trying
to secure soon-to-be deployed wireless public access networks. There are
existing trust relationships that can be leveraged to make solving the
problem
alot easier than those involved in the MIP BU security problem. In that
case, there is no a priori trust relationship between the players to
leverage.
So while an infrastructureless solution is certainly not without its
attractions,
I think the constraints on the problem are such that it might not be
necessary.
jak
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
