Subject: Re: My conclusion re site-local clean-up

From: Keith Moore <[email-masked]>
Date: Fri, 15 Nov 2002 11:33:22 -0500

> I think restricting site-local addresses to sites without ANY external
> connection is wrong.

I think expecting applications to cope with a mixture of site-local
and global addresses is not only wrong, but unworkable, unless all
nodes are also guaranteed to have globals and the site-local 
addresses can safely be ignored.  

> It results in excluding many large network with
> permanent external connection, that currently have deployed
> "site-local-like" addresses and aim at continuing doing so, because of
> the "advantages" it provides.

no, it just results in those networks having to use slightly different
security measures for IPv6 than they used for IPv4.

Keith
--------------------------------------------------------------------
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: "Tony Hain" <[email-masked]>
Date: Fri, 15 Nov 2002 10:22:22 -0800

Keith Moore wrote:
> I think expecting applications to cope with a mixture of 
> site-local and global addresses is not only wrong, but 
> unworkable, unless all nodes are also guaranteed to have 
> globals and the site-local 

It is clear that some application developers will have to decide if they
want to bother with the new capabilities provided by simultaneous
support for multiple scopes. That does not mean it is wrong for anyone
to use them. 

As an example (yes hypothetical, but could easily describe the
requirements or goals of the vast majority of the fortune 1000); Company
X has 125,000 employees globally, with regular reorganizations causing
constant office shuffles between regions. Each employee has a laptop,
which will have global access, and a network connected printer which
will not have global access (we won't bother with the rest of the
network connected devices here). There are 100 touch-points to the
Internet, with the 3 primary ones running multiple OC-48 access loops. 

The 'explicit filter lists at the border' model requires keeping 100
tables in sync in the face of constant change, and parsing a 125,000
entry list at OC-48 rates for every packet at 3 of the borders (while
this creates demand for very expensive routers, it is not a scalable
approach). 

The 'well-known SL filter at the border' model requires the organization
to tell their printer manufacturer to preconfigure all the devices they
buy to only accept and auto-configure SL prefixes from the RA (likely a
widely demanded item), and put in a 2 entry list that remains static at
every border. In addition, it is reasonable and expected that the peer
across the border will maintain a matching version of the filter list.

The compromise model of 'using 2 public prefixes per segment' allows for
a 2 entry static list at every border, which may or may not be
considered reasonable to match by the border peer. It does not provide
the printer manufacturer a preconfiguration option that matches other
customers, and even if it was done, as soon as Company X changes
providers, they have to manually touch every printer for the new
configuration. It also consumes 2x the public prefix space, to support
nodes that will never be accessible from the public network.

To make the name service simple in these 3 cases, we will run
back-to-back normal dns servers. The primary set facing internally to
accommodate dynamic updates, with a slave set facing externally. A
periodic process will replicate the information from the source-of-truth
internal facing servers to the external ones, but the security team
requires it to scrub out all records for internal-only nodes. 

For model 1, the scrubbing process would have to contact the border
filter list (after deciding which was the current source of truth), the
parse through it for all 250,000 entries to decide which are replicated.

For model 2, the scrubbing process simply has to look for records with
the SL prefix and replicate all others. 

For model 3, the scrubbing process has to look for the bit flag that
identifies the private-use public prefix, and replicate all others.

Once any one of these processes completes, all nodes are accessable by
name in the internal scope, and all nodes that should be accessed from
the outside are accessable by name in the global scope. Applications
that are expected to *work* across the border will have global scope
addresses to use. Multi-party apps that use name-string referals will
work across the border, but those that use SL literals will fail by
design (note: use of SL == expected to fail across border). Use of
filtered global scope addresses makes it impossible for the application
to know why it failed to connect. 

This scenario only addresses 2 devices per employee, so the numbers
could easily be 5x this large. Approaches that work in the small, rarely
scale well to large distributed environments with constant churn.  

Another side-effect of choosing SL over global scope prefixes is the
simplification of diagnostic efforts for communications within the site.
It makes little sense to use RFC 3041 IID's within the boundaries of a
site, and avoiding them makes it easier for the support team to
correlate network traces. It is reasonable to expect OS vendors to
prevent binding a 3041 IID to the SL prefix without explicit
configuration. In turn, it would require explicit configuration of every
device to recognize the 'private' nodes (either private-use public
prefix, or the entire border filter list) to avoid use of a 3041 IID
when talking to those nodes. 

> no, it just results in those networks having to use slightly 
> different security measures for IPv6 than they used for IPv4.

The tone of that statement makes it a non-starter as far as the security
teams are concerned. The point has to be that the security measures
start from exactly the same point they are in IPv4, but with
simultaneous use of SL & global prefixes we have the opportunity to
expand the functionality of the network by allowing some nodes to avoid
the need for nat. 

The absolute requirement for filtering will trump any complaints about
broken applications, which means there will be site-scope address space.
If we don't provide an opportunity to move beyond the current model
where all nodes are required to live in the single scope of filtered
space, by providing simultaneous support for site/global space, we will
be stuck with nat forever. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Nov 2002 13:54:47 -0500

> support for multiple scopes. 

that's simple for applications developers to decide, since
multiple scopes provide no new capabilities to applications.

unfortunately it's not applications developers who are making
the decision about whether to impose scoped addresses on networks.

your hypothetical example is misleading.  any filters that can be
implemented with SLs can as easily be implemented with globals -
and using globals provides additional flexibility (at the cost
of a longer filter list) for when it is needed, that simply is not
available with SL.  furthermore if the company isn't just being
re-organized internally but (as is common these days) is also subject
to mergers and/or intensive collaboration  with other organizations, 
SL has to be abandoned anyway.

> considered reasonable to match by the border peer. 

there are other ways to do this than having separate prefixes.
you can use any bit after the initial /48.  

> It does not provide
> configuration. 

if printer vendors are being told that they can provide security
or their devices by using site-local addresses, we need to publically
shoot that idea immediately.  it is completely unreasonable to 
assume that a site boundary is trusted or that hostile traffic cannot
leak in from offsite - even if site local addresses are used.

> It also consumes 2x the public prefix space, to support

no it does not.   

> Use of filtered global scope addresses makes it impossible for the 
> application to know why it failed to connect.

that's blatently false, as has been explained multiple times.

first, there is an ICMP messages that exists for this very purpose.  

second, there's no way that SLs can provide a general mechanism for 
applications to know why a destination was unreachable anyway, because
SLs are nowhere nearly flexible enough for general filtering purposes.
so having applications have to deal with SL just increases the burden
on applications for no gain in functionality.

third, applications will be expected to communicate between nodes
that use SLs - that's exactly what proxies do, for instance - and 
use of SLs will unnecessarily increase the complexity of almost any
application that involves more than two parties.

> simplification of diagnostic efforts for communications within the site.

no, it makes diagnostics more difficult (for both the network and for
applications) because SL addresses are ambiguous.

> > no, it just results in those networks having to use slightly=20
> start from exactly the same point they are in IPv4, 

folks who believe that should stay with IPv4 and NAT.  if you deploy
a v6 network only to impair that network in such a way that v6 provides
no benefit, what's the point?

> but with

SL can avoid the need for NAT but still impose the same constraints on
applications.  what's the point, particulary when you can avoid the need
for NAT without using SL?

> broken applications, which means there will be site-scope address space.

NO IT DOES NOT.  Filtering is a given, but it does not imply scoped address
space.  This has been explained over and over.

SLs may have some marginal utility, but filtering is not part of that.

> be stuck with nat forever.

You have said nothing which supports such a statement.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 15 Nov 2002 11:43:31 -0800

Keith Moore wrote:
> ...
> > The compromise model of 'using 2 public prefixes per 
> segment' allows 
> > for a 2 entry static list at every border, which may or may not be 
> there are other ways to do this than having separate 
> prefixes. you can use any bit after the initial /48.  

The point is that the organization on the other side of the border may
not consider a matching filter to be reasonable if it is more specific
than the /48, or a well-known value.

> if printer vendors are being told that they can provide 
> security or their devices by using site-local addresses, we 
> need to publically shoot that idea immediately.  it is 
> completely unreasonable to 
> assume that a site boundary is trusted or that hostile 
> traffic cannot leak in from offsite - even if site local 
> addresses are used.

I did not say security, you did. I said that printers preconfigured for
SL-only would comply with simplified filter policies.

> > nodes that will never be accessible from the public network.

