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

From: Elwyn Davies <[email-masked]>
Date: Thu, 18 Aug 2005 19:08:44 +0100

Fred Baker orinally asked me to comment on this draft in the light of my 
editorship of the NAT-PT to experimental recommendation.  It has turned 
into a bit of a marathon...I think there is quite a lot of improvements 
to be made before it moves on, but I would support its going forward.  
The editorial pieces are mostly language improvements but there are IMO 
significant substantive issues to sort out.

In terms of NAT-PT, I think it would be appropriate to add a section 
saying why it would be dangerous to constrain future developments of 
IPv6 networks by eliminating NATs and then adding back the general form 
of NAT-PT just to do transitions.  If it is agreed that this is wanted, 
I am prepared to draft a suitable piece of text.

BTW I did read (lightly) the Appendices but they seem pretty good so 
there are no comments on them (at present).

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?

Substantive:

s2.2: para 2: should mention need for improved trust in end systems 
which are not physically secured.

s2.3: para 2: last sentence: surely the NAT state database log would 
amount to exactly the time-correlated list which the admin instance is 
assumed to have hold of? Clearly if you don't have a sensible log there 
is a big problem, but I think the 2nd para needs a rethink.  Also I am 
not sure why port mapping makes things more difficult - the mappings may 
be *finer* grained allowing *better* tracking of what an end host is up 
to than in an address only NAT.  In either case you need to know the 
outside destination (address and port) when the source mapping is 
created in order to have an idea of what the end host is doing.

s2.5: Maybe the downside of RFC 1918 from this point of view of site 
merging could be mentioned as well with pointers to s2.7.

s2.7: The high probability of address overlaps with RFC1918 addressing 
needs to be explicitly mentioned (as a new second sentence in para 3).  
The reason why there are overlapping addresses (in the final words of 
the para) is not made clear.

s2.4 and s3.1: 'device profiling' as used as a shorthand in s3.1 is 
effectively defined in s2.4 - would be a good idea to say that this term 
will be used for the process set out in para 2 of s2.4.

s3.2: para 1: last sentence: 'as that would have a serious negative 
impact on global routing':  I think this is completely wrong unless we 
are trying to say something other than what is retailed 4 paras further 
on.  ULAs are specifically designed to be essentially benign should 
routes to them leak on account of being a.s. unique.

s3.4: para 2:  I think the term 'aggregation device' is maybe 
misleading.  The actual function is 'indirection device'.   A reference 
to s4.4 for more details would help clarify this rather bald statement 
(or maybe the 'how it is done' should be here?)

s4.1: RFC3484 currently doesn't know about ULAs.  There should therefore 
be a comment about requiring the policy table to be correctly set up so 
that true globals are distinguished from ULAs and will be used for the 
source address in preference when the destination is not a (local) ULA.

s4.2: (item 1): Need to point out the risk of confusing DDoS detection 
systems if the address changes too quickly! (xref to 
draft-ietf-v6ops-security-overview-02.txt).

s4.2: Item 3: I am not sure that this doesn't promote [17] to a 
Normative reference.. either way having recommendations that an 
administrator should take into consideration
in an I-D is not very satisfactory.  Some of this was documented in an 
appendix of draft-ietf-v6ops-security-overview-02.txt (in an abbreviated 
form)... if we are going to promote the ideas in this draft [17] it 
should either go to RFC or the ideas should be fully integrated into 
either the NAP draft or the security overview.  I would support 
publishing draft-chown-port-scanning-implications as an RFC.

s4.2: para after Item 3: last sentence:  Which thing is opposite to?  I 
think this is not a good statement.  What we are trying to say (I think) 
is: IPv6 security best practices will avoid this kind of illusory 
security but can only do this if correctly configured firewalls and IDS 
systems are used at the perimeter where some IPv4 networks have relied 
on NATs.

s4.2: Item 3: Add a new next to last sentence: This protection will also 
be nullified if IIDs are configured in a group near the start of the IID 
space.

