Re: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09: Section 5

Benjamin Kaduk <kaduk@mit.edu> Wed, 14 October 2020 23:25 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A5F3A1136; Wed, 14 Oct 2020 16:25:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrbi1pZy7vy3; Wed, 14 Oct 2020 16:25:25 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4F83A1133; Wed, 14 Oct 2020 16:25:24 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09ENPHjf030034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Oct 2020 19:25:22 -0400
Date: Wed, 14 Oct 2020 16:25:17 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: mohamed.boucadair@orange.com
Cc: "draft-ietf-dots-signal-call-home.all@ietf.org" <draft-ietf-dots-signal-call-home.all@ietf.org>, "dots@ietf.org" <dots@ietf.org>
Message-ID: <20201014232517.GU50845@kduck.mit.edu>
References: <10675_1602686295_5F870D57_10675_35_2_787AE7BB302AE849A7480A190F8B93303156014A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <10675_1602686295_5F870D57_10675_35_2_787AE7BB302AE849A7480A190F8B93303156014A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/eVY8eJldpB89zH5i49zKHRfYG8Q>
Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09: Section 5
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Oct 2020 23:25:30 -0000

Hi Med,

Also inline.

On Wed, Oct 14, 2020 at 02:38:15PM +0000, mohamed.boucadair@orange.com wrote:
> Re-,
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
> > 
> > Section 5
> > 
> > We should probably say something about how the the call home channel
> > is a potential vector for attack, with mitigation requests
> > potentially causing the indicated device to be partially blocked or
> > booted off the network entirely; mutual authentication of a trusted
> > call home server, "a healthy dose of skepticism about the indicated
> > attack" (or rather, local inspection of the indicated traffic), and
> > involvement of the local administrator can mitigate the new risks
> > that are opened up.
> > This is related to what we currently have in the last paragraph, but
> > we don't specifically discuss it as a new risk/attack vector due to
> > this protocol.
> 
> [Med] Add this NEW text:
> 
>    The DOTS Call Home can be misused by a misbehaving Call Home DOTS
>    client by arbitrary signalling legitimate traffic as being attack

(nit) "arbitrarily", I think

>    traffic, or falsifying mitigation signals so that some sources are
>    disconnected or some traffic is rate-limited...
> 
> > 
> > We might also consider referencing the security considerations of
> > RFC
> > 8071 (NETCONF/RESTCONF call home) since the "considerations not
> > associated with server authentication" are likely similar.
> 
> [Med] The only paragraph that can apply is the one related to computation. That one is already echoed in the document.
> The one about scanning does not apply as connections always at the initiative of the server.

Thanks for checking!

> > 
> > There may also be some considerations when the indicated attack
> > source-prefix is in a private or local-use address range -- the "in
> > scope" check at the call home server doesn't mean much.
> 
> [Med] Added this text right after the NEW one provided above:
> 
>    ... Such misbehaving Call
>    Home DOTS clients may include sources identified by IP addresses that
>    are used for internal use only (that is, these addresses are not
>    visible outside a Call Home DOTS server domain).  Such requests
>    should be discarded by the Call Home DOTS server.  More generally,
>    Call Home DOTS servers should not blindly trust mitigation requests
>    from Call Home DOTS clients....

I like this (especially the last sentence), but can we check that purely
internal address cannot ever be the source of an attack (even in the
presence of, e.g., NAT)?  It is not intuitively obvious to me that always
discarding such mitigation requests is the right thing.

> > 
> >    Common precautions mitigating DoS attacks are recommended, such
> > as
> >    temporarily blacklisting the source address after a set number of
> >    unsuccessful authentication attempts.
> > 
> > [I note that we used the term "drop-list" in RFC 8783.]
> 
> [Med] Indeed. Fixed. 

Thanks!

-Ben