[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPv6 Network Architecture Protection draft
On Thu, 14 Oct 2004, Brian E Carpenter wrote:
The authors would be interested in comments on the draft below.
Thanks. Mine below. I think this is an important and very
well-written draft.
I recognize a number of recommendations/v6 approaches which I
definitely don't like, but would rather see changed (if it was
possible), but because this draft is meant more as a political
document I understand why those (more or less) have to be in there...
substantial
-----------
2. Perceived benefits of NAT and its impact on IPv4
This section provides visibility into the generally perceived
benefits of the use of IPv4 NAT. The goal of this description is not
to analyze these benefits or discus the rightfulness of the
perception, but to identify the connectivity and security
prerequisites to deploy IPv6 to functionally replace IPv4 combined
with a NAT device.
==> as said above, this is a practically good approach at finishing this
document in finite time. I just hope it would have been possible to insert
some enlightenment, possibly a subsection per existing subsection, saying
why a particular concern is not such a big problem or is a bad idea. You
never know, someone could even be convinced about it.... :-)
2.6.2 Small private networks
2.6.3 Single user connection
==> do we dare to mention some ISPs' business models here, i.e., NAT helps
the customer to deploy as many devices as he wants in even residential,
cheapo access deal? ISP could force the user's hand if ISP only gave
/128's. On the other hand, then the user can just use tunneling like Teredo
or 6to4, and get v4-dependent v6 address space regardless of the ISP.
This simple rule would create similar protection and security holes
the typical IPv4 NAT device will offer and may for example be enabled
by default on all broadband edge-routers. but with that difference
that the security caveats will be documented, and may hence be
removed with the next revision of the rule.
==> this also needs to discuss how to not throw away the baby with the
bathwater, i.e., how one could deploy e.g. new apps (like p2p) without
having to do the same kind of firewall traversal as v4. This probably
would need some signalling mechanism or something.. Probably an issue to be
investigated.
An alternative method to hide the internal topology would be to use
MIPv6 internally where the public facing addresses (HA) are
consolidated on an edge Home Agent, then use MIP in tunnel mode to
the ULA as a COA. This truly masks the internal topology as all
nodes with global access appear to share a common subnet. (it
wouldn't really need to be a single subnet either so local policy can
run rampant trying to obscure addressing correlations.) There is no
reason that rack mounted devices shouldn't be considered mobile nodes
to mask the internal topology.
==> You're referring to using MIPv6 in a MIPv4-like manner, e.g., using
bidirectional tunneling only, no route optimization. This should be stated
out explicitly. That's equivalent to running a VPN to a central server.
This has issues e.g. relating to scalability and reliability of the server
which should also be at least briefly mentioned.
NOTE:
Is all of the material in this section, specifically the material
that does not directly address the "advantages" of IPv4 NAT,
necessary?
==> agree, most of this is irrelevant here. I'd suggest, unless something
else is figured out, to moving the non-relevant parts to an appendix and
figuring out later what should be the final destiny..
semi-editorial
--------------
Once a list of available devices and IP addresses has been mapped, a
port-scan on these IP addresses can be performed. A port scan is an
automated procedure of initiating sessions on every specified TCP
port to see whether the host replies. If it does, a service is
running on the target port of the machine. Different services run on
default ports. For example, FTP usually runs on port 21, and HTTP
usually runs on port 80. These open port cold be used for initiating
attacks on an end system.
==> there's UDP port scanning as well, in case the firewall is returning
port unreachables for the unfiltered ports (which tells which ports are
passed by the firewall, or if there is no firewall, which ports are open at
the host).
==> this and a couple of other sections go a bit unnecessary in depth to
describe e.g., what port scanning is, but considering the target audience
this is probably a good idea..
2.5 Independent control of addressing in a private network
2.7 Multihoming and renumbering with NAT
==> these seem to be more tightly coupled, so would it make good sense to
move 2.7 as 2.6, and rename 2.6 as 2.7 (and respectively)? If not, there
should be a pointer from 2.5 (last paragraph) to section 2.7.
Based on the amount of connections and required network services the
network design and addressing dynamics are different.
==> what "connections"? _simultaneous_? TCP connections or flows in
general?
3. The size of the typical subnet ::/64 will make a network ping
sweep and resulting port-scan virtually impossible due to the
amount of possible combinations available
==> make explict ref to Tim Chown's document ?
4.6.4 ISP/Carrier customer networks
==> this is roughly the same as 2.6.4, and needs to be updated ?
(nothing v6-specific here..)
5.1 Universal any-to-any connectivity
One of the original design points of the Internet was any-to-any
connectivity. The dramatic growth of Internet connected systems
coupled with the limited address space of the IPv4 protocol spawned
address conservation techniques. NAT was introduced as a tool to
reduce demand on the limited IPv4 address pool, but the side effect
of the NAT technology was to remove the any-to-any connectivity
capability. By removing the need for address conservation (and
therefore NAT), IPv6 returns the any-to-any connectivity model and
removes the limitations on application developers. With the freedom
to innovate unconstrained by NAT traversal efforts, developers will
be able to focus on new advanced network services (i.e. peer-to-peer
applications, IPv6 embedded IPsec communication between two
communicating devices, instant messaging, Internet telephony, etc..)
rather than focusing on discovering and traversing the increasingly
complex NAT environment.
==> maybe this needs reference to the default firewall policy section, and
the caveat about that causing issues for new any-to-any apps..
IPv6 allows also for innovative usage of the IPv6 address length, and
makes it possible to embed the multicast 'Rendez-Vous Point' (or RP)
directly in the IPv6 multicast address when using ASM multicast.
this is not possible with limited size of the IPv4 address.
==> I guess it might also be worth saying that using this approach
simplifies the multicast model considerably, making it easier to understand
and to deploy.
o IPv6 has the IPsec technology embedded directly embedded into the
IPv6 protocol. This allows for simpler peer-to-peer encryption
and authentication, while the usage of some other less secure
mechanisms is avoided (i.e. md5 password hash for neighbor
authentication)
==> in all fairness, there is still the small matter of key/trust management
to consider, unless an opportunistic IPsec model is acceptable..
o On a local network, any user will have more security awareness.
This awareness will motivate the usage of simple firewall
applications/devices to be inserted on the border between the
external network and the local (or home network).
==> I didn't understand what this tried to say..
o The technology to enable source-routing on a network
infrastructure has been enhanced to allow this feature to
function, without impacting the processing power of intermediate
network devices. The only devices impacted with the
source-routing will be the source and destination node and the
intermediate source-routed nodes. This impact behavior is
different if IPv4 is used, because then all intermediate devices
would have had to look into the source-route header. Looking into
the source-route header consumed CPU power of these devices and
was generally discouraged to be enabled on a network due to
potential Denial-of-Service attack potential.
==> this is technically not correct. Both v4 and v6 behave the same way;
the routing header is only processed by those nodes who are at the
destination address (before it's changed), so on-path nodes don't need to
peek at the packets. I suggest this bullet be removed.
6. IPv6 gap analysis
Like IPv4 and any major standards effort, IPv6 standardization work
continues as deployment starts.
==> "as deployment starts" sounds as if deployment has not started yet ;-).
Maybe "is ongoing"?
8. Security Considerations
Various security and privacy benefits of both IPv4 NAT and native
IPv6 are discussed throughout this document. It does not introduce
any new security concerns.
==> this section will probably need to expand a bit, but I guess it's OK to
keep it as is for now, to see how the recommendations develop.
11 References
==> need to be split to normative/informative
editorial
---------
to analyze these benefits or discus the rightfulness of the
==> s/discus/discuss/
which member of a family, which customer of an Internet caf?, or
==> s/caf[weird character here]/cafe/
of NAT to avoid the ongoing operational complexity of overlapping
addresses
==> add "." at the end.
An example of a potential rule could be:
==> s/rule/set of firewall rules/
This simple rule would create similar protection and security holes
the typical IPv4 NAT device will offer and may for example be enabled
by default on all broadband edge-routers. but with that difference
that the security caveats will be documented, and may hence be
removed with the next revision of the rule.
==> s/but/But/, or something missing there?
4.5 independent control of addressing in a private network
==> s/in/In/
route-injection could be done based on ::/128 host-routes to each
==> remove "::".
4.6.2 small private networks
==> s/small/Small/
Operation Center (NOC) and are using either a dial-up connection or
broadband access..
==> remove the other "."
o IPv6 has the IPsec technology embedded directly embedded into the
==> kill extra "embedded"
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings