Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 12 August 2019 22:33 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 26E6312138D; Mon, 12 Aug 2019 15:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 wwuuU-fbwKV3; Mon, 12 Aug 2019 15:33:28 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F27F1225DC; Mon, 12 Aug 2019 13:23:55 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6B6B63818D; Mon, 12 Aug 2019 16:23:09 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 37E37DCB; Mon, 12 Aug 2019 16:23:54 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Benjamin Kaduk <kaduk@mit.edu>
cc: The IESG <iesg@ietf.org>, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org
In-Reply-To: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com>
References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 12 Aug 2019 16:23:54 -0400
Message-ID: <1777.1565641434@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/dNt7nBqYieyeXG-FKeOaz2QZVG4>
Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (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: Mon, 12 Aug 2019 22:33:31 -0000

Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
    > Section 13.2

    > I think CDDL needs to be a normative reference, as does RFC 7231.  RFC
    > 2473 is listed but not referenced in the text, as are RFC 2663, RFC
    > 7217, and RFC 7575.

CDDL->RFC8610, now normative. (Glad that got published)
RFC2473 removed, we no longer attempt to document a stateless IPIP proxy
mechanism.

RFC2663 (NAT terminology) reference was for Join Proxy, and I've restored
a reference in section 4.

RFC7217 was thought to be relevant to Pledge use of SLAAC, but actually it's
not, removed.

You are right that we don't reference RFC7575, which is the architecture of
ANIMA.  I have added a sentence to the Intro, referencing RFC7575's
goal of "secure by default"

    > Appendix B

    doc>    Discovery of registrar MAY also be performed with DNS-based service
    doc> discovery by searching for the service "_brski-
    doc> registrar._tcp.example.com".  In this case the domain "example.com" is
    doc> discovered as described in [RFC6763] section 11 (Appendix A.2 suggests
    doc> the use of DHCP parameters).

    > I'd suggest using "<domain>" per 6763 rather than "example.com".

okay.

    doc>    If no local proxy or registrar service is located using the GRASP
    doc> mechanisms or the above mentioned DNS-based Service Discovery methods
    doc> the pledge MAY contact a well known manufacturer provided bootstrapping
    doc> server by performing a DNS lookup using a well known URI such as
    doc> "brski-registrar.manufacturer.example.com".  The details of the URI are
    doc> manufacturer specific.  Manufacturers that leverage this method on the
    doc> pledge are responsible for providing the registrar service.  Also see
    doc> Section 2.7.

    > It seems like there are some security considerations for device owners
    > that may wish to prevent such registrars from being used.  Do we need
    > to direct them to run a firewall or similar?

If they are doing ANIMA ACP bootstrapping, then there would ideally be no
IPv4 available, and so this won't work anyway.
I'd rather not get into too much of this here.

    > Appendix C

    > I don't know how important file "ietf-mud-extension@2018-02-14.yang"
    > is, but it seems a tad generic.

Renamed already.

Ben, I'm posting the -25, and then moving on back to the responses to
my responses, including Adam's concerns.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [