[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: I-D ACTION:draft-vandevelde-v6ops-nap-01.txt]
Hi,
Firstly, I also agree, this document is good and useful.
A few comments.
"2.4 Privacy and topology hiding"
I'm a bit confused by the last paragraph, which looks to be a general
description of what port scanning is. Is it trying to say that in a
number of IPv4 NAT scenarios (e.g., 1 to 1 or 1 to many, as described by a
few of the earlier paragraphs), that once the public IP address(es) of the
NAT devices have been identified, port scanning can take place against
the hosts behind the NAT device (which in reality is the NAT device
itself) ?
If that is generally the intention, then I'd suggest
(a) moving the paragraph to a bit earlier in the section. To me, it
would seem better placed directly after the 2nd paragraph, which
finishes with "At the same time a NAT creates a smaller pool of
addresses for a much more focused point of attack."
(b) it is probably worth distinguishing between configured "server port
mappings" and ephemeral port mappings on the NAT device, and then
briefly describing the possible attacks based on either type of port
mapping. The text seems to be only describing launching a port scan
against NAT boxes with configured server port mappings, and then using
those results to launch a targetted application attack. Pro-NAT people
will argue that that is a far less common scenario than ephemeral port
mappings for servers on the Internet and clients behind the NAT box, and
therefore isn't a major concern.
Suggestion (b) might be a bit too detailed for this RFC. On the other
hand, I think it would be useful if an RFC such as this one could be
read "stand alone", meaning that it also incorporates brief discussion
of the issues as well as a reference to more informative RFCs on the
particular topic. I think it would be useful to say "just read this
(single) RFC" as to why IPv6 eliminates the need for NAT."
"3.4 Untraceable IPv6 addresses"
I'm probably going slightly off topic ...
I seem to remember some concern on the IPv6 ML with ISPs assigning /127s
to PtoP links, and it causing problems related to multicast or anycast
capabilities. Admittedly I don't fully understand the issues, although I
also wonder whether they exist if /128s are assigned to hosts and host
routes used in the method described in this section.
"4.3 User/Application tracking"
I first read this in horror ( :-) ), as the ability to track usage is
anti-privacy. Then I remembered that it serving one of the perceived
benefits of IPv4+NAT for network managers, as discussed in section 2.3.
I think this is a relatively uncommon use of IPv4+NAT, so I think it
might be useful to mention again in this section that IPv4+NAT is
sometimes used for this purpose, just to placate people who've also
forgotten about section 2.3, as I did while reading through the ID.
The next section addresses my default privacy concern. As an alternative
to my previous suggestion, maybe there would be value in reversing the
order of the "User/Application tracking" and "Privacy and topology
hiding using IPv6" sections in both main sections 2 and 4.
"4.5 Independent control of addressing in a private network"
I'd suggest clarifying the following a bit further :
When using IPv6, the need to ask for more address space will become
far less likely due to the increased size of the subnets. These
subnets typically allow 2^64 hosts per subnet and an enterprise will
typically receive a /48 which allows segmentation into at least 2^16
different subnets.
2^16 subnets is only possible if flat routing is used, and I'm not aware
that this is possible with current IGPs, or hierarchial addressing is
used with the network topology perfectly matching the addressing
hierarchy levels. I think the "at least" implies a minimum in common
scenarios, and I wouldn't think this will be the case.
More than 2^16 subnets within a single /48 would require bits to be
stolen from the IID section of the global address. If this is the
scenario that the "at least" is implying, I think it should be clarified
a bit more.
Regards,
Mark.
--
"This signature intentionally left blank."