s4.2: The section on firewall rules needs at least to be turned round so 
that the point of it is clear from the outset... Indeed I am not clear 
whether there is any real need for the detailed stuff on the plain 
vanilla setup - taking into account the need for some ICMPv6 traffic to 
be allowed, more detail might be required to get a sensible answer.  I 
suspect that this document is not the place for that sort of discussion  
I think it could be replaced with something like:

   To implement simple security for IPv6 in, for example, a DSL 
connected home
   network, the DSL broadband gateway/router should be equipped with 
stateful
   firewall capabilities. These should provide a default configuration 
which provides
   a minimum set of connectivity for users in the home network (e.g., 
just to external
   HTTP servers) with incoming traffic limited to return traffic 
resulting from outgoing
   packets (sometimes known as reflective session state) with an easy 
interface which
   allows users to create additional 'pinholes' for specific purposes.

   Administrators and the designers of configuration interfaces for 
simple IPv6 Firewalls
   need to provide a means of documenting the security caveats that 
arise from a given
   set configuration rules so that users (who are normally oblivious to 
such things) can be
   made aware of the risks.  As rules are improved iteratively, the goal 
will be to make
   use of the IPv6 Internet more secure for oblivious users.

s4.2: last para:  The material from 'This mostly starts..' is 
essentially covered in draft-chown-port-scanning-implications.  If [17] 
is referenced (and even more so if it becomes an RFC), this material is 
superfluous.

s4.4: The final statement about encryption and overhead is slightly 
disingenuous.  It is true that the data tunnels can be run unencrypted 
as they are wholly in the local network but the Binding Updates 
generated by the masked nodes to setup the COA are required to use an 
SA.  This has a limited effect on performance but requires some 
configuration.  Also it should be noted that the pseudo-mobile nodes 
need to have route optimization turned off for all correspondents, and 
firewalls need to ensure that the pseudo-mobile nodes cannot move 
outside the local networks and that the indirection device doesn't 
accept inappropriate (external) mobile node registrations.

s4.7: last para: Given the recent work on renumbering, the words about 
'zero-touch external mechanism' may be seen as somewhat optimistic!!

s5.1: we would hope that if an enterprise has multiple /48's from an ISP 
they are generally adjacent (i.e. /47's, /46s etc) (but the nibble 
alignment of the reverse DNS may have some impact).

s6.4: Does this need to be updated in the light of the recent reports on 
renumbering?

s6.5: Site Multihoming: I am (personally) not convinced that what is 
going on in shim6 coincides with the words in this section. It ought to 
be updated in the light of developments.

Editorial:

Global: consistent capitaliuzation (or otherwise) of Home Agent.

Global: RFC3177 should be in the references.

s1: para 3:  I would split up the last sentence which is a bit long and 
mention the retention of any-to-any connectivity, thus: s/...and privacy 
and will... translation./...and privacy. NAP will achieve these security 
goals without address transaltion whilst maintaining any-to-any 
connectivity./

s2.2: para 3: last sentence: s/are/is/, s/actually false/actually an 
illusion/

s2.3: para 1:  s/of the NAT devices state/from the NAT device's state/

s2.4: para 1: s/reflected/represented/

s2.7: last para: s/This solution/The addition of an extra NAT as a 
solution/ (Not clear whether 'This' refers to extra NAT or long term 
solution.)

s2.7: last para: 'the merged address space' is misleading : suggest 
s/merged address space/overlapping address speaces in the merged networks/

s3.1: s/by contacted web sites, so IPv6/by web sites that are accessed 
from the device: IPv6 /

s3.3: last para: s/delegating router/delegating router (incorporating a 
DHCPv6 server)/, s/across an administrative/possibly across an 
administrative/

s3.4: para 2: Replace first sentence with:  'The random assignment is 
intended to mislead the outside world about the structure of the local 
network.'

s3.4: para 2: s/there is a correlation/needs to maintain a correlation/

s3.4: para 2: s/like a/such as a/

s3.4: para 3: s/unpredictable/amorphous/, s/or from mapping/and from 
mapping of/

s3.4: para 3: s/are reachable on/are allocated to devices on/

s3.4: para 3: s/belonging to the same subnet next to each 
other/belonging to devices adjacent to each other on the same subnet/

s4.2: para 1: s/similar as for an/similar to that of an/

