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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Thu, 02 May 2019 12:47 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 205BC120110; Thu, 2 May 2019 05:47:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 U9KWjR6-TyNs; Thu, 2 May 2019 05:47:23 -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 B055F12002F; Thu, 2 May 2019 05:47:22 -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=1556800856; 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=d 3Wf+D6N2mt9ut0DWTuYmzoTH6qly8q2Dw0eAF7MGK Q=; b=WN6No5iKKhnqUgUlXmu0WHIJoVuzJWLmVtlSKX6Mot9C 8kczhNxt20ZYFhVz3btChXEGm6Hs99gp85CYeLcl3afl8ZlOsK fZz5eRI6ZnxfxrtmS0vp5ju09TY53bQLYO2V7V3r0KrXmWRwD2 PGVrLkQtUaMhNfuRyhgfd1NjSEw=
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 0db5_5e70_43e3b305_19a1_487b_9862_e0fe0fc1b7ae; Thu, 02 May 2019 06:40:55 -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; Thu, 2 May 2019 06:47:11 -0600
Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 2 May 2019 06:47:11 -0600
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 2 May 2019 06:47:09 -0600
Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2440.namprd16.prod.outlook.com (20.177.226.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.16; Thu, 2 May 2019 12:47:08 +0000
Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62%5]) with mapi id 15.20.1835.018; Thu, 2 May 2019 12:47:08 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Alexey Melnikov" <aamelnikov@fastmail.fm>, The IESG <iesg@ietf.org>
CC: "draft-ietf-dots-signal-channel@ietf.org" <draft-ietf-dots-signal-channel@ietf.org>, Liang Xia <frank.xialiang@huawei.com>, "dots@ietf.org" <dots@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>
Thread-Topic: Alexey Melnikov's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)
Thread-Index: AQHVALPzk4IGAmdRUUORb7E5KmipGaZXyAYw
Date: Thu, 2 May 2019 12:47:08 +0000
Message-ID: <BYAPR16MB2790D805F0057AF598F2C0E6EA340@BYAPR16MB2790.namprd16.prod.outlook.com>
References: <155672115649.991.301467308616633255.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA68A2C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA68A2C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
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: 974aef90-b07e-419a-00d5-08d6cefc49e1
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR16MB2440;
x-ms-traffictypediagnostic: BYAPR16MB2440:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BYAPR16MB2440207F52ABA03AF8E8ED42EA340@BYAPR16MB2440.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0025434D2D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(136003)(396003)(366004)(32952001)(13464003)(189003)(199004)(54906003)(316002)(11346002)(30864003)(446003)(81156014)(6506007)(71200400001)(102836004)(71190400001)(81166006)(7736002)(4326008)(2906002)(53546011)(26005)(486006)(305945005)(80792005)(66066001)(6116002)(99286004)(186003)(3846002)(74316002)(33656002)(25786009)(6436002)(72206003)(478600001)(476003)(110136005)(52536014)(68736007)(966005)(66446008)(229853002)(76116006)(66476007)(8676002)(53936002)(66556008)(64756008)(8936002)(86362001)(73956011)(66946007)(6246003)(5660300002)(9686003)(6306002)(76176011)(14454004)(2501003)(14444005)(256004)(55016002)(7696005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2440; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: gklBbuKaSrwEwbrqnPdecpg/VcCKQWWdNl7fmarzixJgUxnkrke1HXGxyGaLocStT37Hll8i59niiJs0rpXrpg8bKQz3AMWpnpthpG5JhI5BDeczjpmz63I4pQWi81OWcI0LDj0YFz4NnpPwxgHDFFdrICvntDzSL7UOA9kpSMlglyWZXfCISMhmi+mbntHsfMNbO8egbCjogiZJFudrwIry59C7U8k4uIn9SFymh8CTvJ6EJtXzEaXRDsPA6yOccPR5DKyl+WV4CkC/dvbf9GkwUBN1DxvmePE2hN4LgTy3BPt8a0jet/y3HNfsanrFGIJlciD9ARc5ulT3eXNGLbxYyymGcdkmLY1E491wCRcX3Oh5nD0Cay15OPpW+PivxELVQul4q8ovBoxci1Q8FUXS6uvYEUHyaVGKIi1nSIQ=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 974aef90-b07e-419a-00d5-08d6cefc49e1
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2019 12:47:08.4275 (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: BYAPR16MB2440
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 <6538> : inlines <7070> : streams <1820354> : uri <2839663>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/Y1k09B-tZSbOss3yumu7Rtgndzg>
Subject: Re: [Dots] Alexey Melnikov'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: Thu, 02 May 2019 12:47:26 -0000

> -----Original Message-----
> From: Dots <dots-bounces@ietf.org> On Behalf Of
> mohamed.boucadair@orange.com
> Sent: Thursday, May 2, 2019 12:24 PM
> To: Alexey Melnikov <aamelnikov@fastmail.fm>fm>; The IESG <iesg@ietf.org>
> Cc: draft-ietf-dots-signal-channel@ietf.org; Liang Xia
> <frank.xialiang@huawei.com>om>; dots@ietf.org; dots-chairs@ietf.org
> Subject: Re: [Dots] Alexey Melnikov's Discuss on draft-ietf-dots-signal-
> channel-31: (with DISCUSS and COMMENT)
> 
> 
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Alexey Melnikov via Datatracker [mailto:noreply@ietf.org] Envoyé
> > : mercredi 1 mai 2019 16:33 À : The IESG Cc :
> > draft-ietf-dots-signal-channel@ietf.org; Liang Xia; dots-
> > chairs@ietf.org; frank.xialiang@huawei.com; dots@ietf.org Objet :
> > Alexey Melnikov's Discuss on draft-ietf-dots-signal-channel-31: (with
> > DISCUSS and COMMENT)
> >
> > Alexey Melnikov 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:
> > ----------------------------------------------------------------------
> >
> > Thank you for a well written document. Despite its length, it was a
> > pleasure to read.
> >
> 
> [Med] Thank you.
> 
> > I have a list of small issues/questions to discuss before I can recommend
> > approval of this document.
> >
> > 1) RFC 3986 must be Normative as you use URI syntax in the document.
> >
> 
> [Med] Done.
> 
> > 2) In 4.4.1: base64url needs a Normative reference. Please point to section
> 5
> > of RFC 4648.
> 
> [Med] Ben did also raised this point. Already fixed in my local copy.
> 
> >
> > 3) Also in the same section:
> >
> >    A DOTS gateway MAY add the CoAP Hop-Limit Option
> >    [I-D.ietf-core-hop-limit].
> >
> > Use of RFC 2119 language makes this reference Normative. Which means
> that
> > this
> > document can't be published as an RFC until [I-D.ietf-core-hop-limit] is
> > published as an RFC.
> 
> [Med] I'm comfortable to move this one to the normative reverences given
> that I-D.ietf-core-hop-limit is ready for the WGLC since at least two months.
> 
> >
> > 4) Later in the same section:
> >
> >    If the request is missing a mandatory attribute, does not include
> >    'cuid' or 'mid' Uri-Path options, includes multiple 'scope'
> >    parameters, or contains invalid or unknown parameters, the DOTS
> >    server MUST reply with 4.00 (Bad Request).  DOTS agents can safely
> >    ignore comprehension-optional parameters they don't understand.
> >
> > How can DOTS agents know which parameters are comprehension-optional?
> 
> [Med] This is done by looking at the key value:
> 
>       Key value for the parameter.  The key value MUST be an integer in
>       the 1-65535 range.  The key values of the comprehension-required
>       range (0x0001 - 0x3FFF) and of the comprehension-optional range
>       (0x8000 - 0xBFFF) are assigned by IETF Review (Section 4.8 of
>       [RFC8126]).  The key values of the comprehension-optional range
>       (0x4000 - 0x7FFF) are assigned by Specification Required
>       (Section 4.6 of [RFC8126]) and of the comprehension-optional range
>       (0xC000 - 0xFFFF) are reserved for Private Use (Section 4.1 of
>       [RFC8126]).
> 
> >
> > 5) In 4.4.2:
> >
> >    The 'c' (content) parameter and its permitted values defined in
> >    [I-D.ietf-core-comi] can be used to retrieve non-configuration data
> >
> > Because you define syntax of the parameter by reference, this makes
> > [I-D.ietf-core-comi] Normative. (It doesn't matter that the feature is
> > optional. Implementors still need to look at [I-D.ietf-core-comi] to
> > implement
> > this aspect of your document.)
> >
> > If you don't want Normative dependency, you should fully specify syntax in
> > your
> > draft and keep the reference Informative.
> >
> 
> [Med] I went with the second approach. Thanks.
> 
> 
> >    (attack mitigation status), configuration data, or both.  The DOTS
> >    server MAY support this optional filtering capability.  It can safely
> >    ignore it if not supported.  If the DOTS client supports the optional
> >    filtering capability, it SHOULD use "c=n" query (to get back only the
> >    dynamically changing data) or "c=c" query (to get back the static
> >    configuration values) when the DDoS attack is active to limit the
> >    size of the response.
> >
> > 6) In 4.4.3:
> >
> >       {
> >        "ietf-dots-signal-channel:mitigation-scope": {
> >          "scope": [
> >            {
> >              "target-prefix": [
> >                 "2001:db8:6401::1/128",
> >                 "2001:db8:6401::2/128"
> >               ],
> >              "target-port-range": [
> >                {
> >                  "lower-port": 80
> >                },
> >                {
> >                  "lower-port": 443
> >                },
> >                {
> >                   "lower-port": 8080
> >                }
> >              ],
> >              "target-protocol": [
> >                 6
> >              ],
> >              "attack-status": "under-attack"
> >
> > This value is invalid, as you define this attribute as numeric on the next
> > page.
> 
> [Med] The example is correct because the JSON encoding is as follows:
> 
>    +----------------------+-------------+-----+---------------+--------+
>    | Parameter Name       | YANG        | CBOR| CBOR Major    | JSON   |
>    |                      | Type        | Key |    Type &     | Type   |
>    |                      |             |     | Information   |        |
>    +----------------------+-------------+-----+---------------+--------+
>    | attack-status        | enumeration |  29 | 0 unsigned    | String |
> 
> >
> >            }
> >          ]
> >        }
> >       }
> >
> > 7) In 7.1:
> >
> >    When a DOTS client is configured with a domain name of the DOTS
> >    server, and connects to its configured DOTS server, the server may
> >    present it with a PKIX certificate.  In order to ensure proper
> >    authentication, a DOTS client MUST verify the entire certification
> >    path per [RFC5280].  The DOTS client additionally uses [RFC6125]
> >    validation techniques to compare the domain name with the certificate
> >    provided.
> >
> > I am glad that you are referencing RFC 6125 here, but the description is not
> > complete. Do you allow for wildcards in certificate subjectAltNames? Do
> you
> > support CN-ID, DNS-ID, SRV-ID, URI-ID? I think you only want to support
> DNS-
> > ID
> > and possibly SRV-ID and CN-ID. This needs to be explicitly stated in the
> > document.
> >
> 
> [Med] Fair enough. Will consider updating the text.

