Re: [Dots] AD review of draft-ietf-dots-telemetry-16 (Sections 7.1.5 - 7.3)

mohamed.boucadair@orange.com Thu, 25 November 2021 13:48 UTC

Return-Path: <mohamed.boucadair@orange.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 B41503A0B8D; Thu, 25 Nov 2021 05:48:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.344
X-Spam-Level:
X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_FAKE_RF_SHORT=0.755, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 OPOUPDkYFf1E; Thu, 25 Nov 2021 05:48:13 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66493A0AD3; Thu, 25 Nov 2021 05:48:06 -0800 (PST)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar23.francetelecom.fr (ESMTP service) with ESMTPS id 4J0K2Y39H2zBsRw; Thu, 25 Nov 2021 14:48:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1637848085; bh=nAsges5v5sgnBEmiOW9lO5ZrXwuCKe94sEGKvv3DBPo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=woWo16kN3lMA3bs+mzzqbt5ZAzYsIq1WSLNCNU3Hgw0VX4J3x4IQE4otb5SR4pj3H aHRhQgbm1D7Bac7iAisWWWPDDAE0BZ4JgPAzx7IbWCaMn+dKB/YqUHjR8lX/qNOta8 ndvzCc5bG/3wTF8AOU8wxOBxJlNeI3k67GEw78Up2GUmt/3QLD+xUR0oQ/m9BP/9rb NJrW+qJt1RqyA7uza0voQiqenCVB3ubM8kqKttLcVHcYcdW+pab3a3LF7WUsNo++rH D8ajU47US3lannFMruI81JxntUI5lraSRqGW3Xp6aALxq3NooHbpGLMQchpAJzqzKR nTPt1cXRpMfew==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar04.francetelecom.fr (ESMTP service) with ESMTPS id 4J0K2Y21sVz1xpR; Thu, 25 Nov 2021 14:48:05 +0100 (CET)
From: mohamed.boucadair@orange.com
To: Benjamin Kaduk <kaduk@mit.edu>, "draft-ietf-dots-telemetry.all@ietf.org" <draft-ietf-dots-telemetry.all@ietf.org>
CC: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] AD review of draft-ietf-dots-telemetry-16 (Sections 7.1.5 - 7.3)
Thread-Index: Adfh6JfGszAFMJBfTYmQzH6qbR5x3w==
Content-Class:
Date: Thu, 25 Nov 2021 13:48:04 +0000
Message-ID: <8173_1637848085_619F9415_8173_37_1_787AE7BB302AE849A7480A190F8B933035458F83@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2021-11-25T10:38:42Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=6e9c57df-0875-4b88-96ae-ad25aa6af7c8; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/2My5z5v1kxlLWqUTL1RhXvDhlZI>
Subject: Re: [Dots] AD review of draft-ietf-dots-telemetry-16 (Sections 7.1.5 - 7.3)
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, 25 Nov 2021 13:48:18 -0000

Re-,

You can track the changes at: https://tinyurl.com/dots-telemetry-latest.

Please see inline for more context for Sections 7.1.5 to 7.3. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots <dots-bounces@ietf.org> De la part de Benjamin Kaduk
> Envoyé : mercredi 24 novembre 2021 23:42
> À : draft-ietf-dots-telemetry.all@ietf.org
> Cc : dots@ietf.org
> Objet : [Dots] AD review of draft-ietf-dots-telemetry-16
> 
> Hi all,
> 
...
> 
> Section 7.1.5
> 
>    vendor-id:  Vendor ID is a security vendor's Enterprise Number as
>       registered with IANA [Enterprise-Numbers].  It is a four-byte
>       integer value.
> 
>    attack-id:  Unique identifier assigned for the attack.
> 
> If the vendor-id is being used as a scoping value to let each vendor
> assign attack-id values, then we should say so here, the first place we
> really handle this part of the YANG tree.  Even if not, we should probably
> say more about why we care what the vendor-id is, and we should also say
> who assigns the attack-id.  (Maybe it's scoped to the DOTS server; I don't
> know yet at this point in the document!)

