Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08

"Black, David" <David.Black@dell.com> Mon, 20 May 2019 15:16 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 E3F4B1201EF for <tsvwg@ietfa.amsl.com>; Mon, 20 May 2019 08:16:55 -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_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, 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=MRY0ZOaU; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=feIvWFdv
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 FRJJLjC5YePR for <tsvwg@ietfa.amsl.com>; Mon, 20 May 2019 08:16:50 -0700 (PDT)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.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 6497B1201E2 for <tsvwg@ietf.org>; Mon, 20 May 2019 08:16:50 -0700 (PDT)
Received: from pps.filterd (m0170396.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4KF4u86006068; Mon, 20 May 2019 11:16:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=/mQZbOiAMzd4y5eqSVrG04JkkNxG+yP/bqKYbav1pLA=; b=MRY0ZOaUD0oI0F4lqDWQwZxwntXlliafssB3vKDhuu9my3hk62CH53UvbVmxAJX+dhiz olDn0rmomBX33KdbulzdAz8bpxqx33CDSb4dIYmIIBjb4HJdGrfFaYSOWhwpN0TgBAYa bT7dCyq9X+i0kgFDCQQWdOVeUfrb8OP/iaSIGm55oK3TaZ0S8Awlt/Qn+U80WcCnR2gP D7dOoRU1NK4LChPGVnwPP42sIhCFnE6kehxuSFxSbm/+RIeu9KW8l1M5rmOjXbBIP0iq /yvHTEoWpaevXP1RKP/kCamKiBfHSUEQre+cY4Jr8H6qRsUHXgURnZgTvuLfLwWnEPLV LQ==
Received: from mx0a-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 2sjdvxcgdp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 20 May 2019 11:16:05 -0400
Received: from pps.filterd (m0089484.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4KF2nl5063990; Mon, 20 May 2019 11:16:05 -0400
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by mx0b-00154901.pphosted.com with ESMTP id 2skx85rjyw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 20 May 2019 11:16:05 -0400
Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x4KFG3r5017187 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 May 2019 11:16:03 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com x4KFG3r5017187
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1558365364; bh=j2iaWF9MkcksRG84eHt4bMgKAPY=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=feIvWFdvaZSaVLbEyK8vfTZNvJ/BVVXQD7RKDBEpKbIehyC0H42sHbADUVP5xtbgk 5GK0kO/iFireFtZmBdrrg8M42MDk81Dd2CLmp4vBYXUGegUfGOdCa4QL83rHlUmSRk 8/KksArVupo6qKdgw8XWOojbamWKdGOGc+mf346I=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com x4KFG3r5017187
Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd05.lss.emc.com (RSA Interceptor); Mon, 20 May 2019 11:15:42 -0400
Received: from MXHUB321.corp.emc.com (MXHUB321.corp.emc.com [10.146.3.99]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x4KFFfXw002747 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 20 May 2019 11:15:42 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB321.corp.emc.com ([10.146.3.99]) with mapi id 14.03.0439.000; Mon, 20 May 2019 11:15:41 -0400
From: "Black, David" <David.Black@dell.com>
To: Bob Briscoe <ietf@bobbriscoe.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08
Thread-Index: AdUGAGT4Th8zbG5rQXClmZ/2hSiF0gAAs+7gAZfidQAAGJaicAAZHhAAABHUYIAAasL0YA==
Date: Mon, 20 May 2019 15:15:40 +0000
Message-ID: <CE03DB3D7B45C245BCA0D24327794936305727C6@MX307CL04.corp.emc.com>
References: <CE03DB3D7B45C245BCA0D243277949363055BC3F@MX307CL04.corp.emc.com> <CE03DB3D7B45C245BCA0D243277949363055BDDC@MX307CL04.corp.emc.com> <89e67cfc-9574-c7a7-b837-c909c2180595@bobbriscoe.net> <CE03DB3D7B45C245BCA0D243277949363056D070@MX307CL04.corp.emc.com> <d8ab6fb1-250b-2bf4-64ae-c3572f9a10d4@bobbriscoe.net> <63cb3350-7abe-7ec1-cd49-a983105111f6@bobbriscoe.net>
In-Reply-To: <63cb3350-7abe-7ec1-cd49-a983105111f6@bobbriscoe.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.21.130]
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D24327794936305727C6MX307CL04corpem_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-20_07:, , 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-1905200099
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-1905200099
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/WbrXgIYBKK02BK75yDJrtJAbjzU>
Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08
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: Mon, 20 May 2019 15:16:56 -0000

I noticed that network operators are a primary target of the text involved, hence the interest in a BCP.  Let's set that aside for now, more inline ...

Thanks, --David

From: Bob Briscoe <ietf@bobbriscoe.net>
Sent: Saturday, May 18, 2019 3:58 AM
To: Black, David; tsvwg@ietf.org
Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08


[EXTERNAL EMAIL]
David, An extra thought added to (d) below...
On 18/05/2019 00:27, Bob Briscoe wrote:
David,

Three push backs and a question:
a) The MUST and SHOULD you quote below are surely not BCP, they are straight protocol implementation spec.
[David>] Indeed they are.

b) I believe it is important that this safety update to RFC6040 is formally flagged as an update, so it gets noticed and hopefully acted upon.
[David>] Agree.

