Re: [Dots] AD Review of draft-ietf-dots-architecture-14

Roman Danyliw <rdd@cert.org> Fri, 10 January 2020 10:36 UTC

Return-Path: <rdd@cert.org>
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 30F161200BA for <dots@ietfa.amsl.com>; Fri, 10 Jan 2020 02:36:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=cert.org
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 glCuvW6K3Bmr for <dots@ietfa.amsl.com>; Fri, 10 Jan 2020 02:36:31 -0800 (PST)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 08615120071 for <dots@ietf.org>; Fri, 10 Jan 2020 02:36:30 -0800 (PST)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 00AAaT3O030470; Fri, 10 Jan 2020 05:36:29 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 00AAaT3O030470
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1578652589; bh=J68R1GLLLohLtZxqWUt3l7rqQ4NX2+8iDnkR8275vZA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ZvTvpWdV6Er1C+VTkIg/r3yi/MwdglQYxDTyRIy6lTOMP2AQdskiLVtq82EdsNZaM g8GOHZHBlbZRU7P1pJbhTeQevVnUL98Rd4A3/OQhzWtn93pMzl1PL09GJunrdjqw8H 6NgTjLkWAHfIHojOmavpVWkkWVXFa7QZH18oDh8Q=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 00AAaSTm032317; Fri, 10 Jan 2020 05:36:28 -0500
Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0468.000; Fri, 10 Jan 2020 05:36:28 -0500
From: Roman Danyliw <rdd@cert.org>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>
CC: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: AD Review of draft-ietf-dots-architecture-14
Thread-Index: AdXHMmoiRx3D3KUrRUiecOSiRVyATgAQ2HbAAAsA/cU=
Date: Fri, 10 Jan 2020 10:36:27 +0000
Message-ID: <F6100032-5A01-4F94-BB00-A0F7DA79D99C@cert.org>
References: <359EC4B99E040048A7131E0F4E113AFC01E7100170@marchand>, <DM5PR1601MB1259400B085262756BF3C125EA380@DM5PR1601MB1259.namprd16.prod.outlook.com>
In-Reply-To: <DM5PR1601MB1259400B085262756BF3C125EA380@DM5PR1601MB1259.namprd16.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/nCpqcAjZAzE8471pwbARLnz0VPY>
Subject: Re: [Dots] AD Review of draft-ietf-dots-architecture-14
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: Fri, 10 Jan 2020 10:36:33 -0000

Hi Tiru!

Everything proposed below works for me and addresses my concerns. Med’s subsequent consistency edits make sense to me too.

Thanks for the quick turn around. I’ll start the IETF LC with the -15 that has these changes.

Roman

> On Jan 10, 2020, at 4:05 AM, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@mcafee.com> wrote:
> 
> Hi Roman,
> 
> Thanks for the review. Please see inline
> 
>> -----Original Message-----
>> From: Dots <dots-bounces@ietf.org> On Behalf Of Roman Danyliw
>> Sent: Friday, January 10, 2020 3:00 AM
>> To: dots@ietf.org
>> Subject: [Dots] AD Review of draft-ietf-dots-architecture-14
>> 
>> CAUTION: External email. Do not click links or open attachments unless you
>> recognize the sender and know the content is safe.
>> 
>> Hello!
>> 
>> The following is my AD review of draft-ietf-dots-architecture-14:
>> 
>> ** Section 1.2.  Per "In this architecture, DOTS clients and servers
>> communicate using DOTS signaling ...", is this definition too narrow?  Per the
>> guidance in Section 1.1.2 to use RFC8612 definitions, which says that "DOTS
>> signal:  [is a] A status/control message transmitted over the authenticated
>> signal channel ..." the text seems to ignoring the data channel.
> 
> Updated line as follows:
> In this architecture, DOTS clients and servers communicate using DOTS signal channel and data channel protocols.
> 
>> 
>> ** Section 1.2.  Along the same line, the next sentence, "As a result of signals
>> from the DOTS client ...", seems to also present a very narrow example of
>> what the signal channel might do (let alone the data channel).  I'm not sure
>> how much this sentence adds to clarifying the scope as suggested by the
>> section title.
> 
> Agreed, I don't see a need for this sentence in the "Scope" section. Removed it. 
> 
>> 
>> ** Section.  1.3 Per "The signal and data channels are loosely coupled, and
>> may not terminate on the same DOTS server", it seems help to clarify the
>> obvious that how these signals would be synchronized is out of scope.
> 
> Okay, added the following line:
> How the DOTS servers synchronize the DOTS configuration is out of scope of this specification.
> 
>> 
>> ** Section 2.  Figure 3.  Is this figure (i.e., the JSON example) normative?
> 
> No.
> 
> This
>> seems like a detail best left to the data channel spec (and omitted from this
>> document).
> 
> Yes, we have an example in the data channel spec. Removed Figure 3. 
> 
>> 
>> ** Section 2.  Per:
>> Note that while it is possible to exchange the above information
>>   before, during or after a DDoS attack, DOTS requires reliable
>>   delivery of this information and does not provide any special means
>>   for ensuring timely delivery of it during an attack.  In practice,
>>   this means that DOTS deployments should not rely on such information
>>   being exchanged during a DDoS attack.
>> 
>> It seems to me that there is guidance missing here.  If the first sentence says
>> that this information can be exchanged before, during or after an attack, but
>> don't count on it during the attack.  The second sentence reiterates the point
>> that during an attack it will be unreliable, is a statement to the effect that
>> necessary configuration must be made prior to the attack also needed?
> 
> Yes, updated last line as follows:
> In practice, this means that DOTS deployments should rely on such information 
> being exchanged only under normal traffic conditions.
> 
>> 
>> ** Section 2.1  Per "It is not until this point that the mitigation service is
>> available for use.", this closing point about a mitigation service follows from
>> the previous description.  However, I wanted to point out, the notion of a
>> "mitigation service" being available after a fully configured DOTS client is not
>> a construct previously used in the document or the terminology.  It's likely
>> worth relating it to the previously defined terms like mitigator.
> 
> "mitigation service" is already used in Sections 2 and 1.2
> 
>> 
>> ** Section 2.1.  To avoid confusion on terms (i.e., from HTTP), perhaps
>> replace s/basic authorization/authorization/.
> 
> Okay, replaced.
> 
>> 
>> ** Section 2.2.2.  Per "For a given DOTS client (administrative) domain, the
>> DOTS server needs to be able to determine whether a given target  resource
>> is in that domain.", what is a "target resource" isn't clear.  I think it is meant to
>> be the resource that is the target of the attack (that the DOTS client is
>> signaling about). 
> 
> Yes.
> 
>> Also, the idea that DOTS clients have "domains" is a new
>> concept here that needs clarification.
> 
> I have simplified the text as follows:
> For a given DOTS client (administrative) domain, the DOTS server needs to be
> able to determine whether a given resource is in that domain. For
> example, this could take the form of associating a set of IP addresses and/or
> prefixes per DOTS client domain.
> 
>> 
>> ** Section 2.2.2. Per "The DOTS server enforces authorization of DOTS
>> clients' signals for mitigation.", no objection.  Is there a complementary
>> statement to make the data channel?
> 
> Good point, updated text as follows:
> The DOTS server enforces authorization of signals for mitigation, filtering rules and aliases for resources from DOTS clients.  
> The mechanism of enforcement is not in scope for this document, but is expected to restrict mitigation requests, filtering rules and aliases
> scope to addresses, prefixes, and/or services owned by the DOTS client domain, such that a DOTS
> client from one domain is not able to influence the network path to another
> domain. A DOTS server MUST reject requests for mitigation of resources, filtering rules and aliases for
> resources not owned by the requesting DOTS client's administrative domain.
> 
>> 
>> ** Section 5.  Per "Any attacker with the ability to impersonate ...", this
>> paragraph clearly describes in the impact of impersonation.  However, the
>> suggested mitigations read like requirements.  Instead of trying to list them
>> again, I would recommend explicitly citing the relevant requirements from
>> Section 2.4 of the RFC8612 and noting that need for conformance to these
>> security mechanisms.
> 
> Good point, updated paragraph as follows:
> 
> Any attacker with the ability to impersonate a legitimate DOTS client or server
> or, indeed, inject false messages into the stream may potentially
> trigger/withdraw traffic redirection, trigger/cancel mitigation activities or
> subvert drop-/accept-lists.  From an architectural standpoint, operators MUST
> ensure conformance to the security requirements defined in Section 2.4 of 
> RFC8612 to secure data in transit. 
> 
>> 
>> ** Section 5.  Per "Similarly, received data at rest SHOULD be stored with a
>> satisfactory degree of security.", I would recommend explaining why the
>> data should be secured. Perhaps:
>> OLD:
>> Similarly, received data at rest SHOULD be
>>   stored with a satisfactory degree of security.
>> 
>> NEW (or something like it):
>> Similarly, as the received data may contain network topology, telemetry,
>> threat, or preconfigured mitigation information which could be considered
>> sensitive in certain environment, it SHOULD be protected at rest per required
>> local policy.
> 
> Works for me, minor update to proposed text:
> 
> Similarly, as the received data may contain network topology, telemetry,
> threat and mitigation information which could be considered
> sensitive in certain environment, it SHOULD be protected at rest per required
> local policy.
> 
>> 
>> ** Section 5.  Per "As many mitigation systems employ diversion to scrub
>> attack traffic, operators of DOTS agents SHOULD ensure DOTS sessions are
>> resistant to Man-in-the-Middle (MitM) attacks.", I'm not following the link
>> between the mitigation systems re-routing traffic with DOTS agents resisting
>> MitM attack.  What actions should be agents be taking?
> 
> Good point, modified paragraph as follows (and removed line discussing re-routing traffic):
> 
> An attacker with control of a DOTS client may negatively
> influence network traffic by requesting and withdrawing requests for mitigation
> for particular prefixes, leading to route or DNS flapping. DOTS operators should carefully
> monitor and audit DOTS clients to detect misbehavior and deter misuse.
> 
> 
>> 
>> ** Section 5.  Per:
>>   Any attack targeting the availability of DOTS servers may disrupt the
>>   ability of the system to receive and process DOTS signals resulting
>>   in failure to fulfill a mitigation request.  DOTS agents SHOULD be
>>   given adequate protections, again in accordance with best current
>>   practices for network and host security.
>> -- The first sentence talks about "DOTS servers".  The second talk about
>> protecting "DOTS agents".  What's the role in the DOTS clients in this
>> guidance?
>> -- Shouldn't the protections afforded to the DOTS agents be a mandatory
>> (MUST)?
> 
> Good point, the guidance is only meant for DOTS servers and is mandatory. Modified text as follows:
> DOTS servers MUST be given adequate protections,  in accordance with best current practices for network and host security.
> 
>> 
>> ** Editorial Nits:
>> -- Section 1.  Editorial. s/for help defending/for help to defend/
>> -- Section 3.2.5.  Typo. s/deployements/deployments/
> 
> Thanks, Fixed.
> 
> Cheers,
> -Tiru
> 
>> 
>> _______________________________________________
>> Dots mailing list
>> Dots@ietf.org
>> https://www.ietf.org/mailman/listinfo/dots
>