Subject: a different approach to site-local's "security"

From: Steve Bellovin <[email-masked]>
Date: Mon, 25 Nov 2002 14:08:21 -0500

Some people want the "security" that site-local brings.  For a 
different approach that's about as easy but more flexible -- and 
without the architectural complexities of site-local -- see
http://www.research.att.com/~smb/papers/draft-bellovin-ipv6-accessprefix-00.txt
(I've submitted it to internet-drafts, but they've got a backlog to 
clear.)

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com ("Firewalls" book)

--------------------------------------------------------------------
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: Pekka Savola <[email-masked]>
Date: Mon, 25 Nov 2002 23:03:11 +0200 (EET)

Hello,

> (I've submitted it to internet-drafts, but they've got a backlog to 

I like this approach as the trust model of router advertisements and 
configuration appears to be similar.

One general worry is whether the RA's are the right place for doing 
something like this, and whether this includes "RA explosion".

One alternative solution would be an option in e.g. router
solication/neighbor solicitation (directed at the config'd router),
explicitly asking for the info by defining a bit in the ND header.  I'm
not sure what is best.

Comments:

 1) the proposed solution will prevent neighbor discovery, as link-local 
multicast address is not allowed as destination.  Also, what about the 
first DAD packet with the unspecified address..  

 2) prefix lifetime; would there be any restrictions on withdrawal of it, 
like there is one of 2 hours in default route advertisements.

 3) I'm not sure if link-locals should be overridable; it's just way too 
easy to screw up the system intentionally/unintentionally..

 4) 'class' is essentially required if we have differently scoped dumb 
devices in the same segment, and we want to do config shortcut ("in the 
printer menu, select class X").  If we concentrate on dumb devices, I 
believe class is pretty much unnecessary (or at most, there could be like 
3 bits to use, the rest being reserved)

 5) I'd be much harsher against "security" of this option in the security 
considerations; in particular, the last paragraph protections only protect 
from most off-link attackers, you can do anything if you're on-link.

 6) perhaps the applicability of this mechanism should be restricted to be
used only on physical links, ie. tunneling (which introduces remote
off-link attacks using link-local addresses and hop count of 255) or
pseudo-interfaces could be forbidden.

btw. doesn't specify if prfxlen > 128 is received, but I guess it's
obviously silently discard.

HTH

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Tim Chown <[email-masked]>
Date: Mon, 25 Nov 2002 23:58:21 +0000

> configuration appears to be similar.

Ditto.
 
> something like this, and whether this includes "RA explosion".

Indeed.  If hosts trust RAs to determine addressing and default routing,
then DNS is a next logical step.  Beyond that, how much creeping featurism
do we wish to add?

Tim

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Nov 2002 20:01:54 -0500

> then DNS is a next logical step.

no it's not.  DNS has nothing to do with addressing and routing, and
I don't particularly like the idea of expecting the routing system
to provide application-specific data to hosts - particularly when that
data has nothing to do with network topology.

Keith