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

[Roman Danyliw via Datatracker <[e-mail]>]

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