Subject: RE: Limiting the Use of Site-Local

From: "Michel Py" <[email-masked]>
Date: Mon, 28 Oct 2002 16:44:59 -0800

>> Michel Py wrote:
>> Let's talk about an airplane's IPv6 internal systems. There will
>> be a requirement that the rudder's embedded controller reacts
>> to site-local only, just in case a bozo mixes up something. OTOH,
>> the NAV computer does need to talk to the outside word to extract
>> weather or other in-flight dynamic data and to report to ground.

> Keith Moore wrote:
> that's what packet filtering is for.  

Keith, you don't get my point. The requirement for site-local is because
someone or something can mess up packet filtering. It is in *addition*
of the packet filtering. In an airplane, one level of security does not
take off.

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: Margaret Wasserman <[email-masked]>
Date: Mon, 28 Oct 2002 20:06:12 -0500

I have heard several arguments for why people might like
to use some sort of limited-scope addressing in special
circumstances.  I've also heard a couple of general benefits
(long-lived connections and dubious security benefits).

But, I haven't really heard any arguments that have swayed
me from my original position.

Private addressing causes significant complexities, and we
don't know how to solve all of the problems that it causes
for applications, DNS, routing protocols and network
management protocols.

Therefore, I don't think that we should define it as an
inherent part of IPv6.

There may be some significant advantages to private addressing,
so I _do_ support the idea of an IRTF WG being formed to sort
out the issues surrounding private addressing and make
recommendations regarding what the IETF should/shouldn't
standardize in this area.  I also think that an IAB document
in this area would be appropriate.  But, I don't want to see us
standardize a badly-thought-out private addressing scheme
at the core of IPv6.

In my opinion, there are three possible choices here:

	(1) Limit the scope of the IPv6 WG's problem, by
		forbidding the use of site-local addresses
		on globally-connected networks in the
		scoped addressing architecture.  This would
		not preclude work in this area by other
		groups within the IETF/IRTF, and we could
		remove the restriction when the implications
		are fully understood.

	(2) Develop a complete solution for scoped unicast
		addressing within the IPv6 WG.  This would
		include solving the problems they cause for
		all protocols/layers.

	(3) Define an IP-level solution for scoped addressing
		(similar to what is currently in the scoped
		addressing architecture), and consider all
		of the implications of that architecture on
		other protocols/layers to be someone else's
		problem.

The first choice is both responsible and doable.

I have deep concerns about the second choice, along two lines:
(1) I think it is important that we stabilize and complete IPv6
quickly, as folks are widely implementing and deploying it, and
(2) I don't know that we have the expertise (in the IPv6 WG or
anywhere in the IETF, without further research) to solve these
problems.

And, in my opinion, the third choice (which is what we seem to
be doing so far) is blatantly irresponsible.

Are there people who want to argue for choices #2 and/or #3?
Or are there other choices that I've left out?

Margaret

---

From: Keith Moore <[email-masked]>
Date: Mon, 28 Oct 2002 20:01:04 -0500

> of the packet filtering. In an airplane, one level of security does not

that's bogus.  filtering SLs has exactly the same vulnerabilities as 
filtering globals or any other pattern of bits.    some routers will
have to filter SLs, others will have to pass them, so there is always
the potential that this bit of configuration can be corrupted.
you can put as many levels to filter globals based on prefix as you
put to filter SLs, and at the same cost.

actually this particular use of SL wouldn't bother me at all as
long as you don't impose SLs on passengers or an external network -
because almost none of this is going to use off-the-shelf hardware
or software but it's also true that SLs don't give you additional 
security. nor do they make your job any easier.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 28 Oct 2002 20:12:26 -0500

seems reasonable to me, as long as "globally-connected" includes 
any IP network that is connected (directly or indirectly) via 
IP to a network that is connected to the global IPv6 Internet.

I also doubt we can ever "remove the restriction" in the
sense that we expect apps that were built to treat all addresses
as global to run when they're exposed to a mixture of global
and scoped addresses.

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 28 Oct 2002 20:32:00 -0500

>IP to a network that is connected to the global IPv6 Internet.

Sounds like an excellent definition to me.

>as global to run when they're exposed to a mixture of global

Correct.  If we later introduce the concept of private
addressing to IPv6, we would need to do it in a way that
wouldn't break deployed apps.  This might include things
like the separate DNS record that Erik Nordmark proposed,
and/or other IP-level mechanisms to prevent handing site-local
addresses to applications that don't know how to deal with
them.

Margaret

---

From: Pekka Savola <[email-masked]>
Date: Tue, 29 Oct 2002 08:51:12 +0200 (EET)

