Re: [Int-area] new I-D available - tunnel issues
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Int-area] new I-D available - tunnel issues
On Fri, 18 Jul 2008, Joe Touch 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
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.
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 triggersFrom int-area-bounces at ietf.org Mon Jul 21 07:48:37 2008
Return-Path: <int-area-bounces at ietf.org>
X-Original-To: int-area-archive at megatron.ietf.org
Delivered-To: ietfarch-int-area-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 627FA3A6816;
Mon, 21 Jul 2008 07:48:37 -0700 (PDT)
X-Original-To: int-area at core3.amsl.com
Delivered-To: int-area at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 34B6F3A6816
for <int-area at core3.amsl.com>; Mon, 21 Jul 2008 07:48:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ljsYELCpoxah for <int-area at core3.amsl.com>;
Mon, 21 Jul 2008 07:48:35 -0700 (PDT)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1])
by core3.amsl.com (Postfix) with ESMTP id 8B36F3A6780
for <int-area at ietf.org>; Mon, 21 Jul 2008 07:48:34 -0700 (PDT)
Received: from netcore.fi (localhost [127.0.0.1])
by netcore.fi (8.13.8/8.13.8) with ESMTP id m6LEn3J3022861;
Mon, 21 Jul 2008 17:49:03 +0300
Received: from localhost (pekkas at localhost)
by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m6LEn2WU022855;
Mon, 21 Jul 2008 17:49:03 +0300
Date: Mon, 21 Jul 2008 17:49:01 +0300 (EEST)
From: Pekka Savola <pekkas at netcore.fi>
To: Joe Touch <touch at ISI.EDU>
In-Reply-To: <4880C8DC.3000508 at isi.edu>
Message-ID: <alpine.LRH.1.10.0807211734580.19299 at netcore.fi>
References: <011e01c8e62c$af44a480$a864a8c0 at china.huawei.com>
<487CAFB4.1090507 at isi.edu> <487D76C7.3010801 at employees.org>
<4880B285.3090308 at cisco.com> <4880C8DC.3000508 at isi.edu>
User-Agent: Alpine 1.10 (LRH 962 2008-03-14)
MIME-Version: 1.0
X-Virus-Scanned: ClamAV 0.93.1/7764/Sun Jul 20 19:42:45 2008 on otso.netcore.fi
X-Virus-Status: Clean
Cc: 'Internet Area' <int-area at ietf.org>
Subject: Re: [Int-area] new I-D available - tunnel issues
X-BeenThere: int-area at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/int-area>,
<mailto:int-area-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/int-area>
List-Post: <mailto:int-area at ietf.org>
List-Help: <mailto:int-area-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>,
<mailto:int-area-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: int-area-bounces at ietf.org
Errors-To: int-area-bounces at ietf.org
On Fri, 18 Jul 2008, Joe Touch 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
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.
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 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?
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
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area
, 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?
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
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
