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

"Black, David" <David.Black@dell.com> Fri, 12 July 2019 15:31 UTC

Return-Path: <David.Black@dell.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 F2999120691 for <tsvwg@ietfa.amsl.com>; Fri, 12 Jul 2019 08:31: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, DKIMWL_WL_HIGH=-0.001, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=uhkdvhh1; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=FJHd4v05
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 P68DM00nlmKe for <tsvwg@ietfa.amsl.com>; Fri, 12 Jul 2019 08:31:06 -0700 (PDT)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 BD9811201CC for <tsvwg@ietf.org>; Fri, 12 Jul 2019 08:31:02 -0700 (PDT)
Received: from pps.filterd (m0170393.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6CFPZJc012873; Fri, 12 Jul 2019 11:31:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=yic1P9NdlNjoYLJO/v79iwT11wIZEaiEZqIPEJM84rM=; b=uhkdvhh1jIrEcMWmsfcxmRre8h1/F3b2+E8e50aPaVs4Uz9gaNPVuJc6HcI+jEi26s0T jMXGWK9hjiTMY97AO57XEDA+McUqgrgY32Nu07I2VYuPRj3dxiWINxzpC2wurx5F48AO +sBkBQH4ibuBrLgJVIfylJ4plTnISqoSMjP4JoC0yTO6GEeuP97IOfwfSoVcCH4dSDd1 w9e3mPkwl5kznVv/PMOy34Lofmp61/n8OdRnQnbvF8zAV2chCwTL49Hm9lyKDgFCeImJ EU8Wa9XX1AlWvuCEXmG+czQMCwLGsQxq8oMFx05KWJX11aro1y75ryYIgl45JWKBy5Dl Kg==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 2tp2kunx1y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Jul 2019 11:30:58 -0400
Received: from pps.filterd (m0144102.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6CFSh0W024103; Fri, 12 Jul 2019 11:30:57 -0400
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by mx0b-00154901.pphosted.com with ESMTP id 2tpv6ugqne-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 12 Jul 2019 11:30:57 -0400
Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x6CFUfOl006821 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Jul 2019 11:30:56 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com x6CFUfOl006821
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1562945456; bh=2sVFAJEQfo/j0ig8PyYov8+EngA=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=FJHd4v05Bfvr5YtYz/9qw4aWUw0XKumUBhqbdfUZwxvWdVBkjXm1C4a4bYjDl7lrJ 8Ae9yu9wJCS7BdWAbjpr+AZSxn/T6D1ev7S4uQr3hy4T64our1g/iMpyHbXNbr0Gxb qUr0R3+N4zWj7CAH9tlYSXbzC3aD8y/0YVhr17t8=
Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd02.lss.emc.com (RSA Interceptor); Fri, 12 Jul 2019 11:30:18 -0400
Received: from MXHUB316.corp.emc.com (MXHUB316.corp.emc.com [10.146.3.94]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x6CFUKVG010158 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 12 Jul 2019 11:30:22 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB316.corp.emc.com ([10.146.3.94]) with mapi id 14.03.0439.000; Fri, 12 Jul 2019 11:30:20 -0400
From: "Black, David" <David.Black@dell.com>
To: Joe Touch <touch@strayalpha.com>
CC: Tom Herbert <tom@quantonium.net>, tsvwg <tsvwg@ietf.org>
Thread-Topic: [tsvwg] draft-ietf-udp-options issues from IETF 104
Thread-Index: AQHVN6fJSr2fz2j+X0mdJ/EyrvZ1aKbFyZkAgAAMWICAAA4/AIAAHX2A///IYUCAAFy8gIAA2GiwgABUnoD//8bSAA==
Date: Fri, 12 Jul 2019 15:30:20 +0000
Message-ID: <CE03DB3D7B45C245BCA0D2432779493630615768@MX307CL04.corp.emc.com>
References: <156262970360.865.13042807682366763561.idtracker@ietfa.amsl.com> <CAPDqMeoMqsB8=tH5TBaq5Tw-sLW3HNc8tpfUU3htV=sWo7pJcA@mail.gmail.com> <D7E52D2B-3912-4897-80C6-0150CDE10218@strayalpha.com> <CAPDqMep9MYqjFvvJSVbqYwo-xJ1pUocYszNukveaZODhf9+75A@mail.gmail.com> <e73919f08202937bf45418cbf8bcc38c@strayalpha.com> <CAPDqMeoh3n5fL1k6Fw9D8rCpy4a9eWyUZvgStyzYfFuJbuWudw@mail.gmail.com> <3f6f54e0b828e2628af964d6ee7f33e1@strayalpha.com> <CALx6S37rt7OJtH5a2ZH23R21ATETuwTeFS-mZQECtgxPQ3nSZA@mail.gmail.com> <ccc386aa429bfe301998f39eb7fccfbf@strayalpha.com> <140f11c854e0ad96c51639f830cbb688@strayalpha.com> <CALx6S35MC_fj+fL6Ax9a-9=-QX0-mHLmMQ7cUs2Rir+AvYE=zA@mail.gmail.com> <5b35e91dd510119672a0836f868ade24@strayalpha.com> <CALx6S36AVbKfvb-6dj07rcGjsVsCz0daFM9qZOBSSstZOM-Ukg@mail.gmail.com> <8A584FFF-6C86-4154-8D9D-CF407CA77145@strayalpha.com> <CAPDqMeq9GjEQKukH1pZOTdE50e_rc3U6gpdxT-5qrS5phD0RGw@mail.gmail.com> <646D45AD-D79B-4BD2-A084-7DA97CE2C415@strayalpha.com> <CALx6S35grMA4uLYRGs4ioLfX BbS8zYN5ygprr=RKQ0hDk=Q1CQ@mail.gmail.com> <7EC37B50-45D5-4CF1-B113-205E55BF244E@strayalpha.com> <CALx6S34s7L7xo+26bt5Cdaqi4Es5Aci42GHk1WNKzugr5st-Gw@mail.gmail.com> <B525BF50-EFCC-44A5-A604-6CDDA914A1CB@strayalpha.com> <CAPDqMep3R6z9PRKkHyOvrh6sV9n5Sc0B++-zVz0FYJCwE6swrQ@mail.gmail.com> <E42A2AE2-F499-465E-BDE6-5EFC0AB20042@strayalpha.com> <CE03DB3D7B45C245BCA0D24327794936306138E9@MX307CL04.corp.emc.com> <f9f1701c2196c5db520d025294202353@strayalpha.com> <CE03DB3D7B45C245BCA0D24327794936306153C4@MX307CL04.corp.emc.com> <4D8799FC-0B90-4410-B852-439A0B598C99@strayalpha.com>
In-Reply-To: <4D8799FC-0B90-4410-B852-439A0B598C99@strayalpha.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2019-07-12T15:19:08.4758316Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public
x-originating-ip: [10.238.21.131]
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D2432779493630615768MX307CL04corpem_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-12_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907120165
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907120165
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/vQtGeg-Oj5jXJ0Wbrx1owHmUk2g>
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: Fri, 12 Jul 2019 15:31:10 -0000

Inline …

Thanks, --David

From: Joe Touch <touch@strayalpha.com>
Sent: Friday, July 12, 2019 10:43 AM
To: Black, David
Cc: Tom Herbert; tsvwg
Subject: Re: [tsvwg] draft-ietf-udp-options issues from IETF 104


[EXTERNAL EMAIL]



On Jul 12, 2019, at 7:09 AM, Black, David <David.Black@dell.com<mailto:David.Black@dell.com>> wrote:

I think I’m over on the “FORCE” side of that dichotomy (i.e., I don’t agree with “easily optional”), although we can split hairs on what degree of “FORCE” is appropriate.   My underlying reasons are these two:
                1) strong "running code" evidence of what breaks when the OCS is omitted,
                2) helps defend against … possibility [of] … other uses of surplus space

IMHO, OCS being the “default” is a good starting point, but … my current view is that on its own, item 1) justifies “MUST implement/SHOULD use” language for OCS (and “SHOULD use” is complementary to and stronger than “default”) and setting the space aside for OCS, at least when LITE is not present.  That view is reinforced by item 2), and I note neither of those two items are within the control of the endpoint implementer or application that uses the endpoint’s UDP option support.

Also note that the “running code” evidence is based on an error. That’s why I worry about designing overhead we live with forever only to overcome a bug that may be ephemeral.
[David>] Albeit a widely deployed error.  I acknowledge the worry, and suggest that it deserves further discussion on what can reasonably be expected in deployed Internet infrastructure.

That said, again, is there some reason you think we CANNOT allow the user to turn off OCS (in this case, set to zero)? Again, this is UDP. The risk - and the decision - is up to the user, IMO.
[David>] Asked in that form, I think my “SHOULD use” is in rough agreement with your views.  I suspect that we may not agree on the appropriate tone/emphasis of the text, in that I believe that “SHOULD use” provides an important warning to those who are inclined not to use OCS, and ought to be backed by more specific discussion of the potential things that can go wrong.   I’m also concerned that this discussion may be oversimplifying a subtle/complex area – e.g., RFC 8085 devotes about 3 pages of text to this topic, including UDP-Lite and IPv6 considerations for UDP checksum usage.

Joe