IETF Logo Mail Archive

Re: [IPsec] IPTFS and transport mode.

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 03 May 2020 17:08 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EDA3A1068 for <ipsec@ietfa.amsl.com>; Sun, 3 May 2020 10:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wn1vvjgLDKOi for <ipsec@ietfa.amsl.com>; Sun, 3 May 2020 10:08:18 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022F43A105A for <ipsec@ietf.org>; Sun, 3 May 2020 10:08:17 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B50DF3897B; Sun, 3 May 2020 13:06:19 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 71460201; Sun, 3 May 2020 13:08:16 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Christian Hopps <chopps@chopps.org>
cc: ipsec@ietf.org
In-Reply-To: <sa6sggh8a9d.fsf@chopps.org>
References: <sa6sggh8a9d.fsf@chopps.org>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Sun, 03 May 2020 13:08:16 -0400
Message-ID: <7081.1588525696@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/7x71zJmOLRKRTPyhFCHRbDhijvs>
Subject: Re: [IPsec] IPTFS and transport mode.
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 May 2020 17:08:20 -0000

Christian Hopps <chopps@chopps.org> wrote:
    > non-TFS tunnel mode as the IP header was leaking user information so it
    > hadn't been a consideration for us; however, it was later pointed out
    > (by Paul W. I believe), that transport mode is (unfortunately?)
    > commonly used with GRE tunnels in lieu of IPsec tunnel mode so we
    > probably still needed to handle this case.

If there will be changes to the GRE/IPsec mode, then maybe BEET mode could be
considered rather than transport mode.  BEET mode looks like transport mode
on the wire, but is treated virtually like tunnel mode.  This is essentially
what you describe:

    > For the common case of GRE/tunnel (which is the main justification for
    > use of transport mode IMO), the GRE header information should be
    > stable, and relatively easy to cache/consolidate for
    > regeneration/aggregation. Handling only this case is relatively easy,
    > We should be able to use the last received header information to
    > generate new headers for empty packets, likewise aggregating headers
    > should also work as each IP header should be the same.

You have described essentially BEET mode :-)
It is described in RFC7402.

    > We believe that there's enough complexity in the handling and
    > specification of TFS for transport mode that we should address this
    > mode in a separate draft. This will allow us to get the less complex
    > TFS tunnel mode specified while we continue to work on the various
    > aspects of how best to handle TFS transport mode.

I am not convinced that you really want to handle the generic transport mode
case.  I think that you want to handle the GRE case specifically.
I'm unclear if your above description is a hack to make GRE/tunnel fit into
your current situation, or if you are describing a new situation that would
handle in a new draft.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email