Re: [Dots] Adam Roach's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Tue, 07 May 2019 12:43 UTC

Return-Path: <TirumaleswarReddy_Konda@mcafee.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF3C1200BA; Tue, 7 May 2019 05:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 RTkzGhMByFEc; Tue, 7 May 2019 05:43:22 -0700 (PDT)
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 A96A9120077; Tue, 7 May 2019 05:43:21 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1557232593; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=9 DeYSGKV4pycM42piYdpmqiCgKG9Gcob0Y6S8wizTD Q=; b=btoySR7+ICBq9WEWW6cMNqzXkQU2D9g+ZV+Q6oRkkYwM ErKxGKEDjl5S4BfxDsXvcdfXPMVgxceSBCa+VjbEDbTXk+qEJd Fomi+RyIydwhA2+r2x+yqqvLNI2B9Qv5OD0shTmxnojWk07FU7 F2vQfXL2DiIIZgY+UYrwPt2V2Tk=
Received: from DNVEXAPP1N05.corpzone.internalzone.com (DNVEXAPP1N05.corpzone.internalzone.com [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 528b_0ecd_58df9714_3bab_4d65_950f_5f63b31f0e9c; Tue, 07 May 2019 06:36:33 -0600
Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 7 May 2019 06:42:49 -0600
Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 7 May 2019 06:42:49 -0600
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 7 May 2019 06:42:48 -0600
Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2998.namprd16.prod.outlook.com (20.178.235.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.11; Tue, 7 May 2019 12:42:46 +0000
Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::8921:8f4d:4710:4379]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::8921:8f4d:4710:4379%2]) with mapi id 15.20.1856.012; Tue, 7 May 2019 12:42:46 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Benjamin Kaduk <kaduk@mit.edu>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
CC: "draft-ietf-dots-signal-channel@ietf.org" <draft-ietf-dots-signal-channel@ietf.org>, Adam Roach <adam@nostrum.com>, "dots@ietf.org" <dots@ietf.org>, Liang Xia <frank.xialiang@huawei.com>, "The IESG" <iesg@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>
Thread-Topic: [Dots] Adam Roach's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)
Thread-Index: AQHVAMcyf3g1859iiUOeeJIx2grdhaZeVjAAgAEudbA=
Date: Tue, 7 May 2019 12:42:45 +0000
Message-ID: <BYAPR16MB2790F2A13E90ED0A4DBDC0FAEA310@BYAPR16MB2790.namprd16.prod.outlook.com>
References: <155677323500.2690.13635225040710635105.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA68BB3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <20190506165056.GI19509@kduck.mit.edu>
In-Reply-To: <20190506165056.GI19509@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-originating-ip: [49.37.205.191]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ddcd3e73-38e8-4824-7ddf-08d6d2e98188
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR16MB2998;
x-ms-traffictypediagnostic: BYAPR16MB2998:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <BYAPR16MB29982D7E1CD30079D3F80AD6EA310@BYAPR16MB2998.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0030839EEE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(396003)(346002)(136003)(366004)(13464003)(199004)(32952001)(189003)(66066001)(4326008)(2501003)(486006)(6306002)(9686003)(53936002)(2171002)(53946003)(52536014)(68736007)(102836004)(5660300002)(186003)(6436002)(53546011)(2906002)(6506007)(25786009)(476003)(26005)(6246003)(33656002)(229853002)(11346002)(446003)(305945005)(74316002)(3846002)(6116002)(55016002)(7736002)(81156014)(81166006)(8676002)(86362001)(966005)(72206003)(478600001)(316002)(71200400001)(110136005)(71190400001)(8936002)(80792005)(5024004)(54906003)(76116006)(256004)(14444005)(14454004)(30864003)(73956011)(76176011)(99286004)(66946007)(7696005)(66446008)(66556008)(64756008)(66476007)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2998; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: xwrpGFRSUkjbLc2g1iz3HnOKRlHmhk4FqWvo4u5pF6rFm+dpg5qt5JLoMrW2g9txAluhFW3NLJ/FmWhlEnbmne/mMJ8CIQ9xQTaFtGKDXJlkIRIHFqGP2EkU5JHVQJUMaRpTH7nivxTtxXkumIIbNm2Fi4p98/FzA/sIruIiRSpz148GLhzxH11FdS2ZyEcUYB1ebvyPFPkkneRWiuL0+kEO6pZzas7jwgM3q7Ox3jAKJ3VN3BmpQd7QS4IehqaQdT4j8sRkwaPjRnHEaGLAOSUDIDBM0tUaU3JWwqe5Dy80M6f2fuAcPfhmoc+y3D7QmiMPocSUI0+QSriCLRs4y9F5HugG5jrgMzT6v90R/L6RQaaUfyfpCjxczCkA4g9/pyJX93fHIDHN9vbJR+E1VGIxLKPKsUf5ra7fP+/6BnE=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ddcd3e73-38e8-4824-7ddf-08d6d2e98188
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2019 12:42:46.0862 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR16MB2998
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0
X-NAI-Spam-Version: 2.3.0.9418 : core <6540> : inlines <7074> : streams <1820832> : uri <2841555>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/swlcbTtFVejRp69pYVtlkAol3o8>
Subject: Re: [Dots] Adam Roach's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 May 2019 12:43:26 -0000

