Subject: Re: IPv6 Network Architecture Protection draft

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Fri, 19 Nov 2004 14:49:41 +0100

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/

---

From: Pekka Savola <[email-masked]>
Date: Wed, 24 Nov 2004 17:06:13 +0200 (EET)

Hi,

(co-chair hat on)

I'd urge the WG participants to read and comment on this draft; when 
the revised version gets out, the chairs will probably ask whether the 
WG wants to adopt the document.  It would be good to review it now...

(hat off)

Long mails take a while to digest.. sorry.  Inline...
(I've snipped the text we seem to be in pretty clear agreement about.)

> would like to avoid writing new rfc 2993.

OK.

> 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.

Well, there are two approaches here:

  1) "MIDCOM"-like pinholing (which could happen independent of 
firewalling), i.e., how those v6 firewalls get through the stateful 
firewall if the users/admins want to let them, or

  2) Fully distributed security, hosts taking care of (at least 
certain) aspects, like Jordi has been proposing.

> link any better in a simple way. maybe the terminology 'physical 

Ack.

>    <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

OK.

> but as you seem so certain i will double-check.

I guess there may be routing platforms which perform like that with IP 
options on packets they're forwarding, but I doubt it.. that would be 
way too easy way to DoS the system.

However, it undoubtedly happens on many systems that if the router 
would be used as a destination address on a packet with IP option + 
source routing, the source routing would be done on the CPU.  Which is 
one reason many have disabled it (in addition to there not being many 
legitimate uses for it in the first place).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings