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

[[e-mail]]

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.  

  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. 

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.       

> 
> -- 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? 

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. 

> 
> -- 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. 

> 
> -- 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" ;-)  

> 
> -- 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.