We will add the following text to address the above comment:

      Certification authorities that issue DOTS server certificates
      SHOULD support the DNS-ID and SRV-ID identifier types. 
      DOTS server SHOULD prefer the use of DNS-ID  and SRV-ID 
      over CN-ID identifier types in certificate requests 
      (as described in Section 2.3 from [RFC6125]) and the
      wildcard character '*' SHOULD NOT be included in the presented
      identifier.

Cheers,
-Tiru

> 
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > In Section 3:
> >
> >    DOTS agents primarily determine that a CBOR data structure is a DOTS
> >    signal channel object from the application context, such as from the
> >    port number assigned to the DOTS signal channel.
> >
> > I don't think this is a good idea, because CORE allows for conveying of
> > Content-Format.
> 
> [Med] Agree. We are not recommending it. FWIW, this is why we are
> defining "application/dots+cbor" content type.
> 
>  Besides knowledge of a port number doesn't guaranty that
> > valid
> > CBOR over COAP data is flowing on it.
> >
> >    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).
> >
> > Also in the same section:
> >
> >    This document specifies a YANG module for representing DOTS
> >    mitigation scopes, DOTS signal channel session configuration data,
> >    and DOTS redirected signalling (Section 5).  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.
> >
> > Does this mean that both approaches are normative to implement? (I
> assume
> > they
> > don't procuce identical encoding.)
> 
> [Med] No, they are not normative. What is really key is the mapping table
> included in the spec. Implementers do only need to look at Table 4. We are
> providing to them the rationale for building such table.
> 
> >
> > In 4.1:
> >
> > Is DHCP option for this defined in another document?
> 
> [Med] Yes. I added a pointer to I-D.ietf-dots-server-discovery.
> 
> >
> > In 4.4.1:
> >
> >    lifetime:
> >
> >       A lifetime of negative one (-1) indicates indefinite lifetime for
> >       the mitigation request.  The DOTS server MAY refuse indefinite
> >       lifetime, for policy reasons; the granted lifetime value is
> >       returned in the response.  DOTS clients MUST be prepared to not be
> >       granted mitigations with indefinite lifetimes.
> >
> >       The DOTS server MUST always indicate the actual lifetime in the
> >       response and the remaining lifetime in status messages sent to the
> >       DOTS client.
> >
> > Can you provide any advice to the server what to return for the “indefinite
> > lifetime” requests?
> 
> [Med] This is deployment-specific.
> 
> >
> > In 4.6:
> >
> >    If the DOTS client has been redirected to a DOTS server to which it
> >    has already communicated with within the last five (5) minutes, it
> >    MUST ignore the redirection and try to contact other DOTS servers
> >    listed in the local configuration or discovered using dynamic means
> >    such as DHCP or SRV procedures.
> >
> > You don't define DHCP or SRV based procedures in the document. Is there
> a
> > suitable informative reference to be inserted here?
> 
> [Med] I added a pointer to I-D.ietf-dots-server-discovery.
> 
> >
> > 9.6.1.1.  Registration Template
> >
> >       Registration requests for the 0x4000 - 0x7FFF range are evaluated
> >       after a three-week review period on the dots-signal-reg-
> >       review@ietf.org mailing list,
> >
> > Responsible AD should make sure that the mailing list exists before this
> > document is published.
> >
> >       on the advice of one or more
> >       Designated Experts.
> >
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots