Subject: Securing Neighbor Discovery

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Mar 2002 16:34:18 -0800

I've submitted a draft on securing neighbor discovery,
draft-kempf-secure-nd-00.txt. Since I forgot to put an IPNG in it, the
drafts editor didn't send a notice to this list, but it was supposed to
be for consideration by the IPNG group. Please send comments.

            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-masked]
--------------------------------------------------------------------

---

From: Alexandru Petrescu<[email-masked]>
Date: 11 Mar 2002 20:14:08 +0100

"James Kempf" <[email-masked]> writes:
> 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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Mar 2002 16:21:39 -0800

Hi Alex,

Sorry its taken so long to get back to you.

> even if ABK's are applied some simple threats still hold.

Certainly agree.

> need for a more complex system.

The draft discusses two possible ways to use ABKs. One is based
on an authenticated exchange between the network and the host,
whereby the host proves its identity to the network and the
network does the same for the host, and the network gives
 the host a private ABK to use. I believe this is what you
are referring to above. This could be accomplished some
other way, by having a session key with the router for example, but
the advantage of ID-crypto is that there is no secret key
held by the router which must be known to other routers in
the event the node is mobile, or which must be periodically
regenerated by the network to avoid compromise. The host's private
key acts as the session key. The cryptoparameters are public so there
is no need to worry about compromise. Also, of course,
standard public key could be used, but in this case,
a cert authority would be required (for a full blown
PKI) or, at the minimum, the host would require
some way to obtain the router's public key. If the
public key is the subnet id, there is no requirement for
this, and particularly if the host is mobile, this is
very convenient.

The other way that identity is proved is that the host
and the network participate in a roaming consortium
which supplies them with preconfigured cryptoparameters
and private key. In this case, there is no need for
an authentication exchange between the host and
network for purposes of securing ND (there may
be a need for other reasons).

> When good router goes bad it's too bad.

Yup. Nothing to do but have the network operator be vigilant for
attacks. Certainly, not requiring the routers to have globally
routable addresses (as IPv6 does) will help keep attacks
to a minimum.

> infinity-0-infinity-0 and consider that subnet unreliable.

Sure, but this is a more complicated
solution that solves a single threat. And like Return Routabliltiy
in Mobile IP, there may be subtle ways around it.

> Threat 3.8 is not addressed by the ABK, I think.

You are right. If someone starts pumping packets at you, there is little
you can do, except maybe to shut down ND for a bit and maybe arrange to
find the perpetrator (it may just be buggy software).

Also, Francis Dupont pointed out that, if cryptographic techniques (any
techniques, not just ABK) are used in ND, then the process of address
resolution will suffer a performance hit (exactly how bad depends, of
course, on the implementation) and an attacker might exploit this to
mount a DOS attack.

So I agree that there are some problems that ABKs solve and some not.

            jak

---

From: Alexandru Petrescu<[email-masked]>
Date: 13 Mar 2002 11:40:56 +0100

Hi James,

After your reply, my expectations confirm more and more that this is
very much of AAA and PANA issue, and much less of securing the ND.
Simple intuition tells me that if AAA and PANA can help authenticate
the access, then ND is subsequently secured.

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.

"James Kempf" <[email-masked]> writes:
> Sure, but this is a more complicated solution that solves a single
> threat.

Yes, but depends on what complex means.  Mathematical complexity,
implementation complexity, society institutions complexity.

> So I agree that there are some problems that ABKs solve and some

I think the ABKs have an important merit in that they let the system
configure the address the way it wants, doesn't impose bits and bytes
anywhere in the address.  I still need to understand how this is done,
it looks like magic to me :-)

Alex

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Mar 2002 13:21:24 +0200

> the access, then ND is subsequently secured.

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.

> 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,
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.

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. Another basic problem is inability
to use *any* IP-based key management protocol (including
IKE) due to chicken-and-egg effect. A third problem
is that when the ND protection gets host specific -
as it should - we need some way of indicating individual
SAs.

Also, the above discussion indicates that if we are
to secure ND, we need a requirements document first.
It isn't clear to me whether everyone agrees that we
need infrastructureless, infrastructure-based, manually
keyed etc.

Jari

---

From: Alexandru Petrescu<[email-masked]>
Date: 13 Mar 2002 15:39:19 +0100

Jari Arkko <[email-masked]> 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.

> able to separate the keying part from the protection part,

This is as natural as it gets.

> 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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Mar 2002 16:55:24 +0200

> infrastructure-less and infrastructure-based arguments apply a little

True (OTOH, other things being equal configuration-less
and infrastructure-less is better).

> the ones created by automatic keying, but I might be wrong.

They can be similar, but my point was that if you use manual
keying you don't want to create a million SAs, while with
dynamic keying you could in theory do that.

> protect from hosts, but we should not look into routers protecting

Yes... I meant that it isn't sufficient for the whole network
to be secured with a single key. This would be possible with
a small extension of IPsec (e.g. standardized SPI value for ND
protection), but wouldn't work in public LANs.

Jari

---

From: Markku Savela <[email-masked]>
Date: Wed, 13 Mar 2002 17:23:08 +0200

> From: Jari Arkko <[email-masked]>
> 

One could consider a special "helper" application/daemon, which would
input from user (configuration) single manual key, and then would
generate and install the necessary from SA's for the ND protection (I
suspect this "daemon" would need to be constantly running, as SA's may
be needed dynamically. Perhaps it could be an additional IPSEC key
manager (which is at least possible with PF_KEY architecture,
e.g. multiple key managements)

One could have "secure virtual home WLAN" this way, as all ND would be
protected by this key which is only configured to your own machines at
home (or at any closed group wanting privacy over WLAN).
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Mar 2002 10:33:55 -0800

Alex/Jari

> > the access, then ND is subsequently secured.

Not necessarily. As the ND threats draft I  believe mentions, a fully
authenticated
node might decide to start playing the trickster, snooping traffic, etc.
Cryptographic
security on ND messaging helps prevent that. All AAA does is
authenticate at the
time of network entry, that the host is authorized to use the network,
and provide
the host with whatever it needs to have access. It doesn't prevent
subsequent
misbehavior.

> as it should - we need some way of indicating individual

Right, these are all issues the ABK draft was written
to help solve, and CGAs might work here as well.

> need infrastructureless, infrastructure-based, manually

Good point.

My intention here is fairly practical. Public access 802.11 networks
today
are very insecure on the last hop. If you look at Mobile Star's
(an 802.11 public access network provider) page, they basically say
you are on your own as far as security goes. For purposes of
providing the kind of secure wireless ISP service that people
expect, I think we need a solution to this problem, and fairly
soon.

So, while I want a good, scalable technical solution, I am
not particularly religious about what form the solution takes.
ABKs have a kind of technical elegance IMHO (as do CGAs
in their own way), but if we can make things work with
IPsec then I'm certainly not averse to doing it.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Mar 2002 10:41:53 -0800

Alex/Jari,

> 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.

> 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.

> protect from hosts, but we should not look into routers protecting

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?

> > 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

---

From: Markku Savela <[email-masked]>
Date: Wed, 13 Mar 2002 22:56:58 +0200

This might belong to IPSEC list, but just give a concrete idea about
it, here is a solution sketch...

Securing ND with existing IPSEC (kernel) only needs to agree on
specific SPI to use and, assuming a special key management daemon,
which would do the following tasks

 - inputs "lan key from as configuration". All generated SA's use this
   (or something derived from it deterministically)

 - automaticly installs following SA's

   1) one SA for well known multicast addresses:

      spi=1 dst=ff02::1 src=any protocol=any
      spi=1 dst=ff02::2 src=any protocol=any

   2) one SA for each own address and solicited node address:

      spi=1 dst=myaddress, src=any, protocol=any
      spi=1 dst=solicitednode, src=any, protocol=any

 - when kernel IPSEC asks a specific SA with dst= link local (unicast
   or multicast), src=any, protocol=any, it installs:

      spi=1 dst=requested-dst src=any protocol=any

then the following security policy is sufficient to protect all ND
discovery and all link local traffic for good measure.

   ff02/16 -> use ESP (src=any, protocol=any)
   fe80/10 -> use ESP (src=any, protocol=any)

For example, when link comes up, system would need to send RS, thus it
matches the multicast destination policy actually and the preinstalled
SA

   spi=1 dst=ff02::2 src=any protocol=any

Note, that the SA's with multicast dst can be used both incoming and
outgoing.

When kernel needs to send neighbor solicitation, the solicited node
destination matches the policy and appropriate SA is requested from
the special key management.

