Subject: [Architecture-discuss] IP virtualisation

From: Leslie Daigle <[email-masked]>
Date: Wed, 26 Oct 2005 17:50:55 -0400

[I'm forwarding Pekka Nikander's suggested topic-starters, one at a
time, to see if we can get some "discuss" going, about "architecture".
  -- LLD]

[Pekka wrote:]
2. IP virtualisation

In the recent discussion w.r.t. tunnelling at the Internet Area list,  a 
clear
need for virtualisation came up.  While tunnelling with clear
implementation-level virtualisation boundaries is clearly one viable  way to
implement virtual IP networks on the top of the "real" IP 
infrastructure, this
issue seems to warrant some deeper digging.   Tunnelling has well known
drawbacks, and we may want to ask what  would be the alternatives.  In 
order to
understand alternatives, if  any, we need to understand better the 
requirements
behind IP  virtualisation, or what people *really* want to achieve with 
it.  Is
it merely ease of configuration, or reduced operational costs?  If  so, 
could
there be other architectural ways of achieving the same  ease or perhaps 
even
larger capital and operational savings?  Some  people have been 
promoting adding
"realms" as a first class service  to the base IP.  Would that provide an
alternative solution?

While the mobility and multi-homing discussion seems to more circle  around
evaluating existing proposals and trying to navigate towards  more unified
solutions, here we seem to lack genuine alternatives and  deep 
understanding of
the real problem domain.

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Aaron Falk <[email-masked]>
Date: Thu, 27 Oct 2005 10:05:24 -0700

--On October 26, 2005 5:50:55 PM -0400 Leslie Daigle 
<[email-masked]> wrote:
>
> [Pekka wrote:]
> Tunnelling has well known
> drawbacks, and we may want to ask what  would be the alternatives.

Pekka-

In the interest of motivating the need for a fresh look at IP 
virtualization, would you mind summarizing what you see as the 'well-known 
drawbacks' of tunneling? Folks on this list may not have been part of the 
Internet area discussion on the topic and, even so, I don't recall coming 
away from it with a clear understanding of tunneling's shortcomings.

regards,

--aaron

---

From: Tony Li <[email-masked]>
Date: Thu, 27 Oct 2005 10:38:01 -0700

> virtualization, would you mind summarizing what you see as the  
> 'well-known drawbacks' of tunneling? Folks on this list may not  
> have been part of the Internet area discussion on the topic and,  
> even so, I don't recall coming away from it with a clear  
> understanding of tunneling's shortcomings.

Issues:

1) MTU - Tunneling overhead may break the link level PMTU.  Does the  
tunnel fragment and reassemble?

2) Overhead - The tunnel always incurs some level of additional  
wrapper as overhead and thus consumes bandwidth.

3) Transparency - Tunneling creates an issue for firewalls, as  
unintended traffic can be tunneled around the policy control points.

Speaking architecturally, tunneling is necessarily a second class  
solution to any problem.  That's not to say that it's without value,  
rather that when we have to resort to tunneling, we're kludging and  
hacking and thus should be thinking about how to perform whatever  
functionality we're trying to achieve in a native manner, if at all  
possible.

Tony

p.s. Please refer to RFC 1701 before flaming me.  ;-)

---

From: Dan McDonald <[email-masked]>
Date: Thu, 27 Oct 2005 13:51:56 -0400

> unintended traffic can be tunneled around the policy control points.

I will admit my bias up front:  IMHO IP-in-IP tunnels should be just another
link layer choice for IP, and should look-and-feel just like any other
network interface.

My own experiences with your tunneling issues are (given my biases):

1 -- A network interface of type IP-in-IP reflects back a (link - overhead)
     MTU.  It can even do this dynamically per-destination using existing
     PathMTU discovery techniques.  (You may lose that first large packet
     when the lower IP discovers something new, but hey, it's IP.)

2 -- Yes, that is always a bandwidth issue.  It's also a latency issue,
     especially if any additional transformations (<cough> IPsec <cough>) are
     performed on the packet.

3 -- If your firewall allows a class of traffic to pass, there is no
     (practical) way to control how users {,ab}use that class of traffic.

Speaking of firewalls...

> functionality we're trying to achieve in a native manner, if at all  

I believe performing:

	s/tunneling/firewalling/g

to your above paragraph yields additional valuable input for this list.  :)

Dan

---

