Subject: site-locals: a way out

From: Shannon -jj Behrens <[email-masked]>
Date: Tue, 8 Apr 2003 09:22:24 -0700

Here are some potential replacements for the advocated features of site-locals.
Warning:  this is a long email.

/me dons his flame retardent suit and adds some stuff to his procmail filter ;)

intermittently-connected networks:
	A BCP should be written that states that ISP's should not dynamically
	assign prefixes to intermittently-connected networks.  Miyakawa-san has
	an Internet-draft that will make this a BCP for DSL networks.  The 
	suggested BCP could also contain a recommendation that
	intermittently-connected networks may continue to use (of course) the
	assigned prefix even when disconnected.

disconnected networks:
	case 1:
		If the network administrator knows that the network may one day
		be connected, he should arrange with an ISP ahead of time to 
		determine an appropriate prefix.  Although inconvenient, this 
		would prevent the hassle of a renumbering.

	case 2:
		Networks that will never be connected can use just about any 
		prefix that they want--it's none of our business.  The fact 
		that these networks would need to renumber to join the global
		Internet may be considered by some a feature (I'm thinking 
		specifically of completely disconnected networks in the 
		government such as the ones that Michael Py has to work with.
		As for the weird networks that Keith Moore has to deal with, 
		I'm sure he can interpolate a solution that has the same flavor
		as the above).  Such networks may use the documentation prefix,
		if so desired.  However, note that the documentation prefix is
		not scoped like site-locals are.  This doesn't matter because
		this recommendation is for *non-connected* networks, so scoping
		is not needed.  (By the way, do we have a BCP against using
		NAT's?  If we do, we should reference it here.  If we don't, we
		should write one.)

	case 3:
		Networks that suddenly need to connect to the Internet after 
		years of non-connectivity should be renumbered [footnote 1].
		After years of non-connectivity, renumbering should be one of 
		the smallest problems that such networks must deal with, when 
		contrasted with the amount of security hardening, etc. that
		such networks must undergo before being safely connected to the
		Internet.  (I have a hard time believing that very large 
		networks would ever find themselves in this state, and I 
		consider renumbering a viable price for such an edge case.  
		Those who are unhappy with this suggestion should perhaps work
		toward a solution for renumbering in general, as this is a
		problem that impacts a far greater number of networks!)

security:
	Although site-locals aren't a security mechanism in and of themselves,
	they do provide a prefix that can be easily filtered by default.  
	Hence, I have two suggestions for a replacement mechanism:

	suggestion 1: 	
		About a year ago, there was a thread on this mailing list about
		a certain unused combination of bits within EUI-64 generated 
		IP's (I apologize for my vagueness.  Hopefully the initiator
		of that thread will recognize what I am trying to reference).
		I suggest that hosts (including embedded devices) could set
		that combination of bits to provide a hint to the firewall that
		some special filtering should take place.  By default, 
		firewalls should disallow communication between such hosts and
		the rest of the Internet.
		
	suggestion 2:
		The suggested minimal allocation size from an ISP is a /48.
		Within that /48, we could have a well-known /64 set aside that 
		would, by default, be a candidate for special filtering by
		firewalls.  I.e., given 2001:418:200::/48, the well known
		/64 would be 2001:418:200:F117::/64.  Although, this should be
		configurable by the firewall administrator, it would be an 
		easy task for a firewall to block incoming connections to any
		address of the form ????:????:????:F117::/64 (although bitwise
		operators would be used, instead of text matching, of course).

	Neither of the above solutions permit nested or overlapping security
	domains.  This is by intention.  The above two solutions are simply
	replacements for the non-fine-grained security benefit of site-locals.
	For nested or overlapping security domains, I recommend manual firewall
	configuration, which can (of course) be arbitrarily complex 
	[footnote 2].

