Subject: RE: Review: draft-ietf-v6ops-nap-01.txt

From: "Bound, Jim" <[email-masked]>
Date: Mon, 22 Aug 2005 15:19:28 -0400

FOlks, favor I really think we deliver NAP to the IESG and to the
public.  Could all those who find subtle disagreements go offline and
come to consensus back to the WG.  I think all are in agreement but this
spec is very useful to the market can we please ship it.

thanks
/jim 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tim Chown
> Sent: Friday, August 19, 2005 4:00 AM
> To: [email-masked] '
> Subject: Re: Review: draft-ietf-v6ops-nap-01.txt
> 
> On Thu, Aug 18, 2005 at 07:08:44PM +0100, Elwyn Davies wrote:
> > 
> > The comments contain a suggestion that 
> > draft-chown-port-scanning-implications should be published 
> as an RFC - 
> > it is referenced both here (in what I consider to be a 
> Normative way) 
> > and it is relevant to the security overview also.  Does 
> anybody else 
> > support this?
> 
> For info, this can be found here:
> 
> http://www.watersprings.org/pub/id/draft-chown-v6ops-port-scan
> ning-implications-01.txt
> 
> It's one of those 'kind of obvious' texts, but has received 
> good comments
> while it was live.
> 
> I would be happy to revive it, or work with 
> Gunter/Fred/Elwyn/whoever to
> merge it into the NAP text itself.   There are pros and cons 
> either way.
> 
> Tim
> 
> 
>

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 23 Aug 2005 09:20:32 -0700

> If the objective is to not have people on the outside know of the
> existence or exact value of an address, or be able to attack it by
> sending traffic to it, then a system that sends packets outside the
> net would need to change addresses periodically, but a system that
> doesn't send packets outside the network merely needs to be protected
> from accidental uses of its address.

So far, I have heard the following arguments:

1) Attack surface reduction: hosts that are not reachable at all from
the outside are less likely to be attacked.

2) Protection against enumeration: even if hosts are reachable, making
their address hard to guess provides protection against systematic
attacks such as worms or port scanning.

3) Protection against topology analysis: if the address cannot be
correlated with a particular enterprise department, attackers have a
harder time figuring out which department is active, or a good target.

The solution to number 1 is to provide those hosts that are not meant to
be reachable with addresses that are explicitly filtered at the entry
points of the organization's network. ULA would do, but are not
necessary: any subnet prefix can be filtered. The simple solution is to
connect unreachable hosts to an unreachable link. If one must mix
reachable and unreachable hosts on the same link, then one has to either
forgo the protection, or manage two different subnet prefixes for the
same link.

The solution to number 2 is well documented in the draft.

Problem number 3 only occurs in some networks. It is not an issue if the
network is entirely switched (single link), or if the enterprise does
not care about hiding its topology. Only then are solutions like flat
routing or MIP6 useful. 

One could make a strong case that topology can be discovered anyhow from
analysis of the application traffic, email addresses, web proxy
selection and other hints. One could easily argue that the supposed
protections are futile. But that amounts to "fighting your customers",
which is not a very rewarding exercise.

-- Christian Huitema