Re: [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15

"Brian Trammell (IETF)" <ietf@trammell.ch> Thu, 30 August 2018 15:46 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA9E130EB2; Thu, 30 Aug 2018 08:46:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ViDZ57fOfEVy; Thu, 30 Aug 2018 08:46:12 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1516130E8B; Thu, 30 Aug 2018 08:46:11 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C83CF340EC0; Thu, 30 Aug 2018 17:46:09 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6030.19358); Thu, 30 Aug 2018 17:46:09 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 30 Aug 2018 17:46:09 +0200 (CEST)
Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 65765631; Thu, 30 Aug 2018 17:46:09 +0200
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
Message-Id: <FD414B30-ED12-4BEC-94FB-737FB1AAECA1@trammell.ch>
Content-Type: multipart/signed; boundary="Apple-Mail=_4561970D-A129-41E4-8704-1166273C9D25"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-lisp-rfc6830bis-15
Date: Thu, 30 Aug 2018 17:46:08 +0200
In-Reply-To: <E76EB141-5D80-4131-AB42-4DB326348B00@gmail.com>
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, tsv-art@ietf.org, IETF Discussion Mailing List <ietf@ietf.org>, "lisp@ietf.org list" <lisp@ietf.org>
To: Dino Farinacci <farinacci@gmail.com>
References: <153538054829.30074.15428909912816972228@ietfa.amsl.com> <ED34F830-1FEF-42BB-BB6E-805D724AB339@gmail.com> <79FA52C8-94AC-43CE-B052-9F921A65E0D5@trammell.ch> <23680BD5-0DD3-4404-888D-D1C78A0A437D@gmail.com> <130902C2-9CEE-4931-8957-D32446723B89@trammell.ch> <CF5E3C7B-E492-4EE9-A2E6-A2D823C6610F@gmail.com> <1514B576-87FD-475F-B6C5-BBA1C2CA94ED@trammell.ch> <CE7ECD23-E8A2-4D48-B752-0D246C02F27E@gmail.com> <FBA13CF2-8E44-46DA-AB5D-9082B5288F05@trammell.ch> <5E2CBC85-87FF-48DC-950B-403E6E8E14BF@gmail.com> <C4425CD6-B44D-479A-819A-BEFCC83E9E33@gmail.com> <B466126A-DBE8-4088-AC93-F7D49C534ABE@trammell.ch> <E76EB141-5D80-4131-AB42-4DB326348B00@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/QPkLuvJfNG9eJMciVK2OzyVR3-E>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Aug 2018 15:46:14 -0000


> On 30 Aug 2018, at 16:55, Dino Farinacci <farinacci@gmail.com> wrote:
> 
>> On Aug 30, 2018, at 2:57 AM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
>> 
>> hi Dino,
>> 
>> Almost. How about:
>> 
>> 
>> OLD:
>> 
>> When the UDP and LISP headers require integrity protection, the
>> methods of using UDP checksums in [RFC8085] can be considered.
>> 
>> NEW:
>> 
>> Implementors are encouraged to consider UDP checksum usage guidelines in section 3.4 of [RFC8085]. Specifically, when the UDP, LISP, and outer IPv6 headers require protection against corruption, the use of non-zero UDP checksums is RECOMMENDED.
> 
> Well if we recommend it and when describing the UDP header in the packet format section we don’t that woudl be a contracdiction.

I think my point here is that the packet format section probably shouldn't do that. :) Yes, I understand the disconnect between the reality of the situation and the

> And note the IPv6 outer header cannot be protected with a UDP checksum. The link-layer CRC will do that.

Eh, this makes assumptions about the underlying link layer's corruption characteristics that may not hold. But yeah, for most packets in most realistic situations this is the case, and I guess we've learned to live with the underlying phy error rate * 1e-10 in any case.

> NEWNEW:
> 
> Implementors are encouraged to consider UDP checksum usage guidelines in section 3.4 of [RFC8085] when
> it is desirable to protect UDP and LISP headers against corruption.
> 
> What do you think?

This seems like a fine compromise to me.

Thanks, cheers,

Brian

> 
> Dino
> 
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art