In the small you are correct. For an organization like Cisco with well
over 50,000 registered subnets, doubling the number of public prefixes
assigned to each segment will require a larger allocation from public
space.

> ...

Not within the context of the routing domain, and filtering is
explicitly intended to preclude crossing routing domains. 

> > The tone of that statement makes it a non-starter as far as the 
> > security teams are concerned. The point has to be that the security 
> > measures start from exactly the same point they are in IPv4,
> 
> folks who believe that should stay with IPv4 and NAT.  if you 
> deploy a v6 network only to impair that network in such a way 
> that v6 provides no benefit, what's the point?

I listed several, but they seem to be falling on deaf ears.
 
> > expand the functionality of the network by allowing some nodes to 
> > avoid the need for nat.
> 
> SL can avoid the need for NAT but still impose the same 
> constraints on applications.  what's the point, particulary 
> when you can avoid the need for NAT without using SL?

As I said, force the network manager to choose between complex filtering
or nat, and nat will win. Provide the option for multiple simultaneous
use of scopes, and there is a path forward to allow apps to work where
they should, and be broken where they shouldn't work.

> NO IT DOES NOT.  Filtering is a given, but it does not imply 
> scoped address space.  This has been explained over and over.

Filtering == scoped address space, no matter where the bits come from.
The point is that some addresses are only valid within the scope of the
filter.

> SLs may have some marginal utility, but filtering is not part of that.

From the perspective of toy networks, there is little utility in
simplified filtering. From the perspective of global enterprise
networks, complexity is expensive, and prone to errors.

> > space, by providing simultaneous support for site/global space, we 
> > will be stuck with nat forever.
> 

Or you have refused to accept all the statements that support it...

