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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Med,

This text is an improvement to me, thanks.

Although the introduction still doesn't seem to state the precise reason why the DOTS client cannot open a regular channel to the DOTs server (e.g. paragraph 2 of the introduction), or I am missing it.

My assumption of the deployment is that the DOTS client is within the outbound DOS attack ISP's network.  Is the specific issue that this document is addressing that the DOTs server may be behind a NAT and hence not be publicly addressable?  Or are there also other reasons why a Call Home architecture is required?  I appreciate that there may be reasons why a Call Home architecture is preferred and potentially simplifies the management of the CPE devices.

Regards,
Rob



> -----Original Message-----
> From: iesg <[e-mail]> On Behalf Of
> [e-mail]
> Sent: 23 December 2020 13:54
> To: Roman Danyliw <[e-mail]>; Rob Wilton (rwilton)
> <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> Valery Smyslov <[e-mail]>; [e-mail]
> 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:[e-mail]]
> > Envoyé : vendredi 18 décembre 2020 17:58
> > À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>; The
> > IESG <[e-mail]>
> > Cc : [e-mail]; dots-
> > [e-mail]; Valery Smyslov <[e-mail]>; [e-mail]
> > Objet : RE: Roman Danyliw's Discuss on draft-ietf-dots-signal-call-
> > home-11: (with DISCUSS and COMMENT)
> >
> > Hi Med!
> >
> > > -----Original Message-----
> > > From: Dots <[e-mail]> On Behalf Of
> > > [e-mail]
> > > Sent: Wednesday, December 16, 2020 1:14 AM
> > > To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> > > Cc: [e-mail]; dots-
> > [e-mail];
> > > Valery Smyslov <[e-mail]>; [e-mail]
> > > 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:[e-mail]]
> > Envoyé :
> > > > mardi 15 décembre 2020 21:01 À : The IESG <[e-mail]> Cc :
> > > > [e-mail]; dots-
> > [e-mail];
> > > > [e-mail]; Valery Smyslov <[e-mail]>;
> > > > [e-mail] 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
> > > [e-mail]
> > > 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.