Subject: RE: Fwd: IPv6 Scoped Addresses and Routing Protocols

From: "Michel Py" <[email-masked]>
Date: Sat, 8 Jun 2002 18:38:22 -0700

> Bill Sommerfeld wrote:
> Denying external connectivity on a host-by-host basis is harder
> than it looks, because if any system with external connectivity
> at any layer is compromised, it can be used as a springboard to
> attack "internal" systems which the firewall allegedly protects.

This is a lot more complicated than being able to attack the system
directly, and requires to develop software that acts as a proxy to the
internal system.

> Site-local addresses add complication and do nothing that a site
> couldn't do already by setting aside part of its address space to
> be blocked at a firewall.

This is untrue.

- With an RFC 1918 host behind a firewall, compromising the firewall is
enough to grant that host outside access. Single point of failure.

- With a site-local only host behind a firewall, this become a double
hack thing: you need to reconfigure the firewall _and_ reconfigure the
host to give it a public IP.

Let's look at the following situation: The hacker can reconfigure the
firewall and is using an OS vulnerability that allows him to read data
from the hosts but not to reconfigure it.

RFC 1918 host: The hacker can freely copy the data.
Site-local only host: The hacker can _not_ copy the data (has to take
extra steps).

> The belief that site boundaries will be configured correctly
> is equivalent to the belief that site boundary firewalls will
> be configured correctly.

What is the message here? Don't configure a firewall because it can
eventually be configured incorrectly? Why don't you post password lists
and network diagrams while you're at it? 

Michel.

--------------------------------------------------------------------
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: Bill Sommerfeld <[email-masked]>
Date: Sun, 09 Jun 2002 01:32:09 -0400

> host to give it a public IP.

Why do you believe this makes a difference?  Wouldn't site-local
traffic be just as likely to leak into an ISP as RFC1918 traffic?
Better isp's will filter it out in their border routers; others won't
bother.

				- Bill

---

From: Pekka Savola <[email-masked]>
Date: Sun, 9 Jun 2002 09:04:52 +0300 (EEST)

> Better isp's will filter it out in their border routers; others won't

Well, addr-arch states that routers MUST drop traffic with site-local 
source address at the edge of a site.

But as site is rather vaguely defined, I think many vendors just skip this 
little detail..

-- 
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: Ralph Droms <[email-masked]>
Date: Sun, 09 Jun 2002 07:12:31 -0400

Regarding "Routers must not forward any packets with site-local source or 
destination addresses outside of the site." [RFC 2373] (note lower case for 
"must not"): the problem is not so much a vendor problem as a deployment 
problem.  A router can't know when it's forwarding a packet outside of a 
site unless it's been configured with information about site borders.  So 
network architects and admins have to define what makes up sites and 
configure the routers at the borders to know about those site 
borders.  And, I don't think there's a good way to define default behavior 
or auto-discovery for site-local addressing...

I don't see much difference between RFC 1918 addresses and site-local 
addresses in the areas of network design and deployment...

- Ralph

---

From: Pekka Savola <[email-masked]>
Date: Sun, 9 Jun 2002 14:54:33 +0300 (EEST)

> or auto-discovery for site-local addressing...

Precisely.
 
> addresses in the areas of network design and deployment...

Me neither.  More probable outcome is that someone starts to request that
people implement NATv6, because 1) they're already used to it (and like
its "security") in v4 world, and 2) they think it's easier for them to do
NAT than to renumber.

Site-locals were born in the era that not all sites had internet
connectivity.  Now that assumption is not all that valid anymore.  It's
just easier for people to use a global address block (even if we define
that address block to be 3ffe:eff3::/32 or whatever) even with these
"internal needs" (note: I believe there should be _something_ that does
not require you to fill any kind of paperwork).

---

From: Brian Haberman <[email-masked]>
Date: Sun, 09 Jun 2002 10:35:22 -0400

Ralph,

Ralph Droms wrote:
> And, I don't think there's a good way to define default behavior

