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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 11 September 2020 21:12 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 DE40A3A099B; Fri, 11 Sep 2020 14:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.046
X-Spam-Level:
X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 qrWDLcaFaVIn; Fri, 11 Sep 2020 14:12:57 -0700 (PDT)
Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FE143A0991; Fri, 11 Sep 2020 14:12:57 -0700 (PDT)
Received: by mail-pg1-x541.google.com with SMTP id t14so7444419pgl.10; Fri, 11 Sep 2020 14:12:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=QL8MdNvcvq+NrUAn+gNwTGceYtoWusA65mZVG5WlzIk=; b=aYo9xhHjvpfpwsLvKz+WNnGTShgB3kqX/fZu3csGT+v5gJRJi0KqyLR3W5aPXfcDFU B8o4AOGY+fh4FsgCyxf7YhxBoFByOJwRYJelYCgJu3XrazXcbF/C8ycOYoHdflL+0e3e XICdv3SY4pC4T8s/dr1LbBVkx2zVwiMjU+vjb8SpK31k3aaUqqJpKGE5nJ+X6V6nazBw 3HcxmSdn7Z5FxRUU27bDiHjwn4fR1AUmJRFabOkv3Dycfgxs5PYGtsWOhYKJpNhzBzh7 HFfwcqnqqNp57Pko0OgDln/7KK3w13UFFv0a9DuLtBK9WBBp2alNX3hqGD/Hp+ASzJfr +6Ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QL8MdNvcvq+NrUAn+gNwTGceYtoWusA65mZVG5WlzIk=; b=Y01f904eLyE7gBM2WDHepwiGHY62SEo7B9ZM2BmO87u9YxjD5/5mjGLAQ0Wmb4i3xZ Dj7Ak/I4qGVSr6OQ3a1OQSCujvEymskM7f11ByyRgXZX78l+PrtUzX4GhQp/0NKsGfeu SiMjkfQZJ+wxSUqA/fCvLlfNjbQwzfhUaii9JeGDHClI8YCbz1FCaqwi0VUy5KdlDhrr YOngKfu0VfkhkZQ8NUIdymlQPo3I6a8RB4cFjjzQRudpuyY/NpW52eQRuBooDmDgWukY fewx+Me/hA/KVXR5hLhFpaNkx/GF+Wo6h5tkIKTkxcELXdKkbPtWx8csHqCjKT9CF7Pe /7zQ==
X-Gm-Message-State: AOAM530dkbq8i77sm49IWzh3lZ0i4ufkTnMUqC0l8dQMjAnK29oWv4Tc duU6vFzaqCFkdKTR9UGHDvzkgw1vtQM=
X-Google-Smtp-Source: ABdhPJyNwwqWxdkpd5G8WteYhzQsIOS6zqNY8hqmfYxXdehWmVmcmPTFKF6/QG3aFSEAVGBm/APGeg==
X-Received: by 2002:a63:c64c:: with SMTP id x12mr3029087pgg.433.1599858776464; Fri, 11 Sep 2020 14:12:56 -0700 (PDT)
Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id l9sm2840071pgg.29.2020.09.11.14.12.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Sep 2020 14:12:55 -0700 (PDT)
To: Toerless Eckert <tte@cs.fau.de>, Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Robert Wilton <rwilton@cisco.com>, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org
References: <159708388539.28258.3242297268864037873@ietfa.amsl.com> <14395.1598218754@localhost> <20200911104532.GA45880@faui48f.informatik.uni-erlangen.de>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <4a0c48d3-b7e2-b00f-4030-735f3bdf3506@gmail.com>
Date: Sat, 12 Sep 2020 09:12:52 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <20200911104532.GA45880@faui48f.informatik.uni-erlangen.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/DymWyR8hH9F017RTaWkvpklFutE>
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 21:12:59 -0000

(CC trimmed to avoid distracting the IESG.)

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

Oh, I think every ASA should have this logic. In my prototype code, the ACP
module provides a status function acp.status() and really that should be polled
regularly, or there should be an event handler for "ACP down". My intention was
that GRASP calls would fail with a "noSecurity" error code in that case.

Actually the code is there but inactive, absent a real ACP.

Regards
   Brian

On 11-Sep-20 22:45, Toerless Eckert wrote:
> 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 =-
> 
> 
>