[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Review: draft-ietf-v6ops-nap-01.txt
Hi Tim,
On Fri, 19 Aug 2005 08:16:11 +0100
Tim Chown <tjc@ecs.soton.ac.uk> wrote:
> On Fri, Aug 19, 2005 at 10:05:38AM +0300, Eric Klein wrote:
> >
<snip>
> One of the things that worries me about this draft is the suggestion to use
> host based routing for topology hiding, or indeed permanent use of MIPv6,
> as neither seems particularly attractive just to serve that purpose.
>
Out of curiosity, are you able to elaborate ? Is it scalability,
tunneling overheads, administrative complexity ? I'm interested because
I thought of another way the IPv6 topology could be hidden over the
weekend, using IPv4, and am interested in any criteria that could be
used to judge its value.
I'd be interested in yours and other people's opinions of the following
method of topology hiding. It was mainly inspired by the way 6to4 works.
I'm willing to spend more time on it if it is worth while, I'd prefer to
not spend more time on it if it isn't :-)
- within the network topology that would be covered by the IPv6 /48,
deploy IPv4, using RFC1918 addressing, restricting the IPv4 node
addresses to the last 2 octets of the IPv4 address space eg. address the
subnets / nodes from out of e.g. 10.0/16.
- make sure the 10.0/16 address space is not visible to the Internet ie.
don't deploy NAT, no need to even have IPv4 forwarding across the
boundary between the Internet and the /48 boundary.
- The IPv6 nodes within the /48 would use the last two octets of their
IPv4 address as the subnet portion of the IPv6 address ie. the field
between /48 to /64.
- To obscure the IPv4 topology, the last two octets of the IPv4 address
would be encoded using a light weight symmetric cipher.
- IPv6 packets travelling within the domain are delivered encapsulated
in IPv4. The destination and/or source addresses of IPv4 addresses of these
packets is the deciphered value of the IPv6 subnet field, prefixed by
the RFC1918 chosen /16 prefix e.g. 10.0/16.
This is effectively treating IPv4 operating within the IPv6 /48 domain
as a NBMA subnet, encoding the layer 2 addresses in the subnet field of
the IPv6 addresses, and then obscuring them such that outside the local
IPv6 /48 domain the "layer 2" IPv4 topology and the IPv6 topology is
hidden.
A normal, global /48 would be used, so it would not be possible to
determine on face value if this technique was being used, unlike the
2002::/16 6to4 prefix. Recording IPv6 addresses over a time period could
be used to see if the IPv6 "subnets" are random, and although that might
indicate this technique was being used, it still doesn't disclose the
either the IPv4 and IPv6 topology, as nodes that are adjacent in IPv4
will still have significanly different IPv6 subnet portions, due to the
cipher.
Privacy addresses can be enabled, and this may also futher enhance the
obfuscation. It would appear that multiple hosts are attached to the
same subnet, when in reality only one is. Admittedly it would be
possible to identify this same host, for example, if some identifyable
service is available on it e.g. a web server with a specific web page.
However, this possibly isn't a problem anyway, and certainly isn't one
that is attempting to be solved by topology hiding.
A further enhancement could be to use IKE between the nodes and the edge
router(s) and have the light weight cipher key change over time. Then,
to external nodes outside the /48, the nodes would also appear to be
moving around over time, as the subnet portion would be changing even
though the underlying IPv4 address isn't.
This solution does restrict the number of IPv6 nodes that can be
supported within a /48 to the efficiency of the IPv4 addressing plan. If
non-topology hidden IPv6 hosts need to exist, or more IPv6 nodes need to
be supported than one IPv4 /16 can support, additional IPv6 /48s could
be used. This is probably a drawback, as it would increase the
consumption of /48s at a rate above what has been projected by documents
such as RFC3177.
This certainly isn't a perfect solution, however, it could be an
improvement over some of the other techniques mentioned.
Any thoughts ?
Thanks,
Mark.