Subject: A few comments on Site-Local Useage

From: Bob Hinden <[email-masked]>
Date: Mon, 04 Nov 2002 13:55:21 -0800

[Working group chair hat off]

A few comments on the Site-Local discussion that I did not see getting 
discussed or proposed.

There was a reference made to networking airplanes somewhere in this 
thread.  If my memory is correct, the airplane industry did select an open 
standard for airlines.  Some planes run ISO CLNP over FDDI.  They did pick 
an open standard, but.....

A lot of the discussion seems to imply that site-local addresses are 
created automatically (like link-local).  This is, of course, not the 
case.  Site-local are only created if someone configures a router with a 
specific site-local address on an interface and tell the router to 
advertise the prefix in a routing protocol to other routers and to 
advertise it to hosts on the link in RAs.  Site-local addresses will only 
appear in a site if an administrator decided to configure them.

It seems to me that from a reachability point of view there isn't too much 
difference between using site-local addresses and having a firewall that 
blocks traffic from one set of global addresses and another.  Firewalls 
create limited scope addresses from global addresses.  If one assumes the 
existence of IPv6 firewalls, then these firewalls can also enforce site 
boundaries.  Firewalls are essentially doing this today.  Compared to what 
firewalls already do today, this is trivial.  If the site boundaries are 
going to be defined by firewalls, then it is probably less important that 
we have to define multi-site router behavior.

One of the issues that was discussed regarding the ease or difficulty of 
configure site-local scope filters in routers.   It seems to me that the 
simple way of doing this is configure the router with the zone that each 
interface is in.  The router would then automatically create internal 
filters that enforce the site boundaries.  This seems much easier to me 
than having to create filter rules based on the prefixes that are assigned 
to each interface.

Another router issue that gets talked around is should packets with 
site-local destination be forwarded to "default".  Given that site-local 
addresses are not created without being configured, one approach could be 
to have a "black hole" route for FEC0::/10 preconfigured in all 
routers.  The router would then only forward packets with site-local to 
destinations that matched more specific routes.  They would never get 
forwarded to the ISP via the normal default route.

 From a private exchange with someone from a router vendor.  They are 
taking the approach of creating a "no-site" site in their product.  That is 
if an interface configured to be in the "no-site" site, the router will not 
forward any packets with site-local addresses to/from this interface.  This 
might make for a simple default behavior site border router.

Bob

--------------------------------------------------------------------
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: Thu, 7 Nov 2002 09:12:18 +0200 (EET)

I never got around to replying to this until now, sorry..

> appear in a site if an administrator decided to configure them.
 
Anyone can just blindly configure a site in one link.  Not much of a site, 
but you can use site-locals, and you can source traffic from site-local 
addresses..

> create limited scope addresses from global addresses.  

Note that a third option is to use global addresses (assuming the site has 
them), a part of their block, but no route it externally at all.   And add 
firewall filters besides.

> If one assumes the 
> boundaries.  

Sure, but that is not sufficient to satisfy addr-archv3 2.5.6 last 
paragraph IMO.

-- 
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: Margaret Wasserman <[email-masked]>
Date: Thu, 07 Nov 2002 03:03:30 -0500

>Sure, but that is not sufficient to satisfy addr-archv3 2.5.6 last

Why not?

If a router is not on a site-boundary, it doesn't need to do anything
to enforce site boundaries.  In Bob's example, the firewall would be
the site border "router", and it would enforce the boundary.

I don't see a conflict.

Margaret

---

From: Pekka Savola <[email-masked]>
Date: Thu, 7 Nov 2002 10:08:04 +0200 (EET)

> the site border "router", and it would enforce the boundary.

Perhaps I should have been more verbose.

What I meant to say that to implement site-locals properly in a router,
the vendor should not be OK to say "we support access-lists, you can use
them to configure site-local borders" or that "we have nice firewall
products, wanna buy one?".

That doesn't seem to be in the spirit of site-local addressing, and I
could imagine a significant percentage of site-local users wouldn't do
these steps properly, leading to a false sense of security. (Thus one
factor in the argument that site-locals in with global networks are bad.)

---

From: Keith Moore <[email-masked]>
Date: Thu, 07 Nov 2002 08:41:29 -0500

> products, wanna buy one?".

I'm not sure about that.  Having routers try to automagically determine 
site boundaries sounds nice, unless there are cases where it will fail.
If the latter is true, then requiring explicit filter configuration seems
like the way to go. 
--------------------------------------------------------------------
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: Thu, 7 Nov 2002 15:54:32 +0200 (EET)

> If the latter is true, then requiring explicit filter configuration seems

.. which brings me back to my original point that the spec text should be 
written in such a fashion that people don't expect the site-local filters 
to "just work", but that people need to do it themselves.

I'm not sure if folks really understand the security impleications (or 
lack thereof) when dealing with site-locals, and the spec doesn't make it 
any better.

---

From: Brian Haberman <[email-masked]>
Date: Thu, 07 Nov 2002 09:44:57 -0500

> lack thereof) when dealing with site-locals, and the spec doesn't make it 

The original intent in the scoped addr arch was that the site-local
zone id would be indicate which interfaces are within a site.  The
filtering between sites is handled by the forwarding code.

Vendors that support these zone ids will have default values for the
zone ids.  If the vendors don't support the zone ids, the box will
be unable to act as a SBR unless the user builds the filters.

Brian

---

From: Pekka Savola <[email-masked]>
Date: Thu, 7 Nov 2002 16:49:40 +0200 (EET)

> be unable to act as a SBR unless the user builds the filters.

I expect many routers will be used in the border of a site and a global 
internet which do not implement the scoped addr arch draft/document, at 
least in full.

---

From: [email-masked]
Date: Thu, 07 Nov 2002 23:50:13 +0900

>be unable to act as a SBR unless the user builds the filters.

	"default value for zone ids"?  which document suggests that?
	i have never seen such docs.  draft-ietf-ipngwg-scoping-arch-04.txt
	talks about default zone id for global address (= 0), but is silent
	about site-locals to me.

itojun

---

From: Brian Haberman <[email-masked]>
Date: Thu, 07 Nov 2002 09:59:04 -0500

> 	talks about default zone id for global address (= 0), but is silent

 From Section 6:

  An implementation should also support the concept of a "default" zone
  for each scope.  It is convenient to reserve the index value zero, at
  each scope, to mean "use the default zone".  Unlike other zone
  indices, the default ID does not contain any scope type, and the
  scope type is determined by the address by which the default ID was
  accompanied.  An implementation may additionally define a separate
  default zone for each scope type.  Those default indices can also be
  used as the zone qualifier for an address for which the node is
  attached to only one zone, e.g., when using global addresses.

Regards,
Brian