I have made the case that several have supported in private mail (but
they refuse to do so on the public list to avoid being "subjected to the
wrath of a rabid attack dog"), so I will not add anything further to
this thread.

Tony

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Nov 2002 16:44:44 -0500

I had written another lengthy reply to Tony's last message, but I'm not 
going to send it right now - maybe I'll wait, or maybe I'll send it in 
private mail.  I'm sending a briefer reply because I want to focus 
attention on a question which seems fairly important to Tony's position:

One of the assertions that Tony seems to be making is that SLs can be
used to communicate to applications when policy forbids them from talking
to one another.    (Tony, if I'm mistating this, please restate it)

So for instance if a process resides on a host which only has an SL 
address, and it wants to communicate with a peer for which it only has 
a global address, then the process can infer that it is forbidden as 
a matter of policy from communicating with that peer.

Or perhaps if process A lives on a host with both global and SL addresses,
and it has only a SL address for the host on which process B resides,
then A can infer that B is forbidden from communicating off-site.

(Offhand I haven't thought of other inferences that could be made - 
certainly if both hosts have both SL and global addresses then 
you can't assume that the hosts are allowed to connect.)

Is there a widespread idea that it's reasonable for apps to make
these kind of inferences?  

Personally, I don't think either of those inferences are reasonable - 
there are too many situations where a host can be temporarily without
a global address (but not forbidden to communicate externally as a 
matter of policy), and too many situations where a process might know
some but not all of the addresses at which a potential peer might be
reached (so the lack of knowledge of a global for that peer doesn't 
imply anything about policy).

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Sun, 17 Nov 2002 15:51:24 -0500

Keith Moore wrote:
> ...
> One of the assertions that Tony seems to be making is that 
> SLs can be used to communicate to applications when policy 
> forbids them from talking

I was suggesting that SL is an indication that a filtering policy has
been applied to this network. This does not by itself indicate where the
boundaries are.

> a matter of policy from communicating with that peer.

Based on its SL address, it can infer that there is an explicit filter
somewhere in the network. That filter may or may not be between it and
the application peer. 

> 
> Or perhaps if process A lives on a host with both global and 
> SL addresses, and it has only a SL address for the host on 
> which process B resides, then A can infer that B is forbidden 
> from communicating off-site.

This is the case that seemed to apply to the referral type apps. If A
only knows a SL for B, and a global prefix for C that does not match its
own, it can assume that the likelihood of C being able to see B is low.
Or at the very least when it fails there is an indication that someone
probably wants it to.

> Is there a widespread idea that it's reasonable for apps to 
> make these kind of inferences?  
> 
> 
> 
> there are too many situations where a host can be temporarily 
> without a global address (but not forbidden to communicate 
> externally as a 
> matter of policy), 

Lack of an external address means that the external nodes will be unable
to communicate with that device from outside the site. Why the node is
without a global address is irrelevant to the ability to use it in a
referral. 

> and too many situations where a process 
> might know some but not all of the addresses at which a 
> potential peer might be reached (so the lack of knowledge of 
> a global for that peer doesn't 

It implies that the ablity to actually connect to it is explicitly
impaired. Other than the case of the private network connected behind a
globally attached network, I see no reason for permiting SL/global
connectivity. If we can get PI prefixes for the private network, we
should simply put a hard stop in SL working with anything except another
SL. 

Tony

---

From: Keith Moore <[email-masked]>
Date: Mon, 18 Nov 2002 10:17:36 -0500

> been applied to this network.

seems like a *huge* stretch - several of the ideas for using SL have nothing
to do with filtering.  also, SL strikes me as an extremely poor mechanism
for communicating filtering policy.  

in general an application must assume that there is a filtering policy
may be in place regardless of whether or not it sees SL addresses.
after all, filtering that can affect an application can exist anywhere
in the network, and SL could at best provide a crude indication of 
filtering on the local network.

the way you determine whether filtering is imposed is by trying to 
communicate and having that attempt fail due to an ICMP 'communication
prohibited' message.

so no, I don't think this flies at all.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 18 Nov 2002 13:30:29 -0500

Keith Moore wrote:
> seems like a *huge* stretch - several of the ideas for using 
> SL have nothing to do with filtering.  also, SL strikes me as 
> an extremely poor mechanism for communicating filtering policy.  

This is demonstrably untrue. SL is not routable between autonomous
administrations without explicit coordination to remove ambiguity. With
coordination, the regions are no longer completely autonomous, and since
there is no ambiguity, applications have no problems using them. Your
concern about applications having to work across SL boundaries is
fundamentally flawed, because routing will not support it without nat.
This is not an argument for nat, and again the only way to avoid nat is
to allow simultaneous use of multiple scopes.

> 
> in general an application must assume that there is a 
> filtering policy may be in place regardless of whether or not 
> it sees SL addresses. after all, filtering that can affect an 
> application can exist anywhere in the network, and SL could 
> at best provide a crude indication of 
> communicate and having that attempt fail due to an ICMP 
> 'communication prohibited' message.
> 

This perspective assumes all control/feedback is based on outbound
traffic. Think 'inbound traffic'.

Tony

---

From: Keith Moore <[email-masked]>
Date: Mon, 18 Nov 2002 17:06:16 -0500

> administrations without explicit coordination to remove ambiguity. 

so what?  the app cannot make ANY reasonable assumptions about the
intent of the site based merely on the fact that it gets an SL 
address.  it cannot reasonably assume that SL addresses are more stable, 
because intrasite renumbering may be more common than intersite
renumbering.  it cannot assume that SL addresses have narrower scope,
because it might not actually be connected to the global internet
even if it has a global prefix.  it cannot assume that SL addresses
are trustworthy, because the distribution of threats varies from
one site to another and internal threats are often more dangerous
than external threats.

all of your arguments about security benefits of SLs are ridiculous 
and entirely without merit.  

Keith

---

From: "Anurag Uxa" <[email-masked]>
Date: Tue, 19 Nov 2002 09:59:05 +0530

Dear Keith n all 

Please clear my doubt. How these following lines of RFC's are possible?

If an implementation provides bidirectional configured tunnels it MUST at least accept and respond to the probe packets used by Neighbor Unreachability Detection. Such implementations SHOULD also send NUD probe packets to detect when the configured tunnel fails at which point the implementation can use an alternate path to reach the destination.

Anurag Uxa
IWave Embedded systems
Bangalore-76
ph.6786243/5 extn :205

www.iwavesystems.com

DISCLAIMER:

This e-mail and any attachment (s) is for authorised use by the intended recipient (s) only. It may contain proprietary material, confidential information and/or be subject to the legal privilege of iWave Systems Technologies Private Limited. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from retaining, using, copying, alerting or disclosing the content of this message. Thank you for your co-operation.