Subject: Issue list of draft-ietf-nap-v6ops-01

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 25 Aug 2005 12:51:13 +0200

Dear All,

During the WGLC (5 August - 19 August) about the draft 
draft-ietf-nap-v6ops-01.txt
there were many suggestions for editorial comments. Lots of these editorials
have been included in a first draft for the -nap-02 draft version.

In addition we have taken the liberty to make a summary of the more 
substantial
comments. In total we have found 37 substantial comments/issues.
The summary list can be found at 
http://www.vandevelde.cc/ietf/NAP-Issue-Log.htm

There is a large variety of comments, some analytical, some less 
analytical, however
we should try to get these worked out by means of WG consensus.

Brgds,
G/

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 25 Aug 2005 12:45:57 +0100

Thanks for the summary...

However, I think it misses the discussion over the last couple of days 
which resulted in the summary from Christian Huitema:

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

Regards,
Elwyn

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 25 Aug 2005 14:16:53 +0200

Thanks again for providing the useful input. I did indeed overlook the summary
comments from Christian Huitema. However they are probably the consensus
summary of issue 24 as that started the discussion initially? I have to 
think on
to modify the text under s4.4 to reflect the words from Christian Huitema.

Brgds,
G/

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 25 Aug 2005 13:27:28 +0100

That is probably true..

E

Gunter Van de Velde (gvandeve) wrote:

> summary of issue 24 as that started the discussion initially? I have 
> to think on
>> However, I think it misses the discussion over the last couple of 
>> days which resulted in the summary from Christian Huitema:
>>