provider-independent:
	How do we avoid the pain of renumbering internally due to external ISP
	changes?  The following have been proposed in the past:

	provider-independent site-locals: 
		The provider-independent nature of site-locals are the
		inspiration for the name of this section (and sub-section).
		However, if all usage of site-locals is to be deprecated, we
		must examine some of the other possibilities.  Furthermore,
		this solution doesn't even solve the entire problem!  For 
		instance, some renumbering configuration will still be 
		required if your site must be contacted by others on the
		Internet (e.g. VPN connections, B2B associations, etc.).

	true provider-independent addresses:
		This would be an ideal solution and would add great value to 
		IPv6.  However, it is a "difficult" problem in and of itself,
		so we should perhaps consider some of the other solutions
		first.

	multihoming:
		Multihoming is a proposed solution, but I don't think it fits
		the bill.  Lazy administrators use NAT to solve this 
		renumbering problem, and I don't think multihoming would induce
		them to remove NAT from their architectures.  In fact, I think 
		the two issues are somewhat orthogonal (Multihoming will not
		remove the reconfiguration necessary when one of the multiple
		ISP's change.).  Furthermore , I think lazy administrators
		would use NAT in conjunction with multihoming.  Of course, I 
		may be wrong.
		
	NAT:
		NAT is the way this problem is handled in the IPv4 world.
		That's why I think we should use it in the IPv6 world--I'm just
		kidding!

	just do it:
		All of the above solutions might be overkill for the problem at
		hand.  Provider-independent addresses and multihoming are
		difficult problems in and of themselves.  Site-locals and NAT
		arguably create more problems than they solve.  It seems to me
		that fixing the renumbering problem may be the easiest solution
		[footnote 1].

Having accomplished the above feats, we would be free of the need for
site-locals, which is indeed my goal.

Footnotes:

1) We really need to solve the renumbering problem.  It is one of the few
   remaining "naked" spots of IPv6.  Furthermore, as explained above, it could
   make solving several other problems unnecessary.  It is my feeling that it
   is a tedious problem to solve, but not one that is technically
   insurmountable.  In fact, I feel that all of the necessary tools to solve it
   are in place.

   First, it is necessary to establish the scope of the solution.  Limiting the
   scope to simply swapping prefixes of equal length could yield substantial
   benefits ("The enemy of good is better.").  Furthermore, renumbering hosts
   is easy with DHCP, so we need only worry about DNS servers and firewalls,
   etc.
   
   I will now expose myself to ridicule by reminding the gentle reader that
   I am a programmer, not a network administrator.  I've never even had to 
   renumber a large network, but please at least read all of what I have to say
   before flaming me!
   
   To start the renumbering event, a designated server sends a message
   describing the renumbering event.  The message could be sent via some 
   new multicast protocol or DHCP.  The clients (e.g. DNS servers and 
   firewalls) would be preconfigured with knowledge of the designated server,
   and they could verify the message via PGP.  Alternatively, the message could
   be sent via IPSec or TSL (the certificates could be exchanged manually, 
   since this must only be done once).  Each client response would then be
   tuned to the type of client.  A host with a DNS server could respond by 
   launching a simple program to do a textual substitution on the DNS 
   configuration file and then HUP the DNS server.  Naturally, it would be 
   optimal if BIND came with such a program.  The router response would 
   be to create new prefixes (remember that I have limited the problem to 
   swapping prefixes of equal length) and deprecate the old prefixes.  I think
   it is important that such a network-wide mechanism have an explicity undo
   mechanism, of course.

   All of the above is clearly very messy, but possible.  We need to solve the
   renumbering problem, and I think now is the time.

2) Some have claimed that having multiple security domains will break certain
   P2P apps just as site-locals do.  However, I agrue that it is the ambiguity
   of site-locals that makes them so problematic for such apps.  Furthermore,
   I suggest that if node A needs to pass node B's address to node C, node A 
   should pass *all* of node B's global addresses to node C.  If the above 
   technique does not succeed in permitting node C to connect to node B, then
   that is probably because the network administrator doesn't want nodes such
   as node C to connect to node B.

Thank you all for your patience with this rather long email.

Best Regards,
-jj

-- 
Hacker is to software engineer as 
Climbing Mt. Everest is to building a Denny's there.
--------------------------------------------------------------------
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: Hans Kruse <[email-masked]>
Date: Tue, 08 Apr 2003 14:34:01 -0400

I really, really do not think that is a good idea.  Everyone will be safer 
and retain their sanity if addresses used for this purpose have a prefix 
that is readily recognizable.

I much prefer the concept of globally unique, PI, non-routable space (for 
which this discussion thread appears to have unearthed some potential 
solutions).

> 		that these networks would need to renumber to join the global

Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer Science
Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax
--------------------------------------------------------------------
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: Erik Nordmark <[email-masked]>
Date: Tue, 8 Apr 2003 21:40:59 +0200 (CEST)

