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

Joe Touch <> Sun, 05 January 2020 03:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A1971200B3 for <>; Sat, 4 Jan 2020 19:22:05 -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 bnEr-25Ycacb for <>; Sat, 4 Jan 2020 19:22:03 -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 A478C12008F for <>; Sat, 4 Jan 2020 19:22:03 -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=4OCWpdhblRPrcUjANsGMwuspuvnHYpVC+76xRcoeUBU=; b=IW6TPp4p6tt5nMQvoRb8AfU4U 0VHHTlAfEXDnucbSO9Odd+spgte/I1tmNRXB/IJUUn2gju+rW465sKIpLMZgsXvbeWKQJNgc1w78K e2wlt3/xhXEO37cGA0WZIFswF2whL+fUyy5cDsm//RRrpQ8J/ADo8GTS26uWx6KUBV25O7spXWBr4 fTgb+qKb/5k7UEvelXwds80NLQVjEv8ciGA5o9OnHkjAOE2+URLrTJdIWGY1xrWvTge+HNmt3UEN5 w0yTXe2mF2L4YjmHuQAl7Ak1+Nh/nC2ldfiXqr5LfVOECt4Eo0/KdXwVIgvA0dTu7lz9BbrqaLj4V plRWt92PA==;
Received: from ([]:63153 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <>) id 1inwUG-003m32-8D; Sat, 04 Jan 2020 22:22:00 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_88DD4F8E-A5D2-4B99-B5B5-05AD88C0D34A"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
From: Joe Touch <>
In-Reply-To: <>
Date: Sat, 04 Jan 2020 19:21:55 -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 03:22:05 -0000

Thank you for AGAIN failing to give an example.


> On Jan 4, 2020, at 7:10 PM, C. M. Heard <> wrote:
> On Sat, Jan 4, 2020 at 3:19 PM Joe Touch wrote:
> I don’t know how best to say this repeatedly, but we are NOT INTRODUCING STATE INTO UDP.
> We have repeatedly indicated that endpoints using certiain options may need to coordinate - OUTSIDE OF UDP. That’s always been true of some options - e.g., TCP-AO and TCP-MD5. The same would be true for AE - a receiver could decide to allow or ignore checks or could require them. A transmitter that needs to know otherwise needs to confirm.
> That’s what we’re talking about when we refer to the soft-state mechanism - the assumption being that because UDP can’t establish or enforce this state, it would at best be soft.
> A "drop the datagram if you don't recognize this UDP option" -- which is what I thought we were discussing -- DOES NOT INTRODUCE STATE INTO UDP. It is totally stateless, and it allows a receiver to drop datagrams that it should not accept without any prior coordination. In situations where prior coordination is required in order to make an option work as intended, it provides protection against failures of that coordination.
> 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. Seeing a SYn-ACK without the option, the initiator will return a RST segment. That will terminate the connection, and since the 3-way handshake never completed, the listener will not deliver any data that may have accompanied the SYN segment.
> For UDP-AE, the listener receives a datagram with an option affecting the handling of the user data that it does not understand. In my view (and Tom's) it should discard that datagram -- the same thing that happens with TCP-AO or TCP-MD5. The easiest way to ensure that, without requiring knowledge of what every option means, is to systematically embed in the Option Kind encoding information on whether the option can be safely ignored or not. We certainly can't do that with a three-way handshake because, as you point out, there is no such thing in UDP (and I agree that UDP options must not introduce it; leave that to efforts like QUIC).
> Granted, UDP-AE is in the spec, so a diligent implementation that does not understand the option will discard packets containing it. But what about options defined in the future?
> This has been discussed many times at multiple IETFs and hasn’t changed.
> It has been indeed been discussed at length, with each of us of repeating our arguments and failing to convince the other. But AFAICT there has been no determination of what the WG consensus is, and that determination is not for you or me to make.
> I'm going to refrain from further discussion until I see a new version of the draft, at which point I will do a complete review.
> Thanks and regards,
> Mike Heard