Subject: [Int-area] new I-D available - tunnel issues

From: Joe Touch <[email-masked]>
Date: Mon, 07 Jul 2008 21:46:52 -0700

Hi, all,

I and Mark Townsley recently completed an I-D summarizing our 
presentation from the last IETF on tunnel issues.

Comments welcome, of course. FYI, a related document on the IPv4 ID will 
be noted to this list shortly.

Joe and Mark

-------------------------------------
Filename:	 draft-touch-intarea-tunnels
Revision:	 00
Title:		 Tunnels in the Internet Architecture
Creation_date:	 2008-07-07
WG ID:		 Independent Submission
Number_of_pages: 21
http://www.ietf.org/internet-drafts/draft-touch-intarea-tunnels-00.txt

Abstract:
This document discusses the role of tunnels in the Internet
architecture. It explains their relationship to existing protocol
layers, and the challenges in supporting tunneling.

_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: "John.zhao" <[email-masked]>
Date: Tue, 15 Jul 2008 11:25:45 +0800

Hi,Joe and Mark

	May I make sure about the scope of this draft? I want to make sure
if it include the discussion related to those MIP also? The type of tunnel
here listed includes IP in IP, IPsec and IPv4 in IPv6 later. So if the
context also cover those scenario in MIP or not?

	Best Rgds,
Thanks

John.zhao

> Comments welcome, of course. FYI, a related document on the 
> IPv4 ID will be noted to this list shortly.
> 
> Joe and Mark
> 
> architecture. It explains their relationship to existing 
> protocol layers, and the challenges in supporting tunneling.
> 
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Jul 2008 20:34:37 -0700

> context also cover those scenario in MIP or not?

I believe the document intends to cover the use of tunnels wherever they 
occur in the Internet; that includes MIP, though it's just MIP's use of 
tunnels that would be covered (not the rest of MIP, e.g.).

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 15 Jul 2008 07:09:56 -0700

John.zhao wrote:
> Hi, Joe
> 
> 	Thanks. So it is can be learnt that GRE,Mini Encapsulation seem also
> can be discussed here, right?

We intend to include broader discussion of other encapsulations in 
future versions; this was intended to be an initial attempt, and 
omissions were not intentional.

We've already received suggestions to include GRE. Can you please 
provide info on Mini Encapsulation, though?

Note that we've also had a suggestion to include MPLS. MPLS is more like 
a conventional L2 layer, which not only encapsulates and decapsulates, 
but also adds new hop-by-hop forwarding. I think it's important to 
distinguish tunneling from L2 or other conventional protocol layering, 
and I believe this is easy as follows:

    tunnels:
	- encaps/decaps of new headers at the endpoints
	- NO new mechanism between the endpoints

    other protocol layering
	- encaps/decaps of new headers at the endpoints
	- new mechanism between the endpoints that may or may
	not rewrite thes headers

Joe

---

From: "John.zhao" <[email-masked]>
Date: Tue, 15 Jul 2008 11:41:36 +0800

Hi, Joe

	Best Rgds,
Thanks,

John.zhao

> 
> 
> John.zhao wrote:
> > Hi,Joe and Mark
> > 
> > 	May I make sure about the scope of this draft? I want 
> to make sure if 
> > it include the discussion related to those MIP also? The type of 
> > tunnel here listed includes IP in IP, IPsec and IPv4 in 
> IPv6 later. So 
> > if the context also cover those scenario in MIP or not?
> 
> I believe the document intends to cover the use of tunnels 
> wherever they occur in the Internet; that includes MIP, 
> though it's just MIP's use of tunnels that would be covered 
> (not the rest of MIP, e.g.).
> 
> Joe
> 
> 
> > 
> > 	Best Rgds,
> > Thanks
> > 
> > John.zhao
> > 
> >> Hi, all,
> >>

---

From: Scott Brim <[email-masked]>
Date: Tue, 15 Jul 2008 21:19:19 -0700

>     - new mechanism between the endpoints that may or may

These sound okay but I would like to see "tunnels" split into two: one 
type where there is a setup phase and sharing state between the 
endpoints, and another where there is no shared state: an endpoint can 
encapsulate a packet, toss it to another endpoint, and the receiving 
endpoint will decapsulate it and do the right thing.  There are three 
qualitatively different levels in the setup mechanism and where shared 
state resides.

Scott

---

From: Mark Townsley <[email-masked]>
Date: Fri, 18 Jul 2008 17:11:01 +0200

Scott Brim wrote:
>> Note that we've also had a suggestion to include MPLS. MPLS is more 
>> like a conventional L2 layer, which not only encapsulates and 
>> decapsulates, but also adds new hop-by-hop forwarding. I think it's 
>> important to distinguish tunneling from L2 or other conventional 
>> protocol layering, and I believe this is easy as follows:
>>
>>    tunnels:
I don't think a case where an operational tunnel has absolutely no 
shared state exists. I say this because I will argue that the simple 
fact that one endpoint knows (i.e., is configured) that a packet 
encapsulated in a certain way will be properly decapsulated at the 
tunnel destination the packet is sent to is, alone, a kind of shared 
state. In practice, most tunneling setups, even ones with the simplest 
of CLI to set them up, end up with coordinated options configured on 
both sides of the tunnels, filters to allow packets only from specific 
destinations, etc.

So, I'm afraid this would be like trying to characterize something as 
black and white, where in reality there are shades of gray.

What perhaps you are getting at though is whether you typically see a 
control protocol between endpoints in order to operate the tunnel, or 
whether the tunnel itself is "dynamic" in nature. Even here though the 
lines can blur - e.g., there are often modes for a given tunnel type 
that is typically setup with a control plane to be setup with static 
config and vice versa (e.g., statically configured MPLS LSPs, control 
protocols for GRE). At best, I think we could explore the different 
"qualitatively different levels" you refer to, and discuss the cases 
where a given tunneling protocol operates in one mode vs. the other. Can 
you provide more information on what you were referring to here?

- Mark

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 18 Jul 2008 18:45:13 +0200

Thanks for this draft.

FRom a mobility (mip-based) standpoint.

-network mobility (the mip-based nemo type) may easily involve several
  levelsof encapsulation, think networks moving into networks, this
  exacerbating the fragmentation and mtu effects and pmtu necessity.
-'stalemate' situations occured in a lab with two moving networks,
  described in appendix B of rfc4888, due to the impossibility of setting
  up the mip tunnels, because of the way things moved.  Never noticed
  that in a non-lab deployment though.
-it's good to note when tunnels are _not_ as bad as feared.  For
  example, contrary to some belief, a single encapsulation to HA
  instead of straight communication does not slow down the application,
  nor does it consume excessive bandwidth nor does it slow the handovers.
-qos: there's currently no means to perpetrate the qos decision of a
  flow (tc/flow label) beyond the HA.  This is potentially an issue with
  end-to-end architectures: a mobile end would like to maintain the tc/fl
  decisions it makes  beyond the HA (the one encapsulating/decapsulating
  its traffic when away from home), and not let the HA make this
  decision.

Virtual interfaces implementing tunnels often have a problem with
implementing link-layer multicast.  They're interfaces, but they're
virtual.  What they lack from real ones is link-layer multicast.  Given
how much IPv6 relies on link-layer multicast often protocols like ND,
DHCPv6, ICMPv6 and MIP6 are quirky implementations over tunnels.

Beyond that, there's a very much fundamental problem with tunnels, I
mean the shift and leap of semantics, overlays.  I'm sure some of this
is at the origin of this draft, but I'm not sure whether the immediate
effects of this problem are listed.  An immediate effect is applicable
to MIP as well as to the popular VPN usage: should an end's default
route point to the tunnel or to the naked first-hop router?

Just some thoughts...

Alex

Joe Touch wrote:
> Comments welcome, of course. FYI, a related document on the IPv4 ID 
> will be noted to this list shortly.
> 
> Joe and Mark
> 
> ------------------------------------- Filename: 
> draft-touch-intarea-tunnels Revision:     00 Title:         Tunnels 
> in the Internet Architecture Creation_date:     2008-07-07 WG ID: 
> Independent Submission Number_of_pages: 21 
> Abstract: This document discusses the role of tunnels in the Internet
> ------------------------------------------------------------------------
> 
> 
> 
> 
> _______________________________________________ Int-area mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/int-area

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Joe Touch <[email-masked]>
Date: Fri, 18 Jul 2008 09:46:20 -0700

Mark Townsley wrote:
...
|> These sound okay but I would like to see "tunnels" split into two: one
|> type where there is a setup phase and sharing state between the
|> endpoints, and another where there is no shared state: an endpoint can
|> encapsulate a packet, toss it to another endpoint, and the receiving
|> endpoint will decapsulate it and do the right thing.  There are three
|> qualitatively different levels in the setup mechanism and where shared
|> state resides.
...
| So, I'm afraid this would be like trying to characterize something as
| black and white, where in reality there are shades of gray.

There are basically known variations of state; these aren't new to tunnels:

	- preshared, static
	- negotiated, hard
	- negotiated, soft

Another dimension is who is involved in state coordination:

	- third party informs both ends (dual push)
	- third party triggers one end, and that end coordinates
	with the other end (push, negotiate)
	- third party triggers one end, and the other end fetches
	state when needed (push/pull)

| What perhaps you are getting at though is whether you typically see a
| control protocol between endpoints in order to operate the tunnel, or
| whether the tunnel itself is "dynamic" in nature.

Is that covered by the above "who is involved" list?

Joe

---

From: Scott Brim <[email-masked]>
Date: Sat, 19 Jul 2008 09:20:26 -0400

> Is that covered by the above "who is involved" list?

What I was getting at was how the egress end sees things.  If it knows 
who is going to be sending it traffic that's one case.  If it doesn't 
know, and is able to receive and process encapsulated packets from 
anywhere, that's quite different.  So it's not whether there is state or 
not, nor is it about who installs the state ... it's whether there is 
state at the egress that is specific to an ingress point.

Scott

---

From: "John.zhao" <[email-masked]>
Date: Mon, 21 Jul 2008 17:51:24 +0800

Hi,Joe

> We intend to include broader discussion of other 
> encapsulations in future versions; this was intended to be an 
> initial attempt, and omissions were not intentional.
> 
> We've already received suggestions to include GRE. Can you 
> please provide info on Mini Encapsulation, though?

Fine to me.

> 
> Note that we've also had a suggestion to include MPLS. MPLS 
> is more like a conventional L2 layer, which not only 
> encapsulates and decapsulates, but also adds new hop-by-hop 
> forwarding. I think it's important to distinguish tunneling 
> from L2 or other conventional protocol layering, and I 
> believe this is easy as follows:
> 
>     tunnels:

So which kind of info you would like to expect to ? Also focus on problem
statement?

John.zhao

---

From: Pekka Savola <[email-masked]>
Date: Mon, 21 Jul 2008 17:49:01 +0300 (EEST)

> There are basically known variations of state; these aren't new to tunnels:

I'm not sure if this falls under "preshared, static", but 6to4 (RFC 
3056) uses a mapping technique to discern the endpoint.  I can't find 
any form of state anywhere in that tunneling mechanism.

>        state when needed (push/pull)

The last bullet might include this scenario but IMHO it should be a 
bullet item of its own:

As an example, in RFC 4023 (MPLS in GRE or IP), one way to decapsulate 
said packets was to just take everything you get at input, strip the 
headers, and forward packets out.  Some state (e.g., communicated 
using BGP, LDP, or some other protocol) is needed at the encapsulating 
router.  Decapsulating router requires no state whatsoever.  Where 
does this belong?

Interesting questions to ask wrt. each tunneling technique are at 
least:
  - does this require state at the decapsulator?  If so, what?
  - what are the security implications of state maintenance or lack 
thereof?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Joe Touch <[email-masked]>
Date: Mon, 21 Jul 2008 08:04:57 -0700

Pekka Savola wrote:
...
|> There are basically known variations of state; these aren't new to
|> tunnels:
|>
|>     - preshared, static
|>     - negotiated, hard
|>     - negotiated, soft
|
| I'm not sure if this falls under "preshared, static", but 6to4 (RFC
| 3056) uses a mapping technique to discern the endpoint.  I can't find
| any form of state anywhere in that tunneling mechanism.

The "state" is sharing the mapping algorithm; that's effectively an
on-demand computed table that both ends share.

|> Another dimension is who is involved in state coordination:
|>
|>        - third party informs both ends (dual push)
|>        - third party triggers one end, and that end coordinates
|>        with the other end (push, negotiate)
|>        - third party triggers one end, and the other end fetches
|>        state when needed (push/pull)
|
| The last bullet might include this scenario but IMHO it should be a
| bullet item of its own:
|
| As an example, in RFC 4023 (MPLS in GRE or IP), one way to decapsulate
| said packets was to just take everything you get at input, strip the
| headers, and forward packets out.  Some state (e.g., communicated using
| BGP, LDP, or some other protocol) is needed at the encapsulating
| router.  Decapsulating router requires no state whatsoever.  Where does
| this belong?

"decaps everything" is never quite that; it only decapsulates things
with the appropriate header sequence. Again, this is like shared static
state where both ends know that the receiver will be doing this.

| Interesting questions to ask wrt. each tunneling technique are at least:
|  - does this require state at the decapsulator?  If so, what?

IMO, they always require state at both ends, even if the state is
encoded in algorithms like "encaps all" or "decaps all with X as an
outer header".

|  - what are the security implications of state maintenance or lack
thereof?

Absolutely! We haven't touched on many aspects of shared state, including:

- - in vs. out of band coordination (when coordinated)
- - security
	- security of that coordination
	- security of the resulting tunnel mechanism
		e.g., can an intruder overload the state
	- security of packets through the tunnel

This is, as noted, a preliminary version of the doc, and other
suggestions for missing items would be great!

Joe