Subject: RE: reqs for local addressing OR requirements for SL replacement?[Re: Accept hain/templin draft as wg item?]

From: "Michel Py" <[email-masked]>
Date: Mon, 25 Aug 2003 11:20:33 -0700

> Leif Johansson wrote:
> The added protection you get from a private address space
> is isn't worth the bits the configuration is stored in.

Exactly the same as saying that car locks are not worth having because
they're so easy to open that they don't stop anybody. It is true indeed
that any amateur with a coat hanger will open a car in a matter of
seconds. As a matter of fact, I locked my keys in my car a while ago and
I had to call AAA to let me back in. It took more time to the driver of
the AAA truck to fill the paperwork than it did to open the door.
 
Guess what: cars have locks anyway and nothing you can say about car
locks being a joke is going to change it. If you don't like it, you can
leave your car open.
 
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: Leif Johansson <[email-masked]>
Date: Mon, 25 Aug 2003 20:36:20 +0200

>locks being a joke is going to change it. If you don't like it, you can
Sigh. This is almost to dumb to respond to and I'll be kicking myself 
when the
next stats come out ;-) It is possible to build a good car lock (I 
claim) and some
day someone will find the economic incentive to do so.

By contrast your private address space does not protect your network 
from an
attack which violates the basic assumption that there is an inside and 
an outside.
The added twist from F.Sobig@mm and friends is that you no longer have to
be a network security geek to appreciate this fact.
   
       Cheers Leif

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Aug 2003 14:47:07 -0400

> they're so easy to open that they don't stop anybody. 

nope.  he didn't say that perimeter security was useless, he said that
using private addressing as a mechanism to enforce perimeter security
was useless.  

- you can accomplish the same thing with global address space and an
ACL or other configuration

- if private addresses are routable at all (and there are good reasons
to make them so) then you need explicit configuration even to block
private addresses, so they don't save you anything

- given that you really need filters within your network more than at
the perimeter, even if you could save that one bit of configuration
needed at the perimeter, it wouldn't save you from having to configure
the filters within your network - and it's more important to
get those right anyway.
--------------------------------------------------------------------
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: Mon, 25 Aug 2003 11:54:04 -0700

> day someone will find the economic incentive to do so.

So there should be no locks on cars until someone finds the economic
incentive to build something better than what is there?

> attack which violates the basic assumption that there is an 

You appear to presume that to be useful a technology must solve all known
problems. Address space that is not routed to the world does provide
protection from direct attacks. It does not prevent indirect attacks through
nodes that have a route.

> The added twist from F.Sobig@mm and friends is that you no 
> longer have to be a network security geek to appreciate this fact.

Any node that can be reached directly or indirectly from outside the
perimeter can bring undesireable content into the protected area. The more
layers of protection there are, the more opportunity there is to isolate and
contain any problems. Having address space that is not routed provides an
extra layer which protects against failures in the firewall/access controls.
If your network doesn't require that extra level, there is no need to deploy
it. At the same time, there are network managers that insist on having that
capability. 

Tony

---

From: Leif Johansson <[email-masked]>
Date: Mon, 25 Aug 2003 21:11:01 +0200

>protection from direct attacks. It does not prevent indirect attacks through
No but new technology must actually solve more problems that it creates. 
Car locks
that are easy to break cause little harm apart from this fact.

<snip>

>it. At the same time, there are network managers that insist on having that
I believe that the lessons learned from the types of attacks prevalent 
today will bring
about a change in the types of solutions network managers ask for.

    Cheers Leif

---

From: Hans Kruse <[email-masked]>
Date: Mon, 25 Aug 2003 15:17:11 -0400

I fear this discussion is headed in the wrong direction as far as the 
decisions in this group.  You are of course right that filtering (by 
private or public addresses) at a border is not sufficient security.  But 
it DOES remove some unwanted traffic.  Is this relevant to local addressing 
-- probably not.  However, I have become convinced that some form of local 
addressing is required to allow network managers enough flexibility to 
solve their design issues.  I hope the WG can create these addresses, try 
to insure that they won't break things (as SL apparently did), and move on.

You mileage may (probably will) vary....

--On Monday, August 25, 2003 20:36 +0200 Leif Johansson <[email-masked]> 
wrote:

> By contrast your private address space does not protect your network from
> an attack which violates the basic assumption that there is an inside and
> an outside. The added twist from F.Sobig@mm and friends is that you no

Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer Science
Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax
--------------------------------------------------------------------
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 E Carpenter <[email-masked]>
Date: Tue, 26 Aug 2003 16:25:36 +0200

The other point that's been missed here is that the security-by-hiding
argument is only part of the story. Stable address space for 
intermittently connected networks, unambiguous address space for VPNs,
and stable identifiers for multihoming, are also needed. Whatever your 
religion on the hiding argument, these other needs have to be met,
and are not met by PA prefixes.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 Aug 2003 07:51:56 -0700

> and are not met by PA prefixes.

And to be frank, Brian, I am not convinced that even this argument has 
been thought out well.  For instance, how will systems be restricted 
from having both types of IP addresses?  Will it be a host policy or a 
network policy?  If it's a network policy, how does that work with 
stateless autoconfiguration?

Eliot

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 26 Aug 2003 10:04:41 -0700

Eliot Lear wrote:
> > religion on the hiding argument, these other needs have to 
> be met, and 
> > are not met by PA prefixes.
> 
> from having both types of IP addresses?  

Some scenarios actually want both. Why do you assume that having both is a
problem?

> Will it be a host policy or a network policy?  

That needs to be a local decision. The IETF is not in the business of
telling people how to run their networks.

> If it's a network policy, how does that work with 

If the goal is only to allow local, then only put a local in the RA. If it
is only to allow global, likewise. If there are to be a mix on the same
wire, it is a host policy by definition.

Tony

---

From: Andrew White <[email-masked]>
Date: Wed, 27 Aug 2003 12:50:01 +1000

I agree with Brian - the security issues are not the driving force in local
addressing.

The requirements I want are simple:

* I want to be able to create prefixes ex-nihilo (from nothing), without
involving the user, the internet, or anything other than my router or
collection of routers.

* I want an acceptable level of uniqueness from these prefixes, so that I
can connect (physically or via VPN) on such network to another without
worrying about address collision.

* I want "internal" applications to be able to keep communicating with each
other regardless of the presense or absence of connections to the global
internet or to other clusters of self-configuring routers.

The 'filtering' requirement is not driven by security, but by a realisation
that any self-created prefix is not going to fit within the aggregable PA
architecture of the current internet.  Thus, to protect the routing tables
we need to filter the self-created space.

Given these requirements, even the Hinden / Carpenter draft doesn't
completely fulfil them, since it requires manual configuration of the prefix
(via an algorithm, but it's still 'manual') and a mechanism to propagate
that prefix within the local network.  So far the best solution I've seen is
to take a /12 prefix (I've been using fef0::/12, but fdf:://12 would work as
well), append a MAC or EUI-48 (to /60) and still have four bits left over if
you need to subdivide further (eg to generate prefixes for interfaces
without an EUI-48 or MAC).

The only drawback here is that each router generates a prefix that is only
aggregable at the /60 (per-router) level and the /12 (universal) level, but
since this is designed for self-contained ad-hoc networks with at the
extreme a couple of hundred nodes (and more usually less than 10 or so)
routing table bloat is not really an issue.  Since each router administers
it's own prefixes there is no need for prefix propagation, and the routing
protocol takes care of the rest of the packet delivery infrastructure.

Incidentally, I've come to realise the 'referral' argument is a minor
concern.  If you're in a "local networking" world, you only want to do
referrals to other nodes in your world.  If you're in a "global" world, then
you of course do global stuff.  The only potential issue is when you're in a
overlaid world, but then I'd suggest that it's the job of the person running
the application to determine which world the application should prefer.

-- 
Andrew White

---

From: Mark Smith <[email-masked]>
Date: Wed, 27 Aug 2003 15:36:17 +0930

On Wed, 27 Aug 2003 12:50:01 +1000

> since this is designed for self-contained ad-hoc networks with at the
                                             
Why are you assuming an "ad-hoc network with at the extreme a couple of hundred nodes" ?

I consider your requirements to be equally applicable to an architected enterprise (or other large) network supporting 1000s, 100 000s or even millions of nodes, which is likely to contain a larger number of routes such that route aggregation is attractive for network stability reasons, or even necessary to cope with equipment limitations.

Only being able to aggregate within the network at between /60 - /64 really limits the usefulness of aggregation.

I do like the idea of autoconfiguration, but in larger networks, it can start to work against you - your network can start doing things behind your back that make it terrible to diagnose faults. 

<snip>

Regards,
Mark.

---

From: Andrew White <[email-masked]>
Date: Wed, 27 Aug 2003 16:34:39 +1000

> Why are you assuming an "ad-hoc network with at the extreme a couple of

and then wrote

> I do like the idea of autoconfiguration, but in larger networks, it can
> start to work against you - your network can start doing things behind
> your back that make it terrible to diagnose faults.

I think you just answered your own question. :)

That said, I believe there are situations where local addressing is
appropriate in a configured network, mainly to exploit the PI aspect of
it.  The difference between such networks and the ad-hoc ones I have in mind
is that an architected network can partition their PI space in an aggregated
manner, exactly as they would do for PA space.

So requirements 2 and 3 are still applicable, but requirement 1 is not (as
we both agree that someone is exercising at least some control over how the
routers are configured).

This still leaves the knotty problem of which address to use by default. 
I'm still of the opinion that the most sensible option is for the 'system'
to suggest that the application by default use the smallest applicable
common scope (known to the system), but make it easy for the application to
override that recommendation if it thinks it knows better.

There are three situations that readily come to mind where an application
might want to override the default:
  * application uses address-based referrals.
  * particular addresses are known to have short lifetimes and the
application plans a long-lived connection.
  * using link-local addresses in an environment where a device could move
between links yet meaningfully keep a constant higher-level address.