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

Christian Hopps <> Sun, 20 December 2020 03:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB8663A097E; Sat, 19 Dec 2020 19:47:54 -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 0iwppsIRLKIg; Sat, 19 Dec 2020 19:47:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E922D3A0978; Sat, 19 Dec 2020 19:47:52 -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 1F0676020D; Sun, 20 Dec 2020 03:47:52 +0000 (UTC)
From: Christian Hopps <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_3F57C823-97C3-4EC7-B63F-89A425C1EF5F"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Sat, 19 Dec 2020 22:47:51 -0500
In-Reply-To: <>
Cc: Christian Hopps <>,, tsv-art <>,
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 03:47:55 -0000

> On Dec 19, 2020, at 7:41 PM, Joseph Touch <> wrote:
>> On Dec 19, 2020, at 1:17 AM, Christian Hopps < <>> wrote:
>> Changes are underway. One comments inline.
>>> On Dec 4, 2020, at 11:42 AM, Joseph Touch < <>> wrote:
>>> Hi, Christian,
>> [...]
>>>>> There is no clear utility in having the blockoffset point past the end of the
>>>>> current packet. It serves – at best – as only a partially useful check on the
>>>>> next packet. I.e., if the two blockoffsets disagree, presumably a packet is
>>>>> lost – but if they agree, it cannot be concluded that a packet is not lost. It
>>>>> is sufficient that it points to the end of the tunnel packet.
>>>> No harm either though, right? Having implemented this, I can tell you that it does help detect bugs in ones code while in development. :)
>>> It’s useful as a check, but it’s important to explain what the check means.
>>> There are four cases (BO = blockoffsets, seq = ESP sequence number)
>>>                               ESP - no gap         ESP - gap
>>> ---------------------------------------------------------------------
>>> BO - aligned          OK                         BO-FP-err
>>> BO - misaligned    SN-FP-err              Typ-err
>>> Typ-err is the typical error when a packet is lost, because that should result in both an ESP seqno gap and blockoffset misalignment.
>>> SN-FP-err is when there’s no ESP seq no gap but the blockoffsets are misaligned. This should only ever happen if the seqno rolls around and you missed it, which you should have some other mechanism to prevent (i.e., drop old packets when they’re half the sequence space old - which is easy to predict because you know the tunnel packet generation rate).
>>> BO-FP-err is when there’s an ESP seq no gap but the blockoffsets are aligned. This is just a false positive (thus “FP” in my notation). S
>>> In any of the error cases, you do not reassemble.
>>> So checking blockoffset alignment only helps you know whether your sequence number check and timeout discard is working correctly.
>>> Protocol implementation correctness should be checked by test vectors, not during normal code operation IMO. At best, it’s unnecessary complexity. At worst, it gives you a false sense of wanting to reassemble when you shouldn’t.
>> Conversely, test-vectors are harder to write w/o this and must be external, whereas this is a simple sanity check that can be added inline (perhaps conditionally) to code which has been shown to catch bugs. This will help implementations be more robust.
> Test vectors run only during testing. By putting this test in regular operation, you’re adding overhead to check that the code is working every time it runs.

The test is already performed to determine if the fragment is complete or not, regardless of whether you use the real value or some marker value.

> It’s your call; I was just pointing out that this is very inefficient.
>> Regarding complexity, having implemented this I can say there really is no complexity :)
> If the LOC > 0, then it’s not “no complexity”.

There really is no complexity added.

copylen = min(inner_remain, outer_remain)
ohdr->block_offset = inner_remain; /* Only Diff */
memcpy(outer_buf, inner_buf, copylen);
if (inner_remain > copylen) more to go...


copylen = min(inner_remain, outer_remain)
ohdr->block_offset = copylen; /* Only Diff */
memcpy(outer_buf, inner_buf, copylen);
if (inner_remain > copylen) more to go...

Except the former allows for creating more robust implementations, and also differentiates the case where a fragment just fits or not for the receiver. The latter ends up stripping away useful information. Both ways point the block offset past the end of payload. I see the loss for stripping the information here, I don't see the gain.


>> You set the block offset to the remaining inner packet length to be sent (or 0 if no packet fragmentation is in progress). This value is sitting right there in the code so you can either plug it in or use some marker value (you suggest the length to the end of the payload). On receive the code is identical: does it exceed the length of the payload or not.
> Agreed, it’s simple - but it’s nonzero effort and code. Again, at run-time. For a check that basically keeps saying the code is working, rather than checking an actual packet error.
> Again, recommending inefficient code is up to you.
> Joe