Subject: Re: IPv6 Network Architecture Protection draft

From: Pekka Savola <[email-masked]>
Date: Mon, 8 Nov 2004 14:31:35 +0200 (EET)

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