> -----Original Message-----
> From: Dots <dots-bounces@ietf.org> On Behalf Of Benjamin Kaduk
> Sent: Monday, May 6, 2019 10:21 PM
> To: mohamed.boucadair@orange.com
> Cc: draft-ietf-dots-signal-channel@ietf.org; Adam Roach
> <adam@nostrum.com>om>; dots@ietf.org; Liang Xia
> <frank.xialiang@huawei.com>om>; The IESG <iesg@ietf.org>rg>; dots-
> chairs@ietf.org
> Subject: Re: [Dots] Adam Roach's Discuss on draft-ietf-dots-signal-channel-31:
> (with DISCUSS and COMMENT)
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> On Thu, May 02, 2019 at 09:12:01AM +0000,
> mohamed.boucadair@orange.com wrote:
> > Re-,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Adam Roach via Datatracker [mailto:noreply@ietf.org] Envoyé :
> > > jeudi 2 mai 2019 07:01 À : The IESG Cc :
> > > draft-ietf-dots-signal-channel@ietf.org; Liang Xia; dots-
> > > chairs@ietf.org; frank.xialiang@huawei.com; dots@ietf.org Objet :
> > > Adam Roach's Discuss on draft-ietf-dots-signal-channel-31: (with
> > > DISCUSS and COMMENT)
> > >
> > > Adam Roach has entered the following ballot position for
> > > draft-ietf-dots-signal-channel-31: Discuss
> > >
> > > When responding, please keep the subject line intact and reply to
> > > all email addresses included in the To and CC lines. (Feel free to
> > > cut this introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > DISCUSS:
> > > --------------------------------------------------------------------
> > > --
> > >
> > > Thanks for all the work everyone put into this document. I think
> > > it's great to have a solution defined for automating these kinds of
> > > operations, and look forward to widespread deployment of this
> > > technology. I do have a small number of comments that I think we
> > > need to close on prior to publication, and a handful of other
> > > suggestions of varying (but lesser) importance.
> > >
> > > --------------------------------------------------------------------
> > > -------
> > >
> > > This is a discuss because the current document attempts to override
> > > normative language in an external document.
> > >
> > > §4.3:
> > >
> > > >  In reference to Figure 4, the DOTS client sends two TCP SYNs and
> > > > two  DTLS ClientHello messages at the same time over IPv6 and IPv4.
> > >
> > > This is problematic for the reason described in RFC 8305 §5 ("In
> > > order to avoid unreasonable network load, connection attempts SHOULD
> > > NOT be made simultaneously").
> > >
> >
> > [Med] I would agree with you if the text in 8305 is using MUST NOT.
> >
> > It is completely fine to send requests sequentially when not attack is
> ongoing, but if a connection is to be established during attack time (e.g.,
> redirect), sending the requests simultaneously would be appropriate so that
> an attack mitigation is placed as ASAP.
> 
> Violating a SHOULD NOT still requires some analysis and justification.
> Blatantly violating it (i.e., a 4x factor rather than 2x) probably requires a
> stronger justification still.

My understanding is RFC 8305 suggests SHOULD NOT because it will be used by endpoints, and if every endpoint initiates connection attempts simultaneously to every domain the end user visits, it would introduce network load. However for DOTS signal channel, connection attempts will only be initiated by DOTS client (typically co-located on the network security services like DDoS mitigator, firewall, IPS). I don't think unreasonable network load would be introduced by a really small number of DOTS clients making connection attempts to the DOTS server. 

> 
> >
> > > To be clear, my discuss is only on the fact that this document
> > > violates a normative statement in RFC 8305. The following comments
> > > are merely my thoughts on the best way to resolve this issue.
> > >
> > > It's also worth noting that RFC 8305 is geared towards getting users
> > > the fastest possible response to a user action, while the text in
> > > DOTS implies that the selection of the "most preferred" connection
> > > is significantly more important
> >
> > [Med] Yes.
> >
> > > (e.g., it talks about migrating from TCP to UDP, and performing
> > > periodic checks to enable such a migration). This factor, combined
> > > with the fact that this is not a transaction that involves user
> > > interactivity requirements, would seem to increase, rather than
> > > decrease, the desire to space out checks across the various
> > > transport/address-family pairs.
> > >
> > > My strong recommendation would be remove the specific description of
> >
> > [Med] This is not that straightforward because of specifics to the DOTS case,
> e.g., probing, caching, no need to cancel other connections if a first one wins,
> etc.
> >
> > > happy-eyeballs-like behavior from this document, and to instead
> > > defer all such specification to the text in RFC 8305. I would
> > > further recommend specification of a "Connection Attempt Delay" (as
> > > that term is defined in RFC 8305) that is substantially larger than
> > > those used for interactive connections: something on the order of 2
> > > to 5 seconds would be my suggestion.
> > >
> > > Of course, be sure to adjust the example to match the specified handling.
> > >
> > >
> > > --------------------------------------------------------------------
> > > -------
> > >
> > > This is a discuss because it impacts interoperability.
> > >
> > > §4.4.1:
> > >
> > > >  target-uri:   A list of Uniform Resource Identifiers (URIs) [RFC3986]
> > > >     identifying resources under attack.
> > >
> > > This definition needs to be clearer about what parts of the URI are
> > > used for what purposes.
> >
> > [Med] The text does not define any restriction. All parts may be included..
> >
> > The text focuses on the host part as this is sensitive:
> >
> >       The same validation checks used for 'target-fqdn' MUST be followed
> >       by DOTS servers to validate a target URI.
> >
> > How other parts are used is trivial, IMO.
> 
> If we call out one part for special handling, we should at least mention that
> the other parts can still be used.

We can add the following the line:
The IP addresses to which DNS domain name portion of URI resolves represent the scope of the mitigation. The mitigation technique used by the DDoS mitigation provider based on the URI is implementation specific (e.g. Puzzles, Reverse Turning tests etc.). 

Cheers,
-Tiru

> 
> >  For example:
> > >
> > >  - The URI scheme can be taken to specify a 'target-protocol'
> > >  - The URI host can be taken to specify a 'target-fqdn' or 'target-prefix'
> > >  - The URI port (or scheme, if absent) can be taken to specify a
> > >    'target-port-range'
> > >
> > > It is unclear whether this specification intends the URI to impact
> > > one, two, or all three of these. This can result in a client asking
> > > for one thing and the server doing something else.
> > >
> > > --------------------------------------------------------------------
> > > -------
> > >
> > > This is a discuss because it impacts interoperability.
> > >
> > > §6:
> > >
> > > The handling of 64-bit values in Table 4 seems problematic. Section
> > > 3
> > > specifies:
> > >
> > > >  Representing these data
> > > >  as CBOR data can either follow the rules in
> > > > [I-D.ietf-core-yang-cbor]  or those in [RFC7951] combined with
> > > > JSON/CBOR conversion rules in  [RFC7049]; both approaches produce a
> valid encoding.
> > >
> > > However, if we consider, say, mitigation-start:
> > >
> > > >  +----------------------+-------------+-----+---------------+--------+
> > > >  | Parameter Name       | YANG        | CBOR| CBOR Major    | JSON   |
> > > >  |                      | Type        | Key |    Type &     | Type   |
> > > >  |                      |             |     | Information   |        |
> > > >
> > > > +----------------------+-------------+-----+---------------+------
> > > > --+
> > > > ...
> > > >  | mitigation-start     | uint64      |  15 | 0 unsigned    | String |
> > >
> > >
> > > If an implementation follows the first path
> > > (draft-ietf-core-yang-cbor), then this value is sent on the wire as
> > > a CBOR 64-bit unsigned integer type. If an implementation instead
> > > uses RFC 7951 followed by RFC 7049 §4, the resulting value is encoded on
> the wire as a CBOR string.
> >
> > [Med] Both are valid.
> >
> > >
> > > If this is the intention, then it represents a huge gotcha for
> > > implementors of both clients and of servers, as all implementations
> > > must be ready to accept both strings and 64-bit data types for these
> > > fields.
> >
> > [Med] No, an implementer does not need to do the mapping. An
> implementer only needs to rely upon the mapping table provided in Section
> 6.
> >
> > If this is the
> > > intention, please add strongly-worded text warning implementors of
> > > this particular gotcha, since it's pretty non-obvious.
> > >
> >
> > [Med] We do already have the following:
> >
> >    All parameters in the payload of the DOTS signal channel MUST be
> >    mapped to CBOR types as shown in Table 4 ...
> 
> If the intention is to make Table 4 the normative rule and either/both
> enocding references advisory, then we need a drastic change to how the
> references are introduced with a big disclaimer that we do some things
> differently.  My personal preference (as you may recall from AD review)
> would just be to pick one encoding procedure and make that normative, and
> call out the potential "gotcha"s of using the other procedure, though of
> course my personal preference should not decide what we do.
> 
> > > It's worth noting that, while some implementations may set limits on
> > > the precision of JSON Numbers, and that such limits may be smaller
> > > than 64 bits, nothing in the format defined by RFC 8259 has any such
> inherent limitations.
> > >
> > > There is a similar (but subtly different) problem with the handling
> > > of enumerations that may cause them to be encoded as either strings
> > > or as
> > > integers:
> > >
> > > >  | status               | enumeration |  16 | 0 unsigned    | String |
> > >
> > > If you choose to maintain the situation currently described in the
> > > document, then the table in section 9.6.1.2 needs to be updated to
> > > allow both formats;
> > > e.g.:
> > >
> > > >  +----------------------+-------+-------+------------+---------------+
> > > >  | Parameter Name       | CBOR  | CBOR  | Change     | Specification |
> > > >  |                      | Key   | Major | Controller | Document(s)   |
> > > >  |                      | Value | Type  |            |               |
> > > >
> > > > +----------------------+-------+-------+------------+-------------
> > > > --+
> > > ...
> > > >  | mitigation-start     |   15  | 0 or 3|    IESG    |   [RFCXXXX]   |
> > >
> >
> > [Med] This will lead to interoperability problems. We just need to pick one
> and record it in the spec.
> >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > COMMENT:
> > > --------------------------------------------------------------------
> > > --
> > >
> > > §3:
> > >
> > > >  The other method
> > > >  DOTS agents use to indicate that a CBOR data structure is a DOTS
> > > > signal channel object is the use of the "application/dots+cbor"
> > > >  content type (Section 9.3).
> > >
> > > Nit: "...structure as a..."
> > >
> > > --------------------------------------------------------------------
> > > -------
> > >
> > > §4.4.1:
> > >
> > > >     Figure 6: PUT to Convey DOTS Mitigation Requests (Message Body
> > > >                                 Schema)
> > >
> > > This seems to be a very informal sketch rather than a formal schema.
> > > It's probably worth calling forward to Section 6 as the formal
> > > definition of the schema, and being clearer that this figure (and
> > > other similar figures) are non-normative sketches of the rough
> > > structure.
> > >
> >
> > [Med] Good point. Done.
> >
> > > --------------------------------------------------------------------
> > > -------
> > >
> > > §4.4.1:
> > >
> > > >     Implementations SHOULD set 'cuid' to the output of a cryptographic
> > > >     hash algorithm whose input is the Distinguished Encoding Rules
> > > >     (DER)-encoded Abstract Syntax Notation One (ASN.1) representation
> > > >     of the Subject Public Key Info (SPKI) of the DOTS client X.509
> > > >     certificate [RFC5280], the DOTS client raw public key [RFC7250],
> > > >     or the "Pre-Shared Key (PSK) identity" used by the DOTS client in
> > > >     the TLS ClientKeyExchange message.  In this version of the
> > > >     specification, the cryptographic hash algorithm used is SHA-256
> > > >     [RFC6234].  The output of the cryptographic hash algorithm is
> > > >     truncated to 16 bytes; truncation is done by stripping off the
> > > >     final 16 bytes.  The truncated output is base64url encoded.
> > >
> > > It's not clear how much of this is a recommendation and how much of
> > > it is mandatory.
> >
> > [Med] This is not mandatory, but a recommended approach for the
> reasons detailed in a new appendix we added to the draft:
> >
> > ==
> > Appendix A.  CUID Generation
> >
> >    The document recommends the use of SPKI to generate the 'cuid'.  This
> >    design choice is motivated by the following reasons:
> >
> >    o  SPKI is globally unique.
> >
> >    o  It is deterministic.
> >
> >    o  It allows to avoid extra cycles that may be induced by 'cuid'
> >       collision.
> >
> >    o  DOTS clients do not need to store the 'cuid' in a persistent
> >       storage.
> >
> >    o  It allows to detect compromised DOTS clients that do not adhere
> > to the 'cuid' generation algorithm.
> > ==
> >
> >  For example: if I'm a server, would it be reasonable for me to
> > > expect
> > > the CUID to be BASE-64 (e.g., to minimize the size of an index
> > > structure) and error out if it contains characters other than those allowed
> in base64url?
> > >
> > > It's also not clear that "SHOULD" is entirely called for here,
> > > especially since the following paragraph's statement that 'cuid' can
> > > vary based on remote host (which requires a variation from the
> > > normative algorithm). Consider the definition of SHOULD:
> > >
> > >   3. SHOULD   This word, or the adjective "RECOMMENDED", mean that
> there
> > >      may exist valid reasons in particular circumstances to ignore a
> > >      particular item, but the full implications must be understood and
> > >      carefully weighed before choosing a different course.
> > >
> > > This seems potentially stronger than what is called for here.
> > > Consider specifying this behavior non-normatively, and reserve the
> > > normative language for the actual requirement (e.g., "MUST be
> > > globally unique")
> > >
> >
> > [Med] That is an option, but we wanted a recommendation for the reasons
> listed in the NEW appendix.
> 
> It may still be worth listing the hard requirements, even if a recommended
> way to achieve them is presented.
> 
> > > --------------------------------------------------------------------
> > > -------
> > >
> > > §4.4.1:
> > >
> > > >     As a reminder, the prefix length must be less than or equal to 32
> > > >     (resp. 128) for IPv4 (resp.  IPv6).
> > >
> > > This is a notation that I haven't seen before, and it may serve to
> > > confuse implementors. Consider rephrasing as: "...less than or equal
> > > to 32 for IPv4, and less than or equal to 128 for IPv6."
> >
> > [Med] OK. Changed to "to 32 (or 128) for IPv4 (or IPv6)."
> >
> > >
> > > --------------------------------------------------------------------
> > > -------
> > >
> > > §4.4.1:
> > >
> > > >  This PUT request MUST use the
> > > >  same 'mid' value, and MUST repeat all the other parameters as
> > > > sent in  the original mitigation request apart from a possible
> > > > change to the  lifetime parameter value.
> > >
> > > Is the server intended to detect violations of this? How would it react?
> >
> > [Med] The spec leaves it to the server to decide how to handle the refresh
> (policy-based):
> >
> >    If the DOTS server finds the 'mid' parameter value conveyed in the
> >    PUT request in its configuration data bound to that DOTS client, it
> >    MAY update the mitigation request, and a 2.04 (Changed) response is
> >    returned to indicate a successful update of the mitigation request.
> 
> Does that imply that it is optional for the server to detect violations (in terms
> of answering Adam's question)?
> 
> >
> > > (Section 4.4.3 says to send a 4.00 if the request was an Efficacy
> > > Update; this is probably the correct general answer, and should be
> > > specified here).
> > >
> > > --------------------------------------------------------------------
> > > -------
> > >
> > > §4.4.2:
> > >
> > > >  {
> > > >    "ietf-dots-signal-channel:mitigation-scope": {
> > > >      "scope": [
> > > >        {
> > > >          "mid": 12332,
> > > >          "mitigation-start": "1507818434",
> > > >          "target-prefix": [
> > > >               "2001:db8:6401::1/128",
> > > >               "2001:db8:6401::2/128"
> > > >          ],
> > > >          "target-protocol": [
> > > >            17
> > > >          ],
> > > >          "lifetime": 1756,
> > > >          "status": "attack-successfully-mitigated",
> > > >          "bytes-dropped": "134334555",
> > > >          "bps-dropped": "43344",
> > > >          "pkts-dropped": "333334444",
> > > >          "pps-dropped": "432432"
> > > >        },
> > > >        {
> > > >          "mid": 12333,
> > > >          "mitigation-start": "1507818393",
> > > >          "target-prefix": [
> > > >               "2001:db8:6401::1/128",
> > > >               "2001:db8:6401::2/128"
> > > >          ],
> > > >          "target-protocol": [
> > > >            6
> > > >          ],
> > > >          "lifetime": 1755,
> > > >          "status": "attack-stopped",
> > > >          "bytes-dropped": "0",
> > > >          "bps-dropped": "0",
> > > >          "pkts-dropped": "0",
> > > >          "pps-dropped": "0"
> > > >        }
> > > >      ]
> > > >    }
> > > >  }
> > >
> > > I get that this is intended to be an informal example, but the use
> > > of quotes around values that are formally encoded as integers --
> > > such as "mitigation-start" -- may trip up users.
> >
> > [Med] We are using JSON encoding similar to RFC7951. We will double
> check how to make this clear in the document.
> 
> My apologies for being blunt, but as Adam quotes below, the Section 4.4
> introduction is very explicit that "JSON diagnostic notation is used", which has
> a well-defined syntax and semantics.  If we are to claim to use that notation,
> we must comply with its requirements; contrariwise, if we want different
> semantics/syntax, we need to state clearly what we are doing.
> 
> >
> >  I would strongly suggest removing
> > > quotes from anything encoded as an integer.
> > >
> > > This applies especially to "status". Since these figures have
> > > explicitly been called out as JSON diagnostic notation (and *not*
> > > the JSON structure produced by RFC 7951), the values need to be the
> > > CBOR values sent on the wire. (This relies on an assumption on my
> > > part that may be incorrect, depending on the resolution of the points I
> raise about section 6 in my DISCUSS).
> > >
> > > This comment applies to several other examples, such as Figure 16.
> > >
> > > For Figure 20 (and several subsequent figures), it also applies to
> > > those values encoded as decimals, such as "max-value-decimal".
> > >
> > > --------------------------------------------------------------------
> > > -------
> > >
> > > §4.4.2:
> > >
> > > >  bps-dropped:  The average number of dropped bytes per second for
> the
> > > >     mitigation request since the attack mitigation is triggered.  This
> > > >     average SHOULD be over five-minute intervals.
> > >
> > > The first sentence conflicts with the second:
> > >  - The first sentence says this is the average since mitigation was
> > > triggered.
> > >  - The second sentence says this is a five-minute (rolling?) average.
> > >
> > > Please make them agree with each other.
> > >
> > > If something more subtle is meant -- like measuring bytes into
> > > five-minute buckets and then averaging these buckets over the time
> > > since the mitigation was triggered -- then the text needs more detail to
> convey it.
> > >
> >
> > [Med] We meant something similar to
> https://tools.ietf.org/html/rfc5835#section-5.1.
> 
> (I don't think that's what I had in mind when I did the AD review, so please to
> add some more clarifications!)
> 
> > > This same comment applies to "pps-dropped," as well as the
> > > descriptions of both properties in §5.3.
> > >
> > > --------------------------------------------------------------------
> > > -------
> > >
> > > §5.1:
> > >
> > > >  A DOTS signal
> > > >  message can either be a mitigation or a configuration message.
> > >
> > > This is at odds with both the tree and the text in the YANG module
> > > in §5.3, both of which specify three message types rather than two
> > > (mitigation, configuration, and redirect).
> >
> > [Med] OK.
> >
> > >
> > > --------------------------------------------------------------------
> > > -------
> > >
> > > §5.1:
> > >
> > > >          |     +--ro bps-dropped?            yang:zero-based-counter64
> > > ...
> > > >          |     +--ro pps-dropped?            yang:zero-based-counter64
> > >
> > > These aren't counters in the way that RFC 6021 defines counters.
> > > Both need to be of type "yang:gauge64." This comment, of course,
> > > also bears on §5.3 as well as Table 4.
> >
> > [Med] Hmm. We are using counter64 similar to the usage in the interface
> YANG module, for example.
> 
> I'm not an expert here, but it looks like the "counter" types are constrained
> to only ever increase, and since we report statistics that can vary up or down
> over time, the "gauge" type is correct.
> 
> -Ben
> 
> > >
> > > --------------------------------------------------------------------
> > > -------
> > >
> > > §6:
> > >
> > > >  | trigger-mitigation   | boolean     |  45 | 7 bits 20     | False  |
> > > >  |                      |             |     | 7 bits 21     | True   |
> > >
> > > You might consider cleaning up the JSON column here to just say
> > > "Boolean," as "True" and "False" are values rather than any of the
> > > six types defined in RFC 8259.
> >
> > [Med] I hear you, but we wanted to indicate the extact value
> corresponding the CBOR type. We prefer to leave it. Thanks.
> >
> >  Similarly, to be consistent with the rest of the table, perhaps the
> > > CBOR column here should simply say "7 simple value". Failing that,
> > > consider at least labeling the CBOR values as "False" and "True"
> > > rather than "bits 20"
> > > and
> > > "bits 21".
> > >
> >
> > _______________________________________________
> > Dots mailing list
> > Dots@ietf.org
> > https://www.ietf.org/mailman/listinfo/dots
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots