IETF Logo Mail Archive

Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-09.txt

Carsten Bormann <cabo@tzi.org> Fri, 18 December 2020 14:17 UTC

Return-Path: <cabo@tzi.org>
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 14B5C3A0332 for <tsvwg@ietfa.amsl.com>; Fri, 18 Dec 2020 06:17:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Sv3VqvKreyBX for <tsvwg@ietfa.amsl.com>; Fri, 18 Dec 2020 06:17:53 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 005243A02BD for <tsvwg@ietf.org>; Fri, 18 Dec 2020 06:17:52 -0800 (PST)
Received: from [192.168.217.118] (p548dca87.dip0.t-ipconnect.de [84.141.202.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Cy9tk6WV8z10DL; Fri, 18 Dec 2020 15:17:50 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <014545D8-D549-4FFF-AF44-64975BA5DB09@strayalpha.com>
Date: Fri, 18 Dec 2020 15:17:50 +0100
Cc: tsvwg IETF list <tsvwg@ietf.org>
X-Mao-Original-Outgoing-Id: 629993869.8641419-10ebb20151f0dc7c6d2211b1f8943e96
Content-Transfer-Encoding: quoted-printable
Message-Id: <31945817-EA0C-416D-B002-EF7A2477654A@tzi.org>
References: <160634937123.31668.16222629354118891810@ietfa.amsl.com> <014545D8-D549-4FFF-AF44-64975BA5DB09@strayalpha.com>
To: Joseph Touch <touch@strayalpha.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/eKYo0q21fhCLY0vE0Sm1zUI6Co8>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-09.txt
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: Fri, 18 Dec 2020 14:17:55 -0000

On 2020-11-26, at 01:14, Joseph Touch <touch@strayalpha.com> wrote:
> 
> 	• This doc now updates ROHC 3095 too
> 		• puts it in line with more recent header compression standards that we caught
> 		• UDP header compression should ever have assumed that UDP Length is implicit based on IP length

Specifically, the draft now says:

   This document hereby deprecates the requirement asserted in the UDP
   profile for Robust Header Compression (ROHC)[RFC3095], noted here:

      "The Length field of the UDP header MUST match the Length
       field(s) of the preceding subheaders, i.e., there must not
       be any padding after the UDP payload that is covered by the
       IP Length.”

This change is highly confused.

You indeed cannot initialize an IR header chain from from a UDP packet where this does not match.  So you would send that uncompressed.  If this MUST were changed, the receiver no longer would be able what length to put into decompressed UDP packets.

Somehow, I feel like responding to an errata report that needs to be rejected…

Grüße, Carsten

v2.23.0 | Report a Bug | By Email