Re: [tsvwg] Rregarding soft-state and UDP options

Joe Touch <> Sun, 05 January 2020 16:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EA481200B1 for <>; Sun, 5 Jan 2020 08:25:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 4oJaikHpWi0O for <>; Sun, 5 Jan 2020 08:25:42 -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 72A35120077 for <>; Sun, 5 Jan 2020 08:25:42 -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=Tu+EjKhR/ktzuGV4E2gckOXH3911LRWpgXbjruXkD4A=; b=S9tJguscfJWU6ecLgm+IGp2Ri F52cCsmRqKExhpjSN/ZAHA7u5ZiD5B+UWFBHik/UV/mfl2QH8xOs8pl6bVJNzjc8lzUHl1ja0fSdx ZXAzE7F3aokCyi7a+KEXwFCQ+vlIdYLxv2YW+BSD6boiGOooKxRBydJVJQd3RigxNDAP7nNKhjId/ y4WbqKm2jcB6GYUCqQ9kvcFhIXD4lamqwzIyM+M4xxn1OCXcgzAT3o1q2zTZyobvXcF7SAC03zpfx Jbhjd+Wo8ygqcBwS1NUdChczvhtUvQPRRhU76iRJB6JW3xiyKp2dZ2j2WEvkKyrAw2QpvsrrCvJzO 3+auHYO8g==;
Received: from ([]:57184 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <>) id 1io8ie-003kuZ-19; Sun, 05 Jan 2020 11:25:40 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_F5B8FB26-97BA-42A1-9802-AC4A0F9D963D"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
From: Joe Touch <>
In-Reply-To: <>
Date: Sun, 05 Jan 2020 08:25:34 -0800
Cc: Tom Herbert <>, TSVWG <>
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
To: "C. M. Heard" <>
X-Mailer: Apple Mail (2.3608.
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: [tsvwg] Rregarding soft-state and UDP options
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 05 Jan 2020 16:25:46 -0000

Just to dive a little into the TCP example, additionally:

> On Jan 4, 2020, at 7:10 PM, C. M. Heard <> wrote:
> Since you brought it up, let's compare and contrast the operation of TCP-AO and TCP-MD5 with that of UDP-AE, in the case that an endpoint erroneously (due, e.g., to a misconfiguration) attempts to initiates an exchange containing the option with a peer that does not understand it.
> For TCP-AO or TCP-MD5, the listener will receive a SYN segment with the option. Since it does not understand the option, it will return a SYN-ACK that does not contain the option.

The presence of unknown TCP options **NEVER** causes a SYN to be ignored, discarded, or to generate a RST. It is simply ignored.

It is the result of *state exchange* that enables the endpoints to know when to use - or not use - those options. It is the responsibility of the sender to know what options to use; the receiver is ALWAYS ALLOWED TO INGORE OPTIONS that it hasn’t confirmed by state exchange - even after a connection is established.

E.g., even if the side opening the connection, sending the SYN+AO were to ignore the reply (SYN-ACK without AO, never RST), let’s look at what happens to the connection afterwards. Let’s say the side opening the connection decides to include AO anyway. The receiver WOULD CONTINUE TO IGNORE OPTIONS IT DOESN’T UNDERSTAND.

See RFC1122, Sec

Your subsequent claim is incorrect, as per the citations below:
	> Seeing a SYN-ACK without the option, the initiator will return a RST segment. 

RFC2385 for TCP-MD5, Sec 2.0:
   Unlike other TCP extensions (e.g., the Window Scale option
   [RFC1323 <>]), the absence of the option in the SYN,ACK segment must not
   cause the sender to disable its sending of signatures.  This
   negotiation is typically done to prevent some TCP implementations
   from misbehaving upon receiving options in non-SYN segments.  This is
   not a problem for this option, since the SYN,ACK sent during
   connection negotiation will not be signed and will thus be ignored.
   The connection will never be made, and non-SYN segments with options
   will never be sent.  More importantly, the sending of signatures must
   be under the complete control of the application, not at the mercy of
   the remote host not understanding the option.

RFC5925 for TCP-AO, Sec 11:
   TCP-AO does not include a fast decline capability, e.g., where a SYN-
   ACK is received without an expected TCP-AO and the connection is
   quickly reset or aborted. 


For UDP, the original design goal was to follow this behavior, i.e., that the receiver always ignores options it doesn’t understand individually. That’s largely because options overall can be ignored - there’s no way to “unring the bell”. Even if we bury options or user data inside the FRAG+LITE, the *ONLY* correct behavior is to have the receiver see a zero-length UDP packet arrival.

There is NO way to prevent that for legacy receivers - and thus there should be no way to do otherwise for option-aware receivers. The best we should ever try to do is to make option-aware receivers see what legacy receivers see in that case (unknown options) - a blank packet.

So regardless of any rules, we MUST NOT try to declare any rule where the receiver “sees NO packet”.