> In my opinion, there are three possible choices here:

There are two others:

        (0) Limit the scope of the IPv6 WG's problem, by
                forbidding the use of site-local addresses
                on globally-connected networks in the
                scoped addressing architecture and clarifying 
                it in the revised addrarch document.  This would
                not preclude work in this area by other
                groups within the IETF/IRTF, and we could
                remove the restriction when the implications
                are fully understood.

> 		other protocols/layers to be someone else's

        (4) As 0) and 1) but kill all references to SL in
                addrarch-v3

> The first choice is both responsible and doable.

But it gives a totally wrong picture to a reader reading a revised edition
of addrarch.  So it's unclear.  0) is clear, responsible and doable.

4) is too rash action for now, I believe.
 
> Or are there other choices that I've left out?

Yes.

I strongly urge for 0).  Some wording changes are required in 2.5.6 
second-last paragraph, and we may need to kill the last paragraph.

I'm not even sure if we could get addrarch to draft standard, have folks 
implemented these two:

--8<--
   Routers must not forward any packets with site-local source or
   destination addresses outside of the site.
--8<--

None of the implementations I use certainly haven't, and this has been 
around for a time now, even since RFC1884..

-- 
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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 29 Oct 2002 17:34:10 +0900

(Note: this message is not directly related to the main point of this
thread.)

>>>>> On Tue, 29 Oct 2002 08:51:12 +0200 (EET), 
>>>>> Pekka Savola <[email-masked]> said:

> around for a time now, even since RFC1884..

KAME can do this.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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: Tue, 29 Oct 2002 13:28:06 +0200 (EET)

> > around for a time now, even since RFC1884..

Note that KAME only supports this through manual configuration (and a 
fix) -- clarified in off-the-list discussion.

To be compliant with the paragraph:

Note: it does not say 'packets from the site' (implying configuration of
the site) but 'with site-local source'.  That strongly implies explicit
configuration will not satisfy.

I expect an implementation must automatically, without any configuration, 
drop e.g. packets received under the following steps:

1) a router is configured to advertise a site-local prefix
2) a node configures a site-local address and starts sending out traffic
3) router drops it or forwards it (using some logic).

Or even:

1) node just blindly configures fec0::1 and starts sending traffic using 
it, testing how far it will go. 

A valid scenario here could be that site-locals would be used inside one
link only -- no config at all in the router -- but the route must disallow
propagation of site-locals through default route if something fails.

You may ask: how is this possible?  we don't have any site-border 
discovery mechanisms?

I say: exactly, that's why the paragraph is so ridiculous!

The only easy and compliant implementation I could think of would be 
discarding all site-locals unless some links are explicitly configured to 
be part of a site.

(Note: one could use some logic, e.g. require all interfaces where
site-local traffic is valid must have site-local addresses to
auto-discover the border between globals and site-locals.. but that would 
have quite a few assumptions I believe)

---

From: Brian Haberman <[email-masked]>
Date: Tue, 29 Oct 2002 07:51:57 -0500

Pekka,

>>>around for a time now, even since RFC1884..

I have implemented it as well.

> configuration will not satisfy.

I don't read it that way at all.  I interpret that to mean, if the
router is configured as a site-border router it must not forward those
packets out of the site.

The behavior is as defined in Section 5 of the scoped addr arch which
is all interfaces are in the same site, unless explicitly configured
by an administrator.

> propagation of site-locals through default route if something fails.

That does not follow from the discussion in scoped addr arch.  Of
course, this should be clarified in addr arch when we decide on the
SL content of that document.

> discarding all site-locals unless some links are explicitly configured to 

 From the discussion I have read, it seems that it would be more that
we are assuming that all interfaces are in the same site unless
explicitly configured.

Brian

---

From: Keith Moore <[email-masked]>
Date: Tue, 29 Oct 2002 08:13:34 -0500

I also think it would be a good idea to amend the addrarch document to
discourage use of SLs except on isolated networks.

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 29 Oct 2002 08:27:36 -0500

>You may ask: how is this possible?  we don't have any site-border

We don't need an autoconfiguration mechanism for every feature of
the IPv6 specifications.  If routers can be configured to act as
site-border routers (and not forward site-local addresses outside
of the site), this is all that the spec requires.  It doesn't
require that the configuration be automatic, or even simple to
configure.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 29 Oct 2002 08:36:26 -0500

I don't think that the addr arch is the right place to do this.

If we start defining how each type of address in the addr arch
will be used, we will basically end-up moving most of the scoped
addressing architecture document into the addressing architecture,
and it will never be finished.

