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

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 12 August 2020 20:53 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: anima@ietf.org
Delivered-To: anima@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7653A0B82; Wed, 12 Aug 2020 13:53:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, anima-chairs@ietf.org, anima@ietf.org, Sheng Jiang <jiangsheng@huawei.com>, jiangsheng@huawei.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <159726562734.26278.13160140371325516611@ietfa.amsl.com>
Date: Wed, 12 Aug 2020 13:53:47 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/AD2AERzGOGTjGOztRU82b26tupk>
Subject: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-autonomic-control-plane-28: (with DISCUSS and COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 12 Aug 2020 20:53:48 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-anima-autonomic-control-plane-28: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(pruned down to the remaining issue)

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


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The style of explaining the design choice after describing an element of the
protocol was informative and helpful.  Thanks.

This document has undergone a significant amount of security review.  Thank you
for incorporating all of this feedback.

Thanks for resolving my previous DISCUSS and COMMENTs.

** Section 6.8.2.1. Editorial.
OLD
The compromised ACP node would
   simply announce the objective as well, potentially filter the
   original objective in GRASP when it is a MITM and act as an
   application level proxy.

NEW
The compromised ACP node would simply announce the objective as well,
potentially filter the original objective in GRASP when it is in-path and
acting as an application level proxy.

** 10.2.2.  Editorial.
OLD
This minimizes man in the middle
   attacks by compromised ACP group members

NEW
This minimizes attacks by compromised ACP group members who are on-path.

** In reviewing the ballot position of my predecessor (ekr)

> Section 6.10.2.
>    o  When creating a new routing-subdomain for an existing autonomic
>       network, it MUST be ensured, that rsub is selected so the
>       resulting hash of the routing-subdomain does not collide with the
>       hash of any pre-existing routing-subdomains of the autonomic
>       network.  This ensures that ACP addresses created by registrars
>       for different routing subdomains do not collide with each others.

[ekr] You need to lay out the security assumptions here. It's not difficult
to create a new domain with the same 40bit hash. If you have a private
CA, this probably isn't an issue, but if you are sharing a public CA,
it would allow me to produce a domain with other people's addresses.

[Roman] If the domain uses a "public CA" as a trust anchor, is there a risk of
it might also be used by some other autonomic domain?