[Med] The is assigned by the vendor. We don't have globally unique attack-ids and we don't ambition to have such a registry. 

We have the following in the YANG module "Unique identifier assigned by the vendor for the attack". 

Updated the text to align. 

> 
> Furthermore, the module structure where attack-id and vendor-id are always
> required, but there is going to need to be the ability to assign a new
> attack description at runtime, seems to force us to conflate
> externally/statically assigned attack-ids and dynamically assigned ones in
> the same number space.  Should we give any guidance to vendors about how
> to allocate IDs in a way that will not produce collisions between
> predistributed/fixed attack IDs and new ones created at runtime?  Or is
> the thought that there will be no dynamic attack-ids since that just
> corresponds to the attack-description string and a generic description can
> be used if there is not a better one available?

[Med] We really don't want to interfere with how these ids are assigned by vendors. For new attacks, and because the client may not have the mapping we do allow for the following:

   When conveying attack details in DOTS telemetry messages (Sections
   7.2, 7.3, and 8), DOTS agents MUST NOT include the 'attack-
   description' attribute unless the corresponding attack mapping
   details were not previously shared with the peer DOTS agent.

> 
> Regardless, I think we should have more verbiage as to what the scope of
> the attack-id is -- what information is it supposed to indicate or
> replace?
> 
>    start-time:  The time the attack started.  The attack's start time is
>       expressed in seconds relative to 1970-01-01T00:00Z in UTC time
> 
> (nit) "in UTC time" and "Z" seem redundant (which does not necessarily
> imply that we should only use one of them...).

[Med] We preferred to echo 3.4.2 of RFC8949 cited right after

> 
>       (Section 3.4.2 of [RFC8949]).  The CBOR encoding is modified so
>       that the leading tag 1 (epoch-based date/time) MUST be omitted.
> 
> (nit) Maybe we should move the CBOR section reference to after we start
> talking about CBOR encoding.  (And we should do the same for 'end-time',
> if we do anything.)

[Med] The section where we discuss CBOR encoding is 4.5. I prefer to keep this mention here. Thanks. 

> 
>    top-talker:  A list of top talkers among attack sources.  The top
>       talkers are represented using the 'source-prefix'.
> 
> Is there a good reference or short description for the notion of top-
> talkers?  I know it's a well-established term of art in many different
> circles, but it's hard to be fully confident that all readers will be
> familiar with it.

[Med] What about:

      A list of attack sources that are involved in an attack
      and which are generating an important part of the attack traffic.

> 
> Also, should we say anything about how the number of talkers to include is
> determined?  (I assume it is best left to the discretion of the sender,
> but we probably want to set a clear expectation that the list is not all
> talkers or a complete list in any other way.)

[Med] We don't include any hint as this is deployment-specific. 

> 
>       'spoofed-status' indicates whether a top talker is a spoofed IP
>       address (e.g., reflection attacks) or not.
> 
> Is this something that can be unambiguously determined by all parties that
> might be producing this telemetry data, or should we use a tri-statae (for
> "unknown") rather than a boolean to represent it?

[Med] The unknown status is handled by not including the leaf. Update the text to indicate so. 

> 
>    In order to optimize the size of telemetry data conveyed over the
>    DOTS signal channel, DOTS agents MAY use the DOTS data channel
>    [RFC8783] to exchange vendor specific attack mapping details (that
>    is, {vendor identifier, attack identifier} ==> attack description).
>    As such, DOTS agents do not have to convey systematically an attack
>    description in their telemetry messages over the DOTS signal channel.
> 
> It's a little surprising to me that this is only a MAY.  Does it make
> sense as a SHOULD (expected to usually happen, but leaving open the
> flexibility when an observed attack does not match a previously
> characterized attack description)?