s4.2: para 1: s/Internet, and firewall and IDS systems are/Internet. The 
use of firewall and Intrusion Detection Systems (IDS) is/

s4.2: para 1: s/but has/but with/

s4.2: para 1: s/end to end/end-to-end/

s4.2: Item 3: s/amount/number/

s4.2: Item 3: s/This goes from the assumption that the attacker has 
no/This protection is nullified if the attacker has/

s4.2: para after Item 3: s/pose/offer/ (or provide).

s4.2: para after Item 3: s/best- practices/best practices/

s4.2: para after example firewall rules: s/create similar protection and 
security holes the typical IPv4 NAT device will offer/provide 
(non-)protection and create security holes  similar to those offered to 
a network using a typical IPv4 NAT device/

s4.2: para next but one after firewall rules: s/What one does when topology
   probing is to get an idea of the available hosts/The intention of 
topology probing is to identify a selection of the available hosts/

s4.4: para 2: after 'As discussed above' insert  '(see Section 3.1)'

s4.4: para 3: s/consolidated on/indirected via/

s4.4: para 3: s/topololgy masked/each topology masked/

s4.4: para 3: Expand acronym COA

s4.4: para 3: s/rack mounted/static/

s4.5: last para: s?/etc?, etc.?
s4.5: last sentence : s?In v6, it's all /64.?For IPv6 all subnets have 
/64 prefixes.?

s4.6: last para: s/which will lead to the IPv4 practice/which will 
require the adoption of the IPv4 workaround/

s4.6: s/the IPv4 constricting scenarios of multiple devices sharing 
a/the constriction of IPv4 scenarios where multiple devies are forced to 
share a/

s5: Replace first three sentences with: In presenting these case studies 
we have chosen to consider categories of network divided first 
according  to their function either as carrier/ISP networks or end user 
(such as enterprise) networks with the latter category broken down 
according to the number of  connected end hosts.

s5: bullet points: s/connection/connected end hosts/

s5.1: s/addressing independence/addressing independence when using IPv4/

s5.1: last para: s/is only affecting/will only affect/

s5.2: para 1: s?is too long?is too long (very often just a /32 just 
giving a single address)?

s5.4: s/chapter 5.1/Section 5.1/
s5.4: s/intra- connection/intraconnection/
s5.4:s/prevent from/prevent them from/

s6.2: para 2: The information about how to do topology masking with 
Mobile IPv6 would be best concentrated in one place.  Currently it is 
spread across three sections.

s6.2: para 2: s/rack-mounted/static/

s6.4: s/well solved/completely solved/

---

From: "Eric Klein" <[email-masked]>
Date: Thu, 18 Aug 2005 22:31:59 +0300

Elwyn Davies wrote

> I am prepared to draft a suitable piece of text.

I am not exactly sure, but it sounds like what you are proposing is exactly
opposite of the goal of this draft. Effectively this draft is saying that
NATs should  not exist in an IPv6 network and should not be supported as the
features and functions that NAT used to provide are now inherent in the IPv6
architecture.

In which case (IMHO) NAT-PT is strictly for transition from IPv4 only to
IPv4 and IPv6 networks and once the network moves to fully IPv6 there is no
need for NAT or NAT-PT.

Eric

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 18 Aug 2005 21:28:54 +0100

>IPv4 and IPv6 networks and once the network moves to fully IPv6 there is no
It's been a long day of reviewing...

Read what I wrote by inserting brackets around (eliminating NATS and 
then adding back the general form of NAT-PT just to do transitions):

In terms of NAT-PT, I think it would be appropriate to add a section 
saying why it would be dangerous to constrain future developments of 
IPv6 networks by (eliminating NATs and then adding back the general form 
of NAT-PT just to do transitions).  If it is agreed that this is wanted, 
I am prepared to draft a suitable piece of text.

What I thought I was saying is that we should avoid putting
1) any sort of NAT, and
2) any  NAT-PT  in its general form (the one that is being made 
experimental)
into an IPv6 network

There may be (almost certainly is) limited scope for a simplfied 
translator as a front end for legacy servers, but using NAT-PT as a way 
to transmit arbitrary protocols between a generic IPv6 network and a 
generic IPv4 network effectievly condemns IPv6 applications to living 
with the set of capabilities that IPv4 has.  This is NOT a good idea. So 
I dont think I am trying to say anything other than the draft is a good 
thing and better if we avoid fully general NAT-PT as well.

Regards,
Elwyn

---

From: "Eric Klein" <[email-masked]>
Date: Thu, 18 Aug 2005 23:52:17 +0300

Elwyn Davies wrote
> thing and better if we avoid fully general NAT-PT as well.

Agreed, this sounds more like what I would be comfortable with adding. I
will wait to see what the other co-authors have to say.

Thanks for the other comments, they all looked very helpful. And yes it has
been a long day of reviewing and writing.

Eric

---

From: chenhongfei <[email-masked]>
Date: Fri, 19 Aug 2005 10:42:00 +0800

Hi all

I apologized to submit question before finished review the draft.

I'm doubt about this sentence in this mail " once the network moves to
fully IPv6 there is no need for NAT or NAT-PT". One of client's reason
to choose NAT is security.  NAT could hide inner IP address. It is
important for some company. There are request of transition IPv6 to IPv6
maybe. Does this request needed in fully IPv6?

Best regards
Hongfei Chen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eric Klein
Sent: Friday, August 19, 2005 4:52 AM
To: [email-masked]
Subject: Re: Review: draft-ietf-v6ops-nap-01.txt

Elwyn Davies wrote
> >NATs should  not exist in an IPv6 network and should not be supported
as
the
> >features and functions that NAT used to provide are now inherent in
the
IPv6
> >IPv4 and IPv6 networks and once the network moves to fully IPv6 there
is
no

Thanks for the other comments, they all looked very helpful. And yes it
has
been a long day of reviewing and writing.

Eric

---

From: "Eric Klein" <[email-masked]>
Date: Fri, 19 Aug 2005 10:05:38 +0300

Hongfei Chen Wrote

> maybe. Does this request needed in fully IPv6?

Part of what this draft was written to explain is that the concept of NAT as
a security tool was very limited, and one that is better served by
firewalls. The second concept of topology hiding (often confused with
security) is one of the inherent features IPv6 by the use of Site-Local
addresses.

NAT was intended as a patch that would allow a company to have more IP
addresses available than they could register (either from a price or
scarcity consideration). One of the biggest problems with NAT in the current
and future communications world is the high probability that when networks
merge (companies combine or interconnect internal networks) then the NAT
address pools will overlap. Making the process twice as hard in renumbering.
Where in IPv6 both networks would have unique numbers and would be able to
be combined without duplicate.

I hope this clears it up for you
Eric

---

From: Tim Chown <[email-masked]>
Date: Fri, 19 Aug 2005 08:16:11 +0100

> security) is one of the inherent features IPv6 by the use of Site-Local

I don't think 'site locals' (ULAs) hide topology, since ULA subnetting will
invariably mirror global subnetting.

One of the things that worries me about this draft is the suggestion to use
host based routing for topology hiding, or indeed permanent use of MIPv6,
as neither seems particularly attractive just to serve that purpose.
 
-- 
Tim/::1

---

From: Tim Chown <[email-masked]>
Date: Fri, 19 Aug 2005 09:00:16 +0100

> and it is relevant to the security overview also.  Does anybody else 

For info, this can be found here:

http://www.watersprings.org/pub/id/draft-chown-v6ops-port-scanning-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: chenhongfei <[email-masked]>
Date: Fri, 19 Aug 2005 16:45:21 +0800

I understand and agree with draft. Thank you.

The problem when networks merge is a big problem for NAT. A good network
design should reduce the effect of this problem. I need finished review
the draft at first :) 

Best regards
Hongfei Chen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eric Klein
Sent: Friday, August 19, 2005 3:06 PM
To: [email-masked]
Subject: Re: Review: draft-ietf-v6ops-nap-01.txt

Hongfei Chen Wrote

> maybe. Does this request needed in fully IPv6?

Part of what this draft was written to explain is that the concept of
NAT as
a security tool was very limited, and one that is better served by
firewalls. The second concept of topology hiding (often confused with
security) is one of the inherent features IPv6 by the use of Site-Local
addresses.

