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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 15 Dec 2020 12:00:45 -0800

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

-- Section 1.2 and 5.1.  Leaves credentials configuration as out of scope. 
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.

-- 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?  Some policy or
operational context seems appropriate here.

-- Section 5.3.1
... notifies the CPE
   administrator about the compromised device

Notify how?

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

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

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

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

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Radia Perlman for the SECDIR review.

** Section 1.1.  The motivation for this protocol in the “home network device”
ecosystem could use a bit more focus.

(a) network devices in a home network can offer network
   security functions (e.g., firewall [RFC4949] or Intrusion Protection
   System (IPS) service [I-D.ietf-i2nsf-terminology] on a home router)

(b) Hence, it is not possible to detect various DDoS attacks in
   the slow path ...

(c) a full-fledged DPI to
   detect these type of DDoS attacks is functionally or operationally
   not possible for all the devices

If IPS is done per (a), (b) and (c) don’t seem like issues. Certainly, NOT all
devices support (a), but not ALL devices or limited by (b) and (c).

The abstract is also clear that “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", but that fairly large other use cases doesn’t seem acknowledged here.

Bottom-line, I had difficulty following the motivation.

** Section 1.1 presents an incomplete view of the problem to motivate the
solution.  It notes that ISPs can already detect a DDoS attack down to the
individual home network, but not the device (because of NATs).  The problem of
what happens next remains unsaid.  It seems to me that options are the ISP
shapes the traffic of that home network (affecting all of its devices) which is
likely undesirable/blunt or the ISP tries to gain cooperation of the home
network edge router to do something (which is the point of this document).

** Section 1.1.

   Existing approaches are still suffering from misused access network
   resources by abusive devices; the support of means for blocking such
   attacks close to the sources are missing.

I didn’t understand what this means.  What “existing approaches”?

** Section 1.2.  For the home network case, the text seems to be missing text
saying that this “Call Home DOTS” solution needs to be deployed on a CPE
capable of some degree of mitigation per the kinds of features DOTS can express
(and the details of this integration is out of scope).

---

From: <[email-masked]>
Date: Wed, 16 Dec 2020 06:13:59 +0000

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:[email-masked]]
> Envoyé : mardi 15 décembre 2020 21:01
> À : The IESG <[email-masked]>
> Cc : [email-masked]; dots-
> [email-masked]; [email-masked]; Valery Smyslov <[email-masked]>;
> [email-masked]
> Objet : Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-
> 11: (with DISCUSS and COMMENT)
> 
> 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.)
> 
> 
> 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

[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

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

> 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

[Med] See above. 

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

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

>    attack signatures, or proceed with both courses of action.

[Med] As above :-)

> Such a decisions seems out beyond the ability of your average home

[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),
> 

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 17 Dec 2020 10:05:48 +0000

Hi Roman,

Thanks for the review. Please see inline for responses to comments.

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of Roman Danyliw via
> Datatracker
> Sent: Wednesday, December 16, 2020 1:31 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: [Dots] Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-
> CAUTION: External email. Do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> 
> 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.)
> 
> 
> 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.  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
> 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
> 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.
> 
> -- Section 5.3.1.
> The suggestion here seems to be that consumers are acquiring devices that
> can be remotely reconfigured with out a defined trust model?  Some policy
> or operational context seems appropriate here.
> 
> -- Section 5.3.1
> ... notifies the CPE
> This seems like a level of sophistication beyond your average home router
> user and a place where implementations should consider a secure defaults.
> 
> -- Section 8.
> -- Section 8  “... explicit policy (e.g., the Call Home DOTS client and server are
> managed by the same administrative entity),
> 