[Med] We went for "MAY" because this is an optimization for a an optional feature. 

> 
> Also, when reading this I assumed that the "attack description" being
> mapped to could include things like the target port/protocol, whether it
> was spoofed, etc.

[Med] Some of the details you cited can be discovered during an attack. 

  But reading on to the ietf-dots-mapping module, it
> seems that this is intended to just be the single "attack-description"
> string.

[Med] This is the portion that consumes most packet size and is thus problematic. 

  If so, we might give some more indications of that, e.g., by
> spelling it that way and having some prose about it being a "string", or
> similar.

[Med] OK.

> 
> Also^2, from here to the end of the section might benefit from being split
> off into a dedicated subsection on using the data channel to pre-populate
> vendor and attack description information

[Med] Makes sense. 

> 
>    tables are at different revisions.  The DOTS client SHOULD transmit
>    telemetry information using the vendor mapping(s) that it provided to
>    the DOTS server and the DOTS server SHOULD use the vendor mappings(s)
>    provided to the DOTS client when transmitting telemetry data to peer
>    DOTS agent.
> 
> Having read a bit further on, I'm not actually sure where in the protocol
> the client has provided vendor mappings to the server, and the server
> provided vendor mappings to the client.  It *might* be the GET and POST
> from/to dots-data/ietf-dots-mapping:vendor-mapping, but we don't really
> give a clear indication of that.  I think we should try to be more precise
> about what we mean by "provided".

[Med] added: (e.g., using a POST as depicted in Figure 34) 

> (editorial) would this then be "SHOULD use any vendor mapping(s)"
> (s/the/any/)?

[Med] Yeah.

> 
>      augment /data-channel:dots-data/data-channel:capabilities:
>        +--ro vendor-mapping-enabled?   boolean {dots-telemetry}?
> 
> None of the other capabilities in this tree (as specified by RFC 8783)
> include a name suffix like "-enabled".  Should this just be "vendor-
> mapping"?

[Med] We could, but we went for -enabled to ease referencing this data node in the text. See for example:

   attack mapping details is supported by the server (i.e., check the
   value of 'vendor-mapping-enabled'). 

Otherwise, we would need to provide the full hierarchy because we do have "vendor-mapping" in 

     augment /data-channel:dots-data:
       +--ro vendor-mapping {dots-telemetry}?