Well, we could very easily apply RFC 2776 to the problem.  It is
already designed to advertise multicast zones.  I may not help
with auto-configuring the borders, but it will help debug them.

Brian

---

From: Ignatios Souvatzis <[email-masked]>
Date: Mon, 10 Jun 2002 10:55:01 +0200

> from the hosts but not to reconfigure it.

virtually all 1918 "firewalls" I've experienced are at least capable, most
also configured to do NAT. Having NAT at the border of your firewall allows
Joe E. Hacker to get access to the internal machines by using pre-existing
border router capabilities.

I see no difference to the "public addresses and configured firewall"
scenario here - only that it slightly more difficult to set up and maintain,
thus slightly more easy to misconfigure. Oh, and it breaks lots of existing
and future protocols for machines that need access to the outside - or
requires to put specialized active code for each of them at the border.

Now, if you're talking about a firewall with internal 1918 addressing 
that does NOT do IPNAT, I admit you're right. However, in that case, it 
is easier to leave the cables disconnected, isn't it?

Ok, there might be a third class of machines besides "inside,
noaccess", and "outside" - "inside, global address, access to outside,
but need access to inside".  In this case, Joe E. Hacker will attack
one of the third class machines to get access to the "secure" inside
machines. Single point of failure again, possibly multiple parallel
instances of it.

Regards,
	-is

---

From: Robert Elz <[email-masked]>
Date: Mon, 10 Jun 2002 16:10:27 +0700

Date:        Sun, 9 Jun 2002 14:54:33 +0300 (EEST)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | Me neither.  More probable outcome is that someone starts to request that
  | people implement NATv6, because 1) they're already used to it (and like
  | its "security") in v4 world,

This is bogus - but then again we see here over and over where people are
only happy when nothing changes (and we're seeing it again here).

  | and 2) they think it's easier for them to do NAT than to renumber.

And they're right.   And that's what site locals are good at - their
main function in my mind.   If site local addresses were used for all
internal communications (whatever "internal" is defined to be), and
globals only for external communications, then renumbering IPv6 becomes
close to isomorphic to renumbering IPv4 using NAT - all the nodes need
to be renumbered, but with IPv6 that's close to automatic, so not much
of an issue.   All internal communications are unaffected, as they're
using site local (just like 1918 addresses in v4 with NAT), and all external
communications are disrupted, because the global address has changed
(just like IPv4 with NAT).

  | Site-locals were born in the era that not all sites had internet
  | connectivity.

That was one of their planned uses, in my mind, always a minor one.

  | It's
  | just easier for people to use a global address block (even if we define
  | that address block to be 3ffe:eff3::/32 or whatever) even with these
  | "internal needs" (note: I believe there should be _something_ that does
  | not require you to fill any kind of paperwork).

Huh?   What difference do you think that would make?   We just define
fec0::/10 as a "global" address block, and we're done according to this
theory.   That's absurd - the bit pattern used can't possibly be relevant.
What matters is whether or not there is some block of addresses that can
be arbitrarily simply "taken" and assigned for local use, and which won't
work for communication that isn't local (whatever definition of local has
been chosen to apply).

If there is, then all the same issues remain - how to discover the address,
how to decide when to use it, how to prevent it leaking where it shouldn't,
etc - none of which is in the slightest impacted by the bit pattern chosen.

And on this, Steve Bellovin went on to suggest ...

  | Yah.  Let's pick a prefix, and tell folks to pick a random number
  | (more  precisely, use an RFC 1750-compatible RNG) to fill out the rest
  | of the  high-order bits to a /48 or a /64.