Also, we don't have any declared consensus about how/if we will
limit site-locals at all...

The current addr arch is light-years ahead of the RFC version, and
I think that we need to get it published.

I'd like to keep talking about the site-local issues, and I hope
that we can get some changes made in the scoped addressing
architecture. Part of the discussion of those changes should (and
will) be a discussion of what impact those changes would have on
other IPv6 documents, including (possibly) the addr arch, address
autoconf, etc.  If/when we have agreement on what changes to make,
that may include changes to other documents.

In the meantime, though, I don't think we should hold up the
addressing architecture.  It has been held up, literally, for
years because there is always some ongoing discussion that
_might_ require changes to it (most of them don't), and I think
that has to stop.

Margaret

---

From: Keith Moore <[email-masked]>
Date: Tue, 29 Oct 2002 10:29:37 -0500

> I think that we need to get it published.

I understand the need to publish it, I just don't want it to mislead
people into thinking that there are actually valid use cases for
all of the kinds of addresses it defines.
--------------------------------------------------------------------
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: Tue, 29 Oct 2002 18:28:55 +0200 (EET)

> router is configured as a site-border router it must not forward those

That kind of interpretation is easy (== activation logic in the 
implementation is simple) , but really, totally useless I believe.

The promise of using site-locals is that they will not propagate globally.

Routers must make sure they don't do that, even without being configured 
as site-border routers.

If this wasn't true, nobody should be able to use site-locals even without 
relatively clean conscience, as nobody could be sure there _is_ a router 
that's blocking illegally-sourced site-locals from coming to my site or 
vice versa.

The paragraph requires clarification for sure.

> is all interfaces are in the same site, unless explicitly configured

Scoped arch draft is irrelevant from the perspective of addrarch 
(independence) IMO.
 
> SL content of that document.

Better: _addrarch_ shouldn't say anything at all like that because we 
don't know how to do it (or can't write it down).

> we are assuming that all interfaces are in the same site unless

The risk of site-local leakage is _way_ too big that way.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 29 Oct 2002 18:34:24 +0200 (EET)

Tailed Cc: list a bit.

> require that the configuration be automatic, or even simple to

People have read it differently, that's for sure.

Some read it (many):

 "if I configure a site here, I must also block site-locals from spreading 
out or false site-locals coming in"

Some others read it:

 "if I use site-locals here, my upstream router will block the site-local 
addresses from spreading out and prevent anyone from spoofing site-locals 
to my site"

The latter is how I read it must be implemented -- and reading Microsoft's
implementation and the reason they're using SL *strongly* suggests they 
also have read it that way.  There are very probably many others.

The paragraph is very unclear at best, extremely dangerous at worst.

---

From: Brian Haberman <[email-masked]>
Date: Tue, 29 Oct 2002 13:22:17 -0500

> implementation is simple) , but really, totally useless I believe.

That depends on the model you believe.  If we take Margaret's proposal
that, by default, a node is in one site (you treat SLs as globals) then
explicit config is needed to have a border router.  In this scenario,
the site-local zone ids are all the same.

The other case is where each interface is in different site (that makes
SLs equivalent to link-locals) and the site-local zone ids are all
unique.

> Routers must make sure they don't do that, even without being configured 

That would require routers to always act as a site border router.

> The paragraph requires clarification for sure.

How about removing it?

> Scoped arch draft is irrelevant from the perspective of addrarch 

What I meant is that any discussion similar to that paragraph should
be in the scoped addr arch.

> don't know how to do it (or can't write it down).

Agreed.

> The risk of site-local leakage is _way_ too big that way.

My statement is based on the proposal that site-locals be restricted
to disconnected networks.

Brian

---

From: [email-masked]
Date: Wed, 30 Oct 2002 10:02:53 +1100

> SLs equivalent to link-locals) and the site-local zone ids are all

	There is also the case where the number of sites < number of interfaces
	and number of sites != 1.

	e.g.
		interfaces 1 and 4 are in site 1
		interfaces 2 and 5 are in site 2
		interface 3 is in site 3
	
	You have to allow SL traffic between 1 and 4 also between
	2 and 5 but not between any other combination of interfaces.

	Mark

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
--------------------------------------------------------------------
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: Brian Haberman <[email-masked]>
Date: Tue, 29 Oct 2002 20:39:23 -0500

Mark,

> 	2 and 5 but not between any other combination of interfaces.

I agree that such a configuration should be allowed.  My example
was to point out the two possible default behaviors that could
occur with no admin configuration.

Brian