Re: [tcpm] Zaheduzzaman Sarker's Discuss on draft-ietf-tcpm-rfc793bis-25: (with DISCUSS and COMMENT)

"" <> Sat, 08 January 2022 17:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 625293A195B; Sat, 8 Jan 2022 09:47:00 -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 6Wz0TjobNdIG; Sat, 8 Jan 2022 09:46:57 -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 35C6B3A1956; Sat, 8 Jan 2022 09:46:57 -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=vi4i0xoH9N+MxMTYs0C2U3RDGH+HECqp1uG19FMtEb0=; b=x8vu69igOsZJy+OZyOmzt3f9sD 5mQTx2yMIKJQmhxApI8W4GhSs+5ScnfmC+OjhQf+2mDWMct+xaGlcxVdjk5eRMHoWvsq3B3TdMhxR DnTnwUAcywTh7lIvc9ztHN8sqh5Np9ZYS+hXDlff5Cbf9M0qp+2xPfXLnZTb6D9CbrvlDCvuotkSh NhbvkpSfHHFzoW5vALEtabbJl53MwJweUy5lgRPxlSzGcIXuK7BZzKjgcilImT6TzRBuDM+FRFJhy /pqjYZ2PA44HryRnqXwZG1IV3LI0fd0wogEupvWS+U+Zy694orm85UgPK9LA9/o9IbTzggIoufmLE CFflFz0Q==;
Received: from ([]:50455 by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <>) id 1n6Fno-00AWVl-8W; Sat, 08 Jan 2022 12:46:56 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_72B643BB-0412-4174-A41C-E508ED68B383"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.\))
From: "" <>
In-Reply-To: <>
Date: Sat, 08 Jan 2022 09:46:50 -0800
Cc: Zaheduzzaman Sarker <>, The IESG <>,, tcpm IETF list <>,
Message-Id: <>
References: <> <>
To: Wes Eddy <>
X-Mailer: Apple Mail (2.3693.
X-OutGoing-Spam-Status: No, score=-1.0
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: [tcpm] Zaheduzzaman Sarker's Discuss on draft-ietf-tcpm-rfc793bis-25: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 08 Jan 2022 17:47:01 -0000

> On Jan 7, 2022, at 11:04 AM, Wesley Eddy <> wrote:
>> I have some comments/questions below. By addressing those, I hope will improve
>> the document even better:
>> * Section 3.1 : says --
>>      Note that the list of options may be shorter than the data offset field
>>      might imply. The content of the header beyond the End-of-Option option
>>      must be header padding (i.e., zero).
>>    Should this be a normative MUST?
> Great question ... The EOL option is a zero byte, and the first such option should signal that the option list is over.  So the receiver shouldn't need to process or check any further bytes of options to see if they're also properly zero'ed padding.
> So, I wouldn't think this needs to be normative, since if it's not followed, no harm should result.  However, that leads to the question of why it says they must be set to zero then.  Maybe someone else from TCPM has a better answer than "that's just what it's always said" ... To me, it seems like it's a good thing to do, but maybe not really required.
I don’t know the original reason, but there are at least three candidates:

A) because zeroes make it easy to check because they won’t affect the TCP checksum further
B) to avoid permitting a covert channel
C) to avoid needing to add and check for NOPs - which are not zeroes, thus need to be checked because they would affect the TCP checksum

So yes, I think for at least these reasons it should be a MUST. Another way to state this is that an EOL MAY be followed by one or more EOLs to enable alignment of the payload, but MUST NOT be followed by any other option.