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

Christian Hopps <> Sat, 19 December 2020 09:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 519ED3A0FAE; Sat, 19 Dec 2020 01:17:53 -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 SzwdYK9zJM3i; Sat, 19 Dec 2020 01:17:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8DE3C3A0FB0; Sat, 19 Dec 2020 01:17:50 -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 5BCEB6092B; Sat, 19 Dec 2020 09:17:49 +0000 (UTC)
From: Christian Hopps <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_97F9B0BA-FC19-48F0-8383-4A607082D918"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Sat, 19 Dec 2020 04:17:48 -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: Sat, 19 Dec 2020 09:17:53 -0000

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.

Regarding complexity, having implemented this I can say there really is no complexity :) 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.