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

Benjamin Kaduk <kaduk@mit.edu> Wed, 14 August 2019 14:56 UTC

Return-Path: <kaduk@mit.edu>
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 4F3AA1208AB; Wed, 14 Aug 2019 07:56:22 -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 AcECTGOzh9c9; Wed, 14 Aug 2019 07:56:20 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C041208A7; Wed, 14 Aug 2019 07:56:20 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7EEuBAc009662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 10:56:13 -0400
Date: Wed, 14 Aug 2019 09:56:10 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Michael Richardson <mcr+ietf@sandelman.ca>
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
Message-ID: <20190814145610.GY88236@kduck.mit.edu>
References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <1777.1565641434@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1777.1565641434@localhost>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/DdnkxhY2zNMQ-wThfyTdTyeNZ9w>
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: Wed, 14 Aug 2019 14:56:23 -0000

On Mon, Aug 12, 2019 at 04:23:54PM -0400, Michael Richardson wrote:
> 
> 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.

I'm not sure I see how v6-only prevents URI dereference or obviates the
usecase for a firewall.  Perhaps you mean that there would be no
non-link-local available?

>     > 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.

Okay, thanks.

-Ben