Re: [Dots] Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS and COMMENT)

Roman Danyliw <rdd@cert.org> Fri, 18 December 2020 16:58 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 AA4863A0A50; Fri, 18 Dec 2020 08:58:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 HqqIKWONjctt; Fri, 18 Dec 2020 08:58:17 -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 10E023A0A49; Fri, 18 Dec 2020 08:58:16 -0800 (PST)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 0BIGwFj2017995; Fri, 18 Dec 2020 11:58:15 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 0BIGwFj2017995
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1608310696; bh=nPuaNIOkvSLdccjpzQmM/Q0WMJMEp26GKJxXDZbLbwM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=LdX4XAGkHDRIeVeXS/eHEJ1BEzn6IpiLEgL3oCiBPBP8O2A+5cYRIHCZ2+VIVfz9L TqsU+bKH4IHOro9jBJn0D9y/ZL333EsjsjfN3lMoIG2HfX1zqUoR0fnkPRu05EPvhh uAesMhwFnCP4wmubFZDGZMz6pjXP3E1ZysyNv8hQ=
Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 0BIGw88b011748; Fri, 18 Dec 2020 11:58:08 -0500
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 18 Dec 2020 11:58:08 -0500
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Fri, 18 Dec 2020 11:58:08 -0500
From: Roman Danyliw <rdd@cert.org>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-dots-signal-call-home@ietf.org" <draft-ietf-dots-signal-call-home@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, Valery Smyslov <valery@smyslov.net>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11: (with DISCUSS and COMMENT)
Thread-Index: AQHW0x04jnFavtZsS0e2FxL8H2KIVKn5kt+AgAN5G1A=
Date: Fri, 18 Dec 2020 16:58:06 +0000
Message-ID: <703969fb11df49a39c6241bb32934ff6@cert.org>
References: <160806244514.15552.2884622118358344184@ietfa.amsl.com> <25337_1608099239_5FD9A5A7_25337_96_1_787AE7BB302AE849A7480A190F8B93303159E228@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <25337_1608099239_5FD9A5A7_25337_96_1_787AE7BB302AE849A7480A190F8B93303159E228@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.202.251]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/6-7maGfb4DD9ruDDyniLyIQRmes>
Subject: Re: [Dots] Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11: (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: Fri, 18 Dec 2020 16:58:20 -0000

Hi Med!

> -----Original Message-----
> From: Dots <dots-bounces@ietf.org> On Behalf Of
> mohamed.boucadair@orange.com
> Sent: Wednesday, December 16, 2020 1:14 AM
> To: Roman Danyliw <rdd@cert.org>rg>; The IESG <iesg@ietf.org>
> Cc: draft-ietf-dots-signal-call-home@ietf.org; dots-chairs@ietf.org; Valery
> Smyslov <valery@smyslov.net>et>; dots@ietf.org
> Subject: Re: [Dots] Roman Danyliw's Discuss on draft-ietf-dots-signal-call-
> home-11: (with DISCUSS and COMMENT)
> 
> Hi Roman,
> 
> Thank you for the review.
> 
> Please see inline for the DISCUSS part. Will see if/what changes are needed for
> the COMMENT part.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Roman Danyliw via Datatracker [mailto:noreply@ietf.org] Envoyé :
> > mardi 15 décembre 2020 21:01 À : The IESG <iesg@ietf.org> Cc :
> > draft-ietf-dots-signal-call-home@ietf.org; dots- chairs@ietf.org;
> > dots@ietf.org; Valery Smyslov <valery@smyslov.net>et>; valery@smyslov.net
> > Objet : Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-
> > 11: (with DISCUSS and COMMENT)
> >
> > Roman Danyliw has entered the following ballot position for
> > draft-ietf-dots-signal-call-home-11: 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-call-home/
> >
> >
> >
> > --------------------------------------------------------------------
> > --
> > DISCUSS:
> > --------------------------------------------------------------------
> > --
> >
> > It seems to me there is a missing operational guidance or undocumented
> > deployment assumptions.  Since the motivational use case seems to be
> > home networks (per Section 1.1), I assumed that the call home servers
> > are running primarily consumer grade routers not managed by
> > professional IT expertise.
> 
> [Med] The generalized applicability scope is what is sketched in Section 3. The
> solution is meant to block attacks close to their source. This can be:
> - the home case,
> - an enterprise network,
> - a transit provider filtering attacks from leaf networks,
> - a provider filtering attacks from data centers,
> - etc.
>
> For the particular case of home networks, this can be part of services supported
> by a ISP-managed CPE or a managed security service subscribed by the user.
> 
> We could mention that in the document, but we didn't because this are
> deployment-specific. Really.
> 
> Other than the introduction, we don't want to overload the document with
> home-specific considerations.

I still think we need a bit more precision.  I don't dispute the general utility of this approach to a variety of environments.  I do see the two sentences in the entire document which say that this is a general purpose approach:

Abstract: The DOTS signal channel Call Home is not specific to home networks;
   the solution targets any deployment in which it is required to block
   DDoS attack traffic closer to the source(s) of a DDoS attack.

Section 3: "The aforementioned problems may be encountered in other deployments
   than those discussed in Section 1.1 (e.g., data centers, enterprise
   networks)."

However, I will reiterate that almost no consideration is made to distinguish these use cases in the narrative text.  The entire motivation for the work in Section 1.0 is through the lens of networks not managed by professionals (home networks).  Furthermore, the explanation of the solution in Section 1.1, 5.1 and Appendix A is done through the lens of a "home network".  For this reason, I'm pushing to make sure the edges of that deployment environment are covered.  

I would assert that most of the behavior described below requires that professional IT expertise (let me know if you think I have it wrong).  I'm looking primarily for a few pieces of clarifying text:
(1) a suggestion/acknowledgement that CPEs using this spec in the home environment are likely to be managed, provisioned, issued (?) by an ISP (this addresses where there professional IT expertise is coming from)
(2) assuming (1) is true, distinguishing the various MUST/SHOULD/MAYs admin behaviors that involve the ISP vs. the actual humans on the home network

Note: everything else below is just more detailed commentary on this theme above.  I'd summarize everything I've said here by saying I think we need more finesse in describing the operational considerations and who is expected to take responsibility for them (realizing there will be a diversity of environments).  However, since there are multiple use cases, IMO, they deserve unique consideration when they are different from each other.

>   If that assumption is true
> > (and it should be documented if that is the case), then I find many of
> > the operational recommendations not congruent with that environment.
> > Specifically, the degree of interaction and tuning seems outside the
> > realm of expertise of someone without IT training and capabilities of
> > home network ecosystem.  In particular:
> >
> > -- Section 1.2
> > The Call Home DOTS server uses the DDoS attack traffic information to
> >    identify the compromised device in its domain that is responsible
> > for
> >    launching the DDoS attack, optionally notifies a network
> >    administrator, and takes appropriate mitigation action(s).
> >
> > How would such notification work?
> 
> [Med] This will depend on the deployment (home, enterprise, DC, access
> provider, peer transit provider, etc.). This can be using DOTS (the administrator
> has a call home dots server app), a push from the app use for managing the
> CPE, syslog, snmp, netconf, an SMS, etc.

I understand this answer in the context of the enterprise use case.  How would this happen for the home user (non-professional IT person)?

If this an instance where if the CPE is managed on behalf a the user, perhaps saying an out-of-scope mechanisms (app, SMS) needs to be provided for the end-user (home user)?

> As you can see a variety of tools can be considered as a function of the local
> deployment case. None of them is called out in the text as this is deployment-
> specific. Not all of them are applicable for each deployment case.

Make sense.  Perhaps some details distinguishing the guidance per the use cases could help.

> >
> > -- Section 1.2 and 5.1.  Leaves credentials configuration as out of
> > scope.
> 
> [Med] That is aligned with how credentials are handled in the base spec
> (RFC8782).
> 
> > Section 1.2 references [I-D.ietf-dots-server-discovery] for
> > provisioning.  In turn, Section 1 of [I-D.ietf.server-discovery] also
> > declares this problem out of scope by saying “This document assumes
> > that security credentials to authenticate DOTS server(s) are
> > pre-provisioned to a DOTS client using a mechanism such as (but not
> > limited to) those discussed in [RFC8572] or [I-D.ietf-anima-
> > bootstrapping-keyinfra]”.  However, RFC8572 seems to rely on NETCONF
> > and RESTCONF which seems like a rather uncommon feature of home
> > routers.  BRKSI relies on a manufacturer supplied/contracted
> > infrastructure and keystores that also seem uncommon for consumer
> > grade equipment.
> 
> [Med] These are not meant to be recommendations. These examples may be
> OK for some deployments, but not appropriate for others.
> 
> >
> > -- Section 5.3.1.
> > The Call Home DOTS server domain administrator consent MAY be
> >    required to block the traffic from the compromised device to the
> >    attack target.  An implementation MAY have a configuration knob to
> >    block the traffic from the compromised device to the attack target
> >    with or without DOTS server domain administrator consent.
> >
> > The suggestion here seems to be that consumers are acquiring devices
> > that can be remotely reconfigured with out a defined trust model?
> 
> [Med] Can you please clarify which suggestion are you referring to?

I'm wondering who the "server domain administrator" is and how they are expected to consent in the home user scenario?

> The text you quoted is referring to blocking traffic from devices that are
> injecting DDoS traffic from within a domain. These devices can be an IP camera,
> an infected PC, etc.
> 
> > Some policy or operational context seems appropriate here.
> >
> > -- Section 5.3.1
> > ... notifies the CPE
> >    administrator about the compromised device
> >
> > Notify how?
> 
> [Med] See above.

Like I noted above, if I'm a home user, how am I likely to get that notification?

> >
> > -- Section 8.
> > Appropriate
> >    filters (e.g., access control lists) can be installed on the Call
> >    Home DOTS server and network between the Call Home DOTS agents so
> >    that only communications from a trusted Call Home DOTS client to
> > the
> >    Call Home DOTS server are allowed.
> >
> > This seems like a level of sophistication beyond your average home
> > router user and a place where implementations should consider a secure
> > defaults.
> 
> [Med] This filtering can be automatically set based on the configured list of Call
> Home DOTS clients. This is a widely used practice (think about SIP proxy
> servers, example). No intervention may be required from the user.

Agreed.  However, this is assuming that someone is managing that configuration.  My point is that in the home user space that is most likely the ISP, so let's just say that.

> >
> > -- Section 8.
> > Call Home DOTS servers can also seek the consent of DOTS
> >    server domain administrator to block the traffic from the
> > potentially
> >    compromised device to the target (see Section 5.3.1).
> >
> > What would be the means to gain such consent?
> 
> [Med] This will depend on the deployment case: this can be an action executed
> using an app, a confirmation to a notification message, etc.
> 
> >
> > -- Section 9.
> > Note that a Call Home DOTS server can seek an administrator's
> >    consent, validate the request by inspecting the relevant traffic
> > for
> >    attack signatures, or proceed with both courses of action.
> >
> > As above.
> 
> [Med] As above :-)
> 
> >
> > -- Section 9.
> >
> >     The DOTS Call Home is only advisory in nature.  Concretely, the
> > DOTS
> >    Call Home does not impose any action to be enforced within the
> >    network hosting an attack source; it is up to the Call Home DOTS
> >    server (and/or network administrator) to decide whether and which
> >    actions are required.
> >
> > Such a decisions seems out beyond the ability of your average home
> > router user.
> 
> [Med] We don't have the notion of "average home router user" ;-)

Agreed.  Probably not us though :-).  My intent was to say that when the actions/decisions are being framed as being for a "network admin", that to me suggests a level expertise outside of the capability of typical end consumer without professional IT decisions.

Regards,
Roman

> >
> > -- Section 8  “... explicit policy (e.g., the Call Home DOTS client
> > and server are managed by the same administrative entity),
> >
> > Is there an underlying assumption that the ISP is managing the device?
> 
> [Med] ISP managed devices is one typical deployment case.
> 
> That's said, the text you quoted is not specific to ISPs. It applies, for example,
> when gateways are on the path and both the Call Home DOTS server and Call
> Home DOTS client will thus be managed by the DC provider, the enterprise
> administrator, the access provider, etc.
> 
> 
> ___________________________________________________________________
> ______________________________________________________
> 
> 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.
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots