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

[[e-mail]]

Hi Rob,

We thought this was covered by the following: 

   Other motivations for introducing the Call Home function are
   discussed in Section 1.1 of [RFC8071].

We preferred that citation vs duplicating the 6 items in this document as well (s/management system/mitigation system). 

I understand from your comment that the link was not evident. If so, will see how to make things better. 

Cheers,
Med

> -----Message d'origine-----
> De : Rob Wilton (rwilton) [mailto:[e-mail]]
> Envoyé : lundi 4 janvier 2021 17:08
> À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>; Roman
> Danyliw <[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,
> 
> 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]; dots-
> [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.


_________________________________________________________________________________________________________________________

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.