Subject: The future of connectivity, or how globally unique site locals may become almost obsolete.

From: Mark Smith <[email-masked]>
Date: 28 Nov 2002 19:33:00 +1100

Hi All,

I've put together the following email as a bit of a thought provoker on
how organisations may connect themselves together in the future, and how
that may effect globally unique site-local use.

Note that I haven't thought out a lot of it thoroughly - it may all be
totally bogus, or may be a totally wrong view of the future.

|1|. IPsec is free in IPv6, why not use it ?

At a certain point in time, IPv6 and the mandatory IPsec component will
become prevalent.

Presuming most organisations have a public Internet connection, they
will be inclined to create IPsec tunnels between each of their
geographical sites, rather than commissioning private circuits.

As long as the IPsec tunnel over the Internet delivers good enough QOS,
organisations will prefer them, as they are far cheaper than dedicated
private circuits, even if that IPsec cost included of upping their
Internet connectivity bandwidth.

An organisation may end up with a large number of point-to-point
tunnels, inter-connecting their geographical sites, in any number of
arbitrary topologies. However, as the cost of a tunnel is only generally
only configuration time, a full mesh tunnel topology is likely to be
common.

Manual tunnel configuration isn't scalable, but automated tools will be
developed to provision these large IPv6 IPsec tunnel based VPNs (they
already exist for IPv4 based ipsec).

|2|. Overlay networks don't scale very well

The problem with overlay or point to point IPsec tunnel VPNs is they
cause IGP scaling problems.

Because each router in the VPN is now directly connected to the others,
running an IGP over the top of it means that each router now has a large
number of IGP neighbors (N-1 in a full mesh topology). There are limits
on how many IGP peers a router can cope with.

This is not a new problem, apparently it has been suffered with IP over
ATM based networks [1].

One way to solve this IGP scaling problem is to use traditional IGP
scaling techniques - dividing the IGP into areas, introduce ASs and an
EGP etc.

|3|. A better solution to overlay network scalability is to flatten the
network.

To avoid the IPsec tunnel scalability problem, you need to get rid of
the point-to-point tunnels, so that the routers at the edge of the VPN
(or encryption domain) are not direct neighbors.

This is similar to what MPLS has done for IP over ATM networks [2].

The routers that are at the edge of the VPN would now peer directly and
equally with the upstream Internet gateway via an IGP or EGP.

However, the consequence of this is that you cannot use any form of
private addressing within the tunnel, as tunnels doesn't actually exist
anymore.

To still create a virtual network, the local VPN gateway would still
need to be able to send traffic to a specific, remote VPN gateway. It
also needs to be able to associate destinations with a IPsec Security
Association.

I imagine this could be achieved by using IPsec in transport mode, in
combination with a loose source route extension header, listing the
global IP address of the remote VPN gateway in the IPv6 header, and the
first hop of the loose source route being the actual destination of the
packet.

For those familiar with IPsec terminology, I would describe this as a 
"bump-in-the-wire transport mode pseudo-tunnel".

|4|. How does this bump-in-the-wire transport mode pseudo-tunnel VPN
effect our proposed globally unique site-locals ?

Now that the VPN gateway is peering directly with the Internet gateway
via an IGP or EGP, rather than the other VPN gateways, it is not allowed
to advertise site-local prefixes to the Internet gateway.

Also, similar to BCP 38 - "Network Ingress Filtering: Defeating Denial
of Service Attacks which employ IP Source Address Spoofing", ISPs are
likely to drop traffic with site-local source addresses.

Which means that all remote communications, to either Internet or VPN
destinations, has to use global addresses.

Under the above model, GUSLs are still useful, but only when two
organisations directly connect or directly merge their physical
infrastructure. This may be a rare occurrence, unless they are in
adjacent buildings, and they pull an ethernet through a hole in the
wall.

Bringing up an IPsec tunnel (either todays type of IPsec tunnel, or the
above psuedo tunnel model) is likely to be easier, and more popular.

|5|. Exceptions, caveats and other notes

5.1 The above assumes that organisations don't immediately deploy true
end-to-end, opportunistic transport mode IPsec between nodes. That being
said, if they did deploy end-to-end opportunistic transport mode IPsec,
they still can't use site-local addressing when communicating over the
Internet.

5.2 I've been meaning to look into whether the ipsec working group have
done any work on anything similar to my "bump-in-the-wire transport mode
pseudo tunnle" ipsec model but haven't got around to it. I've been
intending bring this up in that working group if they haven't. I've been
a bit busy recently organising an interstate move unfortunately.

5.3 With today's IPsec tunnel model, I would prefer not to have the
restriction of not being able to use GUSLs over my IPsec tunnels.

Why do we have this mind set that a site is restricted to a geographical
location ? This is the only instance I know of where a logical boundary
has been defined by the ietf as having a geographical size. OSPF Areas
don't, BGP ASs don't, arguably even link locals don't - you can build
some really big ethernet segments - I know of at least one vendor who
sell GBICs that can drive a 90 Kilometer long piece of single mode
fibre. Surely 90 kilometer's would be bigger than a "site".

I would prefer to be able to define the size of my "site", and include
the "insides" of my IPsec tunnels within that site.

5.4 On the other hand, with my "bump-in-the-wire transport mode pseudo
tunnel" ipsec model, there are now technical reasons not to use GUSLs
over VPNs.

|6|. References

[1] and [2] - MPLS: Technology and Applications, by Bruce S. Davie,
Yakov Rekhter - can't look up the page numbers, my copy is packed in a
box - see point 5.2 above :-)

Any thoughts ?

Thanks,
Mark.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 29 Nov 2002 13:27:23 +0200

Mark,

> they still can't use site-local addressing when communicating over the

Well, if the site-local addresses are globally unique, it
actually *is* possible to use them internally in the hosts
as you communicate over the Internet using a end-to-end
IPsec tunnel.  You just need some more intelligence and
a translation that is very similar to Bellovin's host NAT.
In such a case the site-local globally unique addresses would
act as end-point identifiers, and they would never be seen
in the wire.  The hosts would themselves translate them into
"normal" IP addresses as a part of IPsec processing.  The
benefit is that the static global "addresses" protect the
applications form address changes caused by mobility,
multi-homing and renumbering.

 From one point of view, that's the essense of HIP backward
compatibility mode.  You use global, statistically unique
identifiers instead of IP addresses at the application layer,
map these to IPsec SAs, and then use normal IP addresses
when communicating over the internet.

   Host ID  ->  SA  ->  current IP address(es) of the peer

The details are in Bob Moskowitz's HIP drafts.

> a bit busy recently organising an interstate move unfortunately.

The HIP people have been discussing a "HIP gateway" which
would be functionally more-or-less identical to your
bump-in-the-wire pseudo-tunnel.  Not quite, but close.
Furthermore, if we changed the HIP specs so that there
was an SL/GUPI compatible wire format for Host Identifiers,
the "HIP gateway" would become even close to your
bump-in-the-wire pseudo-tunnel, though with an interesting
twist....

--Pekka Nikander