IETF Logo Mail Archive

Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

"C. M. Heard" <heard@pobox.com> Thu, 18 July 2019 21:43 UTC

Return-Path: <heard@pobox.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B797120154 for <tsvwg@ietfa.amsl.com>; Thu, 18 Jul 2019 14:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wI91ghkTXeHF for <tsvwg@ietfa.amsl.com>; Thu, 18 Jul 2019 14:43:07 -0700 (PDT)
Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D484120137 for <tsvwg@ietf.org>; Thu, 18 Jul 2019 14:43:07 -0700 (PDT)
Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 7467414A42B for <tsvwg@ietf.org>; Thu, 18 Jul 2019 17:43:06 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=dnOWdjbjoP2dw0kEjwWgd1EgU+E=; b=IkCKL0 BWm0VD7sQkA+qAZv/VtDhJw68zOrnovEfFhrT4EAppWdAt3cpqmwzhE1zgDhHV0V CMnZSAHQq1qiQBY0XQLEtCXr9e9bJWwwgOLB31WGhiNlIRNtfnduyFQs8vlFfFqf t6TSqzEPpsLF7cSXQlAW7VuSZp3tVglPQJIvg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=GkTCAYIejqNkWvHxXvW2mU4P6ds4jZtu SSJF9br4mL1FdLp3MoDtxgbaknYObuaaHL9D2Y9bUvOxdBE7+Y76e2E1w6bXJUAc Xddxwt5BukxiberJPOevkde4bVMUP9h260BkYdO+XXYKnAx5ng0i1eeyQSCfq7sx Qcja1SGcuPE=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 58A2A14A427 for <tsvwg@ietf.org>; Thu, 18 Jul 2019 17:43:06 -0400 (EDT)
Received: from mail-io1-f51.google.com (unknown [209.85.166.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id B4DEB14A41F for <tsvwg@ietf.org>; Thu, 18 Jul 2019 17:43:05 -0400 (EDT)
Received: by mail-io1-f51.google.com with SMTP id i10so54063393iol.13 for <tsvwg@ietf.org>; Thu, 18 Jul 2019 14:43:05 -0700 (PDT)
X-Gm-Message-State: APjAAAXxx+W2qDVWOYjxRDXFa+GH0h+9Cwidn2jg2+q3VRmj5+NvL88T Awb2Gu2dslHNCAbDRxe3K2HOV7O1HGtkEfywWcs=
X-Google-Smtp-Source: APXvYqySZVtWMSd8uhM/BpPbHs+7fWNSNGaCGnt8FasIwA54xQAshLoSZIFP+5RjcwwvWwMNgpILdjuUCcAVBY6D7q4=
X-Received: by 2002:a6b:8b8b:: with SMTP id n133mr43869173iod.183.1563486185226; Thu, 18 Jul 2019 14:43:05 -0700 (PDT)
MIME-Version: 1.0
References: <30c17e9c174f6b0da3ecc6b503a8cb17@strayalpha.com> <2f71a292f924a9b8de4227c4bbc2f809@strayalpha.com> <CACL_3VGrF5UnbVsSzZZoy1i57WKiQKBX2T3a16UyEVHY=Kr3XA@mail.gmail.com> <CE03DB3D7B45C245BCA0D243277949363061EF7A@MX307CL04.corp.emc.com> <CACL_3VE7+3WD3Uzubf8X9uQX9ZYPnZVhXjheUOuL9EfjT1JkGQ@mail.gmail.com> <CALx6S35V-d3Rn_wjrhbHUHgS=_+dVjR4hbMJ0-JBsG-1BuFuZg@mail.gmail.com> <B5CCEF58-38CE-4973-9CFD-002B404E4EF3@strayalpha.com> <CACL_3VEnJoV9N9i59fJXG1Nyt=mMWT7SuB8B=C-Y9a9QLtqP7Q@mail.gmail.com> <BB3FD9A5-8D30-4600-A7A7-DA3030BD34A3@strayalpha.com> <20190718100109.GA86292@clarinet.employees.org> <718EBD34-5B4A-4458-B9B4-0A94C33E019E@strayalpha.com> <CACL_3VGL2irCkZeEcP+9HLBHqtqaMPZM66youUsatzosUu=Aew@mail.gmail.com> <A07EA390-1A3A-4AE9-AFD7-2F22CD4B0E31@strayalpha.com> <CALx6S34oOza3Z4Ymjsp+HLXnSTOKwh+SAQO8mt=a-1AbTTB0GQ@mail.gmail.com> <177233bb33272ce3b64298a005254724@strayalpha.com> <CALx6S36ZBa4Bioj=0KYn7wcFi08VeAg8sHUHLRNGURsrUN673w@mail.gmail.com> <5D30B36D.80409@erg.abdn.ac.uk>
In-Reply-To: <5D30B36D.80409@erg.abdn.ac.uk>
From: "C. M. Heard" <heard@pobox.com>
Date: Thu, 18 Jul 2019 14:42:50 -0700
X-Gmail-Original-Message-ID: <CACL_3VERGdtyyn16q=C=K-XKEhvPXQU6etGDEaP7874fWwtU9w@mail.gmail.com>
Message-ID: <CACL_3VERGdtyyn16q=C=K-XKEhvPXQU6etGDEaP7874fWwtU9w@mail.gmail.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: Tom Herbert <tom@herbertland.com>, Joe Touch <touch@strayalpha.com>, tsvwg <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ae8a56058dfb7e9f"
X-Pobox-Relay-ID: 06A38F50-A9A5-11E9-BE22-72EEE64BB12D-06080547!pb-smtp2.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/VX4YBYdWazeNxYBsy0_wLB8C_fw>
Subject: Re: [tsvwg] draft-ietf-udp-options issues from IETF 104
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jul 2019 21:43:09 -0000

On Thu, Jul 18, 2019 at 10:59 AM Gorry Fairhurst wrote:
> That's where I disagree. I think anything that is not a native UDP
> packet MUST be carried in the options space. That's where I would
> suggest we put the compressed payload. if that means the main payload
> area isnothing", then that would be OK for me.

Yes, exactly, and I say that none of the following qualify as native UDP:

- fragments (option and associated data)

- packets with authentication and encryption (AE)

- packets with alternate checksums (ACS)

- any other option that affects the handling of the payload

I would like to see all of those things behind a UDP header
whose length is 8, with OCS (or equivalent) covering the
surplus area (at least if the checksum in the UDP header
is present). Then the options and their associated data
will both be discarded if OCS fails and will both be
processed if OCS passes (modulo unrecognized options,
more on which anon).

Mike

v2.23.0 | Report a Bug | By Email