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

Joseph Touch <touch@strayalpha.com> Wed, 10 February 2021 15:51 UTC

Return-Path: <touch@strayalpha.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 96F2F3A0E37 for <tsvwg@ietfa.amsl.com>; Wed, 10 Feb 2021 07:51:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 d3a9y8vo_l0F for <tsvwg@ietfa.amsl.com>; Wed, 10 Feb 2021 07:51:02 -0800 (PST)
Received: from server217-5.web-hosting.com (server217-5.web-hosting.com [198.54.116.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D21C3A0E3A for <tsvwg@ietf.org>; Wed, 10 Feb 2021 07:50:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To: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=Gmvua4ZBFtMdosNDN2DtUCRaapTflFgngnh/j9ZsXoU=; b=ni8M5UH6rq1VYbiin2qcEUf9K ZnYPO4aatzZmLLPO/issd4KNeXbC7QziE2OdC5UR67vtVGbjl+fdcvinhDs/4YfblLPwwu0fFUMUK vnC+GbbIAMruOa27QhmN0Va5Tu6Gk7rzsDVENbDTo3zF5tqC2SOlBYtTPhKd4JzMmBd4lmbBQUa7A EPu/xNwtWz5PHpJdUg9WZFjT2LzQ8xk0IC3U2wF5ilIyL5b8JIXUAAnR2cZt3ddQzO4RqMiOCqbRW I1NplF8lzNwtZbCRNmxuphCe08CrOWQ5+yqy2PPOlI0RcIyN2TP4Sh3/z3IUBPUeu4GvHHZb18aY3 biwp5Iyfw==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:52812 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <touch@strayalpha.com>) id 1l9rlU-003CjU-RM; Wed, 10 Feb 2021 10:50:57 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <e39f6bd8-7456-617a-f763-515d1ad53c12@erg.abdn.ac.uk>
Date: Wed, 10 Feb 2021 07:50:51 -0800
Cc: Carsten Bormann <cabo@tzi.org>, tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9089311D-3EE3-4127-9FCF-124B78692900@strayalpha.com>
References: <160634937123.31668.16222629354118891810@ietfa.amsl.com> <014545D8-D549-4FFF-AF44-64975BA5DB09@strayalpha.com> <31945817-EA0C-416D-B002-EF7A2477654A@tzi.org> <e39f6bd8-7456-617a-f763-515d1ad53c12@erg.abdn.ac.uk>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
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 - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/iVY3Lr50wmzWwrPA7NC9pSKXqGs>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-09.txt - ROHC
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: Wed, 10 Feb 2021 15:51:04 -0000

Hi, Gorry,

I think the discussion we had back in Dec concluded that “you can only USE a profile if it applies”, so that would mean a correct ROHC implementation would need to *check* whether the UDP Length was consistent with the IP length and only compress using the given profile if that were true.

So the UDP options doc does not need to update ROHC, but I think we do need to make this clear in our doc.

Joe

> On Feb 10, 2021, at 4:31 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> 
> Carsten,
> 
> I'd like to see if we can find suitable text for the discussion of ROHC within the UDP-Options draft.
> 
> My own understanding is also that ROHC-compressed UDP packets need to match the profile for UDP defined in RFC3095, and that use of UDP-Options would result in a packet that can't compressed by the current profile - and hence would be sent uncompressed. If I understand correctly, this seems worth recording. However the current ID text goes further than this, and proposes an update.
> 
> Would you like to propose some alternate text for the WG to discuss?
> 
> Gorry
> 
> On 18/12/2020 14:17, Carsten Bormann wrote:
>> 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
> 
>