> 	Hence, I have two suggestions for a replacement mechanism:

A different replacement mechanism is suggested in 
draft-bellovin-ipv6-accessprefix-01.txt and
draft-zill-ipv6wg-zone-prefixlen-00.txt.

I this mechanism the routers advertise the "local" prefixes.
This allows the hosts to have a single knob "allow/disallow packets
from non-local sources" with very similar effect to the hosts having a
single-knob "allow/disallow configuration of non-site local addresses".
If the knob is in the "disallow" state packets from outside the local domain
(aka site) will be silently dropped by the host.

  Erik

---

From: Shannon -jj Behrens <[email-masked]>
Date: Tue, 8 Apr 2003 13:17:13 -0700

> (aka site) will be silently dropped by the host.

Yes, that does sound nicer than my idea.  Tony Hain has argued strongly for 
idiot-proofing such a security mechanism (he has mentioned multiple times that 
site-locals provide a fallback for security even if you mess something else
up); hence, it might be nice if the firewall automatically filtered based on
these prefixes; although I can imagine that that could really surprise and
frustrate some people.

Best Regards,
-jj

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 8 Apr 2003 23:10:35 +0200 (CEST)

> idiot-proofing such a security mechanism (he has mentioned multiple times
> that  site-locals provide a fallback for security even if you mess something
> else up); hence, it might be nice if the firewall automatically filtered
> based on these prefixes; although I can imagine that that could really
> surprise and frustrate some people.

A firewall typically filters packets that arrive on the "outside" 
interface that has a source address that belongs to the "inside"
to avoid certain spoofing attacks.

The site-locals is one specific case of this, but the general concept
if sufficient together with advertising the "local" prefixes to the hosts.

The only difference I can see between this approach and using site-locals
for it is the "defense in depth" point that Rich Draves raised.
When using site-locals, assuming that the ISPs in the path have configured
site boundaries and are hence filtering out packets with
site-local source addresses, then there would be multiple filters to get
past.
The only issue is that I don't know how likely ISPs are to configure site
boundaries if they are not going to use site-locals themselves.

  Erik

---

From: Robert Elz <[email-masked]>
Date: Thu, 10 Apr 2003 17:13:46 +0700

Date:        Tue, 8 Apr 2003 23:10:35 +0200 (CEST)
    From:        Erik Nordmark <[email-masked]>
    Message-ID:  <[email-masked]>

I have never considered the supposed security benefits of SL
addressing to be anything worthy of even mention.  If anything
they seem to be a red herring that is so easy to shoot down,
(to hook?) that it makes the case for SL addresses look weaker
than it is.

  | The only issue is that I don't know how likely ISPs are to configure site
  | boundaries if they are not going to use site-locals themselves.

If site locals aren't being used, then every router should be a site
boundary.   Site locals should only ever be forwarded by a router
when site local addressing is in use on multiple interfaces, and
they're all in the same site (having them default to all be in the
same site when SL is configured makes sense - it is the usual case,
so it makes life easier for most users - but if SL isn't being used,
forwarding packets containing SL addresses makes no sense at all).

That is, links without SL addressing should be regarded as being in
a site of their own, unique from all other sites.

I never even considered this as being in doubt, is this something that
isn't clear in the specs?   If so, that should certainly get fixed.

kre

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 10 Apr 2003 14:58:29 +0200 (CEST)

> (to hook?) that it makes the case for SL addresses look weaker

While I personally agree with you, lots of folks have expressed this as
a benefit of site-locals that we don't want to loose by removing site-locals.

> isn't clear in the specs?   If so, that should certainly get fixed.

I sure haven't read that explicitly in any spec, and I haven't even gotten
that impression from reading between the lines.
addr-arch says about *link*-locals:
   Routers must not forward any packets with link-local source or
   destination addresses to other links.

And about site-locals:
   Routers must not forward any packets with site-local source or
   destination addresses outside of the site.

If the intent is indeed as you assume, then IMHO the statement about
site-locals above should be augmented to say:
   Routers must by default assume that each link consitutes a different site
   that is, require explicit configuration to make multiple links be
   part of the same site.  As a result of this, routers by default must
   not forward any packets with site-local source or destination
   addresses to other links.

But I have no idea whether this intent has WG consensus - I merely do
not think the spec says what you think it should say.

  Erik