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> Sat, 12 September 2020 23:16 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 CC14D3A0E91; Sat, 12 Sep 2020 16:16:03 -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 1V8bzQ9jki2v; Sat, 12 Sep 2020 16:16:02 -0700 (PDT)
Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) (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 0C5C43A0BD4; Sat, 12 Sep 2020 16:16:02 -0700 (PDT)
Received: by mail-pj1-x1042.google.com with SMTP id jw11so3444269pjb.0; Sat, 12 Sep 2020 16:16:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=IX1FV7LedP86iay5L9yWFY/OEHC23CeyXL24Hbi/bnk=; b=WRQV8ZobrjBU15/+46A/yArwPk0GmVnJCjG15TXavjaHi38H6U25Rkd7Mtimqq0423 tLLWPSSZwZ+4tpt9dXSYrRHW9fXDoUEgVUh8ek3MH7+gKO88r2+H9xSXABrNjWN5SJ9W WM6sotAigii70zss86TvuHwk1fi4pM4M+TFRehBSgjD4vBzj1w9TIaAYup7/Sr567cSq k0xaAMe2S25evT3atYQHvG1HC+wibyLEvKopGE96OHmC49OUzdCvgsDe33b+Oa1I5adx 6xSckFVYb4EMpwSGE9+zaM6pSUi3S/b08yN67qMDJLnqwQ2j5LyuLtzkip2UUc4d8Byq Uf3g==
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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=IX1FV7LedP86iay5L9yWFY/OEHC23CeyXL24Hbi/bnk=; b=SZeNC3/cyxqAmmTUxB8GX9uHshujAkP+3rTI1qXS5a9p457zj8kQiqg0oQCB/D73+B mmxgmti9Rd4IE7UUcCkNI4XGPV0ddRLh/hYKt2gfF2PJZ+BgkeI8vE+jvtX/yIYb400L RU/yx6bihyaqWGHbxHKTxqDhJZs/j+DvCImFGlOvlwnhJG5R87t02AZT1alrMJMY8jBr UnpdB8ITpM2jxE1iK14D/xJ82TCkrCN2ZxmvHrvHavjpENNLb9pQ11rPvXHSvIkT3/XZ 1WaYru6wLDktI8iARjSf+/C9012tjAuLDkt6UQ0MfTBAVV4QKFF2qlDyl7hGsS07pjKW TpJA==
X-Gm-Message-State: AOAM5326DZVyYZclYE+Qpt/sJ84eDhidDBPLhY4wAcOptF8oh2ozEab/ HATTL3bnCSiimTVY4hWQKVQdPsUpGww=
X-Google-Smtp-Source: ABdhPJzKHNsdZAPMj3mzrzW5ytanH0sweEfs+cdwPF1plPx7ACQkTUG4LWztclVKHaax0tWN5vzfcw==
X-Received: by 2002:a17:902:ff12:: with SMTP id f18mr7850637plj.118.1599952561222; Sat, 12 Sep 2020 16:16:01 -0700 (PDT)
Received: from [192.168.178.20] ([151.210.138.136]) by smtp.gmail.com with ESMTPSA id 64sm6102894pfg.98.2020.09.12.16.15.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Sep 2020 16:16:00 -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> <4a0c48d3-b7e2-b00f-4030-735f3bdf3506@gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <5ada62db-96de-639d-5155-c82f89f9680b@gmail.com>
Date: Sun, 13 Sep 2020 11:15:55 +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: <4a0c48d3-b7e2-b00f-4030-735f3bdf3506@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/jfylhUmpAFMBMzLsorMBJ1b1wBE>
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: Sat, 12 Sep 2020 23:16:04 -0000

And I have improved that code, so that it really does make all GRASP
calls fail if the ACP reports that it is insecure and there is no
other security in place. It's still not production code, of course.

https://github.com/becarpenter/graspy/commit/c6d2270aea723baa4076cf8db34f8dcf14c9bd34

Regards
   Brian Carpenter

On 12-Sep-20 09:12, Brian E Carpenter wrote:
> (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 =-
>>
>>
>>