So, let the prefix be fec0::/10 and then when you have just suggested is
Paul Francis' NUSLA's - see the thread from Feb 2001 with the illumination
Subject of "Wade through the archives" (and perhaps also the threads on
"Question on scopes involving IPv6 addresses" and "what is a site??" from
March '01).

This stuff seemed to just drift into silence, without any real discussion,
which it really deserved having.

kre

---

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Jun 2002 12:42:10 +0300 (EEST)

> etc - none of which is in the slightest impacted by the bit pattern chosen.

Bit pattern is not relevant of course (except how it is handled by
"legacy" implementations, which is why I tossed 3ffe:eff3::/32 in the
air).

What I'd like is that there wouldn't need to be special handling for
site-local addresses.  If you really wanted to have Site Border Routers,
you would just be shooting in your own foot (like with 10.0.0.0/8 etc.
today).

Implementation (and specification) simplicity..

---

From: Francis Dupont <[email-masked]>
Date: Mon, 10 Jun 2002 12:10:43 +0200

In your previous mail you wrote:

=> yes, there is a new ICMP error for this case.

=> I disagree: we have a similar but more complex issue for multicast
forwarding and the zone boundary check is very easy to implement
(this point was verified when the multicast addressing stuff was advanced).
If this is the only hard point in a multi-sited implementation I (and many
of us) will be *very* happy (:-)!

Thanks

[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Mon, 10 Jun 2002 04:06:39 -0700

>> But as site is rather vaguely defined, I think many vendors just skip
>> this little detail..
> I disagree: we have a similar but more complex issue for multicast

cool.  how do you detect that you are at the edge of a site?

randy

---

From: Robert Elz <[email-masked]>
Date: Mon, 10 Jun 2002 18:35:31 +0700

Date:        Mon, 10 Jun 2002 12:42:10 +0300 (EEST)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | Bit pattern is not relevant of course (except how it is handled by
  | "legacy" implementations, which is why I tossed 3ffe:eff3::/32 in the
  | air).

But how is the handling by legacy implementations any different than
what you would require anyway?

  | What I'd like is that there wouldn't need to be special handling for
  | site-local addresses.

How can there not be?

  | If you really wanted to have Site Border Routers,
  | you would just be shooting in your own foot (like with 10.0.0.0/8 etc.
  | today).

If there are to be uses of non-unique addressing (site locals, 1918's
or anything else) then there has to be borders.   And if there are
borders, then there has to be border routers.   Something has to keep
one use of the addresses separate from others.

Perhaps what you want to discourage is multi-site nodes ?
(Usually would be a router, but doesn't have to be).

As I recall, when site locals were first discussed, there were 3
possibilities for how the border between one site and other would be
handled.

One was to have only single site nodes, but allow links to be in multiple
sites.   That doesn't work at all with the current packet/addressing
formats, as there's no way to tell on the wire which site a packet would
belong to, so that one's just a write off.

Two was to have only single site nodes, only single site links, and
non-site links (DMZs) between sites.

Three is what we have now - single site links, and multi-site nodes.

This was all debated and settled so long ago, I've even forgotten which
of the two (feasible) proposals I supported, though I suspect it was
probably the one called "two" above.  Which is what you're also probably
really suggesting here.

However, upon reflection, there is comparatively little to be gained
by that choice over the third one (some things get simpler to explain
while the lack of regularity makes others harder to fathom, and some
stuff becomes simply impossible to manage - like if two sites are
connected via a router that has LANS for each site connected to it,
there's no convenient link to make be the DMZ).

Scoping has to exist for link locals to work anyway, and so routers need
to deal with that (and link locals, and their properties, are too deeply
ingrained now to possibly contemplate their removal).  By their very
nature, link locals require multi-scope nodes to exist, or we could not
have routers at all.

The only real difference between 2 & 3 above for implementations, given
that apps can run on "routers" and that apps need to be able to use link
local addressing if necessary (for the unconnected dentist's office nets)
so all the scoping architecture needs to exist - all that would be gained
is that in (2) a router would have a different decision to make before
forwarding site local addresses - rather than "is this link in the same
site?" it would need to ask "is this link in a DMZ?"

Is that (trivial) simplification really worth the loss of flexibility?

The difficult part of handing any situation where there are multiple
addresses is how to decide which address should get used, initially.
This is just the same when a node as two global addresses (whether they're
in different prefixes, or the same one) or when it has global & private
addresses.

In IPv4 we just ignore the question mostly - a node with two global
addresses we just toss a coin.   And nodes with private addresses mostly
just don't get given global addresses (and/or the two are treated for
essentially all purposes as if they belonged to two different nodes).

For IPv6 we're being asked to actually attempt to provide some answers
to this question - as essentially all nodes (certainly the vast majority)
with private addresses will also have global ones.

kre

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 10 Jun 2002 13:45:16 -0400

It's also worth pointing out that NAT is not the only way a
site-local-only system could get external connectivity.

A transport-layer gateway/relay like a socks implementation for v6 or
the KAME "faithd" would be another way..

						- Bill

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Jun 2002 09:14:06 +0300 (EEST)

> what you would require anyway?

I don't know what assumptions different implementations might have glued 
in to fec0::/8, but selecting a different one would mean it would be 
treated as global no matter what.

(I don't think there would really be problems even if fec0::/8 was used.)
 
>   | What I'd like is that there wouldn't need to be special handling for

By limiting the applicability of the addresses.
 
> one use of the addresses separate from others.

Sure.
 
> (Usually would be a router, but doesn't have to be).

Yes.  RFC1918 model has not required changes to routing protocols, 
partially because we acknowledge "you can always shoot in your foot".  Now 
with IPv6 site-locals, it seems we want to add features to e.g. routing 
protocols to (try to) prevent that, which leads more complexity.
 
> non-site links (DMZs) between sites.

This seems the best to me IMO.

> there's no convenient link to make be the DMZ).

In more complex topologies, one could always just enforce globals and be 
done with it.
 
> nature, link locals require multi-scope nodes to exist, or we could not

Sure, but the link scope is rather easily defined, and the addresses of 
link scope are meaningless outside of the link (ie. no need to carry them 
in routing protocols).
 
> local addressing if necessary (for the unconnected dentist's office nets)

I'm not sure if link-locals is the right way to go in this particular 
case.

> site?" it would need to ask "is this link in a DMZ?"

A question is, is the scoping architecture required for only link-local 
addresses more lightweigh than one for both LL's and e.g. site-locals.

> with private addresses will also have global ones.

The thing is, how usable is it to try to solve this problem, at least in 
its most generic form?  I'm not all that certain it's all that beneficial.

---

From: Ignatios Souvatzis <[email-masked]>
Date: Tue, 11 Jun 2002 11:09:57 +0200

> the KAME "faithd" would be another way..

faithd does NAT while changing the address family at the same time, doesn't 
it?

	-is

---

From: Francis Dupont <[email-masked]>
Date: Tue, 11 Jun 2002 11:44:39 +0200

=> no detection but static configuration... Technically this is easy
to implement, of course the question whether this is easy to manage
is very different (BTW I am on the "site-local == private for never
connected sites" side from the beginning).

Regards

PS: IMHO to reopen the site-local addressing question for the third time
(at least) is a good idea *only* if we have a reasonable chance to reach
a consensus.
--------------------------------------------------------------------
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: Bill Sommerfeld <[email-masked]>
Date: Tue, 11 Jun 2002 14:02:42 -0400

> faithd does NAT while changing the address family at the same time, doesn't

No doubt one of the KAME folks will correct me but my impression was
that it was more of a TCP-layer proxy rather than a layer-3 NAT.  

Regardless of how it works, it's one of many ways for a
site-local-addresses-only node to get external connectivity.

						- Bill

---

From: [email-masked]
Date: Wed, 12 Jun 2002 11:01:35 +0900

>that it was more of a TCP-layer proxy rather than a layer-3 NAT.  

	exactly, it is a TCP-layer proxy with specific address handling
	(lowermost 32bit used to relay IPv6 TCP session to IPv4 TCp session).

>site-local-addresses-only node to get external connectivity.

	yes.

itojun

---

From: Ignatios Souvatzis <[email-masked]>
Date: Tue, 11 Jun 2002 11:09:57 +0200

-is