Typically network security services co-located on home routers are limited by (b) and (c).  Home routers are constrained network devices and network security service co-located on the home router cannot run a full-fledged DPI. In addition, network security services in SOHO/SMB may or may not be able to detect DDoS attacks using DPI. ISPs offering DDoS mitigation service have DDoS Detection capability using anomaly detection (for example, see https://www.netscout.com/sites/default/files/2018-10/SECPDS_004_EN-1802-Arbor-Threat-Mitigation-System-%28TMS%29.pdf) to identify zero day DDoS attacks and to detect DDoS attacks that cannot be detected using signatures and rate-limit techniques. 

> required to block DDoS attack traffic closer to the source(s) of a DDoS attack",
> but that fairly large other use cases doesn’t seem acknowledged here.
> 
> individual home network, but not the device (because of NATs).  The
> problem of what happens next remains unsaid.  It seems to me that options
> are the ISP shapes the traffic of that home network (affecting all of its
> devices) which is likely undesirable/blunt or the ISP tries to gain cooperation
> of the home network edge router to do something (which is the point of this
> document).

The problem is not specific to devices behind NAT, ISP cannot identify devices using IPv6 addresses attached to the home network to isolate and remediate compromised devices launching DDoS attack. We have the following text in Section 1.1.

   Even in case of an IPv6 home network, although the ISP can identify the infected device in the
   home network launching the DDoS traffic by tracking its unique IPv6
   address, the infected device can easily change its IPv6 address to
   evade remediation.  A security function on the local home network is
   better positioned to track the compromised device across IPv6 address
   (and potentially even MAC address) changes and thus ensure that
   remediation remains in place across such events.

> I didn’t understand what this means.  What “existing approaches”?

Thanks, will modify the above text for clarity:

   Existing approaches discussed above suffer from misused access network
   resources by abusive devices; the support of means for blocking such
   attacks close to the sources are missing.

> 
> ** Section 1.2.  For the home network case, the text seems to be missing
> text saying that this “Call Home DOTS” solution needs to be deployed on a
> CPE capable of some degree of mitigation per the kinds of features DOTS can
> express (and the details of this integration is out of scope).

We already have the following text in Section 1.2:
In a typical deployment scenario, the Call Home DOTS server is enabled on a Customer Premises Equipment (CPE), which is aligned with recent trends to enrich the CPE with advanced security features.

Cheers,
-Tiru

> 
> 
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 18 Dec 2020 16:58:06 +0000

Hi Med!

> From: Dots <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Wednesday, December 16, 2020 1:14 AM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; Valery
> Smyslov <[email-masked]>; [email-masked]
> Subject: Re: [Dots] Roman Danyliw's Discuss on draft-ietf-dots-signal-call-
> home-11: (with DISCUSS and COMMENT)
> 
> Hi Roman,
> 
> > De : Roman Danyliw via Datatracker [mailto:[email-masked]] Envoyé :
> > mardi 15 décembre 2020 21:01 À : The IESG <[email-masked]> Cc :
> > [email-masked]; dots- [email-masked];
> > [email-masked]; Valery Smyslov <[email-masked]>; [email-masked]
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > 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,
> 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.
> 

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.

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

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

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

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

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

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

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

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

---

From: <[email-masked]>
Date: Wed, 23 Dec 2020 13:53:31 +0000

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

> De : Roman Danyliw [mailto:[email-masked]]
> Envoyé : vendredi 18 décembre 2020 17:58
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>; The
> IESG <[email-masked]>
> [email-masked]; Valery Smyslov <[email-masked]>; [email-masked]
> Objet : RE: Roman Danyliw's Discuss on draft-ietf-dots-signal-call-
> > Valery Smyslov <[email-masked]>; [email-masked]
> > Please see inline for the DISCUSS part. Will see if/what changes
> are
> > needed for the COMMENT part.
> >
> > Cheers,
> > Med
> >
> Envoyé :
> > > [email-masked]; Valery Smyslov <[email-masked]>;
> > > [email-masked] Objet : Roman Danyliw's Discuss on
> > > draft-ietf-dots-signal-call-home-
> > > ----------------------------------------------------------------
> ----
> > > --
> > > DISCUSS:
> > > ----------------------------------------------------------------
> ----
> > > --
> > >
> > [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,
> > 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:
> 
> 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.
> 
> environment.
> > > realm of expertise of someone without IT training and
> capabilities
> > > of home network ecosystem.  In particular:
> > >
> > > -- Section 1.2
> > >    identify the compromised device in its domain that is
> responsible
> > > for
> > 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.
> 
> > > -- Section 1.2 and 5.1.  Leaves credentials configuration as out
> of
> > > scope.
> >
> 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.
> >
> > >    that only communications from a trusted Call Home DOTS client
> to
> > > the
> > [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.
> > [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.
> > >    consent, validate the request by inspecting the relevant
> traffic
> > > for
> > >     The DOTS Call Home is only advisory in nature.  Concretely,
> the
> > > DOTS
> > > Such a decisions seems out beyond the ability of your 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
> 
> > >
> > 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.
> >
> >
> >
> > 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.
> >