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

[Elwyn Davies <elwynd@dial.pipex.com>]

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/