c) Also, all the updates to specific protocols in the shim draft start with a section like the following example:
5.1.4.1<https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-08#section-5.1.4.1>.  Safe Configuration of a 'Non-ECN' Ingress AMT Relay

   The following text is appended to Section 4.2.2 of [RFC7450]<https://tools.ietf.org/html/rfc7450#section-4.2.2> as an

   update to the AMT specification:



      The operator of an AMT relay that does not support RFC 6040<https://tools.ietf.org/html/rfc6040> or one

      of its compatible predecessors (RFC 4301<https://tools.ietf.org/html/rfc4301> or the full functionality

      mode of RFC 3168<https://tools.ietf.org/html/rfc3168>) MUST follow the configuration requirements in

      Section 4<https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-08#section-4> of RFCXXXX to ensure it clears the outer IP ECN field to

      zero. {RFCXXXX refers to the present document so it will need to

      be inserted by the RFC Editor}

For implementers updating a particular protocol (e.g. AMT) it would be gratuitously weird to have moved Section 4 into a different RFC (especially one that did not have PS status).
[David>] Ok, and that 5.1.4.1 text (and analogs) is BCP-like text, but ok to use here.

d) Do you agree with my assessment that the MUST you quote below doesn't make anything non-compliant that wasn't already non-compliant with 2474. And anything that wants to claim support for anything to do with ECN has to comply with the aspect of 2474 that split off the last 2 bits from the ToS byte?
[David>] Maybe, let's see where this discussion goes:
> If any equipment does not satisfy the proposed 'MUST' statement above, it will not
> be treating the DSCP and the ECN fields independently. Such equipment would not
> have complied with RFC2474, which separated out the last 2 bits of the ToS byte, which made it possible to specify ECN in the first place.
[David>] I agree that a tunnel implementation whose ingress blindly copies the inbound DSCP/ECN byte to the outer header and whose egress discards the outer header is not compliant with RFC 2474.  The S.4 text change suggested below helps:

If so, there's no longer a problem to solve. Let's move on. This has dragged on long enough.

[BB] Would the following text change to S.4 of the shim draft also help?