> 
>            "vendor-id": 1234,
>            "vendor-name": "mitigator-s",
>            "last-updated": "1576856561",
>            "attack-mapping": []
> 
> [this last updated is from December 2019; we could probably pick something
> more current if we wanted, but it doesn't really matter.]

[Med] OK

> 
>    The DOTS client reiterates the above procedure regularly (e.g., once
>    a week) to update the DOTS server's vendor attack mapping details.
> 
> Do the udpates have to preserve any existing assignments?

[Med] No. The client can even determine that a given vendor is not used anymore.

> 
>    If the DOTS client concludes that the DOTS server does not have any
>    reference to the specific vendor attack mapping details, the DOTS
>    client uses a POST request to install its vendor attack mapping
>    details.  [...]
> 
> This suggests that a client would not bother sending its own vendor
> mapping if the server already has one

[Med] yes, because there same mapping is used in both sides.

, and at least to me further implies
> that the client would use the sever-provided mapping for the messages that
> the client generates.  This seems at odds with the earlier guidance that
> the client should send using the vendor-mapping it provided to the server,
> and the server should send using the vendor-mapping it provided to the
> client.  Which one is it?
> 
>    The DOTS server indicates the result of processing the POST request
>    using the status-line.  Concretely, "201 Created" status-line MUST be
>    returned in the response if the DOTS server has accepted the vendor
>    attack mapping details.  If the request is missing a mandatory
>    attribute or contains an invalid or unknown parameter, "400 Bad
>    Request" status-line MUST be returned by the DOTS server in the
>    response.  [...]
> 
> I think (but did not specifically check) that these specific status code
> values are preexisting requirements of core RESTCONF (and HTTP), so we may
> not need to write new "MUST" keywords.

[Med] We tried to be consistent with RFC8782, where we can find:

   If the request is missing a mandatory attribute or it contains an
   invalid or unknown parameter, a "400 Bad Request" status-line MUST be
   returned by the DOTS server.

> 
>    If the request is received via a server-domain DOTS gateway, but the
>    DOTS server does not maintain a 'cdid' for this 'cuid' while a 'cdid'
>    is expected to be supplied, the DOTS server MUST reply with "403
>    Forbidden" status-line and the error-tag "access-denied".  Upon
>    receipt of this message, the DOTS client MUST register (Section 5.1
>    of [RFC8783]).
> 
> (nit) the analogous text in RFC 8783 itself refers only to "Section 5"
> (not 5.1).

[Med] I prefer to keep 5.1 because 5 covers both registration and de-registration.

> 
>    The DOTS client uses the PUT request to modify its vendor attack
>    mapping details maintained by the DOTS server (e.g., add a new
>    mapping).
> 
> As above, is this really just an example behavior or a hard requirement to
> preserve existing mappings?

[Med] We are not using any normative language for POST, hence this wording for PUT.  

> 
> Section 7.2
> 
>            "attack-detail": [
>              {
>                "vendor-id": 1234,
> 
> The vendor-ID is supposed to be an IANA-assigned PEN, and 1234 is assigned
> to Linkage Software Inc.  We have other options, like 32473, "Example
> Enterprise Number for Documentation Use" (RFC 5612).

[Med] This is better. Added a note to Section 4.6 as well. 

> 
>                "start-time": "1957811234",
> 
> This value represents a time in 2032; should we be using something a
> little more current?

[Med] No problem. Updated.  

> 
> Section 7.3
> 
>    This request MUST be maintained active by the DOTS server until a
>    delete request is received from the same DOTS client to clear this
>    pre-or-ongoing-mitigation telemetry.
> 
> It seems like we might want to allow some provision for a server to clean
> up state associated with a client that disappears entirely without
> cleaning itself up.

[Med] this was a hidden behavior. Thanks for catching this. Updated as follows: 

   This request MUST be maintained in an active state by the DOTS server
   until a delete request is received from the same DOTS client to clear
   this pre-or-ongoing-mitigation telemetry or when the DOTS client is
   considered inactive (e.g., Section 3.5 of [RFC8783]).

  For example, is the server allowed to discard state
> when it reboots, or does this requirement extend to writing the state to
> persistent storage?
> 
>       If more than one Uri-Query option is included in a request, these
>       options are interpreted in the same way as when multiple target
>       attributes are included in a message body.
> 
> I a little bit wonder if we could put a section reference here for
> "interpreted in the same way", since the reader may not remember what that
> way is, at least on the first reading.
> 

[Med] Added a pointer to 4.4.1 of 9132 where there is some text about appending target values. 

>       parameters.  DOTS clients MUST NOT include a name in which the "*"
>       character is included in a label other than the leftmost label.
> 
> Do we want to say what the server should do if it gets one anyway?
> (It's not really clear that we need to say anything, strictly speaking.)
> 

[Med] This is covered by:

   Requests with invalid query types (e.g., not supported, malformed)
   received by the DOTS server MUST be rejected with a 4.00 (Bad
   Request) response code.

>                "vendor-id": 1234,
>                "attack-id": 77,
>                "start-time": "1957818434",
> 
> [same as above]

[Med] OK

> 
>    A DOTS client that is not interested to receive pre-or-ongoing-
>    mitigation telemetry data for a target MUST send a delete request
>    similar to the one depicted in Figure 37.
> 
> I'm not sure that this strictly needs to be a "MUST"; it seems like we
> could say that such a client "sends a delete request" and leave it at
> that.
> 

[Med] OK 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.