Re: [Anima] Robert Wilton's No Objection on draft-ietf-anima-autonomic-control-plane-28: (with COMMENT)

Toerless Eckert <tte@cs.fau.de> Fri, 11 September 2020 10:45 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7BC3A0E48; Fri, 11 Sep 2020 03:45:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.87
X-Spam-Level:
X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 zJR6J5QiSdfk; Fri, 11 Sep 2020 03:45:38 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23A83A0E37; Fri, 11 Sep 2020 03:45:37 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5BFCD548624; Fri, 11 Sep 2020 12:45:32 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 54D02440059; Fri, 11 Sep 2020 12:45:32 +0200 (CEST)
Date: Fri, 11 Sep 2020 12:45:32 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Robert Wilton <rwilton@cisco.com>, The IESG <iesg@ietf.org>, anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com
Message-ID: <20200911104532.GA45880@faui48f.informatik.uni-erlangen.de>
References: <159708388539.28258.3242297268864037873@ietfa.amsl.com> <14395.1598218754@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <14395.1598218754@localhost>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/paZCTdOpWxmseadBr4pWm2As_Y8>
Subject: Re: [Anima] Robert Wilton's No Objection on draft-ietf-anima-autonomic-control-plane-28: (with COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Sep 2020 10:45:41 -0000

On Sun, Aug 23, 2020 at 05:39:14PM -0400, Michael Richardson wrote:
> 
> Robert Wilton via Datatracker <noreply@ietf.org> wrote:
>     > 6.10.1.  Fundamental Concepts of Autonomic Addressing
> 
>     > For a PE device or NID, how does it know which interfaces to run ACP
>     > over?
> 
> I think that "PE" here means "Provider Edge"?
> The answer is that it runs the GRASP DULL on *ALL* interfaces, because it the
> device may have no idea it is a Provider Edge device on that Interface.
> 
> A Provider might want to turn this off, and they could well do that once the
> device has joined the ACP and gotten management control.  But, the risk of
> doing that is that the cables will get plugged in wrong, and the operator
> will lose access to the device.

In addition to loosing access to the device, the authenticated presence of
an ACP neighbor on an interface should also result in the appropriate configuratoin
of the data plane, and in reverse the absence as well:

When someone mis-plugs a cable, a CE facing interface might be miscabled to
a PE interface assumed to be inside the provider domain - and now the customer
could gain access to the SP infrastructure. Very often that infra is so fragile
that one might be able to inject a virus in short time. A malicious attacker
today likely needs to get some insight into the SP network from someone and
then bribe a lowly paid worker to accidentially misplug a cable for 10 minutes...

With ACP, the data-plane for "internal" config could immediately be shut down
as soon as there is no ACP neighbor.

Nice short term, small one pager ASA idea ;-))

Cheers
    Toerless

> In this case, I think that ANIMA's ACP prefers connectivity over the small
> amount of privacy lost by indicating that an IKEv2 is listening on an IPv6
> Link-Local address.  There is no security breach possible because the IKEv2
> (or DTLS) connection will not complete without the right trust anchors present.
> 
> A smart heuristic might be to include some kind of dead-man's switch.
> The management interface might turn the DULL off on some interfaces for a
> period of time, and if the management interface is lost, then the interfaces
> would stop being suppressed.  This falls into the quality of implementation
> category at this point.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-



-- 
---
tte@cs.fau.de