From nobody Mon Dec 2 15:56:40 2019 Return-Path: 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 D512112008F for ; Mon, 2 Dec 2019 15:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ck9VMxMym85z for ; Mon, 2 Dec 2019 15:56:37 -0800 (PST) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 35A3E120058 for ; Mon, 2 Dec 2019 15:56:37 -0800 (PST) Received: by mail-pg1-x52a.google.com with SMTP id k13so631383pgh.3 for ; Mon, 02 Dec 2019 15:56:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ojtGScWuGJ/sw0mcAZOuZCgZOvK3vy9okSCO0nsLkLY=; b=bOMkmMjOhHtsdKfr8c0HphW+XITMJANbbUm3EmKGN/kRFr4BBJ8EcmjR8dAmEgFAXT bQRItqtO2mzo67cmOm+Q+XIN83B4IMf2eL5TyR1eOQFvxu+fIwgnUoZ6L31OEGjAlJf3 o8epxTD0GHJ1y9rQq1hLkLOcxJeNYRrHU5cLEA6d1RCh8jaIhO+R9eDwuNRzbOCaNFS+ DOzLm7XDzMJ4pwqpSMenYWIJbtaGWymi8OmrbvK08uobz2x3kXtlkA3f++31gq/3jqAK ytOSoOXdWVWz+VV96LkS3M+0WTLs5XylRiOexsbTxRB80kj+XvDY2IyZacDxTWc+it7a 0YPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ojtGScWuGJ/sw0mcAZOuZCgZOvK3vy9okSCO0nsLkLY=; b=WxGuqx5KtMeHd0Pjve37UV1/hWwz3GL0pAcbUocB5oKpSRUS8W8sfgCE/Iv02gERYx JwF8HGcFLgnqz7qNTJ+pECgk0F3uHXOZwGNW0MJBwO/4Ti3bc/sPyyHUheETzp8J5SHB /0btiIaOC+Gjbo432RyoS5hSOpnvNI+MuNKP+zLJ8kv5ZwKUGVwqRzxa111vXknh6Iql K+hM8Drbfufovi7g1pIMNg8vTzxFqvVHka05ZXWe3rJMEt+w6px2IlkdVvp+R+WB4fqu CM9A1EnbY/1GEJwtmnTZoMThx7JAWCfji7YrXOoz5tlOTxraROrxF8Gm6qnDlboGwp8E erhQ== X-Gm-Message-State: APjAAAX1W2iRCEyo9qFDkpfIWsBEcdHtHGjTfm0tezyagdbecj03sfgw Duo8MsQu8huAjrdzQXwI42mz8tEC X-Google-Smtp-Source: APXvYqzVxOq/uUWH3v8rYXDMc1fn0u7hng8WyM7ZsuHgEfY4lpRv6TDybm0bOrSkcpbv10o46zTjsw== X-Received: by 2002:a63:da47:: with SMTP id l7mr1998915pgj.34.1575330996451; Mon, 02 Dec 2019 15:56:36 -0800 (PST) Received: from [130.216.37.136] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.37.136]) by smtp.gmail.com with ESMTPSA id t8sm652358pfq.92.2019.12.02.15.56.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Dec 2019 15:56:35 -0800 (PST) To: Anima WG , Michael Richardson References: <157529976858.4217.101359000675381605@ietfa.amsl.com> From: Brian E Carpenter Message-ID: Date: Tue, 3 Dec 2019 12:56:31 +1300 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: <157529976858.4217.101359000675381605@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-richardson-anima-registrar-considerations-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 23:56:39 -0000 Hi, This looks like all good stuff to me and I don't have much to say. > The domain is embodied by the Registrar component. I think that's a step too far, because the Registrar doesn't do anything to establish the domain boundary and which nodes are at the edges of the domain. So I think it's better to say "The Registrar component embodies the identity, membership and trust anchor of the domain." [The identity being the DomainID, and the membership being the set of currently enrolled pledges. The registrar is the trust anchor because it either contains or interfaces with the CA.] > This document, while a Best Current Practices, makes use of BCP14 > language to indicate which practices are mandatory, and which ones > are just recommendations. Did you mean to write "while *not* a BCP"? In any case you've tagged the draft for the standards track, which seems wrong. Regards Brian On 03-Dec-19 04:16, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Operational Considerations for BRSKI Registrar > Author : Michael Richardson > Filename : draft-richardson-anima-registrar-considerations-00.txt > Pages : 18 > Date : 2019-12-02 > > Abstract: > This document describes a number of operational modes that a BRSKI > Registration Authority (Registrar) may take on. > > Each mode is defined, and then each mode is given a relevance within > an over applicability of what kind of organization the Registrar is > deployed into. This document does not change any protocol > mechanisms. > > This document includes operational advice about avoiding unwanted > consequences. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-richardson-anima-registrar-considerations/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-richardson-anima-registrar-considerations-00 > https://datatracker.ietf.org/doc/html/draft-richardson-anima-registrar-considerations-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Wed Dec 4 07:09:29 2019 Return-Path: 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 C9A4612081D for ; Wed, 4 Dec 2019 07:09:27 -0800 (PST) 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 9PDPm0Je-MmI for ; Wed, 4 Dec 2019 07:09:24 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC2612008C for ; Wed, 4 Dec 2019 07:09:24 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0E22B3818F; Wed, 4 Dec 2019 10:05:46 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BADCE61C; Wed, 4 Dec 2019 10:09:22 -0500 (EST) From: Michael Richardson To: Brian E Carpenter cc: Anima WG In-Reply-To: References: <157529976858.4217.101359000675381605@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 Archived-At: Subject: Re: [Anima] I-D Action: draft-richardson-anima-registrar-considerations-00.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2019 15:09:28 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > This looks like all good stuff to me and I don't have much to say. >> The domain is embodied by the Registrar component. > I think that's a step too far, because the Registrar doesn't > do anything to establish the domain boundary and which nodes > are at the edges of the domain. So I think it's better to say > "The Registrar component embodies the identity, membership and > trust anchor of the domain." Thank you. > [The identity being the DomainID, and the membership being the > set of currently enrolled pledges. The registrar is the trust > anchor because it either contains or interfaces with the CA.] >> This document, while a Best Current Practices, makes use of BCP14 >> language to indicate which practices are mandatory, and which ones >> are just recommendations. > Did you mean to write "while *not* a BCP"? In any case you've > tagged the draft for the standards track, which seems wrong. I meant to mark it as BCP (fixing), or perhaps it would informational. I'm not really sure if makes sense to publish it in any rush. Perhaps it belongs in a book or white paper. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl3nzCIACgkQgItw+93Q 3WWSlgf+Nj2NCpjuulatgH5NvRnm9YrZdVebpSOwfDpqtgiPhCqY+MHgcqTrUMvQ 0FHQothXAjDJa0wbPgJxluKkZqDvvznh2UeHEveV9tlvfEWSJJczEmVIxx61mfP6 eyJhaCjGlVp44VHtw2UugYYnR1j+qi0447viFPZdjKR2Wn5WO1a9P3n4oT1R6Y2A T3b2gS85cA9Jty+yKrCJBsJX+BxpXhc3zRnrWOs4vfeRA6E9F9eIK5WUTNGHWUPf P3G6mq0XYh86ZIjYA0VHidbk1m9deIuTGmTeIk8iTh8ZGIfRgIvqViIYB0AvKQu5 DOhGHmYkNgBX4e9XpLIrIO5BzN6Dwg== =1k9A -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 5 07:19:49 2019 Return-Path: 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 D2452120013 for ; Thu, 5 Dec 2019 07:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 il14xgbuManQ for ; Thu, 5 Dec 2019 07:19:46 -0800 (PST) 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 CB2C812002E for ; Thu, 5 Dec 2019 07:19:46 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 117363818F for ; Thu, 5 Dec 2019 10:16:07 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B450335D for ; Thu, 5 Dec 2019 10:19:45 -0500 (EST) From: Michael Richardson To: anima@ietf.org In-Reply-To: <157549376086.11247.1509180991540489913.idtracker@ietfa.amsl.com> References: <157549376086.11247.1509180991540489913.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 Archived-At: Subject: [Anima] draft-richardson-anima-masa-considerations-01.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2019 15:19:49 -0000 --=-=-= Content-Type: text/plain I have been working on two Operatonal Considerations document for BRSKI Registrar(1) and MASA(2). I also wrote an IPv6-over-LLDP proposal(3) that aims to make the ACP easier to implement. Unfortunately, due copy and paste errors I posted (3) with the file name for (2), so the -00/-01 diff on this document is nonsensical. Here is the MASA operational considerations document. It is far from complete as it does not yet deal with nonceless operation, nor does it deal with constrained voucher operation. It does deal with security implications of different PKI and Signing Authority key architectures. I suspect that there are some other variations that I have neglected or just not considered. internet-drafts@ietf.org wrote: > A new version of I-D, draft-richardson-anima-masa-considerations-01.txt > has been successfully submitted by Michael Richardson and posted to the > IETF repository. > Name: draft-richardson-anima-masa-considerations > Revision: 01 > Title: Operational Considerations for Manufacturer Authorized Signing Authority > Document date: 2019-12-04 > Group: Individual Submission > Pages: 10 > URL: https://www.ietf.org/internet-drafts/draft-richardson-anima-masa-considerations-01.txt > Status: https://datatracker.ietf.org/doc/draft-richardson-anima-masa-considerations/ > Htmlized: https://tools.ietf.org/html/draft-richardson-anima-masa-considerations-01 > Htmlized: https://datatracker.ietf.org/doc/html/draft-richardson-anima-masa-considerations > Diff: https://www.ietf.org/rfcdiff?url2=draft-richardson-anima-masa-considerations-01 > Abstract: > This document describes a number of operational modes that a BRSKI > Manufacturer Authorized Signing Authority (MASA) may take on. > Each mode is defined, and then each mode is given a relevance within > an over applicability of what kind of organization the MASA is > deployed into. This document does not change any protocol > mechanisms. > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > The IETF Secretariat -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl3pIBEACgkQgItw+93Q 3WUTqQf/ch4n1VlOPFMjleF4hR8JfSA53+ZL+1DxSAFCxbFxld2Bvdjg9R4L18EZ RABfkxdS7I5gY8hE1RaoENl9HXhjM9+CED7YL9Rmeyk+fVt8zJdMBRuU3L45yNK0 jDiUm3PUBMnu7/kIjsRxpRdzrhxLjrNuJqd53r4OGSDBv2b6dPhkAjCp3rpJ4UJj vKgCRGIJkxhUx0bZa4R8ucnXay/t/oe18FRhLhb28TjzSZZgqtf3nCbxNZ/CpP5P E25moHjhoX3YNG4J0EdxtjV4XppRAjPfj3aQarsOFf3usDcI5myd5j0K3RaNuRil CnXJgiFJtbobGRrnymIPd1T9wBLsag== =MKrZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 13 00:50:36 2019 Return-Path: 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 6F42D12008C; Fri, 13 Dec 2019 00:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 6JCh6NI8cL40; Fri, 13 Dec 2019 00:50:32 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 8ABE212006B; Fri, 13 Dec 2019 00:50:32 -0800 (PST) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E067270037876B2D73D7; Fri, 13 Dec 2019 08:50:29 +0000 (GMT) Received: from fraeml707-chm.china.huawei.com (10.206.15.35) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 13 Dec 2019 08:50:29 +0000 Received: from fraeml719-chm.china.huawei.com (10.206.15.15) by fraeml707-chm.china.huawei.com (10.206.15.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 13 Dec 2019 09:50:29 +0100 Received: from fraeml719-chm.china.huawei.com ([10.206.15.15]) by fraeml719-chm.china.huawei.com ([10.206.15.15]) with mapi id 15.01.1713.004; Fri, 13 Dec 2019 09:50:29 +0100 From: Xun Xiao To: "anima-chairs@ietf.org" , "anima@ietf.org" CC: "Liubing (Leo)" , Artur Hecker , Zoran Despotovic , Sheng Jiang Thread-Topic: New Version Notification for draft-liu-anima-grasp-distribution-13.txt Thread-Index: AQHVsQhF0Ilpb2SdLU+sljxSk1B686e3wQfA Date: Fri, 13 Dec 2019 08:50:28 +0000 Message-ID: <3bf6b1827b954c29a5bc9647fbe30f71@huawei.com> References: <157616770426.20852.6061499986285417726.idtracker@ietfa.amsl.com> In-Reply-To: <157616770426.20852.6061499986285417726.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.99.168] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] New Version Notification for draft-liu-anima-grasp-distribution-13.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2019 08:50:35 -0000 RGVhciBDaGFpcnMsIERlYXIgQU5JTUEgV0cgbWVtYmVycywNCg0KRHVyaW5nIElFVEYxMDYsIHRo ZSBhdXRob3JzIGhlcmUgaGFkIG1hbnkgdGVjaG5pY2FsIGRpc2N1c3Npb25zIG9uIHRoZSBpbmZv cm1hdGlvbiBkaXN0cmlidXRpb24gdG9waWMgd2l0aCBzZXZlcmFsIGdyb3VwIG1lbWJlcnMuIE1h bnkgdGhhbmtzIGZvciB0aGUgY29uc3RydWN0aXZlIGNvbW1lbnRzL2FkdmljZXMuDQoNCkhlcmVi eSwgYWNjb3JkaW5nIHRvIHRoZSBmZWVkYmFja3MsIGEgcmV2aXNlZCB2ZXJzaW9uIGlzIHVwZGF0 ZWQsIHRyeWluZyB0byBiZXR0ZXIgbW90aXZhdGUgdGhlIHByb2JsZW0gYW5kIGludHJvZHVjZSB0 aGUgcHJvcG9zZWQgc29sdXRpb24uIFdlIHdpbGwgYXBwcmVjaWF0ZSBhbnkgZnVydGhlciBjb21t ZW50cy4NCg0KTWVhbndoaWxlLCBhcyBvbmUgb2YgdGhlIGNoYXJ0ZXJlZCBtaWxlc3RvbmUgdG9w aWMgd29yaywgd2Ugd2VyZSB3b25kZXJpbmcgaWYgdGhlIGRyYWZ0IGNhbiBiZSBhZG9wdGVkIGFz IGEgV0cgZHJhZnQgd29ya2luZyBpbiBwcm9ncmVzcyBvbiB0aGUgc3RhbmRhcmQgdHJhY2suIFRo YW5rcyBmb3IgeW91ciBjb25zaWRlcmF0aW9ucy4NCg0KQmVzdCBSZWdhcmRzLA0KDQpYdW4gWGlh byAo6IKW6L+FKQ0KQWR2YW5jZWQgV2lyZWxlc3MgVGVjaG5vbG9neSBMYWINCk11bmljaCBSZXNl YXJjaCBDZW50ZXINCkh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLEx0ZC4NCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgMTIgRGVjZW1iZXIgMjAx OSAxNzoyMg0KVG86IExpdWJpbmcgKExlbykgPGxlby5saXViaW5nQGh1YXdlaS5jb20+OyBBcnR1 ciBIZWNrZXIgPEFydHVyLkhlY2tlckBodWF3ZWkuY29tPjsgWHVuIFhpYW8gPFh1bi5YaWFvQGh1 YXdlaS5jb20+OyBab3JhbiBEZXNwb3RvdmljIDxab3Jhbi5EZXNwb3RvdmljQGh1YXdlaS5jb20+ OyBTaGVuZyBKaWFuZyA8amlhbmdzaGVuZ0BodWF3ZWkuY29tPg0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saXUtYW5pbWEtZ3Jhc3AtZGlzdHJpYnV0aW9uLTEz LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1saXUtYW5pbWEtZ3Jhc3AtZGlz dHJpYnV0aW9uLTEzLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBYdW4g WGlhbyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1s aXUtYW5pbWEtZ3Jhc3AtZGlzdHJpYnV0aW9uDQpSZXZpc2lvbjoJMTMNClRpdGxlOgkJSW5mb3Jt YXRpb24gRGlzdHJpYnV0aW9uIGluIEF1dG9ub21pYyBOZXR3b3JraW5nDQpEb2N1bWVudCBkYXRl OgkyMDE5LTEyLTEyDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkyMQ0K VVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1saXUtYW5pbWEtZ3Jhc3AtZGlzdHJpYnV0aW9uLTEzLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpdS1hbmltYS1ncmFzcC1kaXN0 cmlidXRpb24vDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWxpdS1hbmltYS1ncmFzcC1kaXN0cmlidXRpb24tMTMNCkh0bWxpemVkOiAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWxpdS1hbmltYS1ncmFzcC1k aXN0cmlidXRpb24NCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1dGlvbi0xMw0KDQpBYnN0cmFjdDoN CiAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSBzb2x1dGlvbiBmb3IgaW5mb3JtYXRpb24gZGlz dHJpYnV0aW9uIGluDQogICBhdXRvbm9taWMgbmV0d29ya3MuIEluZm9ybWF0aW9uIGRpc3RyaWJ1 dGlvbiBpcyBjYXRlZ29yaXplZCBpbnRvIHR3bw0KICAgZGlmZmVyZW50IG1vZGVzOiAxKSBpbnN0 YW50YW5lb3VzIGRpc3RyaWJ1dGlvbjsgMikgcHVibGljYXRpb24gZm9yDQogICByZXRyaWV2YWwu IEluIHRoZSBmb3JtZXIgY2FzZSwgdGhlIGluZm9ybWF0aW9uIGlzIHNlbnQsIHByb3BhZ2F0ZXMN CiAgIGFuZCBpcyBkaXNwb3NlZCBvZiBhZnRlciByZWNlcHRpb24uIEluIHRoZSBsYXR0ZXIgY2Fz ZSwgaW5mb3JtYXRpb24NCiAgIG5lZWRzIHRvIGJlIHN0b3JlZCBpbiB0aGUgbmV0d29yay4NCg0K ICAgVGhlIGNhcGFiaWxpdGllcyB0byBkaXN0cmlidXRlIGluZm9ybWF0aW9uIGFyZSBiYXNpYyBh bmQgZnVuZGFtZW50YWwNCiAgIG5lZWRzIGZvciBhbiBhdXRvbm9tb3VzIG5ldHdvcmsgKGNmLiBB TkkgW0ktRC5pZXRmLWFuaW1hLXJlZmVyZW5jZS0NCiAgIG1vZGVsXSkuIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIHR5cGljYWwgdXNlIGNhc2VzIG9mIGluZm9ybWF0aW9uDQogICBkaXN0cmlidXRp b24gaW4gQU5JIGFuZCByZXF1aXJlbWVudHMgdG8gQU5JLCBzdWNoIHRoYXQgcmljaA0KICAgaW5m b3JtYXRpb24gZGlzdHJpYnV0aW9uIGNhbiBiZSBuYXRpdmVseSBzdXBwb3J0ZWQuIFRoZSBkb2N1 bWVudA0KICAgcHJvcG9zZXMgZXh0ZW5zaW9ucyB0byB0aGUgYXV0b25vbWljIG5vZGVzIGFuZCBz dWdnZXN0cyBhbg0KICAgaW1wbGVtZW50YXRpb24gYmFzZWQgb24gR1JBU1AgZXh0ZW5zaW9ucyBh cyBhIHByb3RvY29sIG9uIHRoZSB3aXJlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoN Cg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlh dA0KDQo= From nobody Fri Dec 13 02:31:36 2019 Return-Path: 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 B9D1512026E; Fri, 13 Dec 2019 02:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=WUkBMoX/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yyRD9ym8 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 0nepNrtNnlPz; Fri, 13 Dec 2019 02:31:33 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB5E120839; Fri, 13 Dec 2019 02:31:33 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 8F409225E6; Fri, 13 Dec 2019 05:31:31 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 13 Dec 2019 05:31:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm1; bh=aRS1vn52nCH6q2eyerlAiX1 blu766y45sX7p+3ZBOQo=; b=WUkBMoX/xPNu/wlCoDbXqlF1iV5rtGe363yBFHA 9n0OdxCGd2Z7k2KAgE79c+i35ggIfwOhky1UDt008PbctiKyxgIAQi/upDhBJCs+ Jv7zrGPuEEZ2YhEKx1ToOHUx+avK/zK6BY7RuFoBMYfJ3Vos+AkWHrjlvmzyJp5s fbjY/GZU+bF7+SBtmj7xK1J+qJtSSgSTVQ9MlporQBRI+iLy5GxX3mzNsGQrSlpN +swC677sR+H3ENncbzeYhlZcuII4yswnjfjn2FvfHBGh31w1Wp6VRyKDt5SOdeqY rNAimWgv5xg7RCBJpCV7S3bGWXNcakyyYuE0LDwbTerqwyA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=aRS1vn 52nCH6q2eyerlAiX1blu766y45sX7p+3ZBOQo=; b=yyRD9ym82yov95J2V01WEh aFIolWH4zC06HPYnQ7ACD+k0K6T95wrO6N8XB+Ma6cIRTaHF74TdfIv8XA1GSSs7 jzVbuQGY2NwMTrRoOV+QbfQc29D83i0Q0HCdf3oSl7QrB+Uis9ZaYI+dX5vpUjPW Dm8sZ6PejnPqxRIErNRAJKkaCoD08p8HGQK6HqTOonUX/3ydKu3WDsFyv9USZ6JB mO83hjkw6NjuoucoXagUPX3pVUDq1U4hdfGgBTd8aaMcMqJbiyGR/vyMnioiD+a5 OVjlqZEOcxAZTN3oQHesvWnS8rdou50oSXNemWuTCq7nzm0qk3bSKGb18/UPj6KA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudelledgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhkfgtggfuffgjvfhfofesrgdtmh erhhdtjeenucfhrhhomheptehlihhsshgrucevohhophgvrhcuoegrlhhishhsrgestgho ohhpvghrfidrihhnqeenucfkphepuddtkedrhedurddutddurdelkeenucfrrghrrghmpe hmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvghr ufhiiigvpedt X-ME-Proxy: Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id BBE5D80066; Fri, 13 Dec 2019 05:31:30 -0500 (EST) From: Alissa Cooper Message-Id: <2FA2728E-6484-4A69-992A-479D8053354E@cooperw.in> Content-Type: multipart/alternative; boundary="Apple-Mail=_F6D9C18E-B407-4178-B1F2-49422E345833" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 13 Dec 2019 05:31:29 -0500 In-Reply-To: <9637.1574756997@localhost> Cc: IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org To: Michael Richardson References: <157123777786.7830.10713306244839546046.idtracker@ietfa.amsl.com> <9637.1574756997@localhost> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2019 10:31:35 -0000 --Apple-Mail=_F6D9C18E-B407-4178-B1F2-49422E345833 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Michael, I have not seen a response to Tom Petch=E2=80=99s last email (copied in = below). Thanks, Alissa > Begin forwarded message: >=20 > From: tom petch > Subject: Re: [Last-Call] [Gen-art] Genart telechat review of = draft-ietf-anima-bootstrapping-keyinfra-28 > Date: October 29, 2019 at 7:49:39 AM EDT > To: Michael Richardson > Cc: "draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org" = , = "gen-art@ietf.org" , Alissa Cooper = , Last Call , Dan Romascanu = , "anima@ietf.org" >=20 > Michael >=20 > I just saw -29 after my last message and it still needs work. >=20 > Appendix C confuses me. The reference to it from IANA Considerations > suggests that it is Normative but there is nothing in it to say that = it > is and my take is that by default it is Informational. >=20 > It contains a YANG module which > - lacks references on import statements > - lacks authors > - lacks copyright > - is not listed in IANA Considerations > - has http: not https: > - has a reference clause with a different title to that of the I-D > - mixes URI and URL > all in 35 lines :-) >=20 > The YANG module in s.3.4 > - references RFC8040 which is not in the I-D References > - references > Voucher Profile for Bootstrapping Protocols > whereas this I-D has a title of > Bootstrapping Remote Secure Key Infrastructures (BRSKI) > - has > // Grouping defined for future usage > whereas the grouping is used in the previous YANG statement which = leaves > me puzzled > - lacks YANG reference statements for > leaf proximity-registrar-cert { > i.e. RFC5280, X.690, RFC8446 > - has [RFC8446] which looks like an XML/HTML anchor where a YANG = module > must be plain text >=20 > - IANA Considerations does not register either module, 3.4 or Appendix > C, as per RFC6020 s.14 >=20 > - Security Consideratrions does not include the required YANG > considerations which in turn generates further Normative References >=20 > - Appendix A > /The secification/The specification/ >=20 > Tom Petch > On Nov 26, 2019, at 3:29 AM, Michael Richardson = wrote: >=20 >=20 > Hi Alissa, just a reminder that the -30 draft posted during IETF week > resolves the Yang Doctor issue that you had raised. >=20 --Apple-Mail=_F6D9C18E-B407-4178-B1F2-49422E345833 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Michael,

I have not = seen a response to Tom Petch=E2=80=99s last email (copied in = below).

Thanks,
Alissa

Begin forwarded message:

From: tom petch <daedulus@btconnect.com>
Subject: Re: [Last-Call] = [Gen-art] Genart telechat review of = draft-ietf-anima-bootstrapping-keyinfra-28
Date: October 29, 2019 at 7:49:39 AM EDT
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org" = <draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org>, = "gen-art@ietf.org" = <gen-art@ietf.org>, Alissa Cooper <alissa@cooperw.in>, = Last Call <last-call@ietf.org>, Dan Romascanu <dromasca@gmail.com>, = "anima@ietf.org" <anima@ietf.org>

Michael

I just saw -29 after my last message and it = still needs work.

Appendix C confuses me. =  The reference to it from IANA Considerations
suggests = that it is Normative but there is nothing in it to say that it
is and my take is that by default it is Informational.

It contains a YANG module which
- = lacks references on import statements
- lacks authors
- lacks copyright
- is not listed in IANA = Considerations
- has http: not https:
- has = a reference clause with a different title to that of the I-D
- mixes URI and URL
all in 35 lines :-)

