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

Roman Danyliw <rdd@cert.org> Thu, 07 January 2021 22:11 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 72CBC3A0813; Thu, 7 Jan 2021 14:11:57 -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 ujH97P2Ho1ms; Thu, 7 Jan 2021 14:11:54 -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 981E93A0475; Thu, 7 Jan 2021 14:11:54 -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 107MBqib011872; Thu, 7 Jan 2021 17:11:52 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 107MBqib011872
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1610057512; bh=QEBWTxSNkfypALFrYNymH7+e75QKn6PLzcvyZmNgQe0=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=aRn8oTUplY3jPQoCmrKKR/FQ0XJ1eDbw90Y1k/gVx7V8Q4hR2ns4BHZ/HFnNiHFnm OQOwU2uqCFixgho12/harp3OMXO64ai2UtVBbNtaZt672Y8Mrm1t1L8KZTLKOyYasZ aAq1J5kxYh25MpJps2fi1dRYfiFkSmcR0KxDq3P4=
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 107MBkLA006608; Thu, 7 Jan 2021 17:11:46 -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; Thu, 7 Jan 2021 17:11:46 -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; Thu, 7 Jan 2021 17:11:46 -0500
From: Roman Danyliw <rdd@cert.org>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Robert Wilton" <rwilton@cisco.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+AgAN5G1CAB7E8YIAYH/ig
Date: Thu, 7 Jan 2021 22:11:46 +0000
Message-ID: <b2b43054ab564bbe8466b3d54eab06b2@cert.org>
References: <160806244514.15552.2884622118358344184@ietfa.amsl.com> <25337_1608099239_5FD9A5A7_25337_96_1_787AE7BB302AE849A7480A190F8B93303159E228@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <703969fb11df49a39c6241bb32934ff6@cert.org> <22745_1608731611_5FE34BDB_22745_117_1_787AE7BB302AE849A7480A190F8B9330315A1C63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <22745_1608731611_5FE34BDB_22745_117_1_787AE7BB302AE849A7480A190F8B9330315A1C63@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.186]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/Wbw5_p4UvilVpzlPwdxxqsmcCgk>
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: Thu, 07 Jan 2021 22:11:57 -0000

Hi Med!

The new language about "managed CPEs" and the more generalize scope in Section 1 better contextualizes the various interactions I had raised concerns about below.  Thanks for publishing it -12.  I've cleared my ballot.

Regards,
Roman

> -----Original Message-----
> From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
> Sent: Wednesday, December 23, 2020 8:54 AM
> To: Roman Danyliw <rdd@cert.org>rg>; Robert Wilton <rwilton@cisco.com>om>; 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: Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-11:
> (with DISCUSS and COMMENT)
> 
> Hi Roman, all,
> 
> We updated the draft to take into account your suggestions. The introduction
> and applicability sections were reworked accordingly. We also kept in mind
> Rob's comment when updating these two sections.
> 
> The new version and a diff can be found at:
> 
> Htmlized:       https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-12
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-call-home-12
> 
> Please let us know if this version addresses your DISCUSS.
> 
> Also, this version integrates the inputs from the Barry/Eric/Erik and directorate
> reviews.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Roman Danyliw [mailto:rdd@cert.org] Envoyé : vendredi 18 décembre
> > 2020 17:58 À : BOUCADAIR Mohamed TGI/OLN
> > <mohamed.boucadair@orange.com>om>; 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 Objet : RE: Roman
> > Danyliw's Discuss on draft-ietf-dots-signal-call-
> > home-11: (with DISCUSS and COMMENT)
> >
> > 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
> 
> ___________________________________________________________________
> ______________________________________________________
> 
> 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.