At least it would work this way with my IPSEC :-). Only the "special
key management" needs to be written. Doesn't look too difficult to me.

The end result would be "multiple virtual lans" on the same physical
media (ethernet, wlan). Only those nodes with same configured key
would see each other.

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Mar 2002 13:28:32 -0800

Markku,

>       spi=1 dst=solicitednode, src=any, protocol=any

Maybe I'm showing my ignorance here, but how does the host install this
SA without doing ND? Use the multicast SA to bootstrap?

Other than that, this looks interesting. Why don't you write a draft on
it?

            jak

---

From: Markku Savela <[email-masked]>
Date: Wed, 13 Mar 2002 23:37:26 +0200

> SA without doing ND? Use the multicast SA to bootstrap?

The "special ND key manager" generates the keys and installs the SA's
directly. It does not communicate with other hosts at all. Of course,
the key generation algorithm and SPI assignment logic must be the same
on each host (this is what would need and RFC to get an agreement).

As far as user is concerned, this would be no different than from
configuring the "password" to the WLAN card of each host that wants to
participate. Only, with IPSEC the crypto would be much stronger.

---

From: Dan McDonald <[email-masked]>
Date: Wed, 13 Mar 2002 17:21:23 -0500 (EST)

> SA without doing ND? Use the multicast SA to bootstrap?

I gave a talk about what Markku was proposing a few IETF's ago under the
title "The Link-Shared Secret".  Basically, you start with a shared-secret
that all nodes on the link use.  You then derive IPsec SAs based on this.

> Other than that, this looks interesting. Why don't you write a draft on

It is interesting, until you factor in the famous Jeff Schiller problem:

	Your attacker is often a legitimate user of the link.

	A person who's trusted on the link can forge packets from any other
	user on the link... including the router, or any other neighbors.

In a perfect world, ND would allow a host to only do host-type things, and
then only on behalf of the host itself.

You _might_ be able to separate out the router-advertising functions of ND by
using an AH auth transform that is a digital signature, but processing this
in interrupt context would be painful.

Solve the aforementioned Jeff Schiller problem, and you probably can secure
ND.  If you can't, all such solutions will just limit your troublemakers to
who is allowed on the LAN.

To be fair, in some cases that's Good Enough (TM).  Perhaps I should bring
back link-shared secret from the dead.

Dan

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 13 Mar 2002 14:32:36 +0100 (CET)

>    (or something derived from it deterministically)

Dan McDonald did a presentation in IPNG on such a scheme a few years back.
I don't recall if there ever was an internet-draft.

This is using all symmetric crypto, right?

This means that if you allow a host on the network and let it
authenticate the router advertisements it has secret necessary
to pretend to be a router itself i.e. can redirect traffic arbitrarely.
While that *might* be reasonable for e.g. a corporate LAN
I don't think it is sufficient for a public access LAN.

Inherently there seems to be a need to authenticate authorized routers
without being able to pretend to be one. 
Thus different keying material must be used by the sender and receiver.

  Erik

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Mar 2002 15:26:13 -0800

> participate. Only, with IPSEC the crypto would be much stronger.

We could leverge the roaming consortium or L2 AAA for this perhaps?
Getting the user involved is not such a good option, as this has nothing
at all to do with anything the user might be concerned about.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Thu, 14 Mar 2002 01:38:54 +0200

Markku Savela wrote:

> be needed dynamically.

 > which would do the following tasks

True. (Both were listed a long time ago in Section 8 of [1] as one of
the alternatives... I tried to do something about the issue at the IPsec
WG but there weren't too many interested parties, maybe v6 wasn't interesting
at that time, or something.)

But as Erik pointed out the symmetric crypto may not be
sufficient.

Jari
----
[1] http://www.piuha.net/~jarkko/publications/draft-arkko-manual-icmpv6-sas-00.txt

---

From: Jari Arkko <[email-masked]>
Date: Thu, 14 Mar 2002 01:43:57 +0200

> at all to do with anything the user might be concerned about.

Something like 802.1x EAP with an appropriate EAP submethod that generates
session keys could be used here. Then you would get per-host session keys,
and presumably all announcements coming from the router would have to be
duplicated for all receivers, and there'd be no host-host communication. Perhaps
that might be good in enough in some cases.

Alternatively, AAA might give you the overall key for the network. In that
case there'd be no limitations mentioned above, but you could spoof yourself
as the router or the other hosts. Not sure there's increase in security
compared to where we started, if unsuccessful network access authentication
throws you out of the link.

Jari

---

From: "James Kempf" <[email-masked]>
Date: Wed, 13 Mar 2002 16:52:45 -0800

> Your attacker is often a legitimate user of the link.

Right, that's the point I was trying to bring up in my response to Alex.
Just because someone has undergone
AAA successfully doesn't mean that they won't disrupt the link.

> back link-shared secret from the dead.

What we were trying to do in the ABK draft was provide a way that a node
on the link could determine definitively that a particular ND/RA message
came from the node/router possessing that identity. There main issue is
some way to establish the right of the node to possess that identity
beforehand, and we included sketches of a couple ways that seem
consistent with current practice. We probably need to flesh these out
some.

That said, ABK is a new an largely unknown technology. In the security
area, old and well trusted technologies are often easier to make work,
because the holes are well known and can be patched around. So a
solution based on IPsec, should it be possible to make it work and prove
secure, would certainly be of interest.

            jak

            jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 13 Mar 2002 18:49:16 -0800

Jari,

> IKE) due to chicken-and-egg effect. A third problem

Actually PANA should be able to work before IP address
configuration, and most possibly (not a requirement) will
distribute keys... 

> as it should - we need some way of indicating individual

alper

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 13 Mar 2002 19:11:45 -0800

Jari,

> that might be good in enough in some cases.

Actually, 802.1x also gives the host a multicast/broadcast key.

alper

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 14 Mar 2002 09:11:31 +0200

James Kempf wrote:
 > Just because someone has undergone AAA successfully doesn't mean that
 > they won't disrupt the link.

I completely agree.  Additionally, I'd like to see an
infrastructureless solution to be used anywhere possible.
Why?  Basically because an infrastructureless solution means
that we can make it to work with zero configuration, while
any infrastructure necessarily needs that either the initial
credentials must be configured or that new nodes must learn
the credentials of the infrastructure through "leap of faith".

Dan McDonald wrote:
 >> In a perfect world, ND would allow a host to only do host-type things,
 >> and then only on behalf of the host itself.
 >>
...
 >> Solve the aforementioned Jeff Schiller problem, and you probably can
 >> secure ND.  If you can't, all such solutions will just limit your
 >> troublemakers to who is allowed on the LAN.
...

 > secure, would certainly be of interest.

Already a year ago I tried to point out that CGA can be used
to solve the ND security problem.  Since CGA is able to securely
bind a public key to a interface ID, you can use CGA to verify
that the right party "speaks for" the interface ID.  That seems
to be sufficient to solve ND.  However, it doesn't help much
with router discovery.  Personally, I think that ABK might have
great potential for router discovery, since ABK can to convert
even network prefixes into public keys.  Now, if we just could
figure out how we could use ABK to somehow express trust relationships
between more covering prefixes (e.g. 3ff0::/16) and subprefixes
(e.g. 3ff0:1::/20), then we would have something...

Back then I also wrote an I-D, which describes one method how
CGA can be used for ND.  For various reasons that I-D never
got published, but it has been available and is still available at
http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-pbk-addresses-00.txt

The basic ideas are also described in

    Pekka Nikander, "Denial-of-Service, Address Ownership,
    and Early Authentication in the IPv6 World", presented
    at Cambridge Security Protocols Workshop 2001,
    April 25-27, 2001, Cambridge University. To be published
    in the workshop proceedings at the LNCS series.

A pre-publication version of the paper is available at
http://www.tml.hut.fi/~pnr/publications/cam2001.pdf

--Pekka Nikander

---

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Mar 2002 08:51:17 -0800

Pekka,

> the credentials of the infrastructure through "leap of faith".

In general, if I am a network service provider, then I have a
strong business interest in maintaining good service in my network.
Since I
am paying for the routers, wires, electricity, etc., and my
customers are paying me for the service, I want to make
sure I've got control over the quality of IP service that gets
delivered, so I can deliever good service to my customers.

This is not like the MIP BU security problem where there is
no infrastructure for authenticating across the Internet. There is, in
fact, an
extensive infrastructure that is available, both technological
(in NASes and AAA servers) and business/societal (in roaming
agreements and billing reconciliation) for ensuring that the host
that gets on the network is who they say they are, and that they
pay for the service they use. This infrastructure is thus leveragable
for
authenticating that the host that gets on the network has the right
to claim a particular identity. What's needed yet, and what we've
proposed in ABKs, is a way for other hosts to validate that claim, and
for a host to validate the claim of a router in that regard after the
initial
entry into the network. The note that Markku sent regarding use
of IPsec seemed like it might have the same properties (but the
details need to be worked out).

So, the upshot of what I am saying is that I believe this is not a
purely
technical problem. There are sociological and business aspects
of it that suggest a solution which leverages off the existing
authentication/business infrastructure is likely to be more of interest
to
existing ISPs and future wireless ISPs.

Now, that said, I agree that an infrastructureless solution may be of
interest in some circumstances. It may even be of interest to ISPs,
if the details are right. But I don't think there will ever be a case
where an ISP will let a host on their network without requiring
some kind of authentication as to the right of that host to use
the network (unless, of course, the ISP is giving away the
service).

            jak

---

From: Jari Arkko <[email-masked]>
Date: Thu, 14 Mar 2002 19:03:18 +0200

James Kempf wrote:

> The upshot of what I am saying is that I believe this is not a
> purely

True.

However, I wouldn't like to design the Internet _just_ for
the ISPs and the commercial providers. If I'm a small business
or a home, I want to set-up my networks without infrastructure,
and I want it to "just work". For instance, I could lay a
network in my home, expect IPv6 to work without major
holes even if I might be using open wireless LANs, and I
would also expect to use other types of infrastructureless
technology, such SSH for my e-mail forwarding and telnetting
needs. I don't want to set-up anything, unless we can
prove that it is necessary. And it doesn't appear to be,
based on proof by example i.e. some proposals that don't
need infrastructure.

Jari

---

From: "James Kempf" <[email-masked]>
Date: Thu, 14 Mar 2002 09:58:07 -0800

Jari,

So, this is getting a little off topic for this list, perhaps
we should move the discussion elsewhere?

Final comments below.

> based on proof by example i.e. some proposals that don't

I don't want to denigate the importance of SOHO and small
networks. Small networks are OK, but designing
something for the Internet based on an assumed small network
configuration would be a mistake, IMHO. The 802.11
committee made this mistake, and now we are trying
to get some attention to fixing it.

What I'm concerned about specifically is the upcoming
deployment of public access IPv6/802.11 networks that
have no security on ND. This is a looming real problem, and
I'd like to see the IETF develop some interoperability
specs to address it before it happens instead of afterwards.
So I'm not arguing from a theoretical or assumed future
scenerio case, but from a problem that I see looming
right now (NTT is deploying a prototype 802.11 network in
Kyoto at the moment).

I think the design needs to accommodate both small networks and
large networks, i.e. it must be scalable. I think that can be
achieved by providing space to leverage off the existing authentication
infrastructure if it is there. If it isn't, then infrastructureless
methods
are, of course, appropriate.

            jak

---

From: [email-masked]
Date: Fri, 15 Mar 2002 10:50:53 +0900

>we should move the discussion elsewhere?

	I guess so.

>right now (NTT is deploying a prototype 802.11 network in

	one thing i don't understand is, why do you think it is not a problem
	for ARP, and is a problem for ND.

itojun

---

From: "James Kempf" <[email-masked]>
Date: Fri, 15 Mar 2002 10:12:55 -0800

> for ARP, and is a problem for ND.

It is a problem for ARP. To be complete, we should have a solution there
too.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Fri, 15 Mar 2002 12:52:52 +0200

> >we should move the discussion elsewhere?

I have set up a list. Send e-mail to
[email-masked] with
the text "subscribe" in the body to join.
(The name of the list is "SEND" for Secure
Neighbour Discovery.)

> for ARP, and is a problem for ND.

It is certainly an issue for ARP as well. There's a few
issues though which make the issue more relevant for us
to discuss in the IPv6 context:

- IPv6 has somewhat more control functionality (router
  discovery etc). Yes, serious enough attacks can be
  already launched with ARP, but nevertheless.

- The IETF doesn't control address resolution on different
  link technologies. We do, however, control neighbour
  discovery and ICMPv6.

- You could make the argument that let's try to fix this
  in v6 and move to using it, rather than fixing it
  in all versions of IP.

Jari