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

Christian Hopps <> Sun, 20 December 2020 04:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE4DD3A09CD; Sat, 19 Dec 2020 20:44:24 -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 xHJC32-oOnCH; Sat, 19 Dec 2020 20:44:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id ABDAF3A09C9; Sat, 19 Dec 2020 20:44:22 -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 DC0E56020D; Sun, 20 Dec 2020 04:44:21 +0000 (UTC)
From: Christian Hopps <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_736B9820-E371-4238-BD14-A1058B40F6C6"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Sat, 19 Dec 2020 23:44:20 -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: Sun, 20 Dec 2020 04:44:25 -0000

Hi Joe,

Thanks  so much for your review and feedback. I have just published a new version of the draft that I believe covers the concerns you raised in the review.

New: <>
Changes: <>


> On Dec 19, 2020, at 7:57 PM, Joseph Touch <> wrote:
>> On Dec 19, 2020, at 2:16 PM, Christian Hopps < <>> wrote:
>>> 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).
> It’s the ways in which you differ that need to be addressed.
>> "IP-TFS never IP fragments the inner packets and the inner packets will not affect the fragmentation of the outer encapsulation packets."
> It doesn’t IP fragment, but it does fragment. There are still fragmentation and reassembly considerations as a result.
>> Do you think I should expand a bit more on that text to anything more clear?
> Yes - the point is to explain how much you rely on some properties of ESP to avoid replays and maintain ordering and explain that’s why some of the typical reassembly issues aren’t relevant. But not all..
>>>> 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).
> It should be noted as how that impacts the methods of this doc.
>>>> 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.
> You should describe how you expect ICMP errors arriving at the ingress to be handled when they arise because of a packet traversing the tunnel. If it’s “how ESP handles it”, fine, but mention that.
>>>> -       Specification of the
>>>> EMTU_R of the tunnel itself, and how that is determined -
>> There is no maximum, all IP packet sizes are supported. :)
> OK, then mention that. It’s different from the EMTU_R of ESP, for example.
>>>>       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.
> Some of it you do inherit, but others you do not (as you note above). They all need to be addressed.
> I.e., you’re potentially putting multiple IP packets inside one tunnel packet; what does the header of the tunnel packet look like? You can’t simply say “do what ESP does” because ESP allows only one IP packet as payload. I.e., see Sec - all those values “copied from the inner packet” - how do they work when you have more than one packet and the values vary across those payloads??
> That’s the point here - you can definitely say “do what ESP does” when that’s enough, but it’s clearly not. The ways in which you differ need to be spelled out explicitly.
> Joe
> _______________________________________________
> IPsec mailing list
> <>
> <>