The YANG module in s.3.4
- = references RFC8040 which is not in the I-D References
- = references
 Voucher Profile for Bootstrapping = Protocols
whereas this I-D has a title of
 Bootstrapping Remote Secure Key Infrastructures = (BRSKI)
- has
 // Grouping defined for = future usage
whereas the grouping is used in the previous = YANG statement which leaves
me puzzled
- = lacks YANG reference statements for
         leaf = proximity-registrar-cert {
i.e. RFC5280, X.690, RFC8446
- has [RFC8446] which looks like an XML/HTML anchor where a = YANG module
must be plain text

- IANA Considerations does not register either module, 3.4 or = Appendix
C, as per RFC6020 s.14

- Security Consideratrions does not include the required = YANG
considerations which in turn generates further = Normative References

- Appendix A
/The secification/The specification/

Tom Petch


On Nov 26, 2019, at 3:29 AM, Michael Richardson <mcr@sandelman.ca> = wrote:


Hi Alissa, just a reminder that the -30 draft = posted during IETF week
resolves the Yang Doctor issue = that you had raised.


= --Apple-Mail=_F6D9C18E-B407-4178-B1F2-49422E345833-- From nobody Sun Dec 15 20:20:51 2019 Return-Path: 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 329F01200C5 for ; Sun, 15 Dec 2019 20:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 uTLzHNulxB0E for ; Sun, 15 Dec 2019 20:20:48 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 932841200B4 for ; Sun, 15 Dec 2019 20:20:48 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id b9so2883944pgk.12 for ; Sun, 15 Dec 2019 20:20:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:from:to:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=RjnfPQMiz2/EoE91ABQgBFIrQ06oJ2TipLl2+Phcl0g=; b=mYUKQkPJq0ycWQLOCxC/KTLe4vyGvKXkzzpDIzbk+zFKdFzt7am6Hm7pjRrOsdR9+0 sED0CK7vE5Bg+1Lb3lTxH2SyYJ50zXK3zZ3b6xaKPkOnoqIYzyIAyacSkYqodeb48N0G KXSRpyoGjgh5ZAOriZ1zQl8bip2GAlchXx3+xJNHpcaylQx7q8pS5ZW9+F3xDo6tOzyg My+H2zVjYCEyHCzK2szyVS2jix76pt9p+Bsgzlmz5FAYNqg4lmpoCkjbnUrhplXm/kyJ 27nudfYuXk0gp/kWKt2Rn5YRf3c2JPM/exLpBVEJeDdP8ET7bjUmh0RgVbZlGWSw+Sb5 VdAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:from:to:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RjnfPQMiz2/EoE91ABQgBFIrQ06oJ2TipLl2+Phcl0g=; b=byyACTFFUPYGNYCdz9gIoUThWT1J9Ll/HeF1Yu+qH6SpO2vYsa3iveXO7k/PEijHxX 1AGVUeEDL1rkIYbbnrNBZ9Zd3uOI1ex0EoAMHM0c74XcS1+4BDNswmm7yfCGiH2+s4ZB xSHXTeCDq+cfORQWxD1eyGBgmpin2E1YnThemNtevxiAWptDhgVnuBL3NpNZT7f96lfe cbwi/7AqC8M1F5nCNF2tI9fO1IkSH9CxMIfDDM4Zy7qY5rwmqlJ26Awo6Ketfji9+Lq9 Hi5M93yawfo6P0S1D3pFwtxniXMDW0tbL9sWh6TbZzfsLcFxSXI7aSWqNdU4Q6SFed4z wXBA== X-Gm-Message-State: APjAAAUWXJSnrdah/KNnrTtpXGBegI9oRXcKydrHvOVwFLTIehk1nT1g ZmnOAPlJG0wJTBSxmqNU2ZGGh9El X-Google-Smtp-Source: APXvYqwtWRlWZcrtETcUZ9Nu2+FjWEwquxtL6Ekx57/iw9X2zI0UpElQ6+8Q4LO1vCh5zxCyUUQ+FQ== X-Received: by 2002:a63:6fca:: with SMTP id k193mr16289048pgc.416.1576470047680; Sun, 15 Dec 2019 20:20:47 -0800 (PST) Received: from [192.168.178.30] (228.147.69.111.dynamic.snap.net.nz. [111.69.147.228]) by smtp.gmail.com with ESMTPSA id ev11sm17639579pjb.1.2019.12.15.20.20.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Dec 2019 20:20:47 -0800 (PST) References: <157616770411.20852.10953979041894273077@ietfa.amsl.com> From: Brian E Carpenter To: Anima WG Message-ID: Date: Mon, 16 Dec 2019 17:20:45 +1300 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: <157616770411.20852.10953979041894273077@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-13.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 04:20:50 -0000 Hi, I think this is a useful extension of the basic autonomic infrastructure. Here are some comments and questions on the GRASP part of the draft. I'd be interested in the authors' comments. > 5.1 Realizing Instant P2P Transmission > > This could be a new message in GRASP. In fragmentary CDDL, an Un- > solicited Synchronization message follows the pattern: > > unsolicited_synch-message = [M_UNSOLIDSYNCH, session-id, > objective] I suggest simply calling this M_PUSH (but see later comments). > A node MAY actively send a unicast Un-solicited Synchronization > message with the Synchronization data, to another node. This MAY be > sent to port GRASP_LISTEN_PORT at the destination address, That port is normally tied up with multicast reception. But since we have a SUBSCRIBE mechanism below, the question of the port can be resolved at SUBSCRIBE time. There must be a listener process for this port, of course. > which > might be obtained by GRASP Discovery or other possible ways. The > synchronization data are in the form of GRASP Option(s) for specific > synchronization objective(s). One objective per message is much simpler to implement. If not, this becomes more like a "unicast Flood". If you want that, we could define the syntax precisely like M_FLOOD. > 5.2 Realizing Instant Selective Flooding > > Since normal flooding is already supported by GRASP, this section > only defines the selective flooding extension. ... > The action means, when the match rule applies, the current device > just continues flood or discontinues. Please remember that a normal M_FLOOD has two aspects for a node that receives it. First, the node stores the objectives delivered in its own flood cache. Second, *if* it is a relay node (with interfaces to more than one link within the AN, such as a router) it relays a copy of the M_FLOOD to its AN neighbors, subject to anti-looping rules. 1) If the result of the match is "continue" I assume that the node does exactly what it does with a normal flood, i.e. caches the received objectives and if it is a relay, it relays the flood to its neighbors. 2) If result of the match is "discontinue" I assume the node does not cache the flooded objectives. 2) If result of the match is "discontinue" and the node is also a GRASP relay, what does the node do? Discard or relay? It cannot know the result of the match in its neighbors. I really don't understand the meaning of the matching rules, especially "match-object = NEIGHBOR / SELF". I think this needs a lot more explanation and some more detailed examples. > 5.3 Realizing Subscription as An Event > > In fragmentary CDDL, a Subscription Objective Option follows the > pattern: > > subscription-objection-option = [SUBSCRIPTION, 2, 2, subobj] > objective-name = SUBSCRIPTION > > objective-flags = 2 > > loop-count = 2 > > subobj = text > > > This option MAY be included in GRASP M_Synchronization, when > included, it means this message is for a subscription to a specific > object. The M_SYNCH message is the reply from a data source to a data destination, so I think that's wrong. I think that SUBSCRIPTION should be used in M_REQ_SYN, when a node first wants to get the value of a given objective but also wants to subscribe to future push updates. So the reply to a M_REQ_SYN with a SUBSCRIPTION option would be M_SYNCH with an initial value for the objective, but the session could stay open with M_PUSH to follow at any time. (So that solves the question of the port: whatever port is used for sending the M_REQ_SYN listens for the M_PUSH messages.) A new M_REQ_SYN would also be used to carry UNSUBSCRIBE. Alternatively, the node could simply close the port and the next M_PUSH would fail. If we did that, UNSUBSCRIBE would not be needed. Finally do we actually need M_PUSH, rather than just sending M_SYNCH again whenever needed? > 5.5 Publishing Objective Option > > In fragmentary CDDL, a Publish Objective Option follows the pattern: > > publish-objection-option = [PUBLISH, 2, 2, pubobj] objective-name > = PUBLISH > objective-flags = 2 > loop-count = 2 > pubobj = text > > This option MAY be included in GRASP M_Synchronization, when > included, it means this message is for a publish of a specific object > data. I don't understand this. An M_SYNCH by definition delivers the current value of an objective. Why do we need to say that we're publishing it? Regards Brian Carpenter From nobody Mon Dec 16 11:11:31 2019 Return-Path: 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 67C491208E4 for ; Mon, 16 Dec 2019 11:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 IKMZiMLx2EWS for ; Mon, 16 Dec 2019 11:11:27 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8DB1208E9 for ; Mon, 16 Dec 2019 11:11:27 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id EBC29548016; Mon, 16 Dec 2019 20:11:21 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id DDB9E440058; Mon, 16 Dec 2019 20:11:21 +0100 (CET) Date: Mon, 16 Dec 2019 20:11:21 +0100 From: Toerless Eckert To: Michael Richardson Cc: Brian E Carpenter , anima@ietf.org Message-ID: <20191216191121.GA63300@faui48f.informatik.uni-erlangen.de> References: <83396eee-ac1c-ee53-5949-2a49590637ec@sandelman.ca> <22922.1574933909@dooku.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22922.1574933909@dooku.sandelman.ca> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] some comments about ACP connect X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 19:11:29 -0000 On Thu, Nov 28, 2019 at 10:38:29AM +0100, Michael Richardson wrote: > > I can see that for conventional management tools. I will just observe > > that GRASP discovery doesn't need to be seeded with any well known > > addresses (except the GRASP LL multicast address) so GRASP is completely > > indifferent to how NOC hosts get their unicast addresses. In fact we > > could easily create a full NOC discovery mechanism over GRASP. I built > > a MUD Manager discovery mechanism in the hackathon yesterday, and any > > NOC server could be discovered the same way. It's probably worth > > re-reading RFC8368 before discussing further. > > We will have quite a number of convential management tools in the NOC. > The need to be able to reach out from operator desktop to equipment with SSH > (or gosh... telnet?) will persist into the future, and it's why we built and > secured the ACP. +1 - my currently hibernating drafts for NOC integration are trying to close the most basic gaps for that. > Many existing services will need names, and while putting ULAs into DNS might > surprise some IPv4 operators, I think it's completely sane. Enterprises have put rfc1918 addresses into DNS forever. Alas, it only works with hacks because DNS does not have the concept of different scope/zones of notes/addresses with accordingly different access control. But those hacks are fairly standard. > A question will be how to connect the current crop of management tools to the > ACP. This can be done by literally connecting desktops via ACP Connect. Right. The ACP spec defines the two most sane models to do so, but there are a lot more options achievable through configuration alternatives. > Another way will involve putting bastion hosts (ssh-jump-hosts) into the NOC, > as well as hosting virtual desktops on hypervisors connected via ACP Connect. Right. CHeers Toerless From nobody Mon Dec 16 11:56:29 2019 Return-Path: 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 186A7120639; Mon, 16 Dec 2019 11:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 CasrK3srn6T5; Mon, 16 Dec 2019 11:56:24 -0800 (PST) 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 8481312008C; Mon, 16 Dec 2019 11:56:24 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8671638993; Mon, 16 Dec 2019 14:56:17 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 163121415; Mon, 16 Dec 2019 14:56:18 -0500 (EST) From: Michael Richardson To: Alissa Cooper , daedulus@btconnect.com cc: IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <2FA2728E-6484-4A69-992A-479D8053354E@cooperw.in> References: <157123777786.7830.10713306244839546046.idtracker@ietfa.amsl.com> <9637.1574756997@localhost> <2FA2728E-6484-4A69-992A-479D8053354E@cooperw.in> 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 Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 19:56:27 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable {Hi Tom, I don't quite understand, but I don't seem to get emails directly From=20you. Or perhaps it has to do with it being posted through the datatracker. This is not the first review I have missed in this way.} We had forgotten about the content of Appendix C, which is not normative. It stems from an era when we were not sure how successful RFC8520 will be. I have issued version -31 in which we remove Appendix C rather than fix it. This extension could be added correctly at a later date, and at this point, we don't see the MUD FILE->MASA URL flow as particularly important. Both URLs can be in the IDevID if needed, at the cost of bytes in the IDevID certificate. I think that there are operational problems with embedding the MUD URL in t= he IDevID relating to firmware upgrades, nor is that related to this appendix. It is not a BRSKI issue, but it does mean that the likelyhood of a MUD URL being the only extension that can be afforded an IDevID is significantly le= ss likely. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl334WEACgkQgItw+93Q 3WXLswf/URHcBU0J3kCBS5xCWSPQJ4jUdB9JOzvx9lh5ra+t53c5wynFlkQmxGBx yZTuaTQUvUow+pNmNN0xt0Y0j75hAc0xh0whXuGXhLNE6BYNTvqrid0KylHheLJu zWCI2GvW4jwNHkqBBhIg/i/nBVN4I/0jF7CWQXKVOnMjV/CHMXkGDUQU2m8NApiY oQtWIypyAZCmshUNJxvgu1jY2+iSud1PHMwuvrimv0zGfeck0Yq6/ZJGMVxI6yir +r12rxpA9pqkJ5HTbvnkX2lE4bTsH2arhVMN/QZMyB7OQBiKQAhXg2yG81lVXzGT /zKuX+3Gdnb+WWSFA/Avuuf/QeNNNw== =TDPs -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 16 11:56:54 2019 Return-Path: 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 11CE612008C; Mon, 16 Dec 2019 11:56:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.113.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <157652620800.24521.6351764552044832236@ietfa.amsl.com> Date: Mon, 16 Dec 2019 11:56:48 -0800 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-31.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 19:56:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Toerless Eckert Michael H. Behringer Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-31.txt Pages : 116 Date : 2019-12-16 Abstract: This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/ disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-31 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-31 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-31 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 16 12:08:46 2019 Return-Path: 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 AB24912093B; Mon, 16 Dec 2019 12:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=Wvbp7qq1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rZ+/ORzn 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 xM9PEfqzubES; Mon, 16 Dec 2019 12:08:38 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75623120932; Mon, 16 Dec 2019 12:08:38 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id CB6B122268; Mon, 16 Dec 2019 15:08:37 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 16 Dec 2019 15:08:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=b lLDYwr2keDlEuLO8WgTqKpkEcVQBzz3pTORuowi+7I=; b=Wvbp7qq1MV/5GRuHW Lk6hcLZddbPSDBey2NECpeeUG5CcgEu2YZQ6nmQQdNcJ0r4Rd4dUW2uXXq8YW/Yf 5yLfJ7O9tyG0OzqXEqPZTQ1otVAiP6GlykzmEOCU5QcX3q6uTJYUm+9SMB6Uhbis K5Lj/s/T1yGXw2aY601lABhue8I5JhiBLi5TFcBk0k8VbYR3/hnm0WYyDTSADsaO 0kSnVLNOAiD5RBIF3rZW8JjV3s23BkcNbV9zfWUIBLsm976J4hF2KoZTvoR7uJWh TICwWSnSNzPsAZjI76Y8JLzpt2U0uILu53iYyxv4xZo7owRbCeWTjJjh9KQC8SM+ hOVAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=blLDYwr2keDlEuLO8WgTqKpkEcVQBzz3pTORuowi+ 7I=; b=rZ+/ORzn5Lvf4PpEVqlGlNisRpqqLmcgd4joBwfA/29Gf1G8tVupfDtkP ucEjGsmZeQ8kXcCkaTE+6oKW4pJxwkHmJ9GEtr503LsnR/8Ox0NMZ5d6vfN77sT7 E4OYbpxwdNnSRJ5yFhmy4scyhaDElTAUj+yMBIl9yrvVejaCSqYHMwN6OsaZ7JjU bpqvFzz4xqJZmCIdryBA4Aal6z+fVVl6kc5yFZW2pU1Bp56r7PIjJLutLyGsY0BO I2ajdQ1I8zsqSgwd1RtaMoOLll9JlJrRZ71KFn+lJRY+9PQVYX76YOArzO3V229W NojshxqrkezIpG2NnmOmS9/tz0hmQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddthedgudefgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesth hqmhdthhdtvdenucfhrhhomheptehlihhsshgrucevohhophgvrhcuoegrlhhishhsrges tghoohhpvghrfidrihhnqeenucfkphepudejfedrfeekrdduudejrdeltdenucfrrghrrg hmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.90]) by mail.messagingengine.com (Postfix) with ESMTPA id BEFE830600D7; Mon, 16 Dec 2019 15:08:36 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <20062.1576526178@localhost> Date: Mon, 16 Dec 2019 15:08:35 -0500 Cc: tom petch , IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <157123777786.7830.10713306244839546046.idtracker@ietfa.amsl.com> <9637.1574756997@localhost> <2FA2728E-6484-4A69-992A-479D8053354E@cooperw.in> <20062.1576526178@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 20:08:44 -0000 Thanks Michael. Should Section 8.1 now be removed as well? Alissa > On Dec 16, 2019, at 2:56 PM, Michael Richardson = wrote: >=20 >=20 > {Hi Tom, I don't quite understand, but I don't seem to get emails = directly > =46rom you. Or perhaps it has to do with it being posted through the > datatracker. This is not the first review I have missed in this way.} >=20 > We had forgotten about the content of Appendix C, which is not = normative. > It stems from an era when we were not sure how successful RFC8520 will = be. >=20 > I have issued version -31 in which we remove Appendix C rather than = fix it. >=20 > This extension could be added correctly at a later date, and at this = point, > we don't see the MUD FILE->MASA URL flow as particularly important. >=20 > Both URLs can be in the IDevID if needed, at the cost of bytes in the = IDevID > certificate. >=20 > I think that there are operational problems with embedding the MUD URL = in the > IDevID relating to firmware upgrades, nor is that related to this = appendix. > It is not a BRSKI issue, but it does mean that the likelyhood of a MUD = URL > being the only extension that can be afforded an IDevID is = significantly less > likely. >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 From nobody Mon Dec 16 14:55:14 2019 Return-Path: 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 E375012093E; Mon, 16 Dec 2019 14:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ugkxgtGITVSL; Mon, 16 Dec 2019 14:55:10 -0800 (PST) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 30AEE12093C; Mon, 16 Dec 2019 14:55:10 -0800 (PST) Received: by mail-pf1-x429.google.com with SMTP id d199so6411900pfd.11; Mon, 16 Dec 2019 14:55:10 -0800 (PST) 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=0ZpWp21jHSNKWvLvBhe8RmWRFimp+uFsUprBcixrD9A=; b=vhKTRHq3GnIxkaK+K0x4a38lTcR9SzI1o7V0rPSQU4MRUClTGctKTlT8KDWI4xjpFm jClwkO3eeMvWoWyAUatuwIeROFRrB2D5FvcmXbeWbqYfklpV2hzxJyyb/Bp5USviLo2q TkjP5eOpnyf8kdGGu2g4ieLoSk7OYGMCMegWXmnevuY+Q/mOqAxwD//Cm8x/k3ELapEA pr31GCYMM0eWJHhMKiLQJ+Pl9H3w7KILQ+4NGhNyzMrXd77u6RjQmx8zXbpWYZtyoRz9 i3e0ojl/HZ3mEOBWEGHzd2F72wgiBr7sgWXWgXbEOi3rK9G/J18QuUJyFTae12kGzo8w JuRQ== 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=0ZpWp21jHSNKWvLvBhe8RmWRFimp+uFsUprBcixrD9A=; b=CZpCi65mlzkbl/BzKa0K6XV6uWI4UtqRrFF1ZZfwe3Pe0c2eEPZuNRs/0i/XFpBuEH JnV7WMnHR/e5hq1kEAnOpcNdxs4P3qDClIVyAWCmcaDqET8nlHsp9ttd6+D/f+eYoPqK a1D16oACJ/9af9KWfYcKnmE0Hr07EbY8p+S36nFJ8nJvqBhkp/0KyPN3BPuKjrIXuG3U Bg1f9Og8EGA/vDYZm2+hY0AL4mpEV6dFRLbCkepBk8tQI3tFNQRsk+L7KXgXVUZyum7x vI/MyClmunots6RZWVWdPOKKiDMyk3vR9ItEeFRWHB7T2tyajfXFhrGkkNLtPVYcepzd B3fQ== X-Gm-Message-State: APjAAAVlA02VNttRU24bxQJTsLHPF6u+TbEMMtK6Ud2tPpIral4uF3RC Wp9E1cF0ebzivF5Js3C8mQJyhYf9 X-Google-Smtp-Source: APXvYqxaMl4lQ0c3XO2/Am1wVX93M10Jh4XDKjxn/jzNHYkT47KB0rQ7hsxpG3YjVnAuMGKwYXLofA== X-Received: by 2002:a63:4e0e:: with SMTP id c14mr21242065pgb.237.1576536909119; Mon, 16 Dec 2019 14:55:09 -0800 (PST) Received: from [172.24.4.180] ([202.36.244.177]) by smtp.gmail.com with ESMTPSA id x65sm20311906pfb.171.2019.12.16.14.55.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Dec 2019 14:55:08 -0800 (PST) To: Alissa Cooper , Michael Richardson Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima-chairs@ietf.org, tom petch , IESG , tte+ietf@cs.fau.de, anima@ietf.org References: <157123777786.7830.10713306244839546046.idtracker@ietfa.amsl.com> <9637.1574756997@localhost> <2FA2728E-6484-4A69-992A-479D8053354E@cooperw.in> <20062.1576526178@localhost> From: Brian E Carpenter Message-ID: <32602f31-70f5-e638-100b-e0f10a4c1125@gmail.com> Date: Tue, 17 Dec 2019 11:55:01 +1300 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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2019 22:55:13 -0000 On 17-Dec-19 09:08, Alissa Cooper wrote: > Thanks Michael. Should Section 8.1 now be removed as well? I think that's a good catch. FYI and largely irrelevant, I did lash together some code at the IETF106 hackathon using GRASP to communicate a MUD URL to the network management system. So if we need to integrate MUD handling into the ANIMA infrastructure, there's already a proof of concept, without complicating BRSKI. Brian > > Alissa > >> On Dec 16, 2019, at 2:56 PM, Michael Richardson wrote: >> >> >> {Hi Tom, I don't quite understand, but I don't seem to get emails directly >> From you. Or perhaps it has to do with it being posted through the >> datatracker. This is not the first review I have missed in this way.} >> >> We had forgotten about the content of Appendix C, which is not normative. >> It stems from an era when we were not sure how successful RFC8520 will be. >> >> I have issued version -31 in which we remove Appendix C rather than fix it. >> >> This extension could be added correctly at a later date, and at this point, >> we don't see the MUD FILE->MASA URL flow as particularly important. >> >> Both URLs can be in the IDevID if needed, at the cost of bytes in the IDevID >> certificate. >> >> I think that there are operational problems with embedding the MUD URL in the >> IDevID relating to firmware upgrades, nor is that related to this appendix. >> It is not a BRSKI issue, but it does mean that the likelyhood of a MUD URL >> being the only extension that can be afforded an IDevID is significantly less >> likely. >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Dec 17 09:19:32 2019 Return-Path: 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 BB783120BF7; Tue, 17 Dec 2019 09:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 MTOqHc4AN8TJ; Tue, 17 Dec 2019 09:19:19 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80111.outbound.protection.outlook.com [40.107.8.111]) (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 04A84120BCC; Tue, 17 Dec 2019 09:19:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EJLAW+T3N1R9BXXQy5vw13HWd7N8sqNILiQu71KtXgSQPLgYJS1mKn6N2C5wOfRhdIkZvSssMary8hRZ4gL+EBnksYxfJPwUQ8mDznSos2+LWZqiokPKbBLS5VyEfoL2Dn9BrpexSdn24xl7MOZ6eyChG49KnwV+bno7xbhbpm9/EwSXPzZHLM3OtO2Wrd894lfdyr8juqtAxTSUV9QdQNNhjkUIk7eYcaGi3XvUtWjUVuxtoxXOD1AzzfFKgj/Hl3YTREfOP6qZzRThqVYOvtpo1G0U9wdz4c7iqKysqeve8/zG/UFYvpKhki2X6tqA3aY9AFBrY7BGXUorUfp/QQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EYg/fczKU9OIlHZ6CSX1nagNfPmr/iJ8g0GdKJuLuqc=; b=FuwdB9XNFBmY1QpnaSiUsXVVfNmGSYGf93w32lQo03jE53G7MeGhv8KNLwQQFKEOkFw3tigfnjrEwaFP+7BXgFxpmQPMlIcxRHSKzhpc6Pt8PICM1UAtT8S3M+amISuZjnd2jbWC0XTDuXrqGDPyIi3uJWODAzGnk4XZzCuuGJUoL+AjRJBZLHJWBpvwwXrwdZvIGMhfARLpEQoArr/9ktdmX7Ae/IA4/KsMef3Lhhme3PtCk77QjusvaPd5RfhzQuQKwl6CUqj02AysKLNoGqGJHR/3/M2TeCIugMFU0hpjdT9D+GsRfcM/OTbzisKBryIn6benmSrjLaRZkhiTBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EYg/fczKU9OIlHZ6CSX1nagNfPmr/iJ8g0GdKJuLuqc=; b=MojIwescn3PPErd04Lt5p/894hhVCFp82MhHRG0kPw0ZtSQsB7scYGq0Vb9Pqz0J1onOk3rn5geXBZxkBWqjdnMTRUpVEO/FAQT34TOzjuWKgokv8SP8rH6oedyZnkPN+VX38oHU0Tbx18HtXVKw0lKiBdp4k02HcucVXWYbyzA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; Received: from AM0PR07MB5716.eurprd07.prod.outlook.com (20.178.115.216) by AM0PR07MB4979.eurprd07.prod.outlook.com (20.178.19.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.12; Tue, 17 Dec 2019 17:19:14 +0000 Received: from AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::4156:4119:dd89:95f7]) by AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::4156:4119:dd89:95f7%5]) with mapi id 15.20.2559.012; Tue, 17 Dec 2019 17:19:14 +0000 To: Michael Richardson , Alissa Cooper References: <157123777786.7830.10713306244839546046.idtracker@ietfa.amsl.com> <9637.1574756997@localhost> <2FA2728E-6484-4A69-992A-479D8053354E@cooperw.in> <20062.1576526178@localhost> Cc: IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org From: tom petch Message-ID: <5DF90E0C.9020603@btconnect.com> Date: Tue, 17 Dec 2019 17:19:08 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <20062.1576526178@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0239.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:b::35) To AM0PR07MB5716.eurprd07.prod.outlook.com (2603:10a6:208:11e::24) MIME-Version: 1.0 Received: from [192.168.1.65] (86.139.211.103) by LO2P265CA0239.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:b::35) with Microsoft SMTP Server (version=TLS1_2, cipher=) via Frontend Transport; Tue, 17 Dec 2019 17:19:13 +0000 X-Originating-IP: [86.139.211.103] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e5ca35c1-6121-4574-1506-08d783153d54 X-MS-TrafficTypeDiagnostic: AM0PR07MB4979: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 02543CD7CD X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(136003)(366004)(376002)(346002)(189003)(199004)(51444003)(5660300002)(52116002)(8936002)(2616005)(66946007)(956004)(81166006)(66476007)(2906002)(81156014)(478600001)(6666004)(36756003)(110136005)(6486002)(86362001)(4326008)(16576012)(8676002)(53546011)(26005)(66556008)(87266011)(33656002)(316002)(16526019)(186003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4979; H:AM0PR07MB5716.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: CI2B29Ex9N14lzGmDM5nRGBLkZBe2UYXv2jlDjBU5ltrvEqjLSf+W7SIu01xfUa3Vi8pWu1HQ1uAVn/CdVIkyi0OTxxsahqL75raOp7BOt5Bff5hCBSKfvf6pqeTMHQPFIjlN1AV+SSbNoY+xjjR4U12G8OjwXnp6aOA+p4IITrjY2NeoBJcKkKD8RzrIVLvlz7HaSa2286n0zSBswWedWHFycAtHRvVC1Nif/gfBOIhpG6TBDTr1AnceFTWWGNYG2mE6kzFTB/6BSQ+yypaUBcjPC+iuOLp85mrEFBQt2pRyAOntvs0wmt4mfCQ2SeYvZrd0cgg9S1Jo2YSOonHKa7tyFdwbu9GnjI0p0ABkX5UEwxhGlaeeapcN1NPWTOaBa4X2k9nQ7rP5iinRxXWGKpAIskbn/p6oRoX66kj3cFXS/sPwcEtS+i8dxMVVYta2ms9cnZojovn17Sbbuqu16BKCgA3w7nshc9CQN1h16O8ST3VEyQqjpCZyQ+ziCLW X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: e5ca35c1-6121-4574-1506-08d783153d54 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2019 17:19:14.4735 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: OLHOWmf0f6+GofNwQXD87tcdq/o2dIWfw7RjuadawVF8xpdp8AL0pGx52luoVBSGE8GbEYBpTRjh5hEjdsoD1A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4979 Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 17:19:24 -0000 Michael, my initial posts were a response to the Genart review and so did not include your name, just Anima, Anima chairs, ibagdona, IETF; you are in this one as mcr+ietf@sandelman.ca (but IETF mailers may have a habit of thinking you will get an e-mail via one way and suppress other ways with different e-mail addresses). Yes you have removed the second YANG module which addresses my comments about the second YANG module but my other comments mostly remain. Those about the YANG prefix are fixed. RFC8040 needs to be in the I-D References IANA Considerations mentions the removed module but lacks the two required actions for the remaining module XXXX is used as a place holder for a document name which is not that of this I-D and does not exist AFAICT The YANG module must be plain text - [RFC8446] looks like HTML/XML Security Considerations lacks the required boiler plate for a YANG module Appendix A still has a typo Tom Petch On 16/12/2019 19:56, Michael Richardson wrote: > > {Hi Tom, I don't quite understand, but I don't seem to get emails directly > From you. Or perhaps it has to do with it being posted through the > datatracker. This is not the first review I have missed in this way.} > > We had forgotten about the content of Appendix C, which is not normative. > It stems from an era when we were not sure how successful RFC8520 will be. > > I have issued version -31 in which we remove Appendix C rather than fix it. > > This extension could be added correctly at a later date, and at this point, > we don't see the MUD FILE->MASA URL flow as particularly important. > > Both URLs can be in the IDevID if needed, at the cost of bytes in the IDevID > certificate. > > I think that there are operational problems with embedding the MUD URL in the > IDevID relating to firmware upgrades, nor is that related to this appendix. > It is not a BRSKI issue, but it does mean that the likelyhood of a MUD URL > being the only extension that can be afforded an IDevID is significantly less > likely. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Tue Dec 17 12:29:20 2019 Return-Path: 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 BC483120125; Tue, 17 Dec 2019 12:29:11 -0800 (PST) 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 iEOxcc5YDQf8; Tue, 17 Dec 2019 12:29:08 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E832120836; Tue, 17 Dec 2019 12:29:06 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 651763897E; Tue, 17 Dec 2019 15:29:02 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 59D4451E; Tue, 17 Dec 2019 15:29:05 -0500 (EST) From: Michael Richardson To: Alissa Cooper cc: tom petch , IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: References: <157123777786.7830.10713306244839546046.idtracker@ietfa.amsl.com> <9637.1574756997@localhost> <2FA2728E-6484-4A69-992A-479D8053354E@cooperw.in> <20062.1576526178@localhost> 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 Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2019 20:29:12 -0000 --=-=-= Content-Type: text/plain Alissa Cooper wrote: > Thanks Michael. Should Section 8.1 now be removed as well? I thought that I got it, but I see that I didn't git commit that part. I have removed it, and I'll post that in a day, once I hear from Roman and Ben about whether they feel I am done with their comment stream. -- ] 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 [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl35OpEACgkQgItw+93Q 3WWnxwf/ZCU7xg5dERvDO8obCrwaAa9V0kVwbNgYVtflL/ODtoYeD0XYCPu25om3 IjSq1AeR4/0+VRai+bsL3WiqrOrFmqgwUo2o6zokzS4rgAXNBCq3ye+F6TsszvG2 DzIHdG46GEL4K5/ntanlvLPCRHrhXYzKcRnRlP/498P+bo7Ofc+R5UO+tQUOZcv1 pPJ42ZjOhRqP2h27g7xgaB3oIr3pPZ4NYoQVkMuIX6GvZioxmTsezEgh7OkpwjtB DMAGpQrUU/WrfIqK+X9gbzb9O75kogHymJCFjERZ7UQL6TrY88FKp5dJ/YDzVXeX nS789oKKIFfMHQv4bjXTwA2E9sYegA== =fRAQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 17 18:35:10 2019 Return-Path: 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 46CF1120091; Tue, 17 Dec 2019 18:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 gmQ9_YAvICcw; Tue, 17 Dec 2019 18:35:07 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 E8CC8120043; Tue, 17 Dec 2019 18:35:06 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id CB406E4F3266235FD313; Wed, 18 Dec 2019 02:35:02 +0000 (GMT) Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 18 Dec 2019 02:35:02 +0000 Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 18 Dec 2019 02:35:02 +0000 Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Wed, 18 Dec 2019 02:35:01 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0439.000; Wed, 18 Dec 2019 10:34:53 +0800 From: Sheng Jiang To: Xun Xiao , "anima-chairs@ietf.org" , "anima@ietf.org" CC: "Liubing (Leo)" , Artur Hecker , Zoran Despotovic , Toerless Eckert Thread-Topic: New Version Notification for draft-liu-anima-grasp-distribution-13.txt Thread-Index: AQHVsQhEQFaHbtR5UU6EEvrlOvvwaae3PI8AgAcmCHA= Date: Wed, 18 Dec 2019 02:34:53 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9299CE45D0@NKGEML515-MBX.china.huawei.com> References: <157616770426.20852.6061499986285417726.idtracker@ietfa.amsl.com> <3bf6b1827b954c29a5bc9647fbe30f71@huawei.com> In-Reply-To: <3bf6b1827b954c29a5bc9647fbe30f71@huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] New Version Notification for draft-liu-anima-grasp-distribution-13.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 02:35:09 -0000 SGksIFhpYW8gWHUsDQoNClRoYW5rcyBmb3IgdGhlIG5ld2x5IHVwZGF0ZS4gV2UgaGF2ZSBhIHJv dWdoIGNvbnNlbnN1cyB0byBhZG9wdCB0aGlzIGRvY3VtZW50IG9uIHNpdGUgaW4gSUVURjEwNi4g VGhpcyBuZWVkcyB0byBjb25maXJtIGluIHRoZSBtYWlsIGxpc3QuIEhvd2V2ZXIsIGdpdmluZyB0 aGF0IG1vc3QgcGVvcGxlIG1heSBhbHJlYWR5IGluIHRoZSBDaHJpc3RtYXMgbW9kZWwsIHRoZSBj aGFpcnMgcHJlZmVyIHRvIGhhdmUgdGhlIHR3by13ZWVrIGFkb3B0aW9uIGNhbGwgYWZ0ZXIgcGVv cGxlIGdldCBiYWNrIGZyb20gaG9saWRheXMuDQoNClRoYW5rcyBhbmQgcmVnYXJkcywNCg0KU2hl bmcNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBYdW4gWGlhbw0KPiBT ZW50OiBGcmlkYXksIERlY2VtYmVyIDEzLCAyMDE5IDQ6NTAgUE0NCj4gVG86IGFuaW1hLWNoYWly c0BpZXRmLm9yZzsgYW5pbWFAaWV0Zi5vcmcNCj4gQ2M6IExpdWJpbmcgKExlbykgPGxlby5saXVi aW5nQGh1YXdlaS5jb20+OyBBcnR1ciBIZWNrZXINCj4gPEFydHVyLkhlY2tlckBodWF3ZWkuY29t PjsgWm9yYW4gRGVzcG90b3ZpYw0KPiA8Wm9yYW4uRGVzcG90b3ZpY0BodWF3ZWkuY29tPjsgU2hl bmcgSmlhbmcgPGppYW5nc2hlbmdAaHVhd2VpLmNvbT4NCj4gU3ViamVjdDogUkU6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1dGlv bi0xMy50eHQNCj4gDQo+IERlYXIgQ2hhaXJzLCBEZWFyIEFOSU1BIFdHIG1lbWJlcnMsDQo+IA0K PiBEdXJpbmcgSUVURjEwNiwgdGhlIGF1dGhvcnMgaGVyZSBoYWQgbWFueSB0ZWNobmljYWwgZGlz Y3Vzc2lvbnMgb24gdGhlDQo+IGluZm9ybWF0aW9uIGRpc3RyaWJ1dGlvbiB0b3BpYyB3aXRoIHNl dmVyYWwgZ3JvdXAgbWVtYmVycy4gTWFueSB0aGFua3MgZm9yDQo+IHRoZSBjb25zdHJ1Y3RpdmUg Y29tbWVudHMvYWR2aWNlcy4NCj4gDQo+IEhlcmVieSwgYWNjb3JkaW5nIHRvIHRoZSBmZWVkYmFj a3MsIGEgcmV2aXNlZCB2ZXJzaW9uIGlzIHVwZGF0ZWQsIHRyeWluZyB0bw0KPiBiZXR0ZXIgbW90 aXZhdGUgdGhlIHByb2JsZW0gYW5kIGludHJvZHVjZSB0aGUgcHJvcG9zZWQgc29sdXRpb24uIFdl IHdpbGwNCj4gYXBwcmVjaWF0ZSBhbnkgZnVydGhlciBjb21tZW50cy4NCj4gDQo+IE1lYW53aGls ZSwgYXMgb25lIG9mIHRoZSBjaGFydGVyZWQgbWlsZXN0b25lIHRvcGljIHdvcmssIHdlIHdlcmUg d29uZGVyaW5nDQo+IGlmIHRoZSBkcmFmdCBjYW4gYmUgYWRvcHRlZCBhcyBhIFdHIGRyYWZ0IHdv cmtpbmcgaW4gcHJvZ3Jlc3Mgb24gdGhlIHN0YW5kYXJkDQo+IHRyYWNrLiBUaGFua3MgZm9yIHlv dXIgY29uc2lkZXJhdGlvbnMuDQo+IA0KPiBCZXN0IFJlZ2FyZHMsDQo+IA0KPiBYdW4gWGlhbyAo 6IKW6L+FKQ0KPiBBZHZhbmNlZCBXaXJlbGVzcyBUZWNobm9sb2d5IExhYg0KPiBNdW5pY2ggUmVz ZWFyY2ggQ2VudGVyDQo+IEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLEx0ZC4NCj4gDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBb bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogVGh1cnNkYXksIDEyIERl Y2VtYmVyIDIwMTkgMTc6MjINCj4gVG86IExpdWJpbmcgKExlbykgPGxlby5saXViaW5nQGh1YXdl aS5jb20+OyBBcnR1ciBIZWNrZXINCj4gPEFydHVyLkhlY2tlckBodWF3ZWkuY29tPjsgWHVuIFhp YW8gPFh1bi5YaWFvQGh1YXdlaS5jb20+OyBab3Jhbg0KPiBEZXNwb3RvdmljIDxab3Jhbi5EZXNw b3RvdmljQGh1YXdlaS5jb20+OyBTaGVuZyBKaWFuZw0KPiA8amlhbmdzaGVuZ0BodWF3ZWkuY29t Pg0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1hbmlt YS1ncmFzcC1kaXN0cmlidXRpb24tMTMudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWxpdS1hbmltYS1ncmFzcC1kaXN0cmlidXRpb24tMTMudHh0DQo+IGhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWHVuIFhpYW8gYW5kIHBvc3RlZCB0byB0aGUgSUVU RiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LWxpdS1hbmltYS1ncmFzcC1kaXN0cmli dXRpb24NCj4gUmV2aXNpb246CTEzDQo+IFRpdGxlOgkJSW5mb3JtYXRpb24gRGlzdHJpYnV0aW9u IGluIEF1dG9ub21pYyBOZXR3b3JraW5nDQo+IERvY3VtZW50IGRhdGU6CTIwMTktMTItMTINCj4g R3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6CQkyMQ0KPiBVUkw6DQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saXUtYW5pbWEtZ3Jhc3At ZGlzdHJpYnV0aW9uLTEzLnR4dA0KPiBTdGF0dXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWxpdS1hbmltYS1ncmFzcC1kaXN0cmlidXRpb24vDQo+IEh0bWxpemVk Og0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWRp c3RyaWJ1dGlvbi0xMw0KPiBIdG1saXplZDoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1saXUtYW5pbWEtZ3Jhc3AtZGlzdHJpYnV0aW9uDQo+IERpZmY6DQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1saXUtYW5pbWEtZ3Jhc3At ZGlzdHJpYnV0aW9uLTEzDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBwcm9w b3NlcyBhIHNvbHV0aW9uIGZvciBpbmZvcm1hdGlvbiBkaXN0cmlidXRpb24gaW4NCj4gICAgYXV0 b25vbWljIG5ldHdvcmtzLiBJbmZvcm1hdGlvbiBkaXN0cmlidXRpb24gaXMgY2F0ZWdvcml6ZWQg aW50byB0d28NCj4gICAgZGlmZmVyZW50IG1vZGVzOiAxKSBpbnN0YW50YW5lb3VzIGRpc3RyaWJ1 dGlvbjsgMikgcHVibGljYXRpb24gZm9yDQo+ICAgIHJldHJpZXZhbC4gSW4gdGhlIGZvcm1lciBj YXNlLCB0aGUgaW5mb3JtYXRpb24gaXMgc2VudCwgcHJvcGFnYXRlcw0KPiAgICBhbmQgaXMgZGlz cG9zZWQgb2YgYWZ0ZXIgcmVjZXB0aW9uLiBJbiB0aGUgbGF0dGVyIGNhc2UsIGluZm9ybWF0aW9u DQo+ICAgIG5lZWRzIHRvIGJlIHN0b3JlZCBpbiB0aGUgbmV0d29yay4NCj4gDQo+ICAgIFRoZSBj YXBhYmlsaXRpZXMgdG8gZGlzdHJpYnV0ZSBpbmZvcm1hdGlvbiBhcmUgYmFzaWMgYW5kIGZ1bmRh bWVudGFsDQo+ICAgIG5lZWRzIGZvciBhbiBhdXRvbm9tb3VzIG5ldHdvcmsgKGNmLiBBTkkgW0kt RC5pZXRmLWFuaW1hLXJlZmVyZW5jZS0NCj4gICAgbW9kZWxdKS4gVGhpcyBkb2N1bWVudCBkZXNj cmliZXMgdHlwaWNhbCB1c2UgY2FzZXMgb2YgaW5mb3JtYXRpb24NCj4gICAgZGlzdHJpYnV0aW9u IGluIEFOSSBhbmQgcmVxdWlyZW1lbnRzIHRvIEFOSSwgc3VjaCB0aGF0IHJpY2gNCj4gICAgaW5m b3JtYXRpb24gZGlzdHJpYnV0aW9uIGNhbiBiZSBuYXRpdmVseSBzdXBwb3J0ZWQuIFRoZSBkb2N1 bWVudA0KPiAgICBwcm9wb3NlcyBleHRlbnNpb25zIHRvIHRoZSBhdXRvbm9taWMgbm9kZXMgYW5k IHN1Z2dlc3RzIGFuDQo+ICAgIGltcGxlbWVudGF0aW9uIGJhc2VkIG9uIEdSQVNQIGV4dGVuc2lv bnMgYXMgYSBwcm90b2NvbCBvbiB0aGUgd2lyZS4NCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoN Cg== From nobody Wed Dec 18 02:54:56 2019 Return-Path: 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 34563120103; Wed, 18 Dec 2019 02:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 tPATlcy9tkKS; Wed, 18 Dec 2019 02:54:52 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 62788120019; Wed, 18 Dec 2019 02:54:52 -0800 (PST) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id C1B9FF15362DB234525E; Wed, 18 Dec 2019 10:54:48 +0000 (GMT) Received: from lhreml715-chm.china.huawei.com (10.201.108.66) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 18 Dec 2019 10:54:48 +0000 Received: from lhreml715-chm.china.huawei.com (10.201.108.66) by lhreml715-chm.china.huawei.com (10.201.108.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 18 Dec 2019 10:54:48 +0000 Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml715-chm.china.huawei.com (10.201.108.66) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Wed, 18 Dec 2019 10:54:48 +0000 Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.131]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0439.000; Wed, 18 Dec 2019 18:54:41 +0800 From: "Liubing (Leo)" To: Brian E Carpenter , Anima WG CC: "draft-liu-anima-grasp-distribution@ietf.org" Thread-Topic: [Anima] I-D Action: draft-liu-anima-grasp-distribution-13.txt Thread-Index: AQHVsQhOPF3DhgplkUKWiVFJA32CkKe7qDKAgAQMysA= Date: Wed, 18 Dec 2019 10:54:41 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45DE692DCC@DGGEML532-MBX.china.huawei.com> References: <157616770411.20852.10953979041894273077@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-13.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 10:54:55 -0000 Hi Brian, Thanks for the detailed review. Please see my replies inline. > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E Carpente= r > Sent: Monday, December 16, 2019 12:21 PM > To: Anima WG > Subject: Re: [Anima] I-D Action: draft-liu-anima-grasp-distribution-13.tx= t >=20 > Hi, >=20 > I think this is a useful extension of the basic autonomic infrastructure.= Here are > some comments and questions on the GRASP part of the draft. I'd be intere= sted > in the authors' comments. >=20 > > 5.1 Realizing Instant P2P Transmission > > > > This could be a new message in GRASP. In fragmentary CDDL, an Un- > > solicited Synchronization message follows the pattern: > > > > unsolicited_synch-message =3D [M_UNSOLIDSYNCH, session-id, > > objective] >=20 > I suggest simply calling this M_PUSH (but see later comments). [Bing] Personally I'm ok with it. "PUSH" sounds more intuitive. > > A node MAY actively send a unicast Un-solicited Synchronization > > message with the Synchronization data, to another node. This MAY be > > sent to port GRASP_LISTEN_PORT at the destination address, >=20 > That port is normally tied up with multicast reception. But since we have= a > SUBSCRIBE mechanism below, the question of the port can be resolved at > SUBSCRIBE time. There must be a listener process for this port, of course= . [Bing] The M_PUSH is not bind with SUBSCRIBE. It could be sent standalone. = Is it possible we could specify that GRASP_LISTEN_PORT MUST monitor M_PUSH = as well? =20 > > which > > might be obtained by GRASP Discovery or other possible ways. The > > synchronization data are in the form of GRASP Option(s) for specific > > synchronization objective(s). >=20 > One objective per message is much simpler to implement. If not, this beco= mes > more like a "unicast Flood". If you want that, we could define the syntax > precisely like M_FLOOD. [Bing] I tend to agree from practical perspective. However, I'm not very su= re whether it's necessary to close the little flexibility of multiple objec= tive in one message? > > 5.2 Realizing Instant Selective Flooding > > > > Since normal flooding is already supported by GRASP, this section > > only defines the selective flooding extension. > .... > > The action means, when the match rule applies, the current device > > just continues flood or discontinues. >=20 > Please remember that a normal M_FLOOD has two aspects for a node that > receives it. First, the node stores the objectives delivered in its own f= lood cache. > Second, *if* it is a relay node (with interfaces to more than one link wi= thin the > AN, such as a router) it relays a copy of the M_FLOOD to its AN neighbors= , > subject to anti-looping rules. >=20 > 1) If the result of the match is "continue" I assume that the node does e= xactly > what it does with a normal flood, i.e. caches the received objectives and= if it is a > relay, it relays the flood to its neighbors. [Bing] Exactly. > 2) If result of the match is "discontinue" I assume the node does not cac= he the > flooded objectives. [Bing] The text doesn't explicitly specify the cache behavior. But I share = the same opinion that the node does not cache when the match is "discontinu= e". > 2) If result of the match is "discontinue" and the node is also a GRASP r= elay, > what does the node do? Discard or relay? It cannot know the result of the= match > in its neighbors. [Bing] If there is matching condition in the packet, then the matching rule= s behavior automatically be superior. So, even it is a GRASP relay, it woul= d discard the packet when match condition is "discontinue". The match rules don't consider whether how the neighbors would react on the= same rule. This might be "rude" for some scenarios, but could be efficient= in some specific scenarios, e.g., highly-herachycal networks. > I really don't understand the meaning of the matching rules, especially "= match- > object =3D NEIGHBOR / SELF". I think this needs a lot more explanation an= d some > more detailed examples. [Bing] Normally, the match object is the node itself. But we wanted to keep= a bit programmability to allow the node to judge whether to continue or di= scontinue the flooding based on its neighbors' information. It assumes that the node has already learned the neighbors' info previously= . Let me try to make some detailed examples in the next version. =20 > > 5.3 Realizing Subscription as An Event > > > > In fragmentary CDDL, a Subscription Objective Option follows the > > pattern: > > > > subscription-objection-option =3D [SUBSCRIPTION, 2, 2, subobj] > > objective-name =3D SUBSCRIPTION > > > > objective-flags =3D 2 > > > > loop-count =3D 2 > > > > subobj =3D text > > > > > > This option MAY be included in GRASP M_Synchronization, when > > included, it means this message is for a subscription to a specific > > object. >=20 > The M_SYNCH message is the reply from a data source to a data destination= , so > I think that's wrong. I think that SUBSCRIPTION should be used in M_REQ_= SYN, > when a node first wants to get the value of a given objective but also wa= nts to > subscribe to future push updates. So the reply to a M_REQ_SYN with a > SUBSCRIPTION option would be M_SYNCH with an initial value for the object= ive, [Bing] You are right, we made the mistake. Thanks for pointing it out. > but the session could stay open with M_PUSH to follow at any time. (So th= at > solves the question of the port: whatever port is used for sending the > M_REQ_SYN listens for the M_PUSH messages.) [Bing] As replied above, I believe this is a valid use case. But we wanted = to decouple M_PUSH and SUBSCRIBE.=20 > A new M_REQ_SYN would also be used to carry UNSUBSCRIBE. Alternatively, > the node could simply close the port and the next M_PUSH would fail. If w= e did > that, UNSUBSCRIBE would not be needed. [Bing] If M_PUSH is standalone, then UNSUB is needed. =20 > Finally do we actually need M_PUSH, rather than just sending M_SYNCH agai= n > whenever needed? [Bing] Even if we don't need M_PUSH standalone. I think current GRASP doesn= 't support multiple M_SYNCH for a single M_REQ_SYNCH?=20 Quoted as below from GRASP, I interpret it as "Per Sync Per Req": " It then sends a synchronization request (using M_REQ_SYN) to the counterpart, including a specific synchronization objective. The counterpart responds with a Synchronization message (M_SYNCH, Section 2.8.10) containing the current value of the requested synchronization objective. No further messages are needed and the transport connection SHOULD be closed. " =20 > > 5.5 Publishing Objective Option > > > > In fragmentary CDDL, a Publish Objective Option follows the pattern: > > > > publish-objection-option =3D [PUBLISH, 2, 2, pubobj] objective-na= me > > =3D PUBLISH > > objective-flags =3D 2 > > loop-count =3D 2 > > pubobj =3D text > > > > This option MAY be included in GRASP M_Synchronization, when > > included, it means this message is for a publish of a specific objec= t > > data. >=20 > I don't understand this. An M_SYNCH by definition delivers the current va= lue of > an objective. Why do we need to say that we're publishing it? [Bing] I think it's another mistake. The PUB option should be in the M_PUSH= message. Since it is per Sync per Req (if I understand it correctly). Many thanks again! B.R. Bing =20 > Regards > Brian Carpenter >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed Dec 18 05:10:26 2019 Return-Path: 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 1FFC412011F; Wed, 18 Dec 2019 05:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 wl-8IKV1Ulob; Wed, 18 Dec 2019 05:10:23 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 DC63A12004C; Wed, 18 Dec 2019 05:10:22 -0800 (PST) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 6697221B63654D41401C; Wed, 18 Dec 2019 13:10:20 +0000 (GMT) Received: from fraeml710-chm.china.huawei.com (10.206.15.59) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 18 Dec 2019 13:10:19 +0000 Received: from fraeml719-chm.china.huawei.com (10.206.15.15) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 18 Dec 2019 14:10:19 +0100 Received: from fraeml719-chm.china.huawei.com ([10.206.15.15]) by fraeml719-chm.china.huawei.com ([10.206.15.15]) with mapi id 15.01.1713.004; Wed, 18 Dec 2019 14:10:19 +0100 From: Xun Xiao To: Sheng Jiang , "anima-chairs@ietf.org" , "anima@ietf.org" Thread-Topic: New Version Notification for draft-liu-anima-grasp-distribution-13.txt Thread-Index: AQHVsQhF0Ilpb2SdLU+sljxSk1B686e3wQfAgAdjmYCAAL/DoA== Date: Wed, 18 Dec 2019 13:10:19 +0000 Message-ID: <457a298a40b946d195bcaae07dae31da@huawei.com> References: <157616770426.20852.6061499986285417726.idtracker@ietfa.amsl.com> <3bf6b1827b954c29a5bc9647fbe30f71@huawei.com> <5D36713D8A4E7348A7E10DF7437A4B9299CE45D0@NKGEML515-MBX.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9299CE45D0@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.99.168] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Anima] New Version Notification for draft-liu-anima-grasp-distribution-13.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2019 13:10:25 -0000 RGVhciBTaGVuZywgQ2hhaXJzIGFuZCBBTklNQSBXRywNCg0KRmlyc3Qgb2YgYWxsLCBNZXJyeSBD aHJpc3RtYXMhDQoNCkZvciB0aGUgdGltZSBzY2hlZHVsZSwgd2UgZGVmaW5pdGVseSBmb2xsb3cg dGhlIHN0cmF0ZWd5L3BvbGljeSBvZiBvdXIgV0csIGFzIHlvdSBzdWdnZXN0ZWQuDQoNCkFsc28s IG1ha2luZyB0aGUgZHJhZnQgYmV0dGVyIGFsaWduZWQgd2l0aCB0aGUgV0cncyB0YXJnZXRzIGFu ZCByZXF1aXJlbWVudHMgaXMgb3VyIG9iamVjdGl2ZS4gVGhlcmVmb3JlLCB3ZSBhZ2FpbiB3aWxs IGFwcHJlY2lhdGUgYW55IGNvbW1lbnQsIGFkdmljZXMsIHN1Z2dlc3Rpb25zIHRoYXQgaGVscCB0 byBpbXByb3ZlIHRoZSBjb250ZW50IG9mIHRoZSBkcmFmdC4gVGhhbmtzIQ0KDQpCZXN0IFJlZ2Fy ZHMsDQoNClh1biBYaWFvICjogpbov4UpDQpBZHZhbmNlZCBXaXJlbGVzcyBUZWNobm9sb2d5IExh Yg0KTXVuaWNoIFJlc2VhcmNoIENlbnRlcg0KSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sTHRkLg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU2hlbmcgSmlhbmcgDQpTZW50OiBX ZWRuZXNkYXksIDE4IERlY2VtYmVyIDIwMTkgMDM6MzUNClRvOiBYdW4gWGlhbyA8WHVuLlhpYW9A aHVhd2VpLmNvbT47IGFuaW1hLWNoYWlyc0BpZXRmLm9yZzsgYW5pbWFAaWV0Zi5vcmcNCkNjOiBM aXViaW5nIChMZW8pIDxsZW8ubGl1YmluZ0BodWF3ZWkuY29tPjsgQXJ0dXIgSGVja2VyIDxBcnR1 ci5IZWNrZXJAaHVhd2VpLmNvbT47IFpvcmFuIERlc3BvdG92aWMgPFpvcmFuLkRlc3BvdG92aWNA aHVhd2VpLmNvbT47IFRvZXJsZXNzIEVja2VydCA8dHRlQGNzLmZhdS5kZT4NClN1YmplY3Q6IFJF OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1hbmltYS1ncmFzcC1kaXN0 cmlidXRpb24tMTMudHh0DQoNCkhpLCBYaWFvIFh1LA0KDQpUaGFua3MgZm9yIHRoZSBuZXdseSB1 cGRhdGUuIFdlIGhhdmUgYSByb3VnaCBjb25zZW5zdXMgdG8gYWRvcHQgdGhpcyBkb2N1bWVudCBv biBzaXRlIGluIElFVEYxMDYuIFRoaXMgbmVlZHMgdG8gY29uZmlybSBpbiB0aGUgbWFpbCBsaXN0 LiBIb3dldmVyLCBnaXZpbmcgdGhhdCBtb3N0IHBlb3BsZSBtYXkgYWxyZWFkeSBpbiB0aGUgQ2hy aXN0bWFzIG1vZGVsLCB0aGUgY2hhaXJzIHByZWZlciB0byBoYXZlIHRoZSB0d28td2VlayBhZG9w dGlvbiBjYWxsIGFmdGVyIHBlb3BsZSBnZXQgYmFjayBmcm9tIGhvbGlkYXlzLg0KDQpUaGFua3Mg YW5kIHJlZ2FyZHMsDQoNClNoZW5nDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogWHVuIFhpYW8NCj4gU2VudDogRnJpZGF5LCBEZWNlbWJlciAxMywgMjAxOSA0OjUwIFBN DQo+IFRvOiBhbmltYS1jaGFpcnNAaWV0Zi5vcmc7IGFuaW1hQGlldGYub3JnDQo+IENjOiBMaXVi aW5nIChMZW8pIDxsZW8ubGl1YmluZ0BodWF3ZWkuY29tPjsgQXJ0dXIgSGVja2VyIA0KPiA8QXJ0 dXIuSGVja2VyQGh1YXdlaS5jb20+OyBab3JhbiBEZXNwb3RvdmljIA0KPiA8Wm9yYW4uRGVzcG90 b3ZpY0BodWF3ZWkuY29tPjsgU2hlbmcgSmlhbmcgPGppYW5nc2hlbmdAaHVhd2VpLmNvbT4NCj4g U3ViamVjdDogUkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+IGRyYWZ0LWxpdS1h bmltYS1ncmFzcC1kaXN0cmlidXRpb24tMTMudHh0DQo+IA0KPiBEZWFyIENoYWlycywgRGVhciBB TklNQSBXRyBtZW1iZXJzLA0KPiANCj4gRHVyaW5nIElFVEYxMDYsIHRoZSBhdXRob3JzIGhlcmUg aGFkIG1hbnkgdGVjaG5pY2FsIGRpc2N1c3Npb25zIG9uIHRoZSANCj4gaW5mb3JtYXRpb24gZGlz dHJpYnV0aW9uIHRvcGljIHdpdGggc2V2ZXJhbCBncm91cCBtZW1iZXJzLiBNYW55IHRoYW5rcyAN Cj4gZm9yIHRoZSBjb25zdHJ1Y3RpdmUgY29tbWVudHMvYWR2aWNlcy4NCj4gDQo+IEhlcmVieSwg YWNjb3JkaW5nIHRvIHRoZSBmZWVkYmFja3MsIGEgcmV2aXNlZCB2ZXJzaW9uIGlzIHVwZGF0ZWQs IA0KPiB0cnlpbmcgdG8gYmV0dGVyIG1vdGl2YXRlIHRoZSBwcm9ibGVtIGFuZCBpbnRyb2R1Y2Ug dGhlIHByb3Bvc2VkIA0KPiBzb2x1dGlvbi4gV2Ugd2lsbCBhcHByZWNpYXRlIGFueSBmdXJ0aGVy IGNvbW1lbnRzLg0KPiANCj4gTWVhbndoaWxlLCBhcyBvbmUgb2YgdGhlIGNoYXJ0ZXJlZCBtaWxl c3RvbmUgdG9waWMgd29yaywgd2Ugd2VyZSANCj4gd29uZGVyaW5nIGlmIHRoZSBkcmFmdCBjYW4g YmUgYWRvcHRlZCBhcyBhIFdHIGRyYWZ0IHdvcmtpbmcgaW4gDQo+IHByb2dyZXNzIG9uIHRoZSBz dGFuZGFyZCB0cmFjay4gVGhhbmtzIGZvciB5b3VyIGNvbnNpZGVyYXRpb25zLg0KPiANCj4gQmVz dCBSZWdhcmRzLA0KPiANCj4gWHVuIFhpYW8gKOiClui/hSkNCj4gQWR2YW5jZWQgV2lyZWxlc3Mg VGVjaG5vbG9neSBMYWINCj4gTXVuaWNoIFJlc2VhcmNoIENlbnRlcg0KPiBIdWF3ZWkgVGVjaG5v bG9naWVzIENvLixMdGQuDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddDQo+IFNlbnQ6IFRodXJzZGF5LCAxMiBEZWNlbWJlciAyMDE5IDE3OjIyDQo+IFRvOiBMaXVi aW5nIChMZW8pIDxsZW8ubGl1YmluZ0BodWF3ZWkuY29tPjsgQXJ0dXIgSGVja2VyIA0KPiA8QXJ0 dXIuSGVja2VyQGh1YXdlaS5jb20+OyBYdW4gWGlhbyA8WHVuLlhpYW9AaHVhd2VpLmNvbT47IFpv cmFuIA0KPiBEZXNwb3RvdmljIDxab3Jhbi5EZXNwb3RvdmljQGh1YXdlaS5jb20+OyBTaGVuZyBK aWFuZyANCj4gPGppYW5nc2hlbmdAaHVhd2VpLmNvbT4NCj4gU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciANCj4gZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1dGlvbi0x My50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGl1LWFuaW1hLWdy YXNwLWRpc3RyaWJ1dGlvbi0xMy50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBYdW4gWGlhbyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBO YW1lOgkJZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1dGlvbg0KPiBSZXZpc2lvbjoJMTMN Cj4gVGl0bGU6CQlJbmZvcm1hdGlvbiBEaXN0cmlidXRpb24gaW4gQXV0b25vbWljIE5ldHdvcmtp bmcNCj4gRG9jdW1lbnQgZGF0ZToJMjAxOS0xMi0xMg0KPiBHcm91cDoJCUluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KPiBQYWdlczoJCTIxDQo+IFVSTDoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpdS1hbmltYS1ncmFzcC1kaXN0cmlidXRpbw0KPiBuLTEzLnR4 dA0KPiBTdGF0dXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxp dS1hbmltYS1ncmFzcC1kaXN0cmlidXRpb24vDQo+IEh0bWxpemVkOg0KPiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1dGlvbi0xMw0KPiBI dG1saXplZDoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1s aXUtYW5pbWEtZ3Jhc3AtZGlzdHJpYnV0aQ0KPiBvbg0KPiBEaWZmOg0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1dGlvbi0x DQo+IDMNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIGEgc29s dXRpb24gZm9yIGluZm9ybWF0aW9uIGRpc3RyaWJ1dGlvbiBpbg0KPiAgICBhdXRvbm9taWMgbmV0 d29ya3MuIEluZm9ybWF0aW9uIGRpc3RyaWJ1dGlvbiBpcyBjYXRlZ29yaXplZCBpbnRvIHR3bw0K PiAgICBkaWZmZXJlbnQgbW9kZXM6IDEpIGluc3RhbnRhbmVvdXMgZGlzdHJpYnV0aW9uOyAyKSBw dWJsaWNhdGlvbiBmb3INCj4gICAgcmV0cmlldmFsLiBJbiB0aGUgZm9ybWVyIGNhc2UsIHRoZSBp bmZvcm1hdGlvbiBpcyBzZW50LCBwcm9wYWdhdGVzDQo+ICAgIGFuZCBpcyBkaXNwb3NlZCBvZiBh ZnRlciByZWNlcHRpb24uIEluIHRoZSBsYXR0ZXIgY2FzZSwgaW5mb3JtYXRpb24NCj4gICAgbmVl ZHMgdG8gYmUgc3RvcmVkIGluIHRoZSBuZXR3b3JrLg0KPiANCj4gICAgVGhlIGNhcGFiaWxpdGll cyB0byBkaXN0cmlidXRlIGluZm9ybWF0aW9uIGFyZSBiYXNpYyBhbmQgZnVuZGFtZW50YWwNCj4g ICAgbmVlZHMgZm9yIGFuIGF1dG9ub21vdXMgbmV0d29yayAoY2YuIEFOSSBbSS1ELmlldGYtYW5p bWEtcmVmZXJlbmNlLQ0KPiAgICBtb2RlbF0pLiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0eXBp Y2FsIHVzZSBjYXNlcyBvZiBpbmZvcm1hdGlvbg0KPiAgICBkaXN0cmlidXRpb24gaW4gQU5JIGFu ZCByZXF1aXJlbWVudHMgdG8gQU5JLCBzdWNoIHRoYXQgcmljaA0KPiAgICBpbmZvcm1hdGlvbiBk aXN0cmlidXRpb24gY2FuIGJlIG5hdGl2ZWx5IHN1cHBvcnRlZC4gVGhlIGRvY3VtZW50DQo+ICAg IHByb3Bvc2VzIGV4dGVuc2lvbnMgdG8gdGhlIGF1dG9ub21pYyBub2RlcyBhbmQgc3VnZ2VzdHMg YW4NCj4gICAgaW1wbGVtZW50YXRpb24gYmFzZWQgb24gR1JBU1AgZXh0ZW5zaW9ucyBhcyBhIHBy b3RvY29sIG9uIHRoZSB3aXJlLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgDQo+IHN1Ym1p c3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Thu Dec 19 04:45:41 2019 Return-Path: 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 AE458120121; Thu, 19 Dec 2019 04:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 kEn349XzTBJB; Thu, 19 Dec 2019 04:45:38 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140117.outbound.protection.outlook.com [40.107.14.117]) (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 D107812006D; Thu, 19 Dec 2019 04:45:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AuYekmRE6D+VLPW2BFJy+P7L8UkfvileAmJXd5rkAbvI23Vymh+8pG3oZa3cH84XQcjH5BgceNLl7GykND1eNvjWDMU/ez1pAyHqe4XClw00k8Lu6UMnuhAuKJxBgcDU9wSj8sJIv8pCtwre8b7N99RI+Yl+cuPJEfE0URR5q0RkUgXFW0ZcnGrSdVlqkWhP4frvqUt7YvJfqaTE+GXioYXyq6G7UB5NcOPR9aAsP8YVnwOqs+NubtyCuYUjpe86ASg5+V4YcNJtNKVS/nlbtdqBZoHklfrGnISXogBG6VEtFhbOPvTkt9m4g+5Krice7n3fqfJ8k+bozWhWoxQsSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LhHDPolJKZkOKO2YxMpmfG7CzcCm9qVJTjDgW7jrjGo=; b=VMEg+prKxfn+GGMuXWLeanQpR2ebDcF0u+q2vHV2lCuVC4dwQOcrVp4gXU6eb4dxgu6BnFOeD2USzHxKGDwh3JqG8yVCFw7K6PTunUW/lYG2+zqSHdk6EdrGiWY6uzYxG6fiYGmVBa6kT1Z5FTigjNOqZSQTxmlIJYhZLlMdpaybMRKh9HlGcxf1MVvIzjEM2hbmt2K0m2WgUfUqnDnN0f6lDc04AmOqnLPLUBq931aJ6flpwwwo+mj+gjnT6XmVpWUrY8WIJa+1hKHHIU+ujFMDh8q0v3l8oyteohJqz//iNzP6x5x+ivxFN0BNvDVMIr7leQjqdsy42ZZ5FzdEyg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LhHDPolJKZkOKO2YxMpmfG7CzcCm9qVJTjDgW7jrjGo=; b=f4M/gUewGKo0D554Zj/uY8SdsF1cCl+9dyeMJG1yp8NcqpGURC0vz3lP5vwWHz5uTFVDA3ihyz8lXsR6uvP3uCty3NNvr30tlOTq7vz3umSExZXlnnGMReIMxpkJf3z2nUVWCH+dI24xfuxU3Wu6WMJthtAZwD4BDyAHhOH/Fzw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; Received: from AM0PR07MB5716.eurprd07.prod.outlook.com (20.178.115.216) by AM0PR07MB4259.eurprd07.prod.outlook.com (52.133.57.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.12; Thu, 19 Dec 2019 12:45:35 +0000 Received: from AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::4156:4119:dd89:95f7]) by AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::4156:4119:dd89:95f7%5]) with mapi id 15.20.2559.016; Thu, 19 Dec 2019 12:45:35 +0000 To: Michael Richardson , Alissa Cooper References: <157123777786.7830.10713306244839546046.idtracker@ietfa.amsl.com> <9637.1574756997@localhost> <2FA2728E-6484-4A69-992A-479D8053354E@cooperw.in> <20062.1576526178@localhost> <27190.1576614545@localhost> Cc: IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org From: tom petch Message-ID: <5DFB70E8.7010207@btconnect.com> Date: Thu, 19 Dec 2019 12:45:28 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <27190.1576614545@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P123CA0012.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:a6::24) To AM0PR07MB5716.eurprd07.prod.outlook.com (2603:10a6:208:11e::24) MIME-Version: 1.0 Received: from [192.168.1.65] (86.139.211.103) by LO2P123CA0012.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:a6::24) with Microsoft SMTP Server (version=TLS1_2, cipher=) via Frontend Transport; Thu, 19 Dec 2019 12:45:34 +0000 X-Originating-IP: [86.139.211.103] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f5ebf4a9-a674-4a26-c92e-08d784815772 X-MS-TrafficTypeDiagnostic: AM0PR07MB4259: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:3173; X-Forefront-PRVS: 0256C18696 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(136003)(396003)(376002)(366004)(199004)(189003)(316002)(6666004)(186003)(87266011)(52116002)(86362001)(8936002)(16576012)(2616005)(4326008)(16526019)(53546011)(26005)(4744005)(33656002)(5660300002)(6486002)(66556008)(66476007)(8676002)(478600001)(81166006)(966005)(66946007)(36756003)(2906002)(81156014)(956004)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4259; H:AM0PR07MB5716.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: oue7fmCqpcWMYdlrD3jcidnP0IKvgvLZdClFhQUYrmMxTZV8LsUbP07rFrT4K8SRBjfIukzHC/9lDMxR/09z+3G5hk7NH1DAPLkp2gtUGvC5ULNtKFCrzT6C1/F5060fHNoancgXCBvM9egKtLzIgdGWeXtIGT1zp06ZK8QWdj/0e2Q2kCZpldPkMyezQK0rZaOMCX6GPywC0NlnLsf/Uv7usjfFJU4wFZlB8CmZ2zAi8MS4yAK5CIoJoBh8QLovxuZmM79Fn2USQjDUmCqxqedi71AlJfap0xL/t49Vx2qNbOnBsR6rWwlfOkOuOBWIz2KUwcp1a0etHiVKAEvyUbvIEuU+rvLgmYTBx91avrJkkA4hOGkfkMJiKst06s1yRICoL+g1xg3j4V4NF498VWo5b/ToXCzSwcnQ+f0S7AbsYgmBSu6a0tKTnVF8ta05sxu1OJVTJpVC49OMmbnS5Uey1P2JyDfnlarg7R6j8ZI= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: f5ebf4a9-a674-4a26-c92e-08d784815772 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2019 12:45:34.9952 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: /NzdP16FUB6tjb60Fk3+c70vYMYPdEXjl6qq5wGaif40aA6QTBXhqDu0w4FhZ8Fdov6JHpMH8gwk7jgNyIumaQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4259 Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2019 12:45:41 -0000 Michael Just to reiterate. For a YANG module, you MUST have two IANA actions to register the namespace and the module itself so removing s.8.1 fixes one problem but leaves two outstanding. Details in YANG Guidelines or in any other I-D/RFC with a YANG module Tom Petch On 17/12/2019 20:29, Michael Richardson wrote: > > Alissa Cooper wrote: > > Thanks Michael. Should Section 8.1 now be removed as well? > > I thought that I got it, but I see that I didn't git commit that part. > > I have removed it, and I'll post that in a day, once I hear from Roman and > Ben about whether they feel I am done with their comment stream. > > -- > ] 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 [ > > > From nobody Fri Dec 20 14:31:14 2019 Return-Path: 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 B94591200C1; Fri, 20 Dec 2019 14:31:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.114.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <157688107174.4079.10454309821544008060.idtracker@ietfa.amsl.com> Date: Fri, 20 Dec 2019 14:31:11 -0800 Archived-At: Subject: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-31: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2019 22:31:12 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-31: 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-bootstrapping-keyinfra/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for providing a clear specification of the /enrollstatus EST endpoint in the -30. The following two points still seem unaddressed, though. The -29 reworks the definition of the 'nonce' field to be: strong random or pseudo-random number nonce (see [RFC4086] section 6.2). As the nonce is usually generated very early in the boot sequence there is a concern that the same nonce might generated across multiple boots, or after a factory reset. Difference nonces MUST NOT generated for each bootstrapping attempt, whether in series or concurrently. The freshness of this nonce mitigates against the lack of real-time clock as explained in Section 2.6.1. This needs to either be "Different nonces MUST be generated" or "the same nonce MUST NOT be reused"; this mashup is no good. Email exchange with mcr notes: > > An RFC Editor note about the RFC 8366 assignment of OID > > 1.2.840.113549.1.9.16.1.40 was removed from -23 to -28; do the examples > > properly use that assigned OID now? > > We got a MASA URL Extension OID for: > 1.3.6.1.5.5.7.1.32 > > the examples date from before that, and do not use it yet. We need to fix the examples before publication. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few new comments on the -30 and -31 to start. I think some of my comments on the -29 are still valid, and will try to remove ones that have been addressed. To reiterate: to the best of my knowledge, all the comments in this ballot position are actionable and have not been overtaken by events. In Section 5.9.4: In the case of a FAIL, the same TLS connection MUST be used. The Reason string indicates why the most recent enrollment failed. I'd suggest something more like "In the case of a failed enrollment, the client MUST send the telemetry information over the same TLS connection that was used for the enrollment attempt, with a Reason string indicating why the most recent enrollment failed. (For failed attempts, the TLS connection is the most reliable way to correlate server-side information with what the client provides.)" (Also, why is "FAIL" capitalized?) Thanks for the text in Section 11.2 about second-preimage-resistance of DomainID calculation; the grammar needs a tweak or two, though. My suggestion would be to either drop "The consequences of" or add "be to" to make "would be to allow" (but not both). Section 11.3 has gone back to just "Devices which are reset to factory default in order to perform a second bootstrap with a new owner MUST NOT use idential seeds", but I think it's important to be clear about what the scope of uniqueness is. The text in Section 5.2 is pretty good in this regard, with respect to the nonces (which are generally derived from the seed); I wonder if we might want to restructure this text to be more like "The random seed used by a device at boot MUST be unique across all devices and all bootstraps. Resetting a device to factory default state does not obviate this requirement." (FWIW, I think the text in the -29 was that way because of my request.) [A few comments on the -29, some of which I think might be repeats of ones I made on a WIP interim draft; sorry if I say something again that was already debunked. The comment section from the -28 is preserved later.] In Section 3.3, we now cite RFC 4648; I note that RFC 4648 specifies both base64 and base64url, so a section reference is usually appropriate (and in Section 5 we do give a section reference into RFC 4648). Section 9.1 Other use cases likely have similar, but MAY different requirements. nit: ", but MAY have different, requirements" Section 9.1.1 Authentication process. The MASA creates signed voucher artifacts according to a it's internally defined policies. nit: s/a it's/its/ Section 9.1.3 (Do we need to say "DULL" specifically again here for Join Proxy discovery? Maybe not...) [All new comments for the -28] Please respond to the secdir re-review. Section 2.6.1 A pledge with a real time clock in which it has confidence in, MUST check the above time fields in all certificates and signatures that it processes. nit: s/in// from "in which it has confidence in" (your choice which one). Section 4 This section applies is normative for uses with an ANIMA ACP. The nit: pick one of "applies to" or "is normative for". [...] The use of GRASP mechanism part of the ACP. Other users of BRSKI will need nit: missing "is", "the" Section 5.7 The Status field indicates if the voucher was acceptable. Boolean values are acceptable. nit: I suggest """acceptable, as a boolean, where "true" indicates the voucher was acceptable""". Section 10.6 Section Section 7.4.3 describes some ways in which a manufacturer nit: duplicate "Section". Section 10.7 existing products. Said products might be previous deployed and need to be re-initialized, purchased used, or just kept in a warehouse as long-term spares. nit: s/previous deployed and need/previously deployed that need/ Section 11.2 In particular implementations should pay attention to the advance in [RFC4086] section 3, particulary section 3.4. Devices which are reset to factory default in order to perform a second bootstrap with a new owner MUST NOT seed their random number generators in the same way. nit: s/same way/same way across bootstraps/ Section 11.3 We had some discussion around my previous comment: % Additionally, in order to successfully use the resulting voucher the % Rm would have to attack the pledge and return it to a bootstrapping % enabled state. This would require wiping the pledge of current % % ... and I think there is a different attack if the Rm is in a position % to delay or drop network traffic between the pledge and the intended % registrar, to cause Rm's voucher to be delivered first even though it is % generated after the intended registrar's authorization process. The % intended registrar would need to require reports on voucher processing % status (or investigate their absence) in order to detect such a case. but I can't remember if we decided that we didn't need to discuss the risk in the document. [ed. I also can't remember if we had discussion about this comment] ======================================================================= I trimmed all the "Additional comments since posted ballot position on -28" that were in my previous ballot position, as they are likely stale by now. From nobody Sun Dec 22 17:30:05 2019 Return-Path: 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 86206120026; Sun, 22 Dec 2019 17:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 j_qlXd0mPNLb; Sun, 22 Dec 2019 17:30:03 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E95D5120013; Sun, 22 Dec 2019 17:29:59 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5199E38983; Sun, 22 Dec 2019 20:29:51 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8CA3671D; Sun, 22 Dec 2019 20:29:58 -0500 (EST) To: anima@ietf.org, spam@ietf.org References: <6535.1560786935@dooku.sandelman.ca> From: Michael Richardson Message-ID: <9abd8009-2c3b-f5a5-6c54-09e71b8cfa4b@sandelman.ca> Date: Sun, 22 Dec 2019 20:29:58 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <6535.1560786935@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 01:30:04 -0000 On 2019-06-17 11:55 a.m., Michael Richardson wrote: > > I have posted the draft > https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030est-clarify/ > > this morning. It attempts to address the errata posted by Sean Turner in > 2017 on RFC7030. Specifically the use of Content-Type-Encoding (CTE) and > base64. You can see my other query to httpbis at: > https://mailarchive.ietf.org/arch/msg/httpbisa/m4l4G_lHKfQVfSeAn7IxReUioD0 This document is being considered for adoption by the LAMPS WG. The thread is at: https://mailarchive.ietf.org/arch/msg/spasm/qllFWkh7GSJuXv66nKh12fXrdos (despite the body that says it is about turner-5480-ku) From nobody Wed Dec 25 19:43:55 2019 Return-Path: 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 C6A6412080A; Wed, 25 Dec 2019 19:43:53 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 8Fv1Oxc6bN4t; Wed, 25 Dec 2019 19:43:51 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 8F7D2120819; Wed, 25 Dec 2019 19:43:51 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 84BBABFA53AFCDD6F7B8; Thu, 26 Dec 2019 03:43:49 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 26 Dec 2019 03:43:48 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0439.000; Thu, 26 Dec 2019 11:43:45 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" , Toerless Eckert Thread-Topic: ANIMA minutes - IETF106 Singapore Thread-Index: AdW7nqp9z0lLpfEWSdqsBKY6wkrtIQ== Date: Thu, 26 Dec 2019 03:43:44 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9299D13579@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B9299D13579NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] ANIMA minutes - IETF106 Singapore X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2019 03:43:54 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B9299D13579NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all, The minutes for the ANIMA sessions at IETF106 in Singapore be found at: https://datatracker.ietf.org/doc/minutes-106-anima/ Many thanks to Artur Hecker (Session I), Michael Richardson (Session II) fo= r taking minutes. Sorry for the large delay. I thought we had done it soon after the meeting.= It is partly because the chairs did not receive the text that minutes take= r sent through anima-chairs@ietf.org I seems = not receive any emails through that email address. They were filtered somew= here. Please do send emails directly to the chairs, while may copy to the c= hair address. Please send any corrections to the chairs. Best regards, Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B9299D13579NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi, all,
 