NAT was intended as a patch that would allow a company to have more IP
addresses available than they could register (either from a price or
scarcity consideration). One of the biggest problems with NAT in the
current
and future communications world is the high probability that when
networks
merge (companies combine or interconnect internal networks) then the NAT
address pools will overlap. Making the process twice as hard in
renumbering.
Where in IPv6 both networks would have unique numbers and would be able
to
be combined without duplicate.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 19 Aug 2005 21:40:54 +0300

Le Vendredi 19 Août 2005 11:00, Tim Chown a écrit :
> It's one of those 'kind of obvious' texts, but has received good
> comments while it was live.

I'm not decided myself how well that would fit in such a would-be 
revived document, but, anyway... it might be worth to mention how/why 
being on-link makes it easier to find out host addresses, e.g. if not 
by listening to ICMPv6 ND or MLD traffic, by pinging the allnodes 
multicast addresses.

-- 
Rémi Denis-Courmont

---

From: Tim Chown <[email-masked]>
Date: Mon, 22 Aug 2005 09:17:29 +0100

> by listening to ICMPv6 ND or MLD traffic, by pinging the allnodes 

Interesting... it was initially written with the 'from off link' view,
but could include on-link briefly, or other methods to discover on link
addresses remotely.

Thanks,
-- 
Tim/::1

---

From: Mark Smith <[email-masked]>
Date: Tue, 23 Aug 2005 14:12:08 +0930

Hi Tim,

On Fri, 19 Aug 2005 08:16:11 +0100

> On Fri, Aug 19, 2005 at 10:05:38AM +0300, Eric Klein wrote:
<snip>
> as neither seems particularly attractive just to serve that purpose.

Out of curiosity, are you able to elaborate ? Is it scalability,
tunneling overheads, administrative complexity ? I'm interested because
I thought of another way the IPv6 topology could be hidden over the
weekend, using IPv4, and am interested in any criteria that could be
used to judge its value.

I'd be interested in yours and other people's opinions of the following
method of topology hiding. It was mainly inspired by the way 6to4 works.
I'm willing to spend more time on it if it is worth while, I'd prefer to
not spend more time on it if it isn't :-)

- within the network topology that would be covered by the IPv6 /48,
deploy IPv4, using RFC1918 addressing, restricting the IPv4 node
addresses to the last 2 octets of the IPv4 address space eg. address the
subnets / nodes from out of e.g. 10.0/16.

- make sure the 10.0/16 address space is not visible to the Internet ie.
don't deploy NAT, no need to even have IPv4 forwarding across the
boundary between the Internet and the /48 boundary.

- The IPv6 nodes within the /48 would use the last two octets of their
IPv4 address as the subnet portion of the IPv6 address ie. the field
between /48 to /64. 

- To obscure the IPv4 topology, the last two octets of the IPv4 address
would be encoded using a light weight symmetric cipher.

- IPv6 packets travelling within the domain are delivered encapsulated
in IPv4. The destination and/or source addresses of IPv4 addresses of these
packets is the deciphered value of the IPv6 subnet field, prefixed by
the RFC1918 chosen /16 prefix e.g. 10.0/16.

This is effectively treating IPv4 operating within the IPv6 /48 domain
as a NBMA subnet, encoding the layer 2 addresses in the subnet field of
the IPv6 addresses, and then obscuring them such that outside the local
IPv6 /48 domain the "layer 2" IPv4 topology and the IPv6 topology is
hidden.

A normal, global /48 would be used, so it would not be possible to
determine on face value if this technique was being used, unlike the
2002::/16 6to4 prefix. Recording IPv6 addresses over a time period could
be used to see if the IPv6 "subnets" are random, and although that might
indicate this technique was being used, it still doesn't disclose the
either the IPv4 and IPv6 topology, as nodes that are adjacent in IPv4
will still have significanly different IPv6 subnet portions, due to the
cipher.

Privacy addresses can be enabled, and this may also futher enhance the
obfuscation. It would appear that multiple hosts are attached to the
same subnet, when in reality only one is. Admittedly it would be
possible to identify this same host, for example, if some identifyable
service is available on it e.g. a web server with a specific web page.
However, this possibly isn't a problem anyway, and certainly isn't one
that is attempting to be solved by topology hiding.

