Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-autonomic-control-plane-27: (with DISCUSS and COMMENT)

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 11 August 2020 02:11 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 7F7983A0EEB; Mon, 10 Aug 2020 19:11:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.047
X-Spam-Level:
X-Spam-Status: No, score=-3.047 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.949, 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 5fJGp9CKj6-l; Mon, 10 Aug 2020 19:11:40 -0700 (PDT)
Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (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 3A9203A0F20; Mon, 10 Aug 2020 19:11:39 -0700 (PDT)
Received: by mail-pl1-x644.google.com with SMTP id r4so6073996pls.2; Mon, 10 Aug 2020 19:11:39 -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=uA1+dwu1JpcE8J5fKRQgV1b7RC8jgIXExuQjgJpK63k=; b=vQdekacldOfGt1aRiwdsGA9ItPUti0EquQNEufNp5y/crPNKx2C0G2TrzIyBSWTD3l j6fHwPdq4DQgxkTGb9uNCWCUoPu6XFXxsYjQznVITllrfB9gIxGlBCRKRQlzSfIoWv3a FAO+J2TcnzRb1IjEQH3C8dTUnL/tghaqm/oZMFSFnSx+NDislcr7hSwcwpBiIxD9sduS Nowlg8+HQTs646i+OwHDPo8mbDbYvSsbqdhoxjTZQXH9/mrLPpIqOD86wB0eH++OzLcp XSzzCUdW0XGD9rwYJEWncFdOjPuXBIeM2qNshoBZv76mPVJjeOBCXII6blhZzOK9QcXS LaIA==
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=uA1+dwu1JpcE8J5fKRQgV1b7RC8jgIXExuQjgJpK63k=; b=t04hASfXw4yckpwijIkLvrQwYQ9+OKYcvnQNnU9optL4eVKmRKk0r03p90jktb1S7S SX3chocnHzmbCJfmECI94UMm0ns7epOLIGnmQLD/ltX0cZ8h3/TNz8XOfaaPoCI8U9OJ HIDIlk6h5bB4lO2oUr0YEKEsvgwoBQp8hPpoyu/uGbvX7GfMXAAO+ERDjuugX69GHNxS 8LfocHUtPGM9iUt1G/OWesdPdBv0vVNB3LvxNTAjk8posC/x/nafHd4/lTjzUCD6JeR/ HbGcGL1dn5NVYZst1OyI2QgcjLUQfHez4mMMPtc1JFKEUO87pUPLwP1CYqdsBcAkfFmL oLrQ==
X-Gm-Message-State: AOAM530Obebv9+HMGNJEGHTy6WrXOnyl/SkYrPzFWlRLWez8bGWppDAU X1z7iPfw4LFcdUZAJwvw8SM=
X-Google-Smtp-Source: ABdhPJx3O0TRe2kgM5dHRSeCMcfj16e43edvB4i+rcuzWv/nmvB7zj9dhpX2GA0YqbejhUD8vNz+Ow==
X-Received: by 2002:a17:902:8f94:: with SMTP id z20mr27657761plo.123.1597111898635; Mon, 10 Aug 2020 19:11:38 -0700 (PDT)
Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id il13sm814143pjb.0.2020.08.10.19.11.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Aug 2020 19:11:37 -0700 (PDT)
To: Roman Danyliw <rdd@cert.org>, Toerless Eckert <tte@cs.fau.de>
Cc: "anima-chairs@ietf.org" <anima-chairs@ietf.org>, "draft-ietf-anima-autonomic-control-plane@ietf.org" <draft-ietf-anima-autonomic-control-plane@ietf.org>, The IESG <iesg@ietf.org>, "anima@ietf.org" <anima@ietf.org>, Sheng Jiang <jiangsheng@huawei.com>
References: <159478218035.5567.5331512017107084574@ietfa.amsl.com> <20200728153739.GI1772@faui48f.informatik.uni-erlangen.de> <96a6eb7f4f2c4cd0907a0f2a19900fe6@cert.org>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <346fff69-093f-60a7-c480-bdae39267e48@gmail.com>
Date: Tue, 11 Aug 2020 14:11:33 +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: <96a6eb7f4f2c4cd0907a0f2a19900fe6@cert.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/UoiYuQ-t4hPBUkbrN22EsSnIwmo>
Subject: Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-autonomic-control-plane-27: (with DISCUSS and 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: Tue, 11 Aug 2020 02:11:45 -0000

On 11-Aug-20 13:22, Roman Danyliw wrote:
> Hi Toerless!
> 
> Thanks for your detailed follow-up both in the form of the -28 and the helpful explanations below.  I think everything is cleaned up but the last discuss, I will update my ballot so it's easier to manage.
> 
> Roman
> 
>> -----Original Message-----
>> From: Toerless Eckert <tte@cs.fau.de>
>> Sent: Tuesday, July 28, 2020 11:38 AM
>> To: Roman Danyliw <rdd@cert.org>
>> Cc: The IESG <iesg@ietf.org>rg>; draft-ietf-anima-autonomic-control-
>> plane@ietf.org; anima-chairs@ietf.org; anima@ietf.org; Sheng Jiang
>> <jiangsheng@huawei.com>
>> Subject: Re: Roman Danyliw's Discuss on draft-ietf-anima-autonomic-control-
>> plane-27: (with DISCUSS and COMMENT)

...

> 
>>> ** Section 11.  Per the list of factors on which ACP depends, it seems
>>> like the following are missing:
>>>
>>> -- the security properties of the enrollment protocol
>>>
>>> -- that the security considerations of EST and BRSKI apply (or if not,
>>> why not)
>>
>> Resolution:
>>
>> No change, but the following explanations:
>>
>> The ACP is explicitly defined to be a set of nodes with ACP domain certificates,
>> enrollment/BRSKI is really out of scope. Normative ACP nodes start their
>> existance with an ACP cert. How they got it is part of a prior life. BRSKI security
>> properties are covered in BRSKI draft.
>>
>> I struggled long how to well define registrars given that ACP does not mandate/
>> specify any specific protocol.  The solution in the document is that there is only
>> a very abstract definition of the normative requirements against registrars in
>> 6.10.7, pretty much simple requirements against the resulting certificates such
>> as registrar MUST NOT assign same addresses to multiple nodes for example.
>>
>> Think of a registrar abstractely as this:
>>
>> https://datatracker.ietf.org/meeting/102/materials/slides-102-dinrg-dinrg-
>> anima-toerless-eckert-00
>> Slide 10
>>
>> While funny, its not far away from a possible reality of a network operator
>> being a registrar, provisioning ACP certificates manually into ACP nodes, and
>> performing all the backend operations (CA, MASA, adressing database).
>>
>> BRSKI is of course the ANIMA preferred enrollment protocol, and if it is used,
>> an ACP node is called an ANI node (ACP+BRSKI). Section 3.2 makes the security
>> property of the ACP for any such bootstrap protocol. For example in
>> communities outside of ANIMA, NetConf ZeroTouch might be preferred over
>> BRSKI.
>>
>> The only mandatory ACP part of your above list is EST ONLY for renewal of
>> certificates, an that of course is specified in the normative section.
>>
>> The BRSKI draft itself defines how it integrates with ACP (GRASP objective etc.).
>>
>> Hope this answers satisfactory the concern.
> 
> I reread the Section 11 with your explanation in mind and see your perspective -- it's difficult to be specific without mandating a specific protocol.  However, there seems to be two concrete, normative elements of this architecture -- EST and GRASP.  The latter for bootstrapping and the formal for renewal.  It isn't clear then why their Sec Considerations don't apply.  Furthermore, the protocols and practices of the bootstrapping process are out of scope of this document but seem like a security building block on which ACP is being built.

The use of GRASP for adding a node to the ACP must not rely on the ACP for security, but in "normal life" GRASP must rely on the ACP for security. Although GRASP has been sitting in the RFC queue for >2 years, I think it does cover this fairly clearly:

     2.5.  GRASP Protocol Basic Properties and Mechanisms  . . . . .  12
       2.5.1.  Required External Security Mechanism  . . . . . . . .  12 [that's the ACP]
       2.5.2.  Discovery Unsolicited Link-Local (DULL) GRASP . . . .  13 [that's for booting the ACP]

In other words, GRASP section 2.5.1 depends on ACP security, and ACP security depends on GRASP section 2.5.2. Would a cross reference from ACP to GRASP in the last paragraph of ACP section 11 help?

Also, three paragraphs above, there is this:

   In combination with BRSKI, ACP enables a resilient, fully zero-touch
   network solution...

Would another reference to draft-ietf-anima-bootstrapping-keyinfra there help?

The three documents (ACP, BRSKI, GRASP) really do chase each other's tails.

Regards
   Brian