Subject: RE: Limiting the Use of Site-Local

From: "Richard Draves" <[email-masked]>
Date: Thu, 31 Oct 2002 15:19:57 -0800

> This would only cause trouble, I guess, if the customer's
> system attributes some special security status to packets 
> that appear to come _from_ a site-local address, which would 
> be quite inadvisable.

Hmm, perhaps there is some misunderstanding of how site-locals would be
used for security, because the idea is in fact to give special security
status to packets that come from a site-local address. Here's the model
that I have in mind.

First, the definition of a site has nothing to do with geography. It has
to do with administrative & routing boundaries.

The typical site is at least partially connected to the internet, so it
has a global prefix. (Actually one or more global prefixes.) Plus it has
the site-local prefix. The site uses a common subnet numbering plan
across its prefixes, global and site-local.

Applications use site-local addresses to ensure that communication is
within the site. For example, one has a file server that is intended
only for use within the site: the file server is restricted to only
processing requests from site-local addresses. But the file server node
also has a global address for other uses. In a more extreme example, one
may have a private node that should only be accessible within the site,
so the node has a site-local address but no global addresses.

OK, so how does one implement this functionality without site-locals?

The most obvious alternative is to do filtering or firewalling of the
global prefix at nodes within the site. (Note - NOT filtering at the
site boundary!) So the file server node is configured with a filter rule
to block packets to the file service port with source addresses that
don't match the site's global prefix. The private site-internal node is
configured with a filter rule to block all packets with source addresses
that don't match the site's global prefix. Etc.

Now in previous email I pointed out the inherent "defense in depth" of
the site-local prefix, because there will likely be multiple
site-boundary routers between an attacker and the site, all of which
would have to malfunction or be misconfigured to let the attacker's
site-local packets into the site.

In contrast, the alternative approach has no defense in depth. Any
mistake in configuring the filter rules on a file server or private node
lets the attacker through. And many more nodes have to be configured
properly, because all the internal applications and private nodes have
to be individually protected with filter rules, vs just configuring the
site-boundary routers. If the site renumbers, all those filter rules
have to updated properly.

Now in recent email, if I understand correctly, Keith is proposing that
non-routable global addresses replace site-locals in the above scenario.
So the site would have its normal routable global prefix and also a
non-routable global prefix. The non-routable global prefix would be
standardized so that distributed applications could recognize it.

This sounds exactly like site-locals with the 38 bits of zero replaced
with a unique site identifier so that derived addresses are globally
unique yet not globally routable (sites could make private peering
arrangements to route them).

(This is of course an idea that has been raised & rejected by the WG
several times previously, but never mind that for now.)

Keith, do I understand this right??

Thanks,
Rich

--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Thu, 31 Oct 2002 19:05:50 -0500

> > system attributes some special security status to packets=20
> > that appear to come _from_ a site-local address, which would=20
> > be quite inadvisable.
> 
> status to packets that come from a site-local address. 

I still think it's naive to expect that a single "site" can be a
useful trust boundary in any significantly-sized network.

> lets the attacker through. 

no, it's pretty much the same problem.  

In one case you configure the server to not accept anything that's 
not a site-local.  It's not inherently configured this way, because
trust of SLs will not be appropriate for all servers.  The server 
should not make any assumptions about the meaning of SLs out of the 
box - that's a matter for site configuration.

In another case you configure the server to not accept anything
that's not from one of a small number of prefixes.  

In either case the server can be misconfigured, denying authorized
traffic or permitting unauthorized traffic.  And either case has 
the potential for defense in depth because multiple routers 
(in addition to the host) can filter based on source address 
regardless of whether the prefix is an SL prefix or a global prefix.

(and of course you do want to filter SLs at the site boundary -
I assume you meant that the filtering isn't only at the site
boundary)

SLs do have two slight advantages here -

1. the filtering rules in your servers don't have to change
   when the site changes prefixes
2. more routers outside your site are likely to filter packets
   using SLs as source or destination addresses

however I'd argue that the probability of both you and your ISP
failing to filter traffic with source addresses containing 
your prefix should be very small, so statistically speaking
#2 does not seem like a huge win.

#1 does seem useful in the absence of a good way for servers
to learn which global prefixes are currently trusted.     but
we need to solve the renumbering problem anyway.  I don't claim
that it can be solved by handwaving, but I do think that if we
had a credible solution to the renumbering problem then #1
wouldn't be a significant argument in favor of SLs either.

(and no I don't think that SLs make a significant dent in the 
renumbering problem)

furthermore if you have multiple prefixes on a net, some of which
are trusted and some which are not, then you have to configure
each of those apps to tell them to use the trusted prefix.  

(telling them to use an SL address for the server will work with
some apps - but not all of them - and if you use DNS names for
the servers (which gives you some flexibility) then you get back 
to needing to figure out how to make SL work with DNS.)

at any rate, the disadvantages associated with wide use of SLs
still don't seem worth these slight advantages.

> And many more nodes have to be configured
> site-boundary routers. 

you only get defense in depth if you have mulitiple layers of defense.
claiming that SLs provide defense in depth on one hand and that you 
don't have to have multiple layers of defense on another hand doesn't
seem consistent.

> standardized so that distributed applications could recognize it.

a site with a routable prefix probably wouldn't need a non-routable prefix,
and there are good reasons to not have more prefixes than needed.

> Keith, do I understand this right??

as a first approximation, it does sound right.

(I'm not deterred by the previous rejection of the idea by the WG because
the WG is now stating to understand both the harm done by SLs and the other 
reasons why PI addresses are needed )

Keith

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 31 Oct 2002 16:37:45 -0800

Keith,

I'm doing my best to follow this thread, but one item in your note
to Rich Draves has me confused:

> each of those apps to tell them to use the trusted prefix.  

Can you say more about how this could occur in deployment
scenarios? Prefixes come from router advertisements, stateful
delegations (e.g., DHCPv6), or manual config - right? Are you
saying that applications need to be configured in order to know
which prefixes are legitimate and which are rogues? This sounds
to me like either a site security issue or a requirement for an
application-level prefix authentication mechanism - either way,
it seems unrelated to the subject matter of this thread.

Fred
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Thu, 31 Oct 2002 20:03:31 -0500

> which prefixes are legitimate and which are rogues? 

it is being claimed that 'servers' will know which sources of 
traffic are trustworthy based on source address.  (yes, that's 
fairly dodgy , but a lot of sites do it for internal servers, 
so let's assume it's valid for the sake of argument)

well, if you have multiple prefixes on the net, and some of those
prefixes are trusted and some are not, then the apps (I don't like
to say 'clients' because not all apps are client/server) have to know
to use the trusted prefixes in order that the servers will 
trust them.

this remains the case regardless of whether the trusted prefix
is an SL prefix or not.  but having SL prefixes assumed to be
trustworthy by apps is one of the advantages being claimed for SL.

Keith