A further enhancement could be to use IKE between the nodes and the edge
router(s) and have the light weight cipher key change over time. Then,
to external nodes outside the /48, the nodes would also appear to be
moving around over time, as the subnet portion would be changing even
though the underlying IPv4 address isn't.

This solution does restrict the number of IPv6 nodes that can be
supported within a /48 to the efficiency of the IPv4 addressing plan. If
non-topology hidden IPv6 hosts need to exist, or more IPv6 nodes need to
be supported than one IPv4 /16 can support, additional IPv6 /48s could
be used. This is probably a drawback, as it would increase the
consumption of /48s at a rate above what has been projected by documents
such as RFC3177.

This certainly isn't a perfect solution, however, it could be an
improvement over some of the other techniques mentioned.

Any thoughts ?

Thanks,
Mark.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 23 Aug 2005 08:10:26 +0200

On Tue, Aug 23, 2005 at 02:12:08PM +0930, Mark Smith wrote:
[...]
> improvement over some of the other techniques mentioned.

My thought is basically that it might work, but adds a lot of complexity.
As does the other proposed mechanisms. I would not deploy them, but then
I never understood why people are so concerned about hiding topology. I
guess someone that for some reason think it important might want a
solution. I would rather try to understand why people want to hide their
topology and hopefully explain why it's not important, rather than
presenting solutions adding complexity to the network though...

Stig

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Tue, 23 Aug 2005 09:17:06 +0200

>presenting solutions adding complexity to the network though...

I suppose its just the vain feeling/perception of having security by 
obscurity.

Having a hidden topology may make no real difference for a real attack, however
it may increase the threshold for the not so expert attackers, while at the 
same time
it provides a comfort feeling to the network administrator that he has one 
additional
(yet virtual) barrier the hacker has to go through. I'm not saying that 
this is a
good thing, however, people are by general behavior consistent in keeping a 
believe
in old habits and convictions.

Unfortunatly the industry need for having a tool to provide topology hiding is
real.... and is very easy to deploy in the IPv4 world by using address 
translation, hence
the IPv6 community better provides some solution for this and the MIPv6
one seems most appropriate to me at the moment. (The /128 ULA's is a different
story)

Groetjes,
G/

---

From: Fred Baker <[email-masked]>
Date: Tue, 23 Aug 2005 15:54:39 +0800

On Aug 23, 2005, at 3:17 PM, Gunter Van de Velde (gvandeve) wrote:

> real.... and is very easy to deploy in the IPv4 world by using  
> address translation, hence

Compared to having an address space one doesn't advertise outside,  
mobile ip v6 seems really complex. I'm not fond of ULAs, but as I  
said in another context, simply having a prefix that is not  
advertised seems quite sufficient for hiding internal-only systems.  
And it's only the internal-only systems any of this hides; systems  
that can be seen from the outside can be seen from the outside, and  
the fact that they are on the same or different LANs is really window- 
dressing compared to that.

---

From: Tim Chown <[email-masked]>
Date: Tue, 23 Aug 2005 09:29:40 +0100

> dressing compared to that.

My view is along those of Stig and Fred.