The minutes for the ANIMA sessions a=
t IETF106 in Singapore be found at:
 
https://datatracker.ietf.org/doc/minutes-106-an=
ima/
 
Many thanks to Artur Hecker (Session=
 I), Michael Richardson (Session II) for taking minutes.<=
/pre>

 


Sorry for the large delay. I thought=
 we had done it soon after the meeting. It is partly because the chairs did=
 not receive the text that minutes taker sent through anima-chairs@ietf.org I seems not receive any email=
s through that email address. They were filtered somewhere. Please do send =
emails directly to the chairs, while may copy to the chair address.


 


Please send any corrections to the c=
hairs.


 


Best regards,

 


Sheng


 
--_000_5D36713D8A4E7348A7E10DF7437A4B9299D13579NKGEML515MBXchi_-- From nobody Fri Dec 27 06:46:39 2019 Return-Path: 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 D88E1120052; Fri, 27 Dec 2019 06:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 s_qWmBUC8Hik; Fri, 27 Dec 2019 06:46:36 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E866012004A; Fri, 27 Dec 2019 06:46:35 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CEE683897B; Fri, 27 Dec 2019 09:46:23 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C080BAAD; Fri, 27 Dec 2019 09:46:34 -0500 (EST) From: Michael Richardson To: "Panos Kampanakis \(pkampana\)" , anima@ietf.org, LAMPS WG In-Reply-To: References: <157429966624.922.6336772483106473689.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 Archived-At: Subject: Re: [Anima] [lamps] Call For Adoption of draft-richardson-lamps-rfc7030est-clarify X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 14:46:38 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Panos Kampanakis (pkampana) wrote: > The Abstract mentions GRASP discovery as well which falls out of scope > for LAMPS imo though. Oh, yes. I never actually wrote the text to go with it, I will remove it! We actually don't need that as it turns out, as draft-ietf-anima-autonomic-= control-plane provides for that, but I didn't remember that last spring when I wrote the document. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4GGUoACgkQgItw+93Q 3WUW3Af+Ow7laqBwR0kXeRmZl1OgsIbV28XoIJES21yZ7O7kZuhX/vm+oFJLdHQm EVlML7oh9nK1NPArhno20jv8qZhi69Ugs1zRLsRycCiURfrrYEMhHlfjwubx3go4 Ya6dgk9yzv5kJmB5CFg/NboMhL3v0q+x5UU63rYt7XPogyfB3KDegvnQttsnTzkY S4D6VQlZZW9eYQ4EzQXfqdrHdMvMLrsSqxHiwW/GJ4S0Q/XWlb8K5t2eJwnF18PP B1Z09yN45tMl2LqdEI0wXt+BztGQijaB8QBhitQAlb+VudvLOv4dYBAj7sX8XxjX JaI6+LZ76VNy8V2qnGgCCsbLXxAVig== =36Do -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Dec 29 08:53:40 2019 Return-Path: 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 BFD63120077 for ; Sun, 29 Dec 2019 08:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 Mh1OY7RW5cMG for ; Sun, 29 Dec 2019 08:53:35 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1213F12001A for ; Sun, 29 Dec 2019 08:53:34 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 81440F406C5; Sun, 29 Dec 2019 08:53:22 -0800 (PST) To: kwatsen@juniper.net, mcr+ietf@sandelman.ca, pritikin@cisco.com, tte+ietf@cs.fau.de, toerless.eckert@huawei.com, ibagdona@gmail.com, warren@kumari.net, jiangsheng@huawei.com, tte+anima@cs.fau.de X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: te.hasegawa2@gmail.com, anima@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20191229165322.81440F406C5@rfc-editor.org> Date: Sun, 29 Dec 2019 08:53:22 -0800 (PST) Archived-At: Subject: [Anima] [Editorial Errata Reported] RFC8366 (5949) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2019 16:53:37 -0000 The following errata report has been submitted for RFC8366, "A Voucher Artifact for Bootstrapping Protocols". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5949 -------------------------------------- Type: Editorial Reported by: Tetsuya Hasegawa Section: 5.1. Original Text ------------- 7. Devices that support decrypting SZTP artifacts MUST posses the Corrected Text -------------- 7. Devices that support decrypting SZTP artifacts MUST possess the Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8366 (draft-ietf-anima-voucher-07) -------------------------------------- Title : A Voucher Artifact for Bootstrapping Protocols Publication Date : May 2018 Author(s) : K. Watsen, M. Richardson, M. Pritikin, T. Eckert Category : PROPOSED STANDARD Source : Autonomic Networking Integrated Model and Approach Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Mon Dec 30 09:32:14 2019 Return-Path: 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 EA527120B44; Mon, 30 Dec 2019 09:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 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] 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 4RWdpDlac1Jh; Mon, 30 Dec 2019 09:32:06 -0800 (PST) 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 0E4C8120B42; Mon, 30 Dec 2019 09:32:02 -0800 (PST) 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 xBUHUU8C028197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Dec 2019 12:30:33 -0500 Date: Mon, 30 Dec 2019 09:30:30 -0800 From: Benjamin Kaduk To: Toerless Eckert Cc: The IESG , anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com Message-ID: <20191230173030.GJ35479@kduck.mit.edu> References: <156331768227.15267.2488890611024053018.idtracker@ietfa.amsl.com> <20191103212741.GA48708@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191103212741.GA48708@faui48f.informatik.uni-erlangen.de> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-19: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2019 17:32:12 -0000 Hi Toerless, [Note for everyone else: I've been looking at an editor's copy with some updates since the -21; diff from the -21 is available at ttp://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draf t-ietf-anima-autonomic-control-plane-21.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draf t-ietf-anima-autonomic-control-plane.21.1.txt ] Inline (but reflecting the updated editor's copy)... On Sun, Nov 03, 2019 at 10:27:41PM +0100, Toerless Eckert wrote: > Hi Ben, > > In my last reply to your review from Jul 24th (appended below), i resolved > most issues in -20, and mentioned two open issues. I hope i "resolved" them > with -21 which i just posted. > > Diff 20 - 21: > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-20.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-21.txt > > Complete diff since your last review, -19 -> -21: > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-19.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-21.txt > > 1. Your suggestion for ASN encoding of domain-information / new ASN element > for ACP domain information. > > I did list in my last response to you a range of conditions under which we could > agree that a new ASN.1 certificate element would be a potentially better > soution than using the rfc822 field. I did discuss this during montreal with the > WG, but it does really seem as if the rfc822address was the best coice for > ease of adoption: > > The main reason reflected by others was the ability of existing ASN.1 libraries > to support the rfc822address field without new versions of a library or more > complex updates/extensions to said libraries. I think this was also for low-end > libraries in the IOT space. > > I listed other reasons (ease of diagnostics with existing tools, human > readible string, etc..) too in my last email below. > > Aka: At this stage, i would like to stick to the current rfc822address encoding. > I think we did do a good amount of diligence for it in the WG, and > existing coding seems to support our decision. > > So, i did not change any text for it in -21. While I can understand that this is an appealing approach, it still seems to me that the list at the end of Section 6.1.2 reads more as a list of reasons why it's convenient to use rfc822Name rather than a list of reasons why it's the right thing to do. I have been thinking about this topic a great deal, and consulted with several PKIX experts at IETF 106 during the week, and got a universal sense that this usage is not an rfc822Name, and instead is exactly the sort of thing that otherName is meant for. Accordingly, I'm going to continue to hold a Discuss for this point -- we need to define how to build the ACP in a PKIX-compliant way. That may not preclude individual deployments that build an ACP in a PKIX-non-compliant way (i.e., rfc822Name), and I could imagine some way to write text that admits such a possibility while noting that it's not the right thing to do. That said, my one Discuss point is not the end of the road for things; since as I understand it the WG has already considered the topic extensively, it may be time to check with the responsible AD about bringing the document back on a telechat with, e.g., an alternate ballot procedure ("single-discuss" or the full-on "alternate procedure" from https://ietf.org/standards/process/iesg-ballots/). I don't remember hearing much from any other IESG members on this topic, at least as of yet. > 2. Missing crypto parameters. > > I think i resolved the missing parameters in -21, pls. see diff. > > Re-reading our thread (last reply appended below), you mentioned a > desire for GMAC in IPsec, but i went for ENCR_AES_GCM_16 > already in -20 because rfc8221 says: > > "AUTH_AES_128_GMAC status has been downgraded from SHOULD+ to MAY. > Along with AUTH_AES_192_GMAC and AUTH_AES_256_GMAC, these algorithms > should only be used for AH and not for ESP." > > to hopefully wrap up the crypto discussion: If there are any remaining > crypto parameter gaps, where you can not simply suggest text to resolve them, > i think the best way to resolve them is in person in singapore. After montreal, > i sent a request to the crypto experts you recommended me but didn't receive > reply to the email, so everybody is really busy and its harder and harder > to resolve smaller and smaller issues via email. In Singapore I managed to strong-arm Valery Smyslov into taking a look, and I digested his comments into a pull request at https://github.com/anima-wg/autonomic-control-plane/pull/9 . Note that I marked it as "WIP", as Valery's preferences are to defer to the existing usage guidelines RFCs as much as possible, so that we don't need to say anything at all about several of the parameters. I also wanted to check one last time that the goal is still to go for the 256-bit security level across the board, as a couple things might get tweaked otherwise. > 3. RPL root provisions for logging unknown destinations Just to be concrete, the updated text does address my last discuss point -- thanks! Sorry again for the delay -- I really needed some time to try to digest the rfc822Name topic. -Ben > Appended below our last exchange. > > On Tue, Jul 23, 2019 at 01:22:43AM +0200, Toerless Eckert wrote: > > --- Context: > > > > I hope i am correctly restating, that this reply is as follows: > > -> After finishing second round of replies for -16, Ben Kaduk provided a reply > > that is now also his new DISCUS position on datsatracker. this is my reply > > to that DISCUS. > > > > -> The diff for the changes discussed in this email is: > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.19.2.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.19.3.txt > > They are also summarized under section (3) of the -20 changelog. > > > > -> The total changes -19 to -20 are of course: > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-19.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-20.txt > > > > > On Tue, Jul 16, 2019 at 03:54:42PM -0700, Benjamin Kaduk via Datatracker wrote: > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-anima-autonomic-control-plane-19: 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: > > ---------------------------------------------------------------------- > > > > [trimming to just the topics still under discussion; no change to the > > text of the remaining items even though some changes have been made > > to the document] > > > > I think there needs to be some justification of why rfc822Name is chosen > > over a more conventional structure in the otherName portion of the > > subjectAltName, which is explicitly designed to be extensible. > > Let me but the compromise proposal and conditions on top: > > Compromise proposal (not integrated into current text yet): > > The document defines a new otherName like ACPdomainIdentity, type IA5String > > I can figure out how to write the the necessary formal text for this, > stealing from e.g.: rfc8398 or the like (asking for IANA registration etc..) > i will whine for help (from you) when i fail with that text formalisms/ASN1. stuff. > > The encoding of the string is the existing domain-information > > The length limitation of 64 for the local part is lifted (yeah). > > The rest of the text (justification for formatting etc.) is appropriately > fixed up. I will remove all the text suggesting this could be an actual > rfc822 address and just escribe it in terms of below reasoning (nice format > to express domain based identities "local+policies@domain" or the like. > > Condition: > > Sufficient support in WG (tomorrow meeting) wrt. the following key aspects: > -> Belief that even the most stupid existing libraries to > deparse certificates can give access to this information without rev'ing > such libraries (we assume this is true for rfc822Name). > -> Ability of a good amount of existing diagnostics tools to actually > display the string content as a string, even when it obviously doesn't know > what type the otherName is. > This is based on my hope that i correctly understand BER/DER to be self > identifying, so deparser would know the element is string, but thats's what > i am not sure about. > > Reasons: > - We need both a human readable and in-cmputer representation of the information. > I really don't see enough reason to have two different ones, and i really > don't want to write to structure defintions. So i think the existing > ABNF string is nice for both purposes. This info will go into all type > of backend systems, inventory tracking etc.. deparsing specifically formatted > strings is quite common there. > > - The domain-information is really the non-cryptographic part of the ACP device > identity. and the local@domain part is an established way to represent this, > so its hopefully "nice" too - e.g.: i woldn't know a more appropriate > format. > > > In a few places, the MTI cryptographic mechanisms are under-specified, > > whether the cipher mode for IKE or the TLS ciphersuites. I have attempted > > to note these locations in my section-by-section comments. > > Right. > a) I couldn't find good references for certificate requirements. > The IPsec/IKEv2 reference STANDARDS RFCs lamely said something like > "problem for the PKIX community". > > (seems like a gapipng big interop hope for those protocols if it doesn't exist). > > b) I am confused about TLS parameters needed beside what i wrote in latest > update. See nit discuss below. > > > Section 6.11.1.14 places a normative ("SHOULD") requirement on the RPL > > root, but if I understand correctly the RPL root is automatically > > determined within the ACP, and thus the operator does not a priori know > > which node will become the RPL root. Am I misunderstanding, or is this > > effectively placing this requirement on all ACP nodes? > > Fixed by adding an option to not ask for this diagnostics to lowest-end > nodes least in line to become root. When one of those nodes becomes > root, the network is already in a worst degraded state, so this advanced > diagnostics is then likely the least of problems. > > Details in reply to original -16 review answer you sent. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thank you for adding the implementation experience note to the shepherd > > writeup; it is helpful to understand the maturity level of the document. > > > > The comments here are probably best understood in the context of my > > previous ballot position, specifically with respect to certain topics > > being "speculative" or a matter for "future work". > > > > One somewhat general comment that occurred to me on the reread is that > > by encoding the ACP address into a node's LDevID, we are on the face of > > things locking it into a given addressing model, though in practice it > > should be fairly straightforward to issue a new certificate through > > regular update/renewal mechanisms. I forget if we have discussion of > > this non-issue already. > > Readdressing is possible, but the address is really the non-security > part of the identity of an ACP node (security part is key-pair), so all > the ACP text talks about trying to maintain it whenever possible (discussed > in the text for example in the face of change of registrars, so the originally > assigning registrar is gone). > > There is really nothing breaking in the ACP when ACP nodes change their > addresses, but typically the short-term adoptions of ACP into non-fully > autonomic environments would love to see persistent addresses, because thats > what they do today: > > Operators have used IP addresses as ideally never-changing network services > identifiers of nodes for decades (loopback addresses). Thats just what > we do with ACP, and the assignment via certificate is an elegant way to solve the > current manual problem of network wide unique assignment, it just gets a > bit complicated under the hood in above mentioned cases (registrar change > during cert renewal). > > The use of well-defined address plans standardized in the ACP document is also > something that effectively just automates operational practices and keeps > deployment specific options at a minimum. > > > Section 1 > > > > Combining ACP with Bootstrapping Remote Secure Key Infrastructures > > (BRSKI), see [I-D.ietf-anima-bootstrapping-keyinfra]) results in the > > "Autonomic Network Infrastructure" as defined in > > [I-D.ietf-anima-reference-model], which provides autonomic > > connectivity (from ACP) with fully secure zero-touch (automated) > > bootstrap from BRSKI. The ANI itself does not constitute an > > > > nit: It's unclear that there's universal agreement about what "fully > > secure" might mean, so I'd suggest just using "secure". > > Done. > > > Section 2 > > > > ACP (ANI/AN) Domain Certificate: A provisioned [RFC5280] certificate > > (LDevID) carrying the domain information field which is used by > > > > nit: I think the reference is for "certificate", not "provisioned". > > > > ACP secure channel: A cryptographically authenticated and encrypted > > data connection established between (normally) adjacent ACP nodes > > to carry traffic of the ACP VRF secure and isolated from Data- > > Plane traffic in-band over the same link/path as the Data-Plane. > > > > nit: I'm not sure if "secure" or "securely" is better (but what does > > "secure from" mean?) > > securely sounds find. fixed. > I think its read ... "secure(ly)" and "isolated from". > > > > Enrollment: The process where a node presents identification (for > > example through keying material such as the private key of an > > IDevID) to a network and acquires a network specific identity and > > trust anchor such as an LDevID. > > > > nit: the LDevID is the identity; it's not a trust anchor. > > Fixed to: > > network specific identity such as an LDevID and trust anchors such as Certificate Authority (CA) certificate. > > > Section 5 > > > > 3. For each node in the candidate peer list, it authenticates that > > node (according to Section 6.1.2) and negotiates a mutually > > acceptable channel type. > > > > 4. For each node in the candidate peer list, it then establishes a > > secure tunnel of the negotiated type. The resulting tunnels are > > then placed into the previously set up VRF. This creates an > > overlay network with hop-by-hop tunnels. > > > > nit: the "channel type" of (3) is the "negotiated type" of the "secure > > tunnel" in (4), right? It might be nice to use the same word in > > both items, to help tie the language together. > > Changed to "negotiated channel type in 4". > > > Section 6 > > > > nit: "must have it's ACP domain certificate" gained an apostrophe in "it's" > > but the original "its" was correct. > > fixed. > > > Section 6.1 > > > > members. The LDevID is used to cryptographically authenticate the > > membership of its owner node in the ACP domain to other ACP domain > > members, the TA is used to authenticate the ACP domain membership of > > other nodes (see Section 6.1.2). > > > > nit: comma splice > > fixed (two sentences). > > > The ACP does not mandate specific mechanisms by which this keying > > material is provisioned into the ACP node, it only requires the > > Domain information field as specified in Section 6.1.1 in its domain > > certificate as well as those of candidate ACP peers. See > > > > nit: comma splice > > fixed (two sentences). > > > The ACP domain certificate SHOULD be used for any authentication > > between nodes with ACP domain certificates (ACP nodes and NOC nodes) > > where the required condition is ACP domain membership, such as ACP > > > > nit(?) I'd suggest s/required condition/required authorization > > condition/ > > fixed. > > > Section 6.1.1 > > > > The ABNF in Figure 2 seems to have multiple what I'll call for lack of a > > better term "terminal constructions" (i.e., routing-subdomain and > > domain-information) that are not used in other rules. Some text on > > which one is used in the rfc822Name and which is just informational for > > other purposes is probably in order. > > Added below figure: > > domain-information is the encoded information that is put into the ACP domain certificates subjectAltName / rfc822Name field. routing-subdomain is a string that can be constructed from the domain-information, and it is used in the hash-creation of the ULA (see below). The requirements and sementics of the parts of this information are explained in the following paragraphs: > > I think there are no more terminal name than those two. > > > o The maximum size of "domain-information" is 254 characters and the > > maximum size of node-info is 64 characters according to [RFC5280] > > that is referring to [RFC2821] (superseded by [RFC5321]). > > > > nit: I don't think we refer to node-info anywhere. > > s/node-info/local-part/ > > > On the topic of rfc822Name vs. otherName, I note that there's no > > requirement to use ASN.1 for the internal structure of the value; it's > > perfectly acceptable to make it an OCTET STRING and shove a > > more-friendly data structure in there. (It's a little bit weird in > > terms of mental models, but funny looks aside, it's pretty common.) If > > the other structure is fixed-length, there is not any actual ASN.1 > > knowledge required by the recipient; they just check that the length is > > right and the data starts with the correct fixed prefix (corresponding > > to the OID and ASN.1 length encoding), before processing the encoded > > data in whatever manner is appropriate. Since we want to put domain > > names in, fixed-length is probably out of the figure, but even if we're > > limited to what openssl provides, getting an ASN1_OCTET_STRING and > > extracting its contents to a pointer+length is pretty well established; > > we don't need to make people learn about ASN1_SEQUENCE() at all. So you > > could have the fundamental structure of the otherName be something like: > > > > 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +---------------------------------------------------------------+ > > | Flags |M|A| > > +---------------------------------------------------------------+ > > | | > > + + > > | | > > + [acp-address] + > > | | > > + + > > | | > > +---------------------------------------------------------------+ > > | rsub-len | rsub... | > > +------------------------------+ + > > ~ ~ > > +---------------------------------------------------------------+ > > | acp-domain-len | acp-domain... | > > +------------------------------+ + > > ~ ~ > > +---------------------------------------------------------------+ > > | [TLV extensions] | > > +---------------------------------------------------------------+ > > > > where M means that the holder of the cert is allowed to establish an ACP > > secure channel (what the '0' acp-address does in the present > > formulation) and A means that the acp-address field is present > > > > and just pack that into an OCTET STRING. > > > > Is the rfcSELF@acp.example.com email address for human use really > > providing much value? This is pretty clearly breaking an abstraction > > barrier, from my point of view. > > See above at the DISCUSS for my list of reasons to go with the rfc822name > encoding. Compared to your (more efficient) encoding, its specifically > about diagnostics and the ability for any existing certificarte tool to > correctly display a string for an existing field (rfc822name). What would > a randomn existing tool show a human for your field ? could i easily > copy & paste it, could i easily have a script put it into a list, > copy into excel spreadsheet (annoyingly enough we still live in a world > where we need to deal with humans and their preferences. We're trying to minize > what humans need to manage in ANIMA/ACP, but this is exactly the pieces they > will need to deal with whenever they troubleshoot). > > We wouldn't only have to redo the whole encoding into the certificate > as you proposed, but also come up with recommended standard representations for humans > to make it easy to operate across all type of tool chains where humans > are involved. Which could be the rfc822 representation because its > kinda nicely human logical ("node+tags@domain"...). > > > It also makes acp-domain-name a valid e-mail target across all > > routing-subdomains. > > > > nit: rfcSELF@acp-domain-name > > actually "domain-information", fixed. > > > o It should be possible to share the LDevID with other uses beside > > the ACP. Therefore, the information element required for the ACP > > should be encoded so that it minimizes the possibility of creating > > incompatibilities with such other uses. > > > > otherName with an ACP-specific OID has zero possibility of collisions > > with other uses; reusing rfc822Name has nonzero possibility of > > collision. (Note that having multiple otherNames is allowed.) > > Q1: Who allocates the OID ? > Q2: Could we put the currently domain-information into the otherName as a string ? > Q3: Would existing tools that deparse certificates human readable display > OtherNames that are string type (with e.g.: BER) ? > > > o The information for the ACP should not cause incompatibilities > > with any pre-existing ASN.1 software. This eliminates the > > introduction of a novel information element because that could > > require extensions to such pre-existing ASN.1 parsers. > > > > Even getting to the rfc822Name requires some level of ASN.1 parsing, so > > it's unclear how strong this argument really is. > > From what we discussed in the WG, all ASN.1 parsers people knew would > already be able to parse those defined fields, especially rfc822Name > > > > > o The element required for the ACP should not be misinterpreted by > > any other uses of the LDevID. If the element used for the ACP is > > interpreted by other uses, the impact should be benign. > > > > [OIDs are by construction unique] > > See Q1. > > > o At minimum, both the AN domain name and the non-domain name > > derived part of the ACP address need to be encoded in one or more > > appropriate fields of the certificate, so there are not many > > alternatives with pre-existing fields where the only possible > > conflicts would likely be beneficial. > > > > It's even possible to define multiple OIDs for otherName use, one for > > acp-domain-name, one for rsub, etc.. But that feels kind of like > > overkill to me. > > See above. I am a lot more partial to keep a easily human readable string > representation of the information than using rfc822Name. And i do not really > want to bother about two representations (human vs. machine) in this case. > > Not using rfc822Name would also give the ability to define a longer limit for > local-part which is my biggest worry when we're talking future extensions. > > > Section 6.1.2 > > > > 3: The peer's certificate passes certificate path validation as > > defined in [RFC5280] against one of the Trust Anchors associated > > with the ACP nodes ACP domain certificate (see Section 6.1.3 > > below). > > > > nit: "node's" possessive > > Fixed. > > > 4: If the node certificate indicates a Certificate Revocation List > > (CRL) Distribution Point (CDP) ([RFC5280], section 4.2.1.13) or > > Online Certificate Status Protocol (OCSP) responder ([RFC5280], > > section 4.2.2.1), then the peer's certificate must be valid > > according to those criteria: An OCSP check for the peer's > > certificate across the ACP must succeed or the peer certificate > > must not be listed in the CRL retrieved from the CDP. [...] > > > > side note: we could (but don't have to) note that OCSP stapling is a > > way to get an OCSP response to check. > > Right. thats why i fixed the text already via feedback to i think your first > round by adding that this only applies when the security association protocol > is incapable to carry the CDP/OCSP information itself. > > > 5: The peer's certificate has a syntactically valid ACP domain > > information field (encoded as subjectAltName / rfc822Name) and the > > acp-domain-name in that peer's domain information field is the > > same as in this ACP node's certificate (lowercase normalized). > > > > (Writing this as "has an otherName subjectAltName using the ACP OID" > > seems more concise to me, but I'll try to stop beating that horse.) > > ;-) Let me understand your answers to Q1...Q3 and also tell me what you > think about keeping the string ("looks like an email identity") enoding > but using your suggested field. > > > When an ACP node learns later via OCSP/CRL that an ACP peers > > certificate for which rule 4 had to be skipped during ACP secure > > channel establishment is invalid, then the ACP secure channel to that > > peer SHOULD be closed even if this peer is the only connectivity to > > access CRL/OCSP. The ACP secure channel connection MUST be retried > > periodically to support the case that the neighbor aquires a new, > > valid certificate. > > > > nit: we could probably tighten up the writing here about "MUST be > > retried periodically" in terms of needing to reestablish the TLS > > connection provisionally and repeat the initial connection steps, though > > on second read the current text seems better than I thought on first read. > > I will not take action against this comment as i am not clear what > the suggestion exactly is. Do you want me to try to cut the first sentence > into multiple smaller ones to make sound less like a german hold hostage by > the english language (or vice versa). > > > Only when checking a candidate peer's certificate for the purpose of > > establishing an ACP secure channel, one additional check is > > performed: > > > > nit: I'd suggest s/Only when/When/ > > Done. > > > Formally, the ACP domain membership check includes both the > > authentication of the peers certificate (steps 1...4) and a check > > authorizing this node and the peer to establish an ACP connection > > and/or any other secure connection across ACP or data-plane end to > > end. Step 5 authorizes to build any non-ACP secure connection > > between members of the same ACP domain, step 5 and 6 are required to > > build an ACP secure channel. For brevity, the remainder of this > > document refers to this process only as authentication instead of as > > authentication and authorization. > > > > I'd prefer to see a penultimate sentence along the lines of "Other > > authorization models are possible by local policy, but for this > > specification (and to some extent, autonomic systems in general), domain > > membership is deemed sufficient authorization for all operations." > > "_local_ policy" is in general a big no-no for us except where we can't avoid it, > so i better don't say "local" this without good reason. > > I also don't find this section specifically talking about ACP Domain membership > check the right place to say this. > > I did ad the following paragraph to the new section 6.1.1 about ACP domain certificates: > > Note that is no intention to constrain authorization within the ACP or autonomic networks using the ACP to just the ACP domain membership check as defined in this document. It can be extended or modified with future requirements. Such future authorizations can use and require additional elements in certificates or policies or even additional certificates. For example, see . > > Aka: that example in the appendix already is explaining our recognition > that for higher layers at least roles seem to be clearly needed to create > better security. Indeed the flag in the certificate for an EST server is > really just a speific example of such a role. Except that it seems to be > called "extended certificate usage" instead of role ;-). > > > Section 6.1.3 > > > > A certificate path is a chain of certificates starting at a self- > > signed certificate of a so called root-CA or Trust Anchor, followed > > > > nit(?): I'm used to seeing chain construction start at the > > leaf/end-entity and chain up to the root, but to some extent this is an > > editorial question. > > In routing and biology, trees start at the root, so pls. excuse my ignorance ;-) > > fixed to: > > A certificate path is a chain of certificates starting at > the ACP certificate (leaf/end-entity) followed by zero or more > intermediate Trust Point or sub-CA certificates and ending with > a self-signed certificate of a so called root-CA or Trust Anchor. > > > A single owner can operate multiple independent ACP domains from the > > same set of private trust anchors (CAs) when the ACP Registrars are > > trusted not to permit certificates with incorrect ACP information > > fields to be signed. Such as ACP information with a wrong acp-domain > > field. [...] > > > > nit: This last sentence is a sentence fragment (I suggest joining it to > > the previous one with a comma). > > Done. > > > Section 6.1.4 > > > > with its ACP domain certificate. When BRSKI (see > > [I-D.ietf-anima-bootstrapping-keyinfra]) is used, the ACP address of > > the BRSKI registrar from the BRSKI TLS connection SHOULD be > > remembered and used for the next renewal via EST if that registrar > > also announces itself as an EST server via GRASP (see next section) > > on its ACP address. > > > > IIUC, the BRSKI spec currently advertises BRSKI registrars with the > > EST-TLS objective, and I don't really understand how this interacts with > > SRV.est or whether this text should change. > > The equivalent to the SRV.est announcement is actually in BRSKI the > AN_join_registrar announcement. A registrar that does both BRSKI (initial > enrollment) and renewal (EST propoer) would send both announcements. > I think this text is fine. > > > Section 6.1.4.1 > > > > The objective name "SRV.est" indicates that the objective is an > > [RFC7030] compliant EST server because "est" is an [RFC6335] > > registered service name for [RFC7030]. Objective-value MUST be > > ignored if present. Backward compatible extensions to [RFC7030] MAY > > be indicated through objective-value. Non [RFC7030] compatible > > certificate renewal options MUST use a different objective-name. > > > > I'd consider adding some text about ignoring unrecognized > > objective-values, to attempt to preserve the usability of this extension > > point. > > Non-recognized objective-values (or parts thereof if it is a structure partially understood) MUST be ignored. > > > Section 6.1.4.3 > > > > The ACP node SHOULD support Certificate Revocation Lists (CRL) via > > HTTPs from one or more CRL Distribution Points (CDPs). The CDP(s) > > > > My understanding is that HTTP-not-s is commonly used for CRL > > distribution since the CRL content itself is signed, and there would be > > a risk of a circular dependency in validating the server's TLS > > certificate to get to the CRL information. > > Fixed. > > > HTTPs connections. The connecting ACP node SHOULD verify that the > > CDP certificate used during the HTTPs connection has the same ACP > > address as indicated in the CDP URL of the nodes ACP domain > > certificate if the CDP URL uses an IPv6 address. > > > > nit: "node's" possessive. > > fixed. > > > Section 6.1.4.5 > > > > enrollment. Using the ACP node's domain certificate allows the BRSKI > > registrar to learn that nodes ACP domain information field, so that > > > > nit: "node's" possessive. > > fixed > > > with its old ACP certificate. The re-enrolling candidate ACP node > > SHOULD only request a voucher from the BRSKI registrar when this > > authentication fails during TLS connection setup. > > > > I might suggest "SHOULD only fall back to requesting a voucher". > > fixed. > > > Section 6.1.4.6 > > > > An ACP domain certificate is called failing in this document, if/when > > the ACP node can determine that it was revoked (or explicitly not > > renewed), or in the absence of such explicit local diagnostics, when > > the ACP node fails to connect to other ACP nodes in the same ACP > > domain using its ACP certificate. For connection failures to > > > > nit: maybe "the ACP node to which the certificate was issued", since > > when I first read this I was expecting it to be about telling that some > > other node's certificate is failing, not a node's own certificate. > > fixed. > > > Section 6.5 > > > > At this time in the lifecycle of ACP nodes, it is unclear whether it > > is feasible to even decide on a single MTI (mandatory to implement) > > security association protocol across all ACP nodes. > > (This is a future-looking statement that implies uncertainty in the > > current spec.) > > Yikes. How did this sentence survive so long. > With all the other places pounding on the key thing > being to not mandate a single network wide MTI because there is sufficient > insight that it would be way too limiting. > > removed. Thanks a lot. > > > [11:C2] Node 2 certificate has lower ACP Node-ID than Node2, > > therefore Node 1 considers itself Bob and Node 2 Alice > > on connection C1, but they also identify that C2 is to the > > > > I think this first "Node 2" should be "Node 1"? > > Fixed. > > > interface" that they both connect to. An autonomic node must not > > assume that neighbors with the same L2 or link-local IPv6 addresses > > on different L2 interfaces are the same node. This can only be > > determined after examining the certificate after a successful > > security association attempt. > > > > This could potentially be a "MUST NOT". > > fixed. > > > Section 6.7.1.1 > > > > To run ACP via IPsec natively, no further IANA assignments/ > > definitions are required. An ACP node that is supporting native > > IPsec MUST use IPsec security setup via IKEv2, tunnel mode, local and > > peer link-local IPv6 addresses used for encapsulation. It MUST then > > support ESP with AES-256-GCM ([RFC4106]) for encryption and SHA256 > > hash and MUST NOT permit weaker crypto options. Key establishment > > MUST support ECDHE with P-256. > > > > I don't think "SHA256 hash" is quite specific enough (and we probably > > want GMAC for integrity anyway). > > In the answer to your i already changed this text to ENCR_AES_GCM_16. > The way i understand it (pls. help me if i am wrong), it comes with its > own integrity protection mechanism. Pls. check new text in 6.7.1.1 > > > Section 6.7.1.2 > > > > To run ACP via GRE/IPsec, no further IANA assignments/definitions are > > required. An ACP node that is supporting ACP via GRE/IPsec MUST then > > support IPsec security setup via IKEv2, IPsec transport mode, local > > and peer link-local IPv6 addresses used for encapsulation, ESP with > > AES256 encryption and SHA256 hash. > > > > Why is IPsec/GRE using AES256/SHA256 when IPsec native is using > > AES256-GCM? > > Error in duplication. New text from your and erics review > removes all duplication and has GRE just > refer to the native requirements and only explain changes. > > > Section 6.7.2 > > > > We define the use of ACP via DTLS in the assumption that it is likely > > the first transport encryption code basis supported in some classes > > of constrained devices. > > > > nit: I don't think "basis" is quite the right word, here; maybe "base" > > (or collapsed back to "codebase" as one word) or omit it entirely. > > deleted term. > > > Section 6.7.3 > > > > support DTLS. An ACP node connecting an area of constrained ACP > > nodes with an area of baseline ACP nodes MUST therefore support IPsec > > and DTLS and supports therefore the baseline and constrained profile. > > > > nit: this could probably work just fine as a non-normative "must", since > > it's just describing facts. > > fixed. > > > Section 6.8.2 > > > > nit: Figure 8 has a doubled word "ACP GRASP virtual virtual interfaces" > > in the second box from the top. > > > fixed > > > ............................................................... > > . | | | ^^^ Users of ACP (GRASP/ASA) . > > . | | | ACP interfaces/addressing . > > . | | | . > > . | | | A > > . | ACP-Loopback Interf.| <- ACP Loopback interface C > > . | ACP-address | - address (global ULA) P > > . subnet1 | subnet2 <- ACP virtual interfaces . > > . link-local | link-local - link-local addresses . > > ............................................................... > > > > I'm still a bit confused by this box in the figure -- is the "Users of > > ACP" label supposed to apply to the previous box(es) or the current one? > > If the former, it's confusing to see the "ACP security and transport > > substrate for GRASP" being described as a "user of ACP". > > Changed to "Users of ACP interfaces". > > Alas i have no more lines without breaking the picture onto multiple > pages in RFC TXT so i can not well try to carve out better space to > show where ASA sit (difficult as they would use both ACP interfaces > as well as some GRASP API. > > > GRASP unicast messages inside the ACP always use the ACP address. > > Link-local addresses from the ACP VRF must not be used inside > > objectives. GRASP unicast messages inside the ACP are transported > > via TLS 1.2 ([RFC5246]) connections with AES256 encryption and > > SHA256. Mutual authentication uses the ACP domain membership check > > defined in (Section 6.1.2). > > > > Just "AES256 encryption and SHA256" describes quite a few TLS > > ciphersuites > > (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4); > > I'd suggest limiting to a specific handful like > > > "TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and > > > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and > > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384" > > > (the "Recommended" column in > the registry will be helpful at picking things). > > It's probably also useful to specify a RSA/ECDSA key size (and elliptic > > curve for ECDSA) and the nature of the ECDHE or DHE. > > Can you please suggest recommended text here ? I spent a lot of reading > up on the whole IPsec/channel level especially also because you indicated > we would need other folks to help on IPsec, but i figure you would be > a good person to ask for TLS. > > Given how this is all new code, i see no reason to have mor than one MTI, > its also easy to override at application level (this would ahppen for > application scoped GRASP TLS connections). > > How about mandating LS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > > I have no idea how ECDHE are intermixed with RSA here, and what key sizes > we talk about - i hope the one from the cert, but the cert would only hae > one type of public key, ECDHE or RSA, right ? > > > Section 6.8.2.1 > > > > If GRASP peer connections would just use TCP, compromised ACP members > > could simply eavesdrop passively on GRASP peer connections for whom > > they are on-path ("Man In The Middle" - MITM). Or intercept and > > > > nit: I'd suggest "were to use just TCP". > > fixed. > > > modify them. With TLS, it is not possible to completely eliminate > > > > nit: sentence fragment > > merged with prior sentence. > > > > Section 6.10 > > > > Links inside the ACP only use link-local IPv6 addressing, such that > > each nodes ACP only requires one routable virtual address. > > > > nit: "node's" possessive. > > fixed. > > > Section 6.10.2 > > > > o Establishing connectivity between different ACP (different acp- > > domain-name) is outside the scope of this specification. If it is > > being done through future extensions, then the rsub of all > > routing-subdomains across those autonomic networks need to be > > selected so their hashes do not collide. For example a large > > > > nit: the grammar could be more clear that it's hash(routing-subdomain) > > that must be collision-free, rather than hash(rsub) > > Fixed to .. so the resulting routing-subdomain hashes.. > > > Section 6.10.7.2 > > > > information - ACP domain-name, ACP-address, and so on. If the ACP > > registrar uses BRSKI, it signals the ACP domain information field to > > the Pledge via the EST /csraddrs command (see > > [I-D.ietf-anima-bootstrapping-keyinfra], section 5.8.2 - "EST CSR > > Attributes"). > > > > I don't see a "csraddrs" EST well-known URL in either BRSKI or RFC 7030 > > (and the section number is probably stale as well, as the RFC Editor > > note attests). Oh, but /csrattrs is very close, so this is likely just > > a typo. > > fixed to csrattr, section now 5.9.2 in brski-22 > > > Section 6.10.7.3 > > > > scheme. The first address of the prefix is the ACP address, all > > other addresses in the prefix are for other uses by the ACP node as > > described in the zone and Vlong addressing sub scheme sections. The > > > > nit: comma splice > > fixed. > > > policy. For example, in BRSKI, the ACP registrar is aware of the > > IDevID of the candidate ACP node, which contains a serialNnumber that > > is typically indicating the nodes vendor and device type and can be > > > > nits: "serialNumber", "node's vendor" possessive > > fixed > > > > > ACP registrars SHOULD default to allocate ACP zone sub-address scheme > > addresses with Subnet-ID 0. Allocation and use of zone sub-addresses > > with Subnet-ID != 0 is outside the scope of this specification > > > > nit: it's only referred to as "Subnet-ID" in the manual addressing > > sub-scheme; for the zone addressing sub-scheme it's "Zone-ID". > > > > *yikes*. Good catch. There was one more further down of this mistake. > fixed. > > > Section 6.11.1.1 > > > > Additionally, failed ACP tunnels can be quickly discovered the secure > > channel protocol mechanisms such as IKEv2 Dead Peer Detection. This > > > > nit: missing word, maybe "through the secure channel protocol" > > fixed. > > > Section 6.11.1.9 > > > > [RFC6550] security not used, substituted by ACP security. > > > > Because the ACP links already include provisions for confidentiality > > and integrity protection, their usage at the RPL layer would be > > redundant, and so RPL security is not used. > > > > The ACP links provide only hop-by-hop security, but it looks like at > > least some of the RFC6550 mechanisms provide more global source > > authentication. (I'm not suggesting we change the protocol to use RPL > > security, just noting that this text is not quite right about being > > entirely redundant.) > > I really have no idea. I had these profile template points be filled > out by Pascal Thubert, so i would assume it is correct. I forwarded > the nit to him, let's see what he says. > > > Section 6.11.1.14 > > > > I still think it's worth calling out that the RPL root is not > > necessarily preconfigured and this "SHOULD" requirement could > > potentially apply to any node, but this is only Comment-level and you > > should feel free to ignore it. > > Check the paragraph i inserted into the section for your first review email > talking about how this does not apply to nodes supporting only > "default" administrative preference. Hope this is a good trick to > aleviate the need for forwarding plane enhancemeents on that wouldn't > never become root in a network operating in a state where this diagnostic > function would be useful. > > > Section 6.12.5 > > > > Care must also be taken when creating multi-access ACP virtual > > interfaces across ACP secure channels between ACP nodes in different > > domains or routing subdomains. The policies to be negotiated may be > > described as peer-to-peer policies in which case it is easier to > > create ACP point-to-point virtual interfaces for these secure > > channels. > > > > nit: the text is unclear about what sort of policies are being > > negotiated. > > Changed sentence to: > If for example future inter-domain ACP policies are defined as "peer-to-peer" policies, it is easier to create ACP point-to-point virtual interfaces for these inter-domain secure channels. > > > Section 8.1.1 > > > > When an ACP Edge node receives a packet from an ACP connect > > interface, it MUST only forward it intot he ACP if it has an IPv6 > > > > nit: "into the" > > fixed. > > > Section 9.1 > > > > when using OCSP/CRL. The same benefit can be achieved when using > > CRL/OCSP, periodically refreshing the revocation information and > > also tearing down ACP secure channels when the peers (long-lived) > > certificate is revoked. There is no requirement against ACP > > > > nit: "peer's" possessive > > fixed. > > > partition is left with one or more of such ACP registrars, it can > > continue to enroll new candidate ACP nodes as long as the ACP > > registrars sub-CA certificate does not expire. Because the ACP > > > > nit: "registrar's sub-CA" possessive > > fixed. > > > Section 9.2.2 > > > > not the Data-Plane. Especially for those management plane functions > > that have no good protection by themselves because they do not have > > secure end-to-end transport and to whom ACP does not only provides > > automatic reliable connectivity but also protection against attacks. > > > > nit: s/does not only/not only/ > > fixed > > > Section 9.3 > > > > An ACP is self-forming, self-managing and self-protecting, therefore > > has minimal dependencies on the administrator of the network. > > Specifically, since it is (intended to be) independent of > > configuration, there is no scope for configuration errors on the ACP > > itself. The administrator may have the option to enable or disable > > > > nit: Given that Section 8.2.1 talks about configuring ACP neighbors and > > 8.2.2 about configuring tunneled neighbors, I'd suggest to s/no > > scope/only limited scope/, > > fixed. > > > and perhaps similar tweaks in the following paragraphs. > > fixed to. > > While configuration (except for and ) is not possible > > > Section 10.1 > > > > o Check the validity of the domain certificate: > > > > * Does the certificate authenticate against the trust anchor? > > > > nit: s/authenticate/validate/ > > fixed. > > > - The neighbors certificate does not have the required > > trust anchor. Provide diagnostics which trust anchor it > > has (can identify whom the device belongs to). > > > > - The neighbors certificate does not have the same domain > > (or no domain at all). Diagnose domain-name and > > potentially other cert info. > > > > - The neighbors certificate has been revoked or could not > > be authenticated by OCSP. > > > > - The neighbors certificate has expired - or is not yet > > valid. > > > > nit: s/neighbors/neighbor's/ (every time) > > fixed > > > Section 10.2.2 > > > > For BRSKI or other mechanisms using vouchers: Parameters to > > determine how to retrieve vouchers for specific type of secure > > bootstrap candidate ACP nodes (such as MASA URLs), unless this > > information is automatically learned such as from the LDevID of > > candidate ACP nodes (as defined in BRSKI). > > > > I thought the LDevID was essentially synonymous with "ACP domain > > certificate" in this document, so I can't understand what this means > > (unless IDevID was intended). > > Yes, this and i think one or two more typos LDevID -> IDevID where fixed > already for your first review email. > > > Section 10.2.3 > > > > Even when such a malicious ACP registrar is detected, resolving the > > problem may be difficult because it would require identifying all the > > wrong ACP domain certificates assigned via the ACP registrar after it > > was compromised. And without additional centralized tracking of > > assigned certificates there is no way to do this. > > > > side note: RFC 6962-style certificate transparency is a somewhat > > decentralized way to do such tracking, though I do not think the > > engineering tradeoffs favor trying to use it for this situation. > > Interesting RFC. i pondered adding a reference to it, because some of the > actual logging data structures seems quite useful, but the openness model > would very likely scare operators off ("ACP makes me public how > many and what nodes my network has ??? go away"). > > > Section 10.2.5 > > > > Which candidate ACP node is permitted or not permitted into an ACP > > domain. This may not be a decision to be taken upfront, so that a > > per-serialNumber policy can be loaded into ever ACP registrar. > > > > nit: "every" > > fixed. > > > Section 10.3.x > > > > I still think the document quality here is not as mature as the majority > > of the document, though concede there is value in covering these topics > > to some extent in the initial work. > > Copied from reply to your first mail: > > Not sure how i could bake it better, but it would probably not be worth it > in this document, given how this is mostly food for thought not impacting > interoperability and standardization would only come through implementation > and deployment experimentation followed by some Yang model. Other reviewers > (Joel if i remember correctly) where grumbling, but couldn't provide any better > suggestions of how to make operator level interface shutdowns more resilient against > unintential network disconnect. Hence i argued strongly to keep this section in there > as important food for thought, especially because its been the #1 ask against ACP to > figure out by operators i talked to. > > > Section 10.3.5 > > > > interface level "ACP/ANI enable" is ignored. Once set, ACP/ANI will > > operate interface where "ACP/ANI enable" is set. Setting of > > > > nit: "operate on interfaces where" > > fixed > > > Section 10.3.5.1 > > > > Automatically setting "ANI enable" on brownfield nodes where the > > operator is unaware of it could also be a critical security issue > > depending on the vouchers used by BRKSI on these nodes. An attacker > > could claim to be the owner of these devices and create an ACP that > > the attacker has access/control over. In networks where the operator > > explicitly wants to enable the ANI this could not happen, because he > > would create a BRSKI registrar that would discover attack attempts. > > Nodes requiring "ownership vouchers" would not be subject to that > > attack. See [I-D.ietf-anima-bootstrapping-keyinfra] for more > > details. Note that a global "ACP enable" alone is not subject to > > these type of attacks, because it always depends on some other > > mechanism first to provision domain certificates into the device. > > > > It's probably worth double-checking that all of these details are still > > synchronized with RFC 8366 and the current state of BRSKI. > > Yepp. Nothing changed as this is very fundamental, but i still rewrote the > paragraph somewhat to better express the main concern, which is that > an operator with no clue what BRSKI/MASA is even though his devices support it > would not attempt to get an account at the MASA and that opens the door > to attackers to easier do some form of identity theft > > "Frank, we got a letter from our router-vendor with techno-mumbo-jumbo-masa-account", > "oh, no idea, we're not using that stuff. throw it in the trash bin". > > And then someone who did forge the request to get the account for the company > goes through that company's trash. > > > Section 10.3.6 > > > > Disabling ANI/ACP by undoing "ACP/ANI enable" is a risk for the > > reliable operations of the ACP if it can be executed by mistake or > > unauthorized. This behavior could be influenced through some > > additional property in the certificate (e.g., in the domain > > information extension field) subject to future work: In an ANI > > > > [I don't know if it was intentional or an omission to leave this "future > > work" note in place when most others were removed.] > > I only got rid of all "future" in the normative part, which didn't > only consist of removing the word, but moving text out of the normative section > referring to this - and this is where such text ended up being (non-normative). > > Consider this 10.3.x stuff to be staging for hopefully something we would > put into YANG in followup work (and as in this case extensions to the cert). > (unless we define operator interfaces via YANG, we can't standardize them anyhow). > > > Section 10.4 > > > > There is no desirable configuration for the ACP. Instead, all > > parameters that need to be configured in support of the ACP are > > limitations of the solution, but they are only needed in cases where > > not all components are made autonomic. Whereever this is necessary, > > it will rely on pre-existing mechanisms for configuration such as CLI > > > > "will rely on" can also be seen as an indicator for future work. > > In this case i was just thinking about the future as implementations of this > spec, not future features. So i reworded to "it relies on". > > > > > o When the ACP needs to be extended across interfacess other than > > L2, the ACP as defined in this document can not autodiscover > > candidate neighbors automatically. Remove neighbors need to be > > configured, see Section 8.2. > > > > nit: s/Remove/Remote/ > > fixed. > > > Once the ACP is operating, any further configuration for the data- > > lane can be configured more reliably across the ACP itself because > > > > nit: data-plane > > fixed before. > > > Section 11 > > > > o Every ACP registrar is criticial infrastructure that needs to be > > hardened against attacks similar to a CA. A malicious registrar > > > > nit: as written, this parses as saying that the attacks are similar to a > > CA, not the amount of hardening needed on the ACP registrar. Adding a > > comma would probably help. > > fixed. > > > The ACP It is designed to enable automation of current network > > management and future autonomic peer-to-peer/distributed network > > > > s/It // > > fixed. > > > Attacks from impacted ACP nodes against the ACP are more difficult > > than against the data-plane because of the autoconfiguration of the > > ACP and the absence of configuration options that could be abused > > that allow to change/break ACP behavior. This is excluding > > configuration for workaround in support of non-autonomic components. > > [...] > > The ACP acts as a security (and transport) substrate for GRASP inside > > the ACP such that GRASP is not only protected by attacks from the > > outside, but also by attacks from compromised inside attackers - by > > relying not only on hop-by-hop security of ACP secure channels, but > > adding end-to-end security for those GRASP messages. See > > Section 6.8.2. > > > > This is true, but the system as a whole still has the weakness that the > > compromised node is able to announce GRASP objectives for arbitrary > > services and potentially cause legitimate traffic to be directed towards > > it. The connection would still validate (until the certificate > > expires or is revoked) and the attacker could return bad data that > > causes honest nodes to misbehave. > > Yes. For non-autonomic networks such as those we target via rfc8368, > i think we can most easily solve this problem easily via cert bits for Roles (A.10.5), > so only NOC equipment can announce services. > > Note that this was traditionally not a real issue which is why we didn't wanted > to add all these aspects to certs initially: you would have > a real hard time to get new attack software into a typical legacy HW network infra. > You'd have to attack by adding new hardware that has the software. Of course, > in the last 5 years (after we started this *sigh*) network infra components > become a lot more like PCs, so adding software becomes easier and hence also > attacks from such software. And i fear that even though secure boot etc. exists, > the security chains there are not necesssarily very strong. > > More fully distributed, self-organizing "Autonomic" solutions of course will > be tougher. I would be happy if we can show that the security shell provided > by the ACP and secure router platforms would be strong enough that there is > enough room for starting to deploy more distributed services management > without necessarily having to figure out upfront how to build self-organizing higher > levels of security such as through self-learning reputation sccoring or the > like. There is just a difference between what would be fun to do, and what i > as an operator would be willing to accept as baked enough at any point in time ;-) > > > revocation and non-renewal of short-lived cdrtificates. In this > > > > nit: "certificates" > > fixed. > > > Section A.6 > > > > In my opinion, a lot of this could be split out into a separate draft > > (that need not be published as an RFC) and just a couple paragraphs left > > here with a pointer to that separate draft. But this is only a > > Comment-level point, and I do not insist on it. > > Hah. In the other reply i gave you i think i referred to this text as already removed, > but i forgot that the idea was to remove it before publication. So now i > added the two notes to the top of this section: > > [RFC Editor: This section to be removed before RFC. > [This section kept for informational purposes up until the last draft version as that would be the version that readers interested in the changelog would also go to to revisit it.] > > E.g.: I think its hard to justify putting more time (like separate RFC) > into something that should be called "leftover ramblings from when we worked > out the ACP, that we really should not forget". > > Going up to last draft seems like a low-cost compromise. > > Btw: Its nice you didn't say this is crazy, because as i mentioned in the other > mail, the WG conclusion was that this type of multi-stage negotiation would be > way too complex (hence also the removal). ;-) > > > Section A.7 > > > > An ACP domain is the set of all ACP nodes using certificates from the > > same CA using the same domain field. GRASP inside the ACP is run > > across all transitively connected ACP nodes in a domain. > > > > It's not entirely clear to me that we need to insist on a single shared > > CA; given our discussion of potentially joining two distinct ACT domains > > into a combined network, it seems that we just need to have all nodes > > using the same set of trust anchor(s), which could potentially include > > multiple CAs. (There would of course need to be some out-of-band > > mechanism to avoid address-assignment collisions, which could be as > > simple as rsub.) > > "from one or more Trust Anchors (TA) (typically one CA)" > > > Section A.8 > > > > For example, Intent could indicate the desire to build an ACP across > > all domains that have a common parent domain (without relying on the > > rsub/routing-subdomain solution defined in this document). For > > example ACP nodes with domain "example.com", "access.example.com", > > "core.example.com" and "city.core.example.com" should all establish > > one single ACP. > > > > It is interesting to see this discussion in the context of the text in > > the previous section about """If different ACP domains are to be created > > [...] Domains "example.com" and "research.example.com" are separate > > domains if both are domain elements in the domain information element of > > certificates.""" > > Because this document doesn't intend to fnish working this out, its in appendices ;-) > > > Section A.8 > > > > There still feels like a lot of speculative things in here; I'd suggest > > adding a disclaimer/introduction at the top that "Intent is the > > architecture component [...]. Its applicability for use is quite > > flexible and freeform, with potential applications including:" > > Its applicability for use is quite flexible and freeform, with potential applications including policies flooded across ACP GRASP and interpreted on every ACP node. > > i like "flexible and freeform" as a euphemism for > "unclear, undefined and ongoing contentuous" ;-)) > > But yes, once we come up with specific policies we want to get standardized, > we'll figure out a fitting way to do it, and thats what we then call Intent ;-) > > > Section A.9 > > > > Some solutions may already have an auto-addressing scheme, for > > example derived from existing unique device identifiers (e.g., MAC > > addresses). In those cases it may not be desirable to assign > > addresses to devices via the ACP address information field in the way > > described in this document. The certificate may simply serve to > > identify the ACP domain, and the address field could be empty/unused. > > The only fix required in the remaining way the ACP operate is to > > define another element in the domain certificate for the two peers to > > decide who is Alice and who is Bob during secure channel building. > > > > I think we need to mention this requirement for tiebreaking earlier in > > the document, when we introduce the possibility of a certificate with > > ACP address of '0'. > > The "0" address ACP nodes are not allowed to build secure channels, > they are for ACP-connect'ed nodes in the NOC (i added that explanation > through the reply to your first review email). > > The ++ = no-address ACP addresses are the ones that this spec does > not define but supports interop with (by defining the address format). > Added to the channel selection text in 6.5: > > A peer with an empty ACP address field in its ACP domain certificate becomes Bob (this specification does not define such peers, only the interoperability with them) > > In other words: I do not know nor care yet how to decide on Alive vs. Bob > when both peers have no ACP address in their certificate. Subject to > future work. > > > Section A.10 > > > > nit: the section title uses "futures" as a standalone term synonymous > > with "future work"; unfortunately, "futures" is already an English word > > with a quite distinct meaning. > > Changed to: "Further (future) options" > > I could sell you some A.10.7 options, sure they will go up in value ;-) > (is that what you meant ?). > > > Section A.10.7 > > > > 1. Consider if LLDP should be a recommended functionality for ANI > > devices to improve diagnostics, and if so, which information > > elements it should signal (insecure). Includes potentially new > > information elements. > > > > I'd suggest changing the parenthetical to "noting that such information > > is conveyed in an insecure manner)". > > Fixed. > > > 3. The IDevID of BRSKI pledges should be included in the selected > > insecure diagnostics option. > > > > In some environments (not really the current target case of Enterprise > > networks) the IDevID would be considered privacy-sensitive, which may be > > worth mentioning again here. > > Hmm. i went with a security example (which is arguably one reason for the desire of privacy, but i think many readers would associate privacy mostly with humans, so would be harder to read by some): > > This may be undesirable when exposure of device information is seen as too much of a security issue (ability to deduce possible attack vectors from device model for example) > > I also added a similar note to the end of the paragraph in 6.1.1 about certificates: > > Any other field of the ACP domain certificate is to be populated as required by or desired by the operator of the ACP domain ACP registrars/CA and required by other purposes that the ACP domain certificate is intended to be used for. For diagnostic and other operational purposes, it is beneficial to copy the device identifying fields of the node's IDevID into the ACP domain certificate, such as the "serialNumber" (see section 2.3.1). Inclusion of this information makes it easier to potentially attack the node though, for example by learning the device model, which may help to select a fitting subset of attacks. Neighboring attackers can retrieve the certificate through an otherwise unsuccessful initiation of a secure channel association. > > > Section A.10.8 > > > > Ensuring that manaement sessions using invalidated credentials are > > > > typo: "management" > > Fixed. From nobody Tue Dec 31 11:38:08 2019 Return-Path: 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 9EB1A120047; Tue, 31 Dec 2019 11:37:59 -0800 (PST) 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 R5aq0dW3jIoq; Tue, 31 Dec 2019 11:37:57 -0800 (PST) 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 42C31120026; Tue, 31 Dec 2019 11:37:57 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3C29138981; Tue, 31 Dec 2019 14:37:41 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A62C83FE; Tue, 31 Dec 2019 14:37:55 -0500 (EST) From: Michael Richardson To: tom petch cc: Alissa Cooper , IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <5DF90E0C.9020603@btconnect.com> References: <157123777786.7830.10713306244839546046.idtracker@ietfa.amsl.com> <9637.1574756997@localhost> <2FA2728E-6484-4A69-992A-479D8053354E@cooperw.in> <20062.1576526178@localhost> <5DF90E0C.9020603@btconnect.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 Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 19:38:00 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain A diff against -31 is at: https://tinyurl.com/vuls2ge and will grow to include my responses to Ben's 2019-12-20 comments later today. tom petch wrote: > Yes you have removed the second YANG module which addresses my comments > about the second YANG module but my other comments mostly remain. > Those about the YANG prefix are fixed. > RFC8040 needs to be in the I-D References > IANA Considerations mentions the removed module but lacks the two > required actions for the remaining module I understand now. I wonder if idnits could be taught to find such issues :-) Please see commit: https://github.com/anima-wg/anima-bootstrap/commit/75d7ef8a78b2c03cd2e558705861194357f1e643 > XXXX is used as a place holder for a document name which is not that of > this I-D and does not exist AFAICT Do you mean the self-reference should say "XXXX"? I have used "THIS DOCUMENT" in the past. > The YANG module must be plain text - [RFC8446] looks like HTML/XML I'm confused by this comment. I see: > Michael, my initial posts were a response to the Genart review and so > did not include your name, just Anima, Anima chairs, ibagdona, IETF; > you are in this one as mcr+ietf@sandelman.ca (but IETF mailers may have > a habit of thinking you will get an e-mail via one way and suppress > other ways with different e-mail addresses). Yes, I wasn't complaining about your actions, but more just lamenting: my impression is that the problem is that DMARC is getting in the way, since the DT acts as a remailer. However, btconnect.com has a p=none policy, so it shouldn't be a problem... however, maybe it fails the SPF tests themselves. {I was forced to switch spam processing systems in the spring, and it really has been a PITA to get it configured sensibly. Very few of them support IPv6, and a surprising number of them will not use TLS for final delivery. I specifically need to whitelist everything coming from the IETF SMTP machine, and I don't think I've accomplished that perfectly yet.} leaf proximity-registrar-cert { type binary; description "An X.509 v3 certificate structure as specified by RFC 5280, Section 4 encoded using the ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690. The first certificate in the Registrar TLS server certificate_list sequence (the end-entity TLS certificate, see [RFC8446]) presented by the Registrar to the Pledge. This MUST be populated in a Pledge's voucher request when a proximity assertion is requested."; } I'm not sure I see how you are seeing HTML here. If you are looking at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-31#section-3.4 then the links you are saying are because the HTMLizer sees the reference and HTMLizes it. > Security Considerations lacks the required boiler plate for a YANG > module I see. I have adapted the text from RFC8366, as we extend it, and the normal template does not apply. Fixed in commit: https://github.com/anima-wg/anima-bootstrap/commit/c138bbd24db038f0704770b545e74ba202a98e4e > Appendix A still has a typo secification -> specification. plege->Pledge. --=-=-= Content-Type: text/plain Content-Disposition: inline Content-Description: Signature -- ] 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 [ --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4Lo5MACgkQgItw+93Q 3WUfGAf/bt4+t+GaAW6SU+ofD0mOVQcY7RRKvpuHMZDr2xAaejSTuAUEqWLAKTG6 Di4Lr2u1JslyiwR9u8gweramapuf7zpCyGGNCDhOUqIJiNONjjXx1K/Y5bSdtCgD 70Bo1Nw8BZAi9DGCayg3WgHRLqtMU0M8/PBNDf4q+HjgFFiigEEpPqhQPnWCZs2D 1qh2jnbZX50FnfHEbDWNvrH4G/Q95xtPqMyxsvZzzYLz0b1UNYo3gIJlOtj7QHDj XPfUDzE7Sacoh4TuWm6r/2MCmWBZ1+NrZDkglqb/khqbQVc4UqCdXQeco8JK+UEY KN76TUzQnq1Aq4jeMLAGS69isE2Ulw== =zfQG -----END PGP SIGNATURE----- --==-=-=-- From nobody Tue Dec 31 12:06:53 2019 Return-Path: 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 EFC7412004E for ; Tue, 31 Dec 2019 12:06:51 -0800 (PST) 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 3Z8X4esaf7Nt for ; Tue, 31 Dec 2019 12:06:50 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69DBD120047 for ; Tue, 31 Dec 2019 12:06:50 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7CE6C38981 for ; Tue, 31 Dec 2019 15:06:34 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E16FA3FE for ; Tue, 31 Dec 2019 15:06:48 -0500 (EST) To: anima@ietf.org References: <20191229165322.81440F406C5@rfc-editor.org> From: Michael Richardson Message-ID: <6351efe7-668b-480d-5d94-425341f13d07@sandelman.ca> Date: Tue, 31 Dec 2019 15:06:48 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20191229165322.81440F406C5@rfc-editor.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] [Editorial Errata Reported] RFC8366 (5949) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 20:06:52 -0000 On 2019-12-29 11:53 a.m., RFC Errata System wrote: > The following errata report has been submitted for RFC8366, > "A Voucher Artifact for Bootstrapping Protocols". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5949 > > -------------------------------------- > Type: Editorial > Reported by: Tetsuya Hasegawa > > Section: 5.1. > > Original Text > ------------- > 7. Devices that support decrypting SZTP artifacts MUST posses the > > Corrected Text > -------------- > 7. Devices that support decrypting SZTP artifacts MUST possess the > Looks correct to me. Chairs, I think you can approve this. From nobody Tue Dec 31 12:07:24 2019 Return-Path: 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 7766C120052 for ; Tue, 31 Dec 2019 12:07:22 -0800 (PST) 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 DSh84Wm3JPG8 for ; Tue, 31 Dec 2019 12:07:21 -0800 (PST) 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 2C422120047 for ; Tue, 31 Dec 2019 12:07:21 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A973538981 for ; Tue, 31 Dec 2019 15:07:05 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 248183FE for ; Tue, 31 Dec 2019 15:07:20 -0500 (EST) To: anima@ietf.org References: <5D36713D8A4E7348A7E10DF7437A4B9299D13579@NKGEML515-MBX.china.huawei.com> From: Michael Richardson Message-ID: Date: Tue, 31 Dec 2019 15:07:20 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9299D13579@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] ANIMA minutes - IETF106 Singapore X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 20:07:22 -0000 On 2019-12-25 10:43 p.m., Sheng Jiang wrote: > Hi, all, > > The minutes for the ANIMA sessions at IETF106 in Singapore be found at: > > https://datatracker.ietf.org/doc/minutes-106-anima/ I read the minutes, and I concur with them. From nobody Tue Dec 31 12:16:00 2019 Return-Path: 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 80052120013; Tue, 31 Dec 2019 12:15:58 -0800 (PST) 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 lfpRs3C-B_hf; Tue, 31 Dec 2019 12:15:56 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D707912001E; Tue, 31 Dec 2019 12:15:55 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1E52438981; Tue, 31 Dec 2019 15:15:40 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A6E423FE; Tue, 31 Dec 2019 15:15:53 -0500 (EST) From: Michael Richardson To: Benjamin Kaduk cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <157688107174.4079.10454309821544008060.idtracker@ietfa.amsl.com> References: <157688107174.4079.10454309821544008060.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 Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-31: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 20:15:58 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain A diff against -31 is at: https://tinyurl.com/vuls2ge and will be posted as -32 in a few minutes. Commit with edits here: https://github.com/anima-wg/anima-bootstrap/commit/0bdd9aaf206b0f2d70c51a7c9636a8249fd1366f BTW: I haven't heard from Roman since IETF107. I am also converting to v3 format now, so there are some slight formatting changes. (*->o, some extra spaces in places) I have addressed all of your comments, and I've checked that all the -29 comments have been addressed. Benjamin Kaduk via Datatracker wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > Thanks for providing a clear specification of the /enrollstatus EST > endpoint in the -30. The following two points still seem unaddressed, > though. > The -29 reworks the definition of the 'nonce' field to be: > strong random or pseudo-random number nonce (see [RFC4086] > section 6.2). As the nonce is usually generated very early in the boot > sequence there is a concern that the same nonce might generated across > multiple boots, or after a factory reset. Difference nonces MUST NOT > generated for each bootstrapping attempt, whether in series or > concurrently. The freshness of this nonce mitigates against the lack > of real-time clock as explained in Section 2.6.1. > This needs to either be "Different nonces MUST be generated" or "the > same nonce MUST NOT be reused"; this mashup is no good. Fixed. > Email exchange with mcr notes: >> > An RFC Editor note about the RFC 8366 assignment of OID > >> 1.2.840.113549.1.9.16.1.40 was removed from -23 to -28; do the >> examples > properly use that assigned OID now? >> >> We got a MASA URL Extension OID for: 1.3.6.1.5.5.7.1.32 >> >> the examples date from before that, and do not use it yet. > We need to fix the examples before publication. Yes, I believe that there will be time to update them while in RFC editor queue. I want the examples to be produced by code that has interoperated. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > A few new comments on the -30 and -31 to start. I think some of my > comments on the -29 are still valid, and will try to remove ones that > have been addressed. To reiterate: to the best of my knowledge, all > the comments in this ballot position are actionable and have not been > overtaken by events. okay. > In Section 5.9.4: > In the case of a FAIL, the same TLS connection MUST be used. The > Reason string indicates why the most recent enrollment failed. > I'd suggest something more like "In the case of a failed enrollment, > the client MUST send the telemetry information over the same TLS > connection that was used for the enrollment attempt, with a Reason > string indicating why the most recent enrollment failed. (For failed > attempts, the TLS connection is the most reliable way to correlate > server-side information with what the client provides.)" (Also, why is > "FAIL" capitalized?) I have used your text. The fail was capitalized because bold is not available. Further down, we capitalize SUCCESS. > Thanks for the text in Section 11.2 about second-preimage-resistance of > DomainID calculation; the grammar needs a tweak or two, though. My > suggestion would be to either drop "The consequences of" or add "be to" > to make "would be to allow" (but not both). Done. > Section 11.3 has gone back to just "Devices which are reset to factory > default in order to perform a second bootstrap with a new owner MUST > NOT use idential seeds", but I think it's important to be clear about > what the scope of uniqueness is. The text in Section 5.2 is pretty > good in this regard, with respect to the nonces (which are generally > derived from the seed); I wonder if we might want to restructure this > text to be more like "The random seed used by a device at boot MUST be > unique across all devices and all bootstraps. Resetting a device to > factory default state does not obviate this requirement." (FWIW, I > think the text in the -29 was that way because of my request.) Done. > In Section 3.3, we now cite RFC 4648; I note that RFC 4648 specifies > both base64 and base64url, so a section reference is usually > appropriate (and in Section 5 we do give a section reference into RFC > 4648). okay, section 4 is "base64", added. > Section 9.1 > Other use cases likely have similar, but MAY different requirements. > nit: ", but MAY have different, requirements" fixed. > Section 9.1.1 > Authentication process. The MASA creates signed voucher artifacts > according to a it's internally defined policies. > nit: s/a it's/its/ fixed. > Section 9.1.3 > (Do we need to say "DULL" specifically again here for Join Proxy > discovery? Maybe not...) yes, I think that we need to say this again, as many people get upset about having a full GRASP daemon visible on the insecure side. > [All new comments for the -28] rechecking. > Please respond to the secdir re-review. This is in message: to recap: 1) 10.3, "The so-called "call-home" mechanism that occurs as part of the was toned down. 2) the TLS 1.3 text was already improved. 3) section 5.4.1, "This document does not make a specific recommendation" (regarding whether to use public PKI, DANE, or pinned certificates for MASA authentication. I don't think we can make a statement about the needs here at this point, and why we have the PS->IS step. Note that I wrote https://datatracker.ietf.org/doc/draft-richardson-anima-registrar-considerations/ > Section 2.6.1 > A pledge with a real time clock in which it has confidence in, MUST > check the above time fields in all certificates and signatures that it > processes. > nit: s/in// from "in which it has confidence in" (your choice which > one). I see now, fixed. > Section 4 > This section applies is normative for uses with an ANIMA ACP. The > nit: pick one of "applies to" or "is normative for". already fixed. > [...] The use of GRASP mechanism part of the ACP. Other users of > BRSKI will need > nit: missing "is", "the" fixing. > Section 5.7 > The Status field indicates if the voucher was acceptable. Boolean > values are acceptable. > nit: I suggest """acceptable, as a boolean, where "true" indicates the > voucher was acceptable""". already fixed. > Section 10.6 > Section Section 7.4.3 describes some ways in which a manufacturer > nit: duplicate "Section". already fixed. > Section 10.7 > existing products. Said products might be previous deployed and > need to be re-initialized, purchased used, or just kept in a warehouse > as long-term spares. > nit: s/previous deployed and need/previously deployed that need/ already fixed. > Section 11.2 > In particular implementations should pay attention to the advance in > [RFC4086] section 3, particulary section 3.4. Devices which are reset > to factory default in order to perform a second bootstrap with a new > owner MUST NOT seed their random number generators in the same way. > nit: s/same way/same way across bootstraps/ already fixed with different text. > Section 11.3 > We had some discussion around my previous comment: > % Additionally, in order to successfully use the resulting voucher the > % Rm would have to attack the pledge and return it to a bootstrapping % > enabled state. This would require wiping the pledge of current > % > % ... and I think there is a different attack if the Rm is in a > position % to delay or drop network traffic between the pledge and the > intended % registrar, to cause Rm's voucher to be delivered first even > though it is % generated after the intended registrar's authorization > process. The % intended registrar would need to require reports on > voucher processing % status (or investigate their absence) in order to > detect such a case. > but I can't remember if we decided that we didn't need to discuss the > risk in the document. [ed. I also can't remember if we had discussion > about this comment] We did. We worked hard to create the Rm attack situation, and had to assume some other failures to even get to this discussion. I think that this follows into the "if these ten unlikely things all occur, then you should consider if you are living in simulation" category. > ======================================================================= > I trimmed all the "Additional comments since posted ballot position on > -28" that were in my previous ballot position, as they are likely stale > by now. Thank you. --=-=-= Content-Type: text/plain Content-Disposition: inline Content-Description: Signature -- ] 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 [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4LrHkACgkQgItw+93Q 3WUYKggAwXJKoyWBaUkCajsOdxh5G/oC69hwFHZWkTpmiiZlbPBtlClhznq26jV/ CDFX4ICHHYR1ft42MHoh0XJeUSsTaEyahLmEJW25MZnFnvNfj5w9qkLeTdcAtgHg 8lJQUSUc+66bbYt3DNUKqLcKFQiw0PYQX5xLxctdVcSUn/1dzZ7lB041cv0nuDK0 B4/nlpBdOAb7yIcJzCB8VlMSke3Uw87VwkMue2rMJt7GNADTtZLFdT70BNRZE6V4 AzpDfssRLuFFG557bSSyHtYVkk9TZxz+nSn/MCaU0o7HHKiCZL6bFDq7Asg+vr8I nPaDtK4BCtkx1K4vx9Vvw7XrNruSwA== =EZ74 -----END PGP SIGNATURE----- --==-=-=-- From nobody Tue Dec 31 12:20:58 2019 Return-Path: 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 20313120013; Tue, 31 Dec 2019 12:20:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <157782365001.23297.1679605930684430830@ietfa.amsl.com> Date: Tue, 31 Dec 2019 12:20:50 -0800 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-32.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 20:20:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Toerless Eckert Michael H. Behringer Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-32.txt Pages : 117 Date : 2019-12-31 Abstract: This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/ disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-32 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-32 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-32 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 31 12:27:12 2019 Return-Path: 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 BC6B612001E for ; Tue, 31 Dec 2019 12:27:10 -0800 (PST) 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 9yzXgN2mrivW for ; Tue, 31 Dec 2019 12:27:09 -0800 (PST) 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 D92F0120013 for ; Tue, 31 Dec 2019 12:27:08 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3BE2F38981 for ; Tue, 31 Dec 2019 15:26:53 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id ACCE63FE for ; Tue, 31 Dec 2019 15:27:07 -0500 (EST) From: Michael Richardson To: anima@ietf.org In-Reply-To: <157782365001.23297.1679605930684430830@ietfa.amsl.com> References: <157782365001.23297.1679605930684430830@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 Archived-At: Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-32.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 20:27:11 -0000 --=-=-= Content-Type: text/plain This version converts the v2XML to v3XML before submitting. The result is a bunch of format changes: "o" -> "*" as the bullet mark, and some whitespace changes. These address Tom Petch YANG review comments and Ben Kaduk's comments from 2019-12-20. Have a Happy New Year. internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. > Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) > Authors : Max Pritikin > Michael C. Richardson > Toerless Eckert > Michael H. Behringer > Kent Watsen > Filename : draft-ietf-anima-bootstrapping-keyinfra-32.txt > Pages : 117 > Date : 2019-12-31 > Abstract: > This document specifies automated bootstrapping of an Autonomic > Control Plane. To do this a Secure Key Infrastructure is > bootstrapped. This is done using manufacturer-installed X.509 > certificates, in combination with a manufacturer's authorizing > service, both online and offline. We call this process the > Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. > Bootstrapping a new device can occur using a routable address and a > cloud service, or using only link-local connectivity, or on limited/ > disconnected networks. Support for deployment models with less > stringent security requirements is included. Bootstrapping is > complete when the cryptographic identity of the new key > infrastructure is successfully deployed to the device. The > established secure connection can be used to deploy a locally issued > certificate to the device as well. > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4LrxsACgkQgItw+93Q 3WVkmggAoYiSVzBahGaPue2Nm98oMCjuqmOkZh6zPmZksW3Vq2NDuH3RAY4uLrnm Wbb2yfTD2t+ctSByR8jmNKULjyUVT1rse0h3/GU+bjy8GhQ3Vkz4Itwezq0jJ7IR MbPxI3H9UXx8gUjHxp+6zD95bAB7+tKxBOvTUA9jRrAFwnlHCf48B5GizgvOlO01 C3/5V8avF8fcEVj9/r3WlAbdf5xzy96rwEkzcXakSiR/k2S6rAGR6eAMfi0jOPIa +/r+c6k7OVY/G5/ksKwoqeeXbULOUCeWCPqZwKrKtYbggW3wurPjMC4OYJz+ICix 6NOkMBVvD97ki9lGDMbE0naNP7LrcQ== =phGo -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 31 13:08:34 2019 Return-Path: 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 18289120052; Tue, 31 Dec 2019 13:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 eujFWwwfJ_X2; Tue, 31 Dec 2019 13:08:29 -0800 (PST) Received: from mail-pj1-x1041.google.com (mail-pj1-x1041.google.com [IPv6:2607:f8b0:4864:20::1041]) (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 5C9AC120013; Tue, 31 Dec 2019 13:08:29 -0800 (PST) Received: by mail-pj1-x1041.google.com with SMTP id m13so1594345pjb.2; Tue, 31 Dec 2019 13:08:29 -0800 (PST) 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=lxQT/82zZLDGzU7UsZMC3N1NTbN5nS6e+FpfVsuCNFA=; b=Iylcgw4RLhWWYSOPzlTnR8pXPPKH6l360F335KgN/R7eaeEFUDlDxgJIwG0G1SL2kr pn/N7xuidTlaaaD1WKsziHutcl+S9egct6ZRB37Xmhw8/DhL+AJEW6MxscvPYtC2SbtK Vl+E2QX/t4ijRqsyq8yRpXKqav/SemlrkrxP7DkeSQcB1eSmPjogl4mF0pPG9s0kC9Dk Xbo2/TSX0f1z727M90ryEHJwd+67yCMvByYsAnrJcF31Y4uwsfKN3bAOysYQ3L+4me2Q Ynn4VTd1vy8cM/EXCKOIb/mpuiKNJusvEMbmiJGrrSJUyoTDeifAgPurYzGcK1tTF42r uvEA== 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=lxQT/82zZLDGzU7UsZMC3N1NTbN5nS6e+FpfVsuCNFA=; b=CrGYSaMppNbbosWpn5/LqOFKiGK4GEkqi5T0yYdTiGeopFbiR/f4AE4seq7ly+ZBqb 2On5oRwE1wzcOSgfzFpvLRTOPCup/KhraRFIrERcxWHjuAWWOLNKnFGFEi56COmf+haI maLjncA+t1GokvhlnIicJ50Z+eo2i7ie1pzQpnGa2RC5ubf+BHnHgNB0okOFw22pNbGb LA0FBKFj3AaTnzMMY6rsdAZ1kAjdsPHoHio9q8wLmpoiUPmpDr5k1PUb1zr45ZhkUmWD tSza3NE/m6ftwb7+q6zS3422hEliuF7r9RkEr8h+X4N9fSRgHralv/jTuaf88Lqcct7e xVdw== X-Gm-Message-State: APjAAAVcoOL8z9ueiEvT3OmF/fTFf/UeyPia1r9TaabfasNT6OdmJahP 7jskL5RoVZeLtzwcSOijms1QRU6M X-Google-Smtp-Source: APXvYqyjCu/Ui+fbhS3dvXpLy4TFb6wnU1IEorBxlcGK6PMNrgpIAHmEG8r7ag3uLwQBRFJJ1j2LUg== X-Received: by 2002:a17:902:34a:: with SMTP id 68mr65131785pld.250.1577826508321; Tue, 31 Dec 2019 13:08:28 -0800 (PST) Received: from [192.168.178.30] (228.147.69.111.dynamic.snap.net.nz. [111.69.147.228]) by smtp.gmail.com with ESMTPSA id 200sm57390039pfz.121.2019.12.31.13.08.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Dec 2019 13:08:27 -0800 (PST) To: Michael Richardson , Benjamin Kaduk Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG , anima@ietf.org References: <157688107174.4079.10454309821544008060.idtracker@ietfa.amsl.com> <5018.1577823353@localhost> From: Brian E Carpenter Message-ID: <8e12524a-4e5c-6bc2-f477-5e6cb80e5b06@gmail.com> Date: Wed, 1 Jan 2020 10:08:23 +1300 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: <5018.1577823353@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-31: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 21:08:32 -0000 Michael, thanks for all your effort on this. At this time my personal opinion is that the multiple reviews of this document are well above and beyond the threshold set by RFC 2026 for Proposed Standard status: "... generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable." Regards Brian Carpenter On 01-Jan-20 09:15, Michael Richardson wrote: > > A diff against -31 is at: https://tinyurl.com/vuls2ge > and will be posted as -32 in a few minutes. > Commit with edits here: https://github.com/anima-wg/anima-bootstrap/commit/0bdd9aaf206b0f2d70c51a7c9636a8249fd1366f > > BTW: I haven't heard from Roman since IETF107. > I am also converting to v3 format now, so there are some slight formatting > changes. (*->o, some extra spaces in places) > > I have addressed all of your comments, and I've checked that all the -29 > comments have been addressed. > > Benjamin Kaduk via Datatracker wrote: > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > Thanks for providing a clear specification of the /enrollstatus EST > > endpoint in the -30. The following two points still seem unaddressed, > > though. > > > The -29 reworks the definition of the 'nonce' field to be: > > > strong random or pseudo-random number nonce (see [RFC4086] > > section 6.2). As the nonce is usually generated very early in the boot > > sequence there is a concern that the same nonce might generated across > > multiple boots, or after a factory reset. Difference nonces MUST NOT > > generated for each bootstrapping attempt, whether in series or > > concurrently. The freshness of this nonce mitigates against the lack > > of real-time clock as explained in Section 2.6.1. > > > This needs to either be "Different nonces MUST be generated" or "the > > same nonce MUST NOT be reused"; this mashup is no good. > > Fixed. > > > Email exchange with mcr notes: > >> > An RFC Editor note about the RFC 8366 assignment of OID > > >> 1.2.840.113549.1.9.16.1.40 was removed from -23 to -28; do the > >> examples > properly use that assigned OID now? > >> > >> We got a MASA URL Extension OID for: 1.3.6.1.5.5.7.1.32 > >> > >> the examples date from before that, and do not use it yet. > > > We need to fix the examples before publication. > > Yes, I believe that there will be time to update them while in RFC editor > queue. I want the examples to be produced by code that has interoperated. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > A few new comments on the -30 and -31 to start. I think some of my > > comments on the -29 are still valid, and will try to remove ones that > > have been addressed. To reiterate: to the best of my knowledge, all > > the comments in this ballot position are actionable and have not been > > overtaken by events. > > okay. > > > In Section 5.9.4: > > > In the case of a FAIL, the same TLS connection MUST be used. The > > Reason string indicates why the most recent enrollment failed. > > > I'd suggest something more like "In the case of a failed enrollment, > > the client MUST send the telemetry information over the same TLS > > connection that was used for the enrollment attempt, with a Reason > > string indicating why the most recent enrollment failed. (For failed > > attempts, the TLS connection is the most reliable way to correlate > > server-side information with what the client provides.)" (Also, why is > > "FAIL" capitalized?) > > I have used your text. The fail was capitalized because bold is not available. > Further down, we capitalize SUCCESS. > > > Thanks for the text in Section 11.2 about second-preimage-resistance of > > DomainID calculation; the grammar needs a tweak or two, though. My > > suggestion would be to either drop "The consequences of" or add "be to" > > to make "would be to allow" (but not both). > > Done. > > > Section 11.3 has gone back to just "Devices which are reset to factory > > default in order to perform a second bootstrap with a new owner MUST > > NOT use idential seeds", but I think it's important to be clear about > > what the scope of uniqueness is. The text in Section 5.2 is pretty > > good in this regard, with respect to the nonces (which are generally > > derived from the seed); I wonder if we might want to restructure this > > text to be more like "The random seed used by a device at boot MUST be > > unique across all devices and all bootstraps. Resetting a device to > > factory default state does not obviate this requirement." (FWIW, I > > think the text in the -29 was that way because of my request.) > > Done. > > > In Section 3.3, we now cite RFC 4648; I note that RFC 4648 specifies > > both base64 and base64url, so a section reference is usually > > appropriate (and in Section 5 we do give a section reference into RFC > > 4648). > > okay, section 4 is "base64", added. > > > Section 9.1 > > > Other use cases likely have similar, but MAY different requirements. > > > nit: ", but MAY have different, requirements" > > fixed. > > > Section 9.1.1 > > > Authentication process. The MASA creates signed voucher artifacts > > according to a it's internally defined policies. > > > nit: s/a it's/its/ > > fixed. > > > Section 9.1.3 > > > (Do we need to say "DULL" specifically again here for Join Proxy > > discovery? Maybe not...) > > yes, I think that we need to say this again, as many people get upset about > having a full GRASP daemon visible on the insecure side. > > > [All new comments for the -28] > > rechecking. > > > Please respond to the secdir re-review. > > This is in message: > > to recap: > 1) 10.3, "The so-called "call-home" mechanism that occurs as part of the > > was toned down. > > 2) the TLS 1.3 text was already improved. > > 3) section 5.4.1, "This document does not make a specific recommendation" > (regarding whether to use public PKI, DANE, or pinned certificates for MASA > authentication. > > I don't think we can make a statement about the needs here at this point, and > why we have the PS->IS step. Note that I wrote > https://datatracker.ietf.org/doc/draft-richardson-anima-registrar-considerations/ > > > > Section 2.6.1 > > > A pledge with a real time clock in which it has confidence in, MUST > > check the above time fields in all certificates and signatures that it > > processes. > > > nit: s/in// from "in which it has confidence in" (your choice which > > one). > > I see now, fixed. > > > Section 4 > > > This section applies is normative for uses with an ANIMA ACP. The > > > nit: pick one of "applies to" or "is normative for". > > already fixed. > > > [...] The use of GRASP mechanism part of the ACP. Other users of > > BRSKI will need > > > nit: missing "is", "the" > > fixing. > > > Section 5.7 > > > The Status field indicates if the voucher was acceptable. Boolean > > values are acceptable. > > > nit: I suggest """acceptable, as a boolean, where "true" indicates the > > voucher was acceptable""". > > already fixed. > > > Section 10.6 > > > Section Section 7.4.3 describes some ways in which a manufacturer > > > nit: duplicate "Section". > > already fixed. > > > Section 10.7 > > > existing products. Said products might be previous deployed and > > need to be re-initialized, purchased used, or just kept in a warehouse > > as long-term spares. > > > nit: s/previous deployed and need/previously deployed that need/ > > already fixed. > > > Section 11.2 > > > In particular implementations should pay attention to the advance in > > [RFC4086] section 3, particulary section 3.4. Devices which are reset > > to factory default in order to perform a second bootstrap with a new > > owner MUST NOT seed their random number generators in the same way. > > > nit: s/same way/same way across bootstraps/ > > already fixed with different text. > > > Section 11.3 > > > We had some discussion around my previous comment: > > > % Additionally, in order to successfully use the resulting voucher the > > % Rm would have to attack the pledge and return it to a bootstrapping % > > enabled state. This would require wiping the pledge of current > > % > > % ... and I think there is a different attack if the Rm is in a > > position % to delay or drop network traffic between the pledge and the > > intended % registrar, to cause Rm's voucher to be delivered first even > > though it is % generated after the intended registrar's authorization > > process. The % intended registrar would need to require reports on > > voucher processing % status (or investigate their absence) in order to > > detect such a case. > > > but I can't remember if we decided that we didn't need to discuss the > > risk in the document. [ed. I also can't remember if we had discussion > > about this comment] > > We did. > We worked hard to create the Rm attack situation, and had to assume some > other failures to even get to this discussion. > I think that this follows into the "if these ten unlikely things all occur, > then you should consider if you are living in simulation" category. > > > ======================================================================= > > > I trimmed all the "Additional comments since posted ballot position on > > -28" that were in my previous ballot position, as they are likely stale > > by now. > > Thank you. > > > -- > ] 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 [ > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Tue Dec 31 13:22:41 2019 Return-Path: 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 9511812004C; Tue, 31 Dec 2019 13:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 35gcd8cmZ_6e; Tue, 31 Dec 2019 13:22:37 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on072e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::72e]) (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 C37A3120013; Tue, 31 Dec 2019 13:22:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SvhUH02u8MWjNCM+WCsUgEwCt0UZbReh1A2Q9i385ouGy3NaQ+SH7YrQsal58onKaehruQ7IoMwq9/rf5d9u5YdqcicYd5om838nqFF8AjgNfp8Fkv1C/2XRVQAFyEzuvO7s9WewTk4WxFyxFYXUW/z7865cG0ByiAu1lA2vPNdhrUR+jT4Vy9Tid7e13V+rKkCl8N7I2dnNKH6Rr+DlZbqlDPFzrJgX4ca1QL1FZSjuin76KUvSRPu7wLAGjAtrPQ2DnLUk91L40Fop3emiRaZYM4OIMkpEWfKYruyA04q3ZzDM0YMoKgTNON0aoAbhlU5U8Hkdq26bIT3gW+gMcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SE4L9HL89OG0N5jpj4ra73R+40k6YhwJWasB0MhqrBw=; b=Zf+5TtYMGKipRW48scErxxYqFA0w08UCLOzgoia4oxTL66YDGJP7/BhF7SB9CmII68lMtz5b1Yyf86KZuHBotyTDd7T9E7WpTqyRmpzgsg8+laNxJnVFkLhS0Hjt374j8wjBOQ3F6fcJaLrrpTt+sk5FG5/Axjo8i5+zm6kLZj7NpYhQh52Dlt3TI1OsSwXLqTYFxt1vwgEg6WzsXdfj/pOWND/6Dp/pkCi770HNr8ATXP4HRWhFV1+YwsMfPGBhwSpY88v9+Fr9Yb5IgPLAxVaIdStu+cNgBBggHVPwRHdH+cZ8VV7/K1t5kppyZnm9Pln9GAu8ETJ/r2D7VkI1Zg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SE4L9HL89OG0N5jpj4ra73R+40k6YhwJWasB0MhqrBw=; b=mYzldYy741kOSR/i/c2G79MS4PnuhlOtBiRM7HXAZXK+t0/ZtsOXuVtGFMvBQxIR4fj4gD+dFtX3vq6p30asaZksldfn4EwKt5aeUnyqwidkVQYmVtuoBRslRFplNE1EbQa/jYEKw9ywSF3skViRQoAyFUsaETy+05escybwzNM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; Received: from AM0PR07MB5716.eurprd07.prod.outlook.com (20.178.115.216) by AM0PR07MB4692.eurprd07.prod.outlook.com (52.135.144.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.8; Tue, 31 Dec 2019 21:22:34 +0000 Received: from AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::4156:4119:dd89:95f7]) by AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::4156:4119:dd89:95f7%5]) with mapi id 15.20.2602.010; Tue, 31 Dec 2019 21:22:34 +0000 To: Michael Richardson References: <157123777786.7830.10713306244839546046.idtracker@ietfa.amsl.com> <9637.1574756997@localhost> <2FA2728E-6484-4A69-992A-479D8053354E@cooperw.in> <20062.1576526178@localhost> <5DF90E0C.9020603@btconnect.com> <28309.1577821075@localhost> Cc: Alissa Cooper , IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org From: tom petch Message-ID: <5E0BBC17.5070709@btconnect.com> Date: Tue, 31 Dec 2019 21:22:31 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <28309.1577821075@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0384.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a3::36) To AM0PR07MB5716.eurprd07.prod.outlook.com (2603:10a6:208:11e::24) MIME-Version: 1.0 Received: from [192.168.1.65] (86.139.211.103) by LO2P265CA0384.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a3::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.2581.11 via Frontend Transport; Tue, 31 Dec 2019 21:22:33 +0000 X-Originating-IP: [86.139.211.103] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a6adf92e-6724-4836-75ce-08d78e378d6c X-MS-TrafficTypeDiagnostic: AM0PR07MB4692: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0268246AE7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(366004)(136003)(376002)(39860400002)(346002)(396003)(189003)(199004)(54094003)(66946007)(4326008)(16526019)(186003)(2616005)(4001150100001)(966005)(66556008)(66476007)(478600001)(2906002)(5660300002)(26005)(53546011)(956004)(33656002)(6486002)(16576012)(8676002)(8936002)(81156014)(54906003)(316002)(81166006)(86362001)(52116002)(36756003)(87266011); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4692; H:AM0PR07MB5716.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ex2N6MEJOyHk4Xbh7NY1mNba9+TFthx3xaa19Xr24Yv59/a11WxdHz8+/rZjwFV6vW+bgnAtM2crlMrljA4lYgu6XDVg5Q0pVvrjZ67+C6examZhxK3zYUXPHPnLdQgj/ojhq5UvHXQC74N1uHqmSs/v1ZTtyC9uLpHbLYOTX106IueSOAhskFPfHtEANcjSKRrzhvcQyMKg696N5MrT/1+QTCerMKWLs5hdSHgSLgdLR1PUtKTGyUWaT8CghthHOZxULf/nr3qRqR52oNRNeWpd67Uc/jO1/FXpECYxqQipPbs1EvF8omLEcgLZMZ8E3DuGsDYbtAaC1nwGOa78TBrtIx9dWFdxPohGRuV+y+E5HXLQoXFuoZiy43qhlUh/hxScdghNiHL0J8/m3hq58cGxBS5hr1qnqXQmFQwgx/yQBiftJLvXC60aBDH2zr9rD/a6Qk2grZWQ9yjXvwGtgXE+eAo47GLlKfaYhr36m6gCG0qlUD3lOQ9p0xiNrxvZrVnZhQcgd5d2qeY4xHRiKAXmQT77lAb51Fc+ntkQsjU= X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: a6adf92e-6724-4836-75ce-08d78e378d6c X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Dec 2019 21:22:34.4784 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: qCZaVx0T6a8XrdIuzk/W7IIdd2rvREu9EFSdGt5G9mfc2eDZLJg5bSKGIU/TKp5bLH3odF4EIaQvPzjh7CmfIg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4692 Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 21:22:39 -0000 Michael My e-mail has been rendered almost unusable so I struggle (I cannot access the I-D or much else from this PC:-( My comment about XXXX is that you ask RFC Editor to supply the RFC number for an I-D with a name you give but that name is not the same as the name at the front of the I-D:-( When I see [RFC8446] those square brackets make me suspect HTML/XML which must not appear in the YANG module which must be plain text. Security Considerations, the YANG Guidelines RFC says that you must mention TLS, HTTPS, etc and give pro forma text for doing so. As long as you still have a YANG module, as you do in s.3.4, I would expect those guidelines to apply and so to see something like the pro forma text HTH tom petch with apologies to the IESG for all this noise - I would like to drop them from the Cc: list but do not quite dare. On 31/12/2019 19:37, Michael Richardson wrote: > > A diff against -31 is at: https://tinyurl.com/vuls2ge > and will grow to include my responses to Ben's 2019-12-20 comments later today. > > tom petch wrote: > > Yes you have removed the second YANG module which addresses my comments > > about the second YANG module but my other comments mostly remain. > > Those about the YANG prefix are fixed. > > > RFC8040 needs to be in the I-D References > > > IANA Considerations mentions the removed module but lacks the two > > required actions for the remaining module > > I understand now. I wonder if idnits could be taught to find such issues :-) > Please see commit: > https://github.com/anima-wg/anima-bootstrap/commit/75d7ef8a78b2c03cd2e558705861194357f1e643 > > > XXXX is used as a place holder for a document name which is not that of > > this I-D and does not exist AFAICT > > Do you mean the self-reference should say "XXXX"? I have used "THIS > DOCUMENT" in the past. > > > The YANG module must be plain text - [RFC8446] looks like HTML/XML > > I'm confused by this comment. I see: > > > Michael, my initial posts were a response to the Genart review and so > > did not include your name, just Anima, Anima chairs, ibagdona, IETF; > > you are in this one as mcr+ietf@sandelman.ca (but IETF mailers may have > > a habit of thinking you will get an e-mail via one way and suppress > > other ways with different e-mail addresses). > > Yes, I wasn't complaining about your actions, but more just lamenting: my > impression is that the problem is that DMARC is getting in the way, since the > DT acts as a remailer. However, btconnect.com has a p=none policy, so it > shouldn't be a problem... however, maybe it fails the SPF tests themselves. > {I was forced to switch spam processing systems in the spring, and it really > has been a PITA to get it configured sensibly. Very few of them support > IPv6, and a surprising number of them will not use TLS for final delivery. > I specifically need to whitelist everything coming from the IETF SMTP machine, > and I don't think I've accomplished that perfectly yet.} > > leaf proximity-registrar-cert { > type binary; > description > "An X.509 v3 certificate structure as specified by RFC 5280, > Section 4 encoded using the ASN.1 distinguished encoding > rules (DER), as specified in ITU-T X.690. > > The first certificate in the Registrar TLS server > certificate_list sequence (the end-entity TLS certificate, > see [RFC8446]) presented by the Registrar to the Pledge. > This MUST be populated in a Pledge's voucher request when a > proximity assertion is requested."; > } > > I'm not sure I see how you are seeing HTML here. > If you are looking at: > https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-31#section-3.4 > then the links you are saying are because the HTMLizer sees the reference and > HTMLizes it. > > > Security Considerations lacks the required boiler plate for a YANG > > module > > I see. I have adapted the text from RFC8366, as we extend it, and the normal > template does not apply. > > Fixed in commit: > https://github.com/anima-wg/anima-bootstrap/commit/c138bbd24db038f0704770b545e74ba202a98e4e > > > Appendix A still has a typo > > secification -> specification. plege->Pledge. > > > > -- > ] 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 [ > From nobody Tue Dec 31 14:01:39 2019 Return-Path: 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 BFCDC12004C; Tue, 31 Dec 2019 14:01:37 -0800 (PST) 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 lFVdbaoOcnR8; Tue, 31 Dec 2019 14:01:35 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B92C5120059; Tue, 31 Dec 2019 14:01:35 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9D1863818F; Tue, 31 Dec 2019 17:01:19 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 17E07378; Tue, 31 Dec 2019 17:01:34 -0500 (EST) From: Michael Richardson To: tom petch cc: Alissa Cooper , IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <5E0BBC17.5070709@btconnect.com> References: <157123777786.7830.10713306244839546046.idtracker@ietfa.amsl.com> <9637.1574756997@localhost> <2FA2728E-6484-4A69-992A-479D8053354E@cooperw.in> <20062.1576526178@localhost> <5DF90E0C.9020603@btconnect.com> <28309.1577821075@localhost> <5E0BBC17.5070709@btconnect.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 Archived-At: Subject: Re: [Anima] Alissa Cooper's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 22:01:38 -0000 --=-=-= Content-Type: text/plain tom petch wrote: > Security Considerations, the YANG Guidelines RFC says that you must mention > TLS, HTTPS, etc and give pro forma text for doing so. As long as you still > have a YANG module, as you do in s.3.4, I would expect those guidelines to > apply and so to see something like the pro forma text Please see: https://www.rfc-editor.org/rfc/rfc8366.html#section-7.4 TLS is already specified and discussed at length in the document. If you want me to copy the second paragraph from there in, I can do that, but it seems like needless text. You can't implement BRSKI without reading RFC8366. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4LxT0ACgkQgItw+93Q 3WUtkgf/YhI+GrVZDe66PbNNDBaUtJVRcFud0uS8p1JdeLqntHQMa3VEJspDXnXv uiU+ns2t77QUEBp5/tQsKm9dAVmA+m97GlOOc92hAoLSjQ8V37IZxzC6OkKEnocT /JDZTOsaUcVU3l8q6DMzNcMYroxLK6pyCgC059ChbO2QtVCk1Uav6XObuN2sU9ww VINLTtcmgYunAh4alVcpgjeH5a7JczS74qqTipcceYSoe3u3y3BZIA4VoxtBGfsX OLNbzHCD5wEdddGE/YQp4PErENKjc/12t7tulM8es4phONBjbPZTHxZzoKuYi30+ 9O6Bd4M3lpQbxrUNWQ4vmkisvwk+JA== =ufZC -----END PGP SIGNATURE----- --=-=-=--