Re: [secdir] SECDIR Review draft-ietf-dots-rfc8782-bis-05

mohamed.boucadair@orange.com Tue, 23 March 2021 13:51 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886E33A0D6D; Tue, 23 Mar 2021 06:51:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 emEbpOjT4aIK; Tue, 23 Mar 2021 06:51:48 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (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 761003A0D69; Tue, 23 Mar 2021 06:51:48 -0700 (PDT)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4F4Xpn24hlz8t5g; Tue, 23 Mar 2021 14:51:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1616507505; bh=l4qetUZrp4NzHi41amVbtN/rBvFmnl+HZMUrofnn1TQ=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=gfjTktje8mcXOt3a90JzxV5W4XQP6frBJSX0terR1D1+2TjQzFSzfNxFUHJpvbnWI W3xhee2BkH0Vb+mMVZEPOKRAWUT5ODbI9Dt70ACZtg8QtCTsm+7XKhTDnWPCyVCken Ycxn0qvNPkl3Ujoj72caV5O3bHW82PHynxR9bXtnbtpAwjtLEKQ8kWwV5Aht0YF6LB 35uCw5lnpv08e+6T0WuBJDKG/nnHMgN6D4P2i2Hgyw/nDmBCVkwaz/4TPybk/Klpth qmISbupK41/XsSM4wIlMNyzgm4p4/HN3bcesnQTtZah381uyjj+ogfWtoJoGp3/pJH ptOaE5reHAMSA==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4F4Xpn0fl0z3wdQ; Tue, 23 Mar 2021 14:51:45 +0100 (CET)
From: mohamed.boucadair@orange.com
To: Donald Eastlake <d3e3e3@gmail.com>, "iesg@ietf.org" <iesg@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
CC: "draft-ietf-dots-rfc8782-bis.all@ietf.org" <draft-ietf-dots-rfc8782-bis.all@ietf.org>, secdir <secdir@ietf.org>
Thread-Topic: SECDIR Review draft-ietf-dots-rfc8782-bis-05
Thread-Index: AQHXH6B6k26mqQp2EE65nD9FVUjx5KqRf22g
Date: Tue, 23 Mar 2021 13:51:44 +0000
Message-ID: <23514_1616507505_6059F271_23514_186_1_787AE7BB302AE849A7480A190F8B93303535A427@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <CAF4+nEEAQDNir0ApDqBu3b2H3c-9KM+b=zuaDkaMSn0x0v5Z-Q@mail.gmail.com>
In-Reply-To: <CAF4+nEEAQDNir0ApDqBu3b2H3c-9KM+b=zuaDkaMSn0x0v5Z-Q@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303535A427OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/e4wgMAXjTOScC0elVKoL94XYzeA>
Subject: Re: [secdir] SECDIR Review draft-ietf-dots-rfc8782-bis-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Mar 2021 13:51:54 -0000

Hi Donald,

Many thanks for the review.

Please see inline.

Cheers,
Med

De : Donald Eastlake [mailto:d3e3e3@gmail.com]
Envoyé : mardi 23 mars 2021 05:53
À : iesg@ietf.org; last-call@ietf.org
Cc : draft-ietf-dots-rfc8782-bis.all@ietf.org; secdir <secdir@ietf.org>
Objet : SECDIR Review draft-ietf-dots-rfc8782-bis-05

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These reviews are primarily for the benefit of the Security ADs.
Document editors and WG chairs should treat these comments just
like any other last call comments.

The summary of the review is Ready with Issues.


Security:

I think the Security Considerations section is adequate in its
coverage but see below for some wording problems.

I did not review Sections 5 or 6.


Minor Issues / Nits:

General: I don't mean to be unduly harsh but I was put off by the
discursive and verbose style of this draft. On reading through, I get
the feeling that the same thing is often said more than once,
sometimes with different levels of detail, sometimes with different
terminology, sometimes in consecutive sentences and sometimes in
different parts of the draft; however, the numerous examples are
generally a good thing.

General/Global: All six occurrences of "as a reminder" should be
deleted from the draft. They just add useless words.
[Med] Except the one about IPv4/IPv6, those were added to address comments that we received in the past. I prefer to maintain them.

General: There are lots and lots of default/recommended configuration
values scattered around the draft. It might be useful to have a table
or list of them all, perhaps as an Operational Considerations section
or appendix.


Section 1: Draft says "The DOTS server may (not) be co-located with
the DOTS mitigator."  This appears to be a particularly confusing way
of saying "The DOTS server may or may not be co-located with the DOTS
mitigator." to which wording I would suggest changing.

[Med] Sure.


Section 3:

Suggest wording change for clarity from
   DOTS clients and servers behave as CoAP endpoints.  By default, a
   DOTS client (or server) behaves as a CoAP client (or server).
   Nevertheless, a DOTS client (or server) behaves as a CoAP server (or
   client) for specific operations such as DOTS heartbeat operations
   (Section 4.7).
to
   DOTS clients and servers behave as CoAP endpoints.  By default, a
   DOTS client behaves as a CoAP client and a DOTS server behaves as
   CoAP server.

[Med] Went with this part.

However, for specific operations such as DOTS heartbeat
   operations (Section 4.7), a DOTS client or server may behave as
   the opposite type of CoAP endpoint.

[Med] Will leave the old one. Thanks.


In the text below from the draft, the parenthesis and wording just
seem to muddle things and create doubt as to the meaning:
   In deployments where multiple DOTS clients are enabled in a network
   (owned and operated by the same entity),
I think it would be clearer and easier to understand (assuming I
understood it correctly) as:
   In deployments where multiple DOTS clients are enabled in a network
   with the clients and network owned and operated by the same entity,

[Med] Updated this one to:

   In deployments where multiple DOTS clients are enabled in a single
    network and administrative domain

Should "must" be capitalized in the following draft text?
   Future DOTS extensions that request a CBOR value in the range
   "128-255" must support means similar to the aforementioned DOTS
   telemetry ones.

[Med] Good catch. Fixed.


Section 4.4.1:

The following draft text uses "the trailing "=" " which implies that a
base 64 encoding ends with exactly one equal sign. But I believe there
can be zero, one, or two equal signs. I suggest the following:
OLD
         The truncated output is
         base64url encoded (Section 5 of [RFC4648]) with the trailing
         "=" removed from the encoding, and the resulting value used as
         the 'cuid'.
NEW
         The truncated output is
         base64url encoded (Section 5 of [RFC4648]) with any trailing
         equal signs ("=") removed from the encoding, and the
         resulting value used as the 'cuid'.

[Med] We meant “any trailing”. Fixed by updating to “two trailing "="”

There is talk of greater/lesser mid values. Is that a ring arithmetic
comparison and if so should it reference [RFC182]?
[Med] I guess you meant RFC1982. We don’t need it here.

Apparently pre-configured mitigation triggered by loss of the signal
channel are supposed to use mid's starting at zero but wrap around for
dynamic mitigation wraps to zero. Won't that cause conflicts?

[Med] I don’t see any issue as conflicts takes into account the mitigation-type.

On target-protocol, I suppose a reference to the IANA protocol
registry doesn't hurt but it seems to me that denial of service
traffic could use any protocol number, not necessarily one with a
specific definition. Maybe
OLD
      Values
      are taken from the IANA protocol registry [IANA-Proto].
NEW
      Values are integers in the range of 0 to 255. See [IANA-Proto]
      for common values.

[Med] Works for me. Updated. Thanks.

Section 4.4.3: The section title and contents mis-use the word
"efficacy" standing by itself.  "efficacy" has a strong implication of
being how well something works, NOT how long it works unless there is
some additional word or words such as "period of effectiveness" or
"effective for a week".  As an example, "efficacy" for a vaccine is
how well it work to block the disease after the full course of
vaccination has been given. People use completely different words when
talking about how long a vaccine's protection lasts. In this particular
section, I recommend simply replacing all occurrences of "efficacy"
with "lifetime".

[Med] Not sure to understand the rationale for the proposal to change “efficacy” to “lifetime”. This section is about sending an status in a update message to report the efficacy of ongoing mitigation. We call that “efficacy updates”, for simplicity.

Section 4.4.3: Figure 16 seems to show a string value for
attack-status but Table 4 has only integer values?

[Med] The figure is correct as the example uses JSON. FWOW, here is the corresponding type for the attack-status attribute:


   +---------------------+--------------+------+-------------+--------+

   | Parameter Name      | YANG Type    | CBOR | CBOR Major  | JSON   |

   |                     |              | Key  | Type &      | Type   |

   |                     |              |      | Information |        |

   +---------------------+--------------+------+-------------+--------+
   | attack-status       | enumeration  | 29   | 0 unsigned  | String |


That is explicitly mentioned in Section 4.4:


   JSON encoding of YANG modeled data [RFC7951<https://datatracker.ietf.org/doc/html/rfc7951>] is used to illustrate

   the various methods defined in the following subsections.  Also, the

   examples use the Labels defined in Sections 10.6.2<https://datatracker.ietf.org/doc/html/draft-ietf-dots-rfc8782-bis-05#section-10.6.2>, 10.6.3<https://datatracker.ietf.org/doc/html/draft-ietf-dots-rfc8782-bis-05#section-10.6.3>, 10.6.4<https://datatracker.ietf.org/doc/html/draft-ietf-dots-rfc8782-bis-05#section-10.6.4>,

   and 10.6.5.


Section 4.4.4: I suggest just removing the part of the sentence after
the "," in the following draft text because it just makes the sentence
longer and a little confusing:
   Once the active-but-terminating period elapses, the DOTS server MUST
   treat the mitigation as terminated, as the DOTS client is no longer
   responsible for the mitigation.

[Med] OK.

Section 4.5: Point a: The two sentences on Heartbeat interval are
parallel and slightly inconsistent. Suggest simply deleting the first
sentence.


Section 4.6: Suggested wording change to cut down on verbiage:
OLD
   If a DOTS server wants to redirect a DOTS client to an alternative
   DOTS server for a signal session, then the Response Code 5.03
   (Service Unavailable) will be returned in the response to the DOTS
   client.

   The DOTS server can return the error Response Code 5.03 in response
   to a request from the DOTS client or convey the error Response Code
   5.03 in a unidirectional notification response from the DOTS server.
NEW
   To redirect a DOTS client to an alternative DOTS server for a
   signal session, the server can return the Response Code 5.03
   (Service Unavailable) to the DOTS client or the server can return
   that Response Code in a notification response to the client.

[Med] Thanks. Changed to:

To redirect a DOTS client to an alternative DOTS server, the DOTS server can return the error Response Code 5.03 (Service Unavailable) in response to a request from the DOTS client or convey the error Response Code 5.03 in a unidirectional notification response to the client.

Section 4.6: Suggest replacing "can" with "MAY" or "SHOULD" in the
following draft text:
   Requests issued by misbehaving DOTS clients that do not honor the TTL
   conveyed in the Max-Age Option or react to explicit redirect messages
   can be rejected by DOTS servers.

[Med] s/can/MAY.


Section 7.3: Since the PMTU can change and could be lower that the
values suggested to be assumed in the first paragraph of Section 7.3,
it is essentially impossible to conform to the first sentence as
written. I suggest the following change:
OLD
   To avoid DOTS signal message fragmentation and the subsequent
   decreased probability of message delivery, DOTS agents MUST ensure
   that the DTLS record fits within a single datagram.

[Med] We are echoing the following from Section 4.1.1 of 6347:


“Each DTLS record MUST fit within a single datagram.”


NEW
   To avoid DOTS signal message fragmentation and the subsequent
   decreased probability of message delivery, DOTS agents MUST NOT
   send datagrams exceeding the limits discussed in this Section.


Section 8: The following text says that a server only accepts messages
from a gateway, although this is immediately contradicted in the next

[Med] I don’t see a contradiction as the sentence you quoted is an example: “If, for example, …”


paragraph. I suggest the change indicated:
OLD
   a DOTS server only allows DOTS signal
   channel messages from an authorized DOTS gateway,
NEW
   only if a gateway is authorized does a DOTS server accept DOTS signal
   channel messages from it,


Section 8, Figure 30: Seems slightly misleading because it looks like
the link between the Guest and gateway is broken. But according to the
text, they did mutually authenticate. I would suggest moving the "X"
to indicate failure to just inside the DOTS gateway box where the link
from the client arrives at the gateway box.

[Med] “x” is in reference to this text:


   In

   this example, the DOTS gateway only allows the application server and

   DDoS attack detector to request DDoS mitigation, but does not permit

   the user of type 'guest' to request DDoS mitigation

I think you were confused by “mutually authenticate”. Changed it to “proceed with mutual authentication”.

Sections 10: If all references to [RFC8782] in a registry need to be
replaced with references to [this document], there is no need to list
all the occurrences in the registry. You can just tell IANA to do a
global replace.

[Med] Some tables are maintained as we refer to the “label” in other section. We to remove the one about keys.


Section 11:

I suggest the following change:
OLD
   For this attack vector
   to happen, the misbehaving client needs to pass the security
   validation checks by the DOTS server, and eventually the checks of a
   client-domain DOTS gateway.
NEW
   For this attack
   to succeed, the misbehaving client's messages need to pass the security
   validation checks by the DOTS server and, if they transit a DOTS
   gateway, the security checks of that gateway.

[Med] Thanks. Went with this change:

“For this attack to succeed, the misbehaving client's messages need to pass the security validation checks by the DOTS server and, if the communication involves a client-domain DOTS gateway, the security checks of that gateway.”



The way this sentence talks about moving around "mitigation efficacy"
reads very strangely to me. I suggest the following re-wording:
OLD
   A compromised DOTS client can collude with a DDoS attacker to send
   mitigation request for a target resource, get the mitigation efficacy
   from the DOTS server, and convey the mitigation efficacy to the DDoS
   attacker to possibly change the DDoS attack strategy.
NEW
   A compromised DOTS client can be commanded by a DDoS attacker to
   abuse mitigation requests for a target resource. This could use the
   "mitigation" abilities of the DOTS server for the benefit of the
   attacker possibly leading to a changed and more effective DDoS
   attack strategy.

[Med] Thanks. I prefer the OLD wording.


Here is another "MUST" that I think should be reworded because you
cannot guarantee conformance to the MUST. For example, the server
could have run out of state memory.
OLD
   That is, only actions on IP
   resources that belong to the DOTS client's domain MUST be authorized
   by a DOTS server.
NEW
   A DOTS server MUST NOT authorize actions due to a DOTS client
   request unless those actions are limited to that client's IP
   resources.

[Med] No problem. I went with this change:

“A DOTS server MUST NOT authorize actions due to a DOTS client request unless those actions are limited to that DOTS client's domain IP resources.”


Miscellaneous observation: It's too bad that there seems to be
absolutely no coordination between DOTS and BGP flowspec.

[Med] We tried in RFC8783 to make use of attributes that can be easily mapped to BGP Flowspec. The glue between DOTS and BGP flowpsec is implementation-specific, IMO.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com<mailto:d3e3e3@gmail.com>

_________________________________________________________________________________________________________________________

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.