Given how NAP is in itself a 're-education' tool, we could/should use it
as an opportunity to highlight what can be done with IPv6.   The schemes
for topology hiding proposed to date add back a lot of the complexity that
IPv6 in principle removes.   I really don't agree with the NAP draft's
approach on the topology hiding issue, though otherwise I think it's an 
excellent document.  I think some simpler words can be said, and MIPv6
or host routing avoided (or Mark's scheme, sorry :).

As an aside, when you say 'topology hiding' Gunter, do you really mean
subnet/link topology, or the number of hosts, or...?

-- 
Tim/::1

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Tue, 23 Aug 2005 10:57:18 +0200

>subnet/link topology, or the number of hosts, or...?

When i see 'topology hiding' i make a reference that an entity outside
the network can not make any correlation between the location
of a device and the address of a device on the local network.

This is something that can be achieved with MIP without loosing
any of the end-to-end aspects. Same for the /128's PI addresses.
There could be additional mechanisms, some simple, some more complex.

The draft is not to recommend usage of any of these, however it is to
inform people that there are possibilities to achieve similar result
without address translation. By mentioning that 'topology hiding' is
useless, that it makes no sense and is complete brainless nonsense, well
in that case many NAT biassed people who sincerely believe in
the topology hiding may find IPv6 a 'too risky protocol that does not
provide same features and functionality as IPv4 with respect to security'

Don't get me wrong.. i do not believe in topology hiding myself, however
many people do, and we have to offer alternatives and that is what the
document is about. A potential alternate solution is to make a v6ops
study on the value of topology hiding when using IPv6? and by that make
disarm the motivation to make usage of either MIP, /128 or any other complex
mechanisms.

Groetjes,
G/

---

From: Tim Chown <[email-masked]>
Date: Tue, 23 Aug 2005 10:12:23 +0100

> of a device and the address of a device on the local network.

OK.  Maybe add that sentence to the draft.  Start of section 2.4, add
after first sentence.
 
> There could be additional mechanisms, some simple, some more complex.

And at additional costs, e.g. MIPv6 some would argue breaks 'end to end'
in that you rely on a middlebox to establish communication.
 
> without address translation. 

To me, the table in section 1 suggests that host routes and MIPv6 are the
norm for an IPv6 network.

The only reason you cite in the text for topology hiding is in section 2:

  "NAT of course entirely hides the internal
   subnet topology, which some network managers believe is a useful
   precaution to mitigate scanning attacks."

But the pure size of the address space deters 'random' port scanning anyway.

Then again in section 4:

  "What one does when topology
   probing is to get an idea of the available hosts inside an
   enterprise.  This mostly starts with a ping-sweep."

which suggests topology hiding is all about available/reachable hosts.
That should be mitigated by edge firewalls or the v6 link address space size.

I don't see any other discussion of topology hiding beyond that one issue.

> By mentioning that 'topology hiding' is

Well that is their loss, but my vote is that we don't bend the text in
favour of such preconceptions, unless we hear some technically sound
reasons to do so.
 
> disarm the motivation to make usage of either MIP, /128 or any other complex

But at present NAP says 'topology hiding' = 'host hiding' = 'port scanning
resilience via firewalls or link address size'.

I don't want to do MIPv6 or host routing for that.

Tim

---

From: Mark Smith <[email-masked]>
Date: Tue, 23 Aug 2005 21:51:46 +0930

On Tue, 23 Aug 2005 09:29:40 +0100

> My view is along those of Stig and Fred.

So is mine :-) I don't see much value it in it really either, I was
starting from the assumption that if somebody chose to do it, could the
be a possibly be another simpler or better solution. 

> or host routing avoided (or Mark's scheme, sorry :).

One possibly big problem with my scheme, host routing or MIP is that I
think they all tend to give the IPv6 domain NBMA like characteristics,
meaning that multicasts probably have to be distributed via replicated
unicasts. Possibly in my scheme that could be solved by multicast
enabling the IPv4 "layer 2", and use that to distribute IPv6 multicasts
encapsulated in IPv4 multicast. I don't really know enough about MIP to
know exactly how multicasts are handled for that. The host routing
option might not have an alternative solution other than replicated
unicasts.

The other issue is that they all tend to introduce ambiguity into the
link multicast scope. As all the nodes are members of a single NBMA like
domain, does a link scoped multicast get sent to all of them, possibly
via unicast replication ? If not, where does a link scoped multicast get
sent to ? Does this mean that link and site scopes are now equal ? I
think that if the current topology hiding methods stay in the draft then
these multicast issues should also be mentioned in it.

I'm really starting to also agree that maybe it would be better to
identify the properties that the "toplogy hiding" nature the NAPT
provides, and both show they don't have much or any value or how other
IPv6 mechanisms can meet those features without having to rely on hiding
the toplogy from external entities (e.g., the lack of easy ping scanning
ability preventing hosts being found even if the subnet is known, packet
filtering to prevent traffic being sent to a subnet's router anycast
address.).

Regards,
Mark.