[Dots] Alexey Melnikov's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)
Alexey Melnikov via Datatracker <noreply@ietf.org> Wed, 01 May 2019 14:32 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: dots@ietf.org
Delivered-To: dots@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C99120186; Wed, 1 May 2019 07:32:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alexey Melnikov via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dots-signal-channel@ietf.org, Liang Xia <frank.xialiang@huawei.com>, dots-chairs@ietf.org, frank.xialiang@huawei.com, dots@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alexey Melnikov <aamelnikov@fastmail.fm>
Message-ID: <155672115649.991.301467308616633255.idtracker@ietfa.amsl.com>
Date: Wed, 01 May 2019 07:32:36 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/fXU11oGIe9e35nHlujf6o26QPUI>
Subject: [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
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: Wed, 01 May 2019 14:32:37 -0000
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. 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. 2) In 4.4.1: base64url needs a Normative reference. Please point to section 5 of RFC 4648. 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. 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? 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. (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. } ] } } 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. ---------------------------------------------------------------------- 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. 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.) In 4.1: Is DHCP option for this defined in another document? 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? 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? 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] Alexey Melnikov's Discuss on draft-ietf-do… Alexey Melnikov via Datatracker
- Re: [Dots] Alexey Melnikov's Discuss on draft-iet… mohamed.boucadair
- Re: [Dots] Alexey Melnikov's Discuss on draft-iet… Adam Roach
- Re: [Dots] Alexey Melnikov's Discuss on draft-iet… Alexey Melnikov
- Re: [Dots] Alexey Melnikov's Discuss on draft-iet… mohamed.boucadair
- Re: [Dots] Alexey Melnikov's Discuss on draft-iet… Konda, Tirumaleswar Reddy
- Re: [Dots] Alexey Melnikov's Discuss on draft-iet… Alexey Melnikov
- Re: [Dots] Alexey Melnikov's Discuss on draft-iet… Konda, Tirumaleswar Reddy
- Re: [Dots] Alexey Melnikov's Discuss on draft-iet… Benjamin Kaduk