Re: [Tsv-art] [IPsec] Tsvart early review of draft-ietf-ipsecme-iptfs-03

Christian Hopps <> Sat, 19 December 2020 22:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E75FB3A0C18; Sat, 19 Dec 2020 14:16:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CD6t8RGwxm6X; Sat, 19 Dec 2020 14:16:54 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DF8F63A0C16; Sat, 19 Dec 2020 14:16:53 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 0E09560424; Sat, 19 Dec 2020 22:16:53 +0000 (UTC)
From: Christian Hopps <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_30D1212C-490F-4158-B18C-6D7A63455849"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Sat, 19 Dec 2020 17:16:52 -0500
In-Reply-To: <>
Cc: Christian Hopps <>,,,
To: Joseph Touch <>
References: <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Tsv-art] [IPsec] Tsvart early review of draft-ietf-ipsecme-iptfs-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 19 Dec 2020 22:16:56 -0000

> On Dec 4, 2020, at 3:14 AM, Christian Hopps <> wrote:

Looking through this list I realized one thing. We are not technically defining a new tunnel here. We are defining a new payload for the already defined IPsec/ESP tunnel. So many of these points are covered by the base ESP tunnel document. Where we do differ is that we do not pre-fragment packets (i.e., we do not use IP fragmentation or have a tunnel MTU) on ingress as the encapsulation supports fragmentation and reassembly by design of any sized IP packet. This fact is noted in the text while talking about the DF bit mapping (or lack thereof).

"IP-TFS never IP fragments the inner packets and the inner packets will not affect the fragmentation of the outer encapsulation packets."

Do you think I should expand a bit more on that text to anything more clear?

>> There are a number of other tunnel considerations that should be addressed,
>> again as discussed in draft-ietf-intarea-tunnels. These include:

>> -       The
>> impact of tunnel traversal on the inner hopcount/TTL (there should be none, as
>> per that doc; hopcount should be adjusted by routers, not tunnels) -

This is covered by IPsec ( <> section in particular).

>> Impact of errors in the tunnel on the ingress

What would you suggest saying about this? Broadly I'm thinking "errors in the tunnel will affect inner packet delivery?" Seems a bit obvious so I think I may be missing what your after.

>> -       Specification of the
>> EMTU_R of the tunnel itself, and how that is determined -

There is no maximum, all IP packet sizes are supported. :)

>>       What the
>> ingress should do if an incoming packet exceeds EMTU_R -       It should be
>> noted that this is a unicast tunnel -       What you expect if there are
>> multiple paths between the tunnel ingress and egress -       Does the tunnel
>> itself have a flow ID? (if the outer packet is IPv6) If so, is it fixed or
>> intended to vary arbitrarily (and if so, how)? -       If the outer packet is
>> IPv4, do you expect to use DF=1? If not, how are you handling ID issues in RFC
>> 6864? If so, it might be useful to add a reminder that the ID can be anything
>> (including constant, which may be useful in avoiding a covert channel).

We inherit these from the base IPsec/ESP tunnel mechanism that we use.