From: Scott W Brim <[email-masked]>
Date: Thu, 27 Oct 2005 14:15:25 -0400

> functionality we're trying to achieve in a native manner, if at all  

I used to think exactly that before you yourself convinced me
otherwise.

We can have One Universal Solution to all problems, but in order to
handle all needs, that OUS can become very complex (a VCOUS).  Your
system can be simpler in the aggregate, and significantly more robust,
if you allow two parallel solutions -- in this case one for the
general Internet case and another for special cases.  For example,
consider QoS-based routing and the superstructure for EF, versus using
tunnels for the traffic that needs special treatment.

swb

---

From: Melinda Shore <[email-masked]>
Date: Thu, 27 Oct 2005 14:50:34 -0400

> unintended traffic can be tunneled around the policy control points.

I'm a little sympathetic to that argument but not a lot sympathetic.
I think what you're describing is a more general problem, that the
destination address in the IP header no longer represents the
endpoint and various things flow from that when we're using the
address as basically a proxy for identity and therefore for
policy enforcements of various types (including routing).  However,
saying that it's a problem because the address is concealed from
the firewall is an argument that can be used against encryption, as
well, and in fact has been used against encryption.  But it seems
to me that there's another question here about how much information
needs to be exposed for basic network functions to work.

Melinda

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 27 Oct 2005 11:51:55 -0700

Just joined the list. Sorry for coming in late.

>> I used to think exactly that before you yourself convinced me

    Since tunneling allows transparency in the core, that would seem to be
    a fairly robust architectural principle with lots of value. 

    Or would most think the transparency is a bug and not a feature?

    And I would argue a lot of application value has come to us over the years
    because of "application-level tunneling" where if the infrastructure
    would have had to be upgraded to do these things, we may have less cool
    new apps these days.

Dino

---

From: Tony Li <[email-masked]>
Date: Thu, 27 Oct 2005 12:27:07 -0700

Ok, apparently I need to clarify quite a bit.

I'm *NOT* dumping on tunneling.  I'm not trying to shoot it, kill it  
or maim it in any way.

I *am* trying to get across the perspective that it is not 100%  
transparent and is always necessarily going to be a second-class  
citizen in an architecture.  If we do want a clean, straightforward  
architecture, we should retain tunneling for our exceptions, but it  
should never be our primary mechanism.

Hope that's more clear,
Tony

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 27 Oct 2005 16:59:38 -0400

> unintended traffic can be tunneled around the policy control points.

And firewalls will most likely always be on the losing end of this
battle.

For the most part, any pair of consenting parties separated by a "toll
booth" firewall can invent a tunneling protocol which looks like
innocuous traffic, allowing them to exchange arbitrary traffic
regardless of the policy enforced by the firewall.

					- Bill

---

From: Aaron Falk <[email-masked]>
Date: Thu, 27 Oct 2005 18:26:45 -0700

Hi Tony-

> tunnel fragment and reassemble?

This sounds like a bug in tunnels (or perhaps MTU) as they currently exist. 
Does Path MTU Discovery fix this?

>
> 2) Overhead - The tunnel always incurs some level of additional  wrapper
> as overhead and thus consumes bandwidth.

I'm not very sympathetic to bandwidth as an architectural driver.  The 
Internet was not intended to be efficient as much as it was intended to be 
general.  As network capacity continues to climb, I suggest that designing 
for efficiency continues to be a low priority.

> unintended traffic can be tunneled around the policy control points.

Deep packet inspection on unencrypted tunnels seems pretty easy -- or at 
least, not much harder than without tunnels.  I think your (valid) concern 
is with encryption.  I propose we set that aside for a (potential, future) 
privacy vs. protection discussion on the tussle that motivates firewalls 
and encryption.

--aaron

---

From: Joe Touch <[email-masked]>
Date: Thu, 27 Oct 2005 21:12:25 -0700

Hi, Tony,

> tunnel fragment and reassemble?

Whether a tunnel does this or not is the same as whether a link does
this or not. Consider ATM ;-(  There are cases where this should
propagate back to the endpoints, and cases where reassembly at the
destination should mask it.

Ultimately, tunneling exposed assumptions in IP as deployed, not as
designed. This happens - there were similar assumptions about NFS and
the typical LAN bandwidth that 100Mbps blew away, and pipelining had to
be incorporated. IMO, this is an opportunity to fix the erroneous
assumption that the host interface gives you the final word on a good MTU.

As Aaron hinted, newer versions of path MTU discovery should accomodate
tunnels fine.

> as overhead and thus consumes bandwidth.

The primary impact is in payload size; the headers can be compressed a
bit. This may consume bandwidth, but how much can vary. However, there
are other cases where we have traded efficiency for flexibility. Virtual
memory does two lookups per address. But we accept the overhead because
of the flexibility. I believe that virtual networking (based on tunnels)
has similar benefits, with similar overheads.

> unintended traffic can be tunneled around the policy control points.

Tunneling around policy control points is a feature, not a bug. It is
why tunneling is succeeding as a way to deploy new protocols
incrementally, and a way to experiment with protocols at the application
layer.

Firewalls make the assumption that there is information available at the
network layer that can be used to limit traffic, and that routing will
direct traffic towards the firewall. Both of these assumptions are the
real bug - as Aaron noted, encryption defeats packet inspection moreso
than tunneling anyway.

Joe

---

From: David Barak <[email-masked]>
Date: Fri, 28 Oct 2005 04:10:14 -0700 (PDT)

> >     Since tunneling allows transparency in the
> core, that would  
> > seem to be
> >     And I would argue a lot of application value
> has come to us  
> > over the years
> >     because of "application-level tunneling" where
> if the  
> > infrastructure
> >     would have had to be upgraded to do these
> things, we may have  
> > less cool
> >     new apps these days.
> >
> > Dino
> >

I think that y'all are talking past each other.  Dino,
what you're referring to as
"application-level-tunneling" is basically building
persistent connections between hosts at layer 7 (think
SSL).  What Tony is talking about is bypassing layer 3
at layer 3 (as in a GRE tunnel), and supporting all
layers of service through this.  

When I think of tunnelling, I think more of Tony's
definition than Dino's - that is, Tony's description
is more of a network service: something which supports
not only the two virtually connected host/routers, but
also serve as a virtual network for other hosts, which
are transparently redirected.

David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com

__________________________________ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 28 Oct 2005 09:17:31 -0400

Seems to me we could clarify the architectural role of firewalls.  We 
need to line up what information is available, where, and what 
information is needed to do the job of protecting hosts.  There will be 
a division of labour between network-based firewalls and host-based 
firewalls.  What new information does the network have to pass on to 
hosts so their firewalls can do their jobs?

> Hi, Tony,
...

> ------------------------------------------------------------------------
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Oct 2005 13:01:21 -0700

Tom-PT Taylor wrote:
> Seems to me we could clarify the architectural role of firewalls.

They keep out 'traffic I don't want' - but 'don't want' defined by
application-layer content as well as endpoint context in ways that a
firewall can't always access (by definition, if it's a transit or not
authorized with copies of decryption keys).

> We
> information is needed to do the job of protecting hosts. 

The trouble is as much whether the endpoint is willing to give the
needed information, and whether doing so compromises security or not.

> There will be

IMO, 'what new information' = everything. For any given traffic, the
information may include both all the data in the traffic as well as all
the information in the host (keys, context, etc.).

Although firewalls could be more manageable, in the extreme they can't
be complete or architecturally well-defined, as a result.

Joe

---

From: Pekka Savola <[email-masked]>
Date: Sat, 29 Oct 2005 09:52:15 +0300 (EEST)

> Does Path MTU Discovery fix this?

PMTUD has its limits.

I've studied the operational approaches when you need to tunnel inside 
the network (and not just from a host to host, which is simpler), see:

http://www.ietf.org/internet-drafts/draft-savola-mtufrag-network-tunneling-05.txt

Feedback is appreciated.

NB: I had very long discussion with Joe Touch on int-area list about 
whether it's appropriate to describe implementations which don't honor 
DF-bit in a way I've done; let's not revisit it here.  Have a look at 
his opinion at: 
http://www1.ietf.org/mail-archive/web/int-area/current/msg00103.html 
and the follow-up message.

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

---

From: Bill Sommerfeld <[email-masked]>
Date: Sat, 29 Oct 2005 08:20:11 -0400

> > Does Path MTU Discovery fix this?

You're far too kind.

PMTUD based on feedback from ICMP Fragmentation Needed messages is
essentially unusable in the as-built Internet, thanks in part to
so-called "security auditors" who view all ICMP as potentially toxic. 
ICMP Black holes are everywhere.