CURRENT:

   There might be concern that the above "MUST" makes compliant

   equipment non-compliant at a stroke.  However, any equipment that is

   still treating the former ToS octet (IPv4) or the former Traffic

   Class octet (IPv6) as a single 8-bit field is already non-compliant,

   and has been since 1998 when the upper 6 bits were separated off for

   the Diffserv field [RFC2474<https://tools.ietf.org/html/rfc2474>], [RFC3260<https://tools.ietf.org/html/rfc3260>].
SUGGESTED:

   There might be concern that the above "MUST" makes compliant

   equipment non-compliant at a stroke.  However, by definition it solely applies to

   equipment that provides Diffserv configuration. Any such Diffserv equipment that is

   configuring treatment of the former ToS octet (IPv4) or the former Traffic

   Class octet (IPv6) as a single 8-bit field must have always been non-compliant

   with the definition of the 6-bit Diffserv codepoint in [RFC2474<https://tools.ietf.org/html/rfc2474>].

[David>] Here's the "MUST" requirement text that is referenced:

      *  it MUST make propagation of the ECN field between inner and
         outer IP headers independent of any configuration of Diffserv
         codepoint propagation;

[David>]  That requirement text uses somewhat different language than the added explanation.

If we could rephrase that "MUST" to better align with the latter sentence in the suggested text, I would be happier, e.g.:

      *  it MUST NOT treat the former ToS octet (IPv4) or the former Traffic
          Class octet (IPv6) as a single 8-bit field, as the resulting linkage
          of ECN and Diffserv codepoint field propagation between inner and
          outer is not consistent with the definition of the 6-bit Diffserv
          codepoint field in [RFC2474];

[David>]  However, that feels like a change from the original text.  I suspect the immediately following "SHOULD" on the ability to zero the outer ECN field on tunnel ingress gets the rest of the necessary "clue" across to implementers, but I'm not confident that I haven't weakened the original "MUST" text  in a way that matters.  What's your view?


Bob




Bob

PS. Thx for other response on ecn-encap - mañana.

On 17/05/2019 16:34, Black, David wrote:
Before going further down the compliance rathole, let me suggest an alternative that might resolve this quickly.

The crucial text (whose technical correctness is not in question) is:

      In order that the network operator can comply with the above
      safety rules, even if an implementation of a tunnel ingress does
      not claim to support RFC 6040, RFC 4301 or the full functionality
      mode of RFC 3168:

      *  it MUST make propagation of the ECN field between inner and
         outer IP headers independent of any configuration of Diffserv
         codepoint propagation;

      *  it SHOULD be able to be configured to zero the outer ECN field.

The headaches are being caused by treating that text as an update to RFC 6040, but looking at it now,
it reads like a best current practice recommendation, so ...

Would it be reasonable to move that text into the ecn-encapsulation draft (which is intended to become
a BCP)?  Doing that would sidestep the entire discussion of consequences of the consequences of
updating RFC 6040 with that text.

If that sounds plausible, we should take a look at whether any of the other RFC 6040 update text in section
4 should likewise be moved to the ECN encapsulation draft.

Thanks, --David

From: Bob Briscoe <ietf@bobbriscoe.net><mailto:ietf@bobbriscoe.net>
Sent: Thursday, May 16, 2019 7:44 PM
To: Black, David; tsvwg@ietf.org<mailto:tsvwg@ietf.org>
Subject: Re: [tsvwg] David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08


[EXTERNAL EMAIL]
David,

I'll split your email in two and solely deal with the major issue first. See inline.
On 09/05/2019 02:08, Black, David wrote:
idnits found a couple of minor things:

  *   Current reference for IKEv2 is RFC 7296 instead of RFC 5996
  *   If any text was copied from pre-5378 RFCs, an additional boilerplate disclaimer is required.

Thanks, --David

From: Black, David
Sent: Wednesday, May 8, 2019 8:50 PM
To: tsvwg@ietf.org<mailto:tsvwg@ietf.org>
Subject: David Black's WGLC review of draft-ietf-tsvwg-rfc6040update-shim-08

This is a solidly written draft on updating tunnel protocols that use shim headers to propagate ECN according to RFC 6040.

Unfortunately, I found a major issue with the updates [1] along with a few minor issues (easily dealt with) and a bunch of editorial items.

The major issue [1] on updates creating non-compliant implementations looks like it will need WG discussion on what should be done, as the "right thing to do" appears to be in potential conflict with deployed "running code".

--- Major ---

[1] Compliance with RFC 6040 update

Section 3.1 says:

   However, an RFC has no jurisdiction over implementations that choose
   not to comply with it or cannot comply with it, including all those
   implementations that pre-dated the RFC.  Therefore it would have been
   unreasonable to add such a requirement to RFC 6040.

But then Section 4 goes on to do exactly that by updating RFC 6040 to
add this text:

      In order that the network operator can comply with the above
      safety rules, even if an implementation of a tunnel ingress does
      not claim to support RFC 6040, RFC 4301 or the full functionality
      mode of RFC 3168:

      *  it MUST make propagation of the ECN field between inner and
         outer IP headers independent of any configuration of Diffserv
         codepoint propagation;

      *  it SHOULD be able to be configured to zero the outer ECN field.

followed by this attempt to excuse the result:

   There might be concern that the above "MUST" makes compliant
   equipment non-compliant at a stroke.  However, any equipment that is
   still treating the former ToS octet (IPv4) or the former Traffic
   Class octet (IPv6) as a single 8-bit field is already non-compliant,
   and has been since 1998 when the upper 6 bits were separated off for
   the Diffserv field [RFC2474], [RFC3260].  For instance, copying the
   ECN field as a side-effect of copying the DSCP is a seriously unsafe
   bug that risks breaking the feedback loops that regulate load on a
   tunnel.

These three chunks of text need to be aligned..  I'm not sure what should
be done here, as the concern about updating RFC 6040 to cause non-compliance
is an important concern.
[BB] This draft proposes to update RFC6040, which in turn updated RFC3168, which in turn updated RFC2474 (there were other RFCs in the tree of updates ending at RFC6040, but those updates were not with respect to the Diffserv/ECN fields).

I fully agree that we have to be careful not to make any equipment that already complies with any of these RFCs non-compliant. And we don't...

If any equipment does not satisfy the proposed 'MUST' statement above, it will not be treating the DSCP and the ECN fields independently. Such equipment would not have complied with RFC2474, which separated out the last 2 bits of the ToS byte, which made it possible to specify ECN in the first place.

So the proposed 'MUST' statement does not make any equipment that complied with any of these RFCs non-compliant, unless it was already non-compliant with RFC2474. And RFC2474 grandfathered all these RFCs. So the equipment would already be non-compliant with all these RFCs.

Now, check the detailed wording:
      even if an implementation of a tunnel ingress does
      not claim to support RFC 6040, RFC 4301 or the full functionality
      mode of RFC 3168:

      *  it MUST make propagation of the ECN field between inner and
         outer IP headers independent of any configuration of Diffserv
         codepoint propagation;

You'll notice RFC2474 is not in the list of RFCs that an implementation might even not claim to support. That's because the MUST is about Diffserv configuration. If equipment offers any Diffserv configuration, it already has to comply with RFC2474. However, if it doesn't already comply with this MUST, it already doesn't comply with RFC2474.

So again, this MUST does not make any equipment that complied with any of the chain of RFCs non-compliant, unless they were already non-compliant with RFC2474, and therefore non-compliant with all the RFCs in the chain of updates up to RFC6040, because RFC2474 grandfathered the chain.





Analogous non-compliance concerns apply to the updates to other RFCs in
Section 5 to varying degrees.

If you accept my arguments above, but can still find other non-compliance concerns, please do point them out.

Nonetheless, I'm pretty sure I've been similarly careful to avoid introducing any non-compliance surprises.



Bob






--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/



--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/



--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/