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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Hi Roman,

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

> -----Original Message-----
> From: Dots <[e-mail]> On Behalf Of Roman Danyliw via
> Datatracker
> Sent: Wednesday, December 16, 2020 1:31 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: [Dots] Roman Danyliw's Discuss on draft-ietf-dots-signal-call-home-
> 11: (with DISCUSS and COMMENT)
> 
> CAUTION: External email. Do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> 
> 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).

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. 

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

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.

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

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots