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

Joseph Touch <> Wed, 23 December 2020 22:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A2B33A0EDB; Wed, 23 Dec 2020 14:33:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0-Hv8UAKYrxu; Wed, 23 Dec 2020 14:33:54 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C8F53A0ECE; Wed, 23 Dec 2020 14:33:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0UqBqlW5OGCBCSgu2POy+m3yx3J8A55G7iE2IVm6Oyo=; b=OkOkIC40SLzpju6O3L0Zie5YV 0h68L9JkWS+cboHCrDQDNU7K8cn7ZIkRFD5hi72IIPc43jlUxHGmOZgrDSSx4Lm7qZ9zheB+HUK9y xILQykLjD0Kt/MNUm7QYsFBxp9+0osTR559V6jv81Wqjt6bmc1lvCJ+u+SsUqlo7S1L8dPiXTSX7r 535AT4eP3PkFPEWHIEgjlMRCv00VzodLz2X8mcYTYELOFcBDYY+2UfWTyJmPwCqTM2xu461ZJcTbA Ak7mKUtVwTEkErvk/RzUrl7W2rek7F6DfXan8BefTpyTa+B/K3APivrIswUTes5xIsZXiZvKB0HSC vVaneps1Q==;
Received: from ([]:56735 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <>) id 1ksChY-001ude-5J; Wed, 23 Dec 2020 17:33:53 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_EE6D06EE-7877-44AF-9AF0-B951F6BECF55"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Joseph Touch <>
In-Reply-To: <>
Date: Wed, 23 Dec 2020 14:33:47 -0800
Cc:, tsv-art <>,
Message-Id: <>
References: <> <> <> <> <>
To: Christian Hopps <>
X-Mailer: Apple Mail (2.3654.
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
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: Wed, 23 Dec 2020 22:33:57 -0000

Looks good - thanks.


> On Dec 19, 2020, at 8:44 PM, Christian Hopps <> wrote:
> 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: <>
> Thanks,
> Chris.
>> 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
>> <>
>> <>
> _______________________________________________
> Tsv-art mailing list