[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPv6 Network Architecture Protection draft
many thanks for the review below. Kindly find some actions and
comments below:
At 14:31 8/11/2004 +0200, Pekka Savola wrote:
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....
:-)
Maybe we should do that in appendix or so. We have tried to provide
some ventilation or 2th thoughts on a certain perceived benefit, but we
also
would like to avoid writing new rfc 2993.
We will however take your suggestion onboard in the working document
for the -01 compilation
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.
I added note for our further discussion.
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.
This sounds like the work that Jordi wants to achieve with his
distributed security
draft? I've added note that we need to discus this little broader in the
context of NAP.
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.
ok, i added note in the working document.
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..
agree
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).
ok
==> 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..
that was indeed our motivation to include it
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.
That will happen automatically as we currently plan to place the 2.6 in a
new case-study
chapter.
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?
This refers to physical connections. I can't see how to identify a
physical
link any better in a simple way. maybe the terminology 'physical
interconnection' can
be used
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 ?
makes sense.
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..)
ok
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..
I added note on this in the working document for -01
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.
I proposed following text based on your comment:
<snip>
<t>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. This approach also
simplifies the multicast
model considerably, making it easier to understand and
deploy </t>
<end snip>
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..
Added the note in the working document
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..
ack. We will make it more clear.
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.
Will look deeper into it.
I always believed that a router falls back to CPU switching from the
moment an option is set in the IPv4 header as the router doesn't
know
which options were used. This is one of the (many) reasons
ISP don't allow this through the network as it eats-up CPU cycles
and makes forwarding these packets slow.
but as you seem so certain i will double-check.
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"?
ok :-)
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/
ok
which member of a family, which
customer of an Internet caf?, or
==> s/caf[weird character here]/cafe/
ok
of NAT to avoid the ongoing
operational complexity of overlapping
addresses
==> add "." at the end.
ok
An example of a potential rule
could be:
==> s/rule/set of firewall rules/
ok
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?
ok
4.5 independent control of addressing in
a private network
==> s/in/In/
ok
route-injection could be done
based on ::/128 host-routes to each
==> remove "::".
ok
4.6.2 small private networks
==> s/small/Small/
ok
Operation Center (NOC) and are
using either a dial-up connection or
broadband access..
==> remove the other "."
ok
o IPv6 has the IPsec
technology embedded directly embedded into the
==> kill extra "embedded"
ok
Many thanks for the review and the information provided.
Many of the topics will be included/considered in our working draft for
the -01 release.
Enjoy the weekend,
G/