From nobody Tue Aug 16 06:40:56 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE2A12D82A for ; Tue, 16 Aug 2016 06:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, WEIRD_PORT=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 kmWy9_ZlIMuf for ; Tue, 16 Aug 2016 06:40:53 -0700 (PDT) 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 D972112D819 for ; Tue, 16 Aug 2016 06:40:53 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CD64F2009E for ; Tue, 16 Aug 2016 09:51:54 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0B005639DC for ; Tue, 16 Aug 2016 09:40:53 -0400 (EDT) From: Michael Richardson To: anima-bootstrap X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+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-bootstrap] call today -- 2016-08-16 -- reminder X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 13:40:55 -0000 --=-=-= Content-Type: text/plain To remind, we meet at 1500UTC (11am EDT, 8am PDT, 9am MDT; M=Max) at: https://cisco.webex.com/ciscosales/j.php?MTID=m9a72faf43b6a5be5bec713b25b6bf414 http://etherpad.tools.ietf.org:9000/p/anima-boostrapping?useMonospaceFont=true (note typo in boostrapping) Join WebEx meeting Meeting number: 206 416 892 Meeting password: fMmGVQT8 I don't have a big agenda, but here are the issues that I have: 1) recap on, do we need/want to write up an example ownership voucher. or perhaps, I should say this differently. I intend to write up an Informational Document. Does this group feel it should be a WG deliverable, or not? Perhaps a premature question since no document exists yet. 2) I'm still uncomfortable with the level of detail/protocol around getting the pledge to put the "right things" into the CSR. 3) draft-pritikin-coap-bootstrap-00 ... perhaps out of scope: 9) some changes in how 6tisch-secure bootstrap will occur, making/allowing to leverate a lot of more of ANIMA. See email that I haven't written yet. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV7MX4YCLcPvd0N1lAQJs5AgAwZyvR/dNIVSr5Ti/Dcds0AaP8Ro5wrQG 6EySmNnYAtJ7KYDYbHpOEKUsRjx6ZmToSjMUkTxmJ797Pngem3M7C9P7hEoMtn+J lEGjvTRU7Sk1GXuP2A4rqrCSQSVSzPR6nxFzar9im/iS1HAUJfezLRLlSmYMYUrL cbMbcDj4auDHJ1dled00zaObysipKWCSEIZ37T1oZukQgVwP+5NquS/jThU2sJ3t 3Y/3OQo/NgBrQJHYwi52Jurr+q20DADjg6IP2UlqjluNfIOFQCLQ30yqYKfUfCyT XCrkb1heUhzqBikiSqw1sweu03s6BMtTcdKpV2FRm5tFPCO7u+hrjw== =GMu5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 16 12:27:22 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C208212B00B; Tue, 16 Aug 2016 12:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 d-JyCUaPcFOw; Tue, 16 Aug 2016 12:27:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BBD12D739; Tue, 16 Aug 2016 12:27:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A5D98200A5; Tue, 16 Aug 2016 15:38:15 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 01C58639DC; Tue, 16 Aug 2016 15:27:13 -0400 (EDT) From: Michael Richardson To: anima-bootstrap X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+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: Cc: netconf Subject: [Anima-bootstrap] minutes for anima-bootstrap design team meeting, 2016-08-16 X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: anima-bootstrap List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 19:27:17 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable We return to weekly meetings after a few weeks off for vacations and IETF96. WEEKLY INVITE, SEE ANIMA BOOTSTRAP WIKI: https://trac.tools.ietf.org/wg/ani= ma/trac/wiki/Bootstrap 2016-08-16: present: mcr, max, kent, toerless, P. Kampanakis We had three items on our agenda: 1) recap on, do we need/want to write up an example ownership voucher. 2) the level of detail/protocol around getting =C2=A0 the pledge to put = the "right things" into the CSR. 3) draft-pritikin-coap-bootstrap-00 I think that Kampanakis joined after I asked he was joining our team, being= a co-author of coap-bootstrap. He is a Cisco person with ties to the EST implementations at Cisco. We started on item one, which was the question as to whether or not we need= ed to have a standards track document that defined the onwership voucher. The tl;dr conclusion was that we do need a document, but that it could be Informational. That it should be a WG product, not an independent submission. We did not rule out a standards track document as yet. The ownership voucher, as conceived by draft-ietf-anima-bootstrapping-keyinfra-03#section-5.3 is created by the manufacturer, "signed" with a key the manufacturer posses= ses, and then is verified by the device which the manufacturer created. The word "signed" is in quotes, because it does not have to be asymmetrically signed. The exact details are essentially private to the manufacturer. The netconf ownership voucher, as explained at: https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-09#appendix-A.1 describes a sample voucher in YANG. Netconf is mostly consistent with the view that voucher is a private matter, however there are some situations in netconf where it may be necessary to distinguish one voucher from another. In most cases (DHCP, HTTP) it is possible for the provider of boot information to return a voucher specific to the device asking, but in the DNSSD situation, the responder can not really provide customized replies, so the likely reply is a set of group vouchers. This requires that the booting device be able to sort through the replies looking for one which applies to it. This requires some structure to the voucher, even if most of the voucher can be proprietary. In the ANIMA situation, there is an additional situation where we something very similiar to the voucher, which is in the log provided by the MASA! The MASA audit log is essentially a record of vouchers which have been observed. In discussion, we further acknowledge that in order to debug things in the field, knowing what is in the voucher would aid greatly in diagnosing systems. We further discussed the question as to whether or not there were confidentiality or privacy issues. We conclude that: We believe there is no confidentiality requirement for vouchers. i.e. nothing breaks in the micro-cosm of a single device enrollment. In the macro-cosm of thousands of devices and thousands of ownership vouchers being observed, there are quite possibly privacy issues. We do not think that we can or should encrypt the vouchers themselves; the key management problem is large if each are encrypted seperately, and if asymmetrically encrypted, then diagnostics are out. We came up with three possible actions: 3 paths forward: a) treat this as a hard requirement b) try to leave the door open for future work here c) declare totally out of scope. proposed decision: (b) try to keep the door open but not address at this ti= me. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV7NpDoCLcPvd0N1lAQL2Sgf+MZC2M/8x/oiy0WoTtnOx+zQNCQh0IqwJ 8j7ibG01BJ7+L/pHmXn30mZfc7hpR4O6mAI7hbqu+mQfcl2U8MdanoNyVL3mqfD6 TwnG4YNi6Jz06T6bLv/Cs5sz+475JuH6IjtINeUIUN8fzW5/O5cf4aKQ1EmXfXFo V+u4rn4j9zMwR8UdEb+enOLOjRsq6DPAXibuFItFLuz0ocxsLgoBYNPpfOmCEpYb OZIfG+4Z3OiU8E5ehUt9Y43JeX6GQO9iOT4cEzkuaOef8yHkJ42jvcg8pdoUQ63y v8YWKnYDCNq3tWD0iYDh8+14lztAhVAMEp/atcHiUNcO6g2+KW/kuw== =XmD3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 16 15:46:51 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835D712B05E; Tue, 16 Aug 2016 15:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247, 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 A-0cUgdXLXFu; Tue, 16 Aug 2016 15:46:44 -0700 (PDT) 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 F07A512D08F; Tue, 16 Aug 2016 15:46:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 083CB200A5; Tue, 16 Aug 2016 18:57:45 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EB422639DC; Tue, 16 Aug 2016 18:46:41 -0400 (EDT) From: Michael Richardson To: tisch-security <6tisch-security@ietf.org> X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+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: Cc: anima-bootstrap@ietf.org Subject: [Anima-bootstrap] developments on 6tisch join scheduling X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 22:46:46 -0000 --=-=-= Content-Type: text/plain During discussions at IETF96, it became clear that the join ordering/time sequence envisioned for 6tisch would be less possible than I thought. The bad news is that a new mechanism might be hard to actually design. The good news is that I think a new mechanism would put 6tisch join and ANIMA bootstrap almost identical. To go back, the proposal was: 1) a new pledge would send a NA with an EARO, which would turn into a DAC/DAR process up to the 6LBR. The 6LBR would let the JCE know about the new node through mechanism TBD. The new pledge would receive a NA in reply, which, for the pledge would acknowledge that they might be knocking on the right door. (A network which didn't like that node would reply in some negative fashion, which naturally could also be forged) 2) the JCE would reach out (via the proxy) to the pledge, on a schedule determined by the JCE. The JCE would control the order of joining, and since CoAP would be used with using something like: draft-wang-6tisch-6top-protocol-00 all joining nodes would remain quiet except when responding to queries from the JCE. The goal of having the pledge be passive was one of bandwidth conservation, the JCE would enroll only as many pledges as it felt it had available bandwidth in the upper parts of the MESH DODAG tree. A 6tisch network might allocate a rather small amount of bandwidth for join messages, and utilizing the bandwidth responsabily is important. That means never wasting any energy among the lower parts of the DODAG when the packets would just get dropped further upwards. In discussions, it appears that the EARO as described in draft-thubert-6lo-rfc6775-update-00 might be replaced by the Crypto-ID of draft-sarikaya-6lo-ap-nd-02, and the process is slightly different. One additional reason why the passive pledge turns out to be a problem is that the JCE does not actually know the wake/sleep schedule for the pledge. In the 6tisch case, it ought to be possible for the pledge to sync up to the schedule and so the proxy will know when it can transmit to it, but in order to keep the proxy from having to store a lot of data coming from the JCE, the JCE also needs to know the schedule out at the edge. This does not seem unsolveable, but it was an additional concern raised. Meanwhile, in ANIMA bootstrap, the initial contact is through a GRASP discovery (or DNSSD) to find a proxy. The new pledge uses the proxy to initiate an EST session using the proxy. The enrollment process in the ANIMA case is driven by the pledge, on the assumption that the ANIMA ACP has sufficient bandwidth for normal congestion control present in TCP and CoAP to deal with a limits. What is needed is a way to adjust things so that the pledges will attempt to join in a way that does not overwhelm the network, and more so, that the proxy nodes can easily police that they are doing so. So the idea is to use the ANIMA GRASP discovery mechanism to find a proxy, but in addition, in the reply, to get some kind of number to seed a backoff algorithm that causes the pledge to attempt to initiate the join process at times deterministic to the network. I'm not talking about an exponential backoff. This is where the hard part is, how to come up with a simple to describe, and simple to code algorithm which would fill up the available bandwidth, and be easily subdividable. By subdividable, I mean, if we pass 5% of the join bandwidth to proxy A, at rank 3, that it would be able to easily pass some percent of that bandwidth to a new proxy at rank 4 in a way that does not mean reconfiguring the entire mesh to delegate bandwidth. Removing the subdivable property, some simple pseudo-random number generator, with the right seed would be the right idea. A good PRNG ought to span the available time space evenly. I don't have a solution, but I'm trying to write up the requirements more clearly. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEUAwUBV7OXzoCLcPvd0N1lAQJkIwf4rXSVcoj1tFnLgqLvE17N3AbFPBlb/8iF owaPqV0zl0YfKoeYRWFc/MEjUv+yzSfR5wjJ1OzHKOFJvu9cUO7re+pwxp+ZdpbL 8supqAoU1k9TwYAHMNJy11ZSR+ztGxJhkH9vboOAQZ2sl+1ehMQfKJgBesE8dbUN FqklFmq08/SFb3D0vhMk7BFS7cNVFXmLixMNAacx5iv1jcN9UBO7dq3dThY5+JmK Kj31jt2ouRCA2IJ17wuiz0UqxXiH8DrjoFn6isId9kR/P7yQwD3kvZJTSVJgYYzi xFTP6hmxe/64akGspstNuD8j3xZ7HhoLjfnRzUwgIKoEmJgUwlLC =NZ6u -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 16 16:47:05 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E69B12B02C; Tue, 16 Aug 2016 16:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 yu2jWJ0z43RY; Tue, 16 Aug 2016 16:46:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F8D12B00B; Tue, 16 Aug 2016 16:46:58 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 519B3200A5; Tue, 16 Aug 2016 19:58:00 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E85B6639DC; Tue, 16 Aug 2016 19:46:56 -0400 (EDT) From: Michael Richardson To: anima-bootstrap , netconf@ietf.org In-Reply-To: <3A795BB6-03A8-46B0-9EAD-1607427EE0CD@cisco.com> References: <13187.1471375632@obiwan.sandelman.ca> <3A795BB6-03A8-46B0-9EAD-1607427EE0CD@cisco.com> X-Mailer: MH-E 8.6; nmh 1.6+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-bootstrap] [Netconf] minutes for anima-bootstrap design team meeting, 2016-08-16 X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 23:47:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Max Pritikin (pritikin) wrote: > The common elements we=E2=80=99ve discussed are: > 1) some type information > 2) signature and/or encryption method > 3) validity period / nonce verification > 4) client device identity > 5) domain identity > 7) ability for extensibility(?) > There is also the encoding choices that need to be made. If it turns > out anima and netconf, for example, have entirely different > requirements for encoding (e.g. one requires json and the other cbor = or > something) then there is a problem. Okay, so if we are going to create a ownership voucher format, where will we do it? I don't think it's a question if it fits into the various charters, so much as which one it should fit into. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV7Ol7YCLcPvd0N1lAQLg6Qf+MrSfLY/MJrt8ytYmf6CNqdzlznHt7PhO dopNl5Cil3cHjnByBNLeQGRApzrTtpOpqR0ZAWbNOUuEMtAhu+dIPe6HY8AER4v6 8tUacuqk+0GBEVf7BOoquroK/nFIzAqb/nv9utwEu8XfoOnKH9ATLroEuouej/0S mm6OJHIXaT9JNsIxShv9m9Tg3eaNcTMVe41coEkoJ3mBmucNQHHOckCwOW7EN2eP M67SAiQSHG/5qbuhxe8vtkHmcUFhQBBjK6dmPYX6M7us6OtQopBQ4NxyhnQiDMB2 iC5QxuIJF+DxbBm5jH56oksqy6t06bRyAcQvi1M053atTEgDguq7qg== =fzZD -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 16 18:45:57 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAB112B064; Tue, 16 Aug 2016 18:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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=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 6U_3wyyj_vKv; Tue, 16 Aug 2016 18:45:54 -0700 (PDT) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 C934212B042; Tue, 16 Aug 2016 18:45:54 -0700 (PDT) Received: by mail-pf0-x244.google.com with SMTP id y134so6434837pfg.3; Tue, 16 Aug 2016 18:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=9/dtC8VGTVbAt/2+E5LRjS0UjNRkTo6BDM+om1lRYnA=; b=vavtsA+09OY35tf5OGfptfAV+5JPn2VCAqQJ0w4DV5fUirc+Jz/DrKaVzEs4hSNVwD oO8pnwWmGw0LjtQqWWu/dCtcoqOdRNjzhBlHyE6p5ZpxhyZV5ELxZ1qi59T41K4+CBRn CREyuU2SxKzUvJZzZFQcxBk7ajAF8CLMoPcZo6GFYCg/WsHrDdBvX59t3+j/TvOiizLf ZZWDFDbhoHgojW2d8dbdQpE27cCiV20fH+ke+XkM9nMMJpwozjmn/xyBincGlCcoGdED Er7tNHMelzFFmPsWCQuwotfzJ/GOzpUxGS/6pTtUOXwrXDcfNIGX8YS7ySFK9EsmpeJL 9bQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=9/dtC8VGTVbAt/2+E5LRjS0UjNRkTo6BDM+om1lRYnA=; b=RSmAmdWOOPd17Ki22BERexSmf3uGfST3AiBWoPX5+IwoFfUMphspO5Zux6K27nStoq SoNPUrbPMlV+yH1Ju5CbRupY2whOtw8Rvpb2fZzAwe9HzYPMpRMfEdj6zysEokkaW/uK ELlTo2vF3lBKKd8b2I8/jd9VgCr9jqynZ/kRnQ/brgD/u5K/WtEDaODrE9/UoScfrAqY dv4TaWvKNW9gSTf45/dKwIoKrvhe4VjIn99tmiBWn+ZA4X9w4lXQ5lUJ1fpafqFWyfAe JoYn/1TmydHsn+yYAPSZvWc/dWkSAi/RgN9Qdutc2/4c3i/RJSxdcDiReesSuz69Zw7Q xhiQ== X-Gm-Message-State: AEkoouuCt4C/bZ5DBLTekS8eyvCkkvwaP6s2uj16ZbLwgIvLfyHYZoJdZsfTVOT61KsIeA== X-Received: by 10.98.222.70 with SMTP id h67mr69573320pfg.128.1471398354174; Tue, 16 Aug 2016 18:45:54 -0700 (PDT) Received: from ?IPv6:2406:e007:63aa:1:28cc:dc4c:9703:6781? ([2406:e007:63aa:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 6sm42370026pab.11.2016.08.16.18.45.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Aug 2016 18:45:53 -0700 (PDT) To: Michael Richardson , tisch-security <6tisch-security@ietf.org> References: <24944.1471387601@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <36a58fbd-22a5-7dbe-6287-5bfca0d284fd@gmail.com> Date: Wed, 17 Aug 2016 13:45:56 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <24944.1471387601@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: anima-bootstrap@ietf.org Subject: Re: [Anima-bootstrap] developments on 6tisch join scheduling X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 01:45:56 -0000 > So the idea is to use the ANIMA GRASP discovery mechanism to find a proxy, > but in addition, in the reply, to get some kind of number If you are asking for *content* in a Discovery Response, you are actually asking for GRASP rapid mode (an objective included in the response message). I'm not suggesting that this is a problem. Regards Brian On 17/08/2016 10:46, Michael Richardson wrote: > > During discussions at IETF96, it became clear that the join ordering/time > sequence envisioned for 6tisch would be less possible than I thought. > The bad news is that a new mechanism might be hard to actually design. > The good news is that I think a new mechanism would put 6tisch join > and ANIMA bootstrap almost identical. > > To go back, the proposal was: > 1) a new pledge would send a NA with an EARO, which would turn into a > DAC/DAR process up to the 6LBR. The 6LBR would let the JCE know > about the new node through mechanism TBD. > The new pledge would receive a NA in reply, which, for the pledge > would acknowledge that they might be knocking on the right door. > (A network which didn't like that node would reply in some negative > fashion, which naturally could also be forged) > > 2) the JCE would reach out (via the proxy) to the pledge, on a schedule > determined by the JCE. The JCE would control the order of joining, > and since CoAP would be used with using something like: > draft-wang-6tisch-6top-protocol-00 > all joining nodes would remain quiet except when responding to > queries from the JCE. > > The goal of having the pledge be passive was one of bandwidth conservation, > the JCE would enroll only as many pledges as it felt it had available > bandwidth in the upper parts of the MESH DODAG tree. A 6tisch network might > allocate a rather small amount of bandwidth for join messages, and utilizing > the bandwidth responsabily is important. That means never wasting any energy > among the lower parts of the DODAG when the packets would just get dropped > further upwards. > > In discussions, it appears that the EARO as described in > draft-thubert-6lo-rfc6775-update-00 might be replaced by the Crypto-ID > of draft-sarikaya-6lo-ap-nd-02, and the process is slightly different. > > One additional reason why the passive pledge turns out to be a problem is > that the JCE does not actually know the wake/sleep schedule for the pledge. > In the 6tisch case, it ought to be possible for the pledge to sync up to > the schedule and so the proxy will know when it can transmit to it, but > in order to keep the proxy from having to store a lot of data coming from the > JCE, the JCE also needs to know the schedule out at the edge. This does not > seem unsolveable, but it was an additional concern raised. > > Meanwhile, in ANIMA bootstrap, the initial contact is through a GRASP > discovery (or DNSSD) to find a proxy. The new pledge uses the proxy to > initiate an EST session using the proxy. The enrollment process in the ANIMA > case is driven by the pledge, on the assumption that the ANIMA ACP has > sufficient bandwidth for normal congestion control present in TCP and CoAP to > deal with a limits. > > What is needed is a way to adjust things so that the pledges will attempt to > join in a way that does not overwhelm the network, and more so, that the proxy > nodes can easily police that they are doing so. > > So the idea is to use the ANIMA GRASP discovery mechanism to find a proxy, > but in addition, in the reply, to get some kind of number to seed a backoff > algorithm that causes the pledge to attempt to initiate the join process > at times deterministic to the network. I'm not talking about an exponential > backoff. > > This is where the hard part is, how to come up with a simple to describe, and > simple to code algorithm which would fill up the available bandwidth, and be > easily subdividable. > > By subdividable, I mean, if we pass 5% of the join bandwidth to proxy A, at > rank 3, that it would be able to easily pass some percent of that bandwidth > to a new proxy at rank 4 in a way that does not mean reconfiguring the entire > mesh to delegate bandwidth. > > Removing the subdivable property, some simple pseudo-random number generator, > with the right seed would be the right idea. A good PRNG ought to span > the available time space evenly. I don't have a solution, but I'm trying to > write up the requirements more clearly. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima-bootstrap mailing list > Anima-bootstrap@ietf.org > https://www.ietf.org/mailman/listinfo/anima-bootstrap > From nobody Tue Aug 16 23:51:31 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B384012B011 for ; Tue, 16 Aug 2016 23:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 S6ZPO_loqPej for ; Tue, 16 Aug 2016 23:51:28 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2308512B008 for ; Tue, 16 Aug 2016 23:51:27 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.207]) by smtp-cloud6.xs4all.net with ESMTP id Y6rR1t00S4U4Moq016rRkZ; Wed, 17 Aug 2016 08:51:26 +0200 Received: from 2001:983:a264:1:dc04:129e:842d:28c7 by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 17 Aug 2016 08:51:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 17 Aug 2016 08:51:25 +0200 From: peter van der Stok To: Anima-bootstrap Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <681a69f5cae643a7701e0df980c44a0a@xs4all.nl> X-Sender: stokcons@xs4all.nl (sA4ovDvuunGz+VWaixFSecPpyK2W9srg) User-Agent: XS4ALL Webmail Archived-At: Subject: [Anima-bootstrap] keyinfra-03 review X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 06:51:30 -0000 Hi Max, In Berlin you asked for more reviews of the keyinfra (bootstrapping) draft. Below my efforts from a constrained device/network point of view. I hope the review helps to get the validity of this document for the constrained world better understood. Greetings, Peter __________________________________________________________________________________________________________________ Anima-bootstrapping-keyinfra-03 In general: I think this is quite an important document to standardize autonomous security bootstrapping in the control plane, but its relation to constrained devices could be improved and clarified. I found it difficult to review the document because there is much overlapping text that describes the same protocol or function but in different words. Also I recommend the use of consistent terminology. For example, the terms new entity, device and new device, probably denoting the same thing, are used throughout the document. A consistent choice would help the reader. The terms vendor service, MASA, or just vendor could be aligned in figures and text. As a result this is a quite high-level review, in which I mainly try to point out ways to improve the readability. In more detail: There are two authorizations in the document: a provisional one and a definite one. Giving them different names and referring to them by these names would help. For the moment a reader has to guess what “authorized” means in different parts of the text. The term Zero-touch approach could be explained in section 1.1. Page 4. The 4 questions at the top of page 4 need rephrasing. Especially the words “who”, “mine”, “it”, and “I” are ambiguous. Suggest to remove in the second paragraph: “The domain’s decisions …. Auditable fashion”. This is difficult to follow and needs information provided later. Optimal security (remove optimal) “Bootstrapping … secure”. Remove, does not help. Last phrase before 1.1: reduce to: Support of alternative key infrastructures is discussed. Page 5: DomainID. Remove “(a string value … is used)”. This information does not help me. Pledge: to at the factory (which one to or at?) belongs with this network (you mean domain?) section 1.2. I find the discussion in this section very hard to follow. The general message I receive, is “constrained networks” are out of scope (NO 802.15.4); unless you execute only parts of the bootstrapping protocol. But executing parts of the protocol is not allowed. On the other hand an argument is made about the size of the messages being prohibitive; but it is not clear what sizes we discuss. Later in the document (section 5.7.5) a discussion about CoAP and DTLS follows; but the relation with this section is unclear. My suggestion is to clarify the end state expected from the key distribution as explained in section 3.1.7. Explain that constrained devices may need this state, mention the intended use of coap (section 3.2.1) and point out where the bootstrapping communication may be long (transport of certificates) and will need the block option of CoAP. Page 9: Is ownership tracker part of MASA? In the rest of the document its existence seems not essential. Section 3. The first paragraph about autonomic fashion should go to section 1, where the relation with ACP could be clarified. In general: Ignoring non autonomic aspects will help the readability of this document. Figure 2 is quite helpful, but why is there a figure 5 and 6 on pages 29 and 30; and what are the differences? Section 3.1 I don’t understand: “A new entity…. been configured” Why not; I assume the protocol detects this behaviour. Page 12: identify itself AND authenticate Registrar (they have equal importance) Page 13: point 3: why the text about nonce? This will be treated several times later in the text. Point 4: Very confusing to me. Many terms are used that are explained much later, like: Audit token, ownership voucher, Registrar server certificate. Point 5 “e.g. EST”. Why e.g. it seems to be the only option later in the text. If not can it be made more explicit that other methods are supported. Section 3.1.1 Discovery. The standardization of the discovery of the proxy (registrar) does not seem necessary to me. The bootstrapping protocol is not affected at all when different discovery protocols are used. Just citing GRASP and mDNS as examples within their context seems more than sufficient to me. Section 3.1.2 phrase 1; to what? does the new entity identify itself? Paragraph 2: What is the bootstrapping protocol server here? The proxy or the Registrar? Is it the data received from the registrar that is not trusted? But the data from the new entity is trusted? And why is a TLS connection needed, if no data is trusted? Page 15, last phrase before 3.1.3: bootstrapping server -> registrar? New device -> new entity? Section 3.1.3. Is this where EST is started? Might be helpful to indicate which parts are already fixed by EST. The phrase: “Since client authentication occurs during TLS handshake” is confusing. Is this the TLS handshake discussed under 3.1.2 or a new one? Neither is it clear if this is the provisional authentication or the final one. This section in general needs more clarification and description of the flow on how redirections to a different Registrar works. Section 3.1.4 why cite the non autonomic (and non used) enrolment protocols? The audit token provides sufficient information to continue, but the ownership voucher does not? Section 3.1.5. Why this last paragraph about time distribution? Section 3.1.6 mentions audit token and ownership voucher; but only discusses audit token afterwards to start RFC7030 process. Section 3.1.7 specifies the final purpose of the key distribution? IMO part of this text should go to the introduction to motivate the bootstrapping protocol and also show its validity for constrained devices and networks. 3.2 facilitates communication between ???. According to figure 2 the registrar is not necessarily configured on the Proxy. What is a control plane CPU? Probably text has gone missing. Not clear from the text how/why a device becomes a proxy and by whom/how it is configured with the relevant information like the Registrar’s address. Section 3.2.1 The choice between DTLS and TLS appears all of the sudden. All former text discussed TLS; I suggest that a different section is dedicated to use of CoAP, describes the http/TLS to coap/dtls mapping, and the draft consistently uses TLS for clarity. Section 3.2.1. is then more dedicated to the discovery and keeping proxy stateless. Section 3.2.2 suggests multiple options to proxy the connection to the Registrar. Can other methods be used beyond that are listed here. Section 3.3.1 should the out of band be cited here? The draft describes autonomic behaviour. End of section 3.3.2; why the emphasis on homenet? Section 3.3.3, 2nd paragraph; examples might be handy? Section 3.3.3 Claims for an unauthenticated Registrar are only…; Is this a viable approach? Section 3.4 Factory provider? Section 3.5 As the devices have a common trust anchor… Please make devices more explicit. Section 3.5.1. device -> new entity The new entity can validate the domain membership after joining? You mean it can act as proxy? Section 3.6 Network access Control? Where does this term come from? What does “having sufficient connectivity” mean? Section 4.4 Zero-touch is an unknown term. Already enrolled devices -> proxies. Section 4.5 What are central control functions? Section 5 repeats much of earlier sections. I suggest to remove text in earlier sections (or make more abstract) to minimize duplication. What is an “air-gapped” network? Referring in the text to fig 5 and fig 6 and pointing out the differences helps readability. Here my review stops; The technology seems already quite solid if the proxy behaviour with IPIP encapsulation of the TLS messages are better clarified. The text needs quite some editing to remove duplication, improve consistency, and remove many of the design decision discussions. I hope my comments may help. Greetings, Peter -- Peter van der Stok From nobody Tue Aug 16 23:59:46 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065D012B008 for ; Tue, 16 Aug 2016 23:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 1Wqd0Fl5ODl7 for ; Tue, 16 Aug 2016 23:59:43 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02898127077 for ; Tue, 16 Aug 2016 23:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9034; q=dns/txt; s=iport; t=1471417182; x=1472626782; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=8NZ2qW764xv171Ai13vIxku6nFd9BKv+bN9K76ev1Zo=; b=RGX7AsQvRYjjbYNw3L+yS3CwpujFUvP7C+JoiFsP4641uzQkoVhX0/2x 3TybBym6OMfVnvJpb1tf+W7wDQNbIIXtU17hF5Uv6RVy1CQImuBAgXZmG NgUkJsPBwRgpfyEm463P9Zm+1AWvc4eNxYRjZOr12ZxZu+7fO5/FC7ffo o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BNAgBtCrRX/40NJK1UCoNEVny5UoF9J?= =?us-ascii?q?IV5AoFcOBQCAQEBAQEBAV4nhF8BBQEBJRM0BAcQCxgJJQ8FE0mIMQ6/CwEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARcFineEGBKDQoIvBY8SijKPEwqBa4RciQGMOYN4H?= =?us-ascii?q?jaEGhwyhR4rgRgBAQE?= X-IronPort-AV: E=Sophos;i="5.28,529,1464652800"; d="scan'208";a="311731986" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Aug 2016 06:59:41 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u7H6xfvW000311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Aug 2016 06:59:41 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u7H6xeJE015515; Tue, 16 Aug 2016 23:59:40 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u7H6xeZZ015514; Tue, 16 Aug 2016 23:59:40 -0700 Date: Tue, 16 Aug 2016 23:59:40 -0700 From: Toerless Eckert To: consultancy@vanderstok.org Message-ID: <20160817065940.GC21039@cisco.com> References: <681a69f5cae643a7701e0df980c44a0a@xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <681a69f5cae643a7701e0df980c44a0a@xs4all.nl> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Anima-bootstrap Subject: Re: [Anima-bootstrap] keyinfra-03 review X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 06:59:45 -0000 Thank you very much, Peter! On Wed, Aug 17, 2016 at 08:51:25AM +0200, peter van der Stok wrote: > Hi Max, > > In Berlin you asked for more reviews of the keyinfra (bootstrapping) > draft. > Below my efforts from a constrained device/network point of view. > I hope the review helps to get the validity of this document for the > constrained world better understood. > > Greetings, > > Peter > > __________________________________________________________________________________________________________________ > > Anima-bootstrapping-keyinfra-03 > In general: > I think this is quite an important document to standardize autonomous > security bootstrapping in the control plane, but its relation to > constrained devices could be improved and clarified. > I found it difficult to review the document because there is much > overlapping text that describes the same protocol or function but in > different words. Also I recommend the use of consistent terminology. For > example, the terms new entity, device and new device, probably denoting > the same thing, are used throughout the document. A consistent choice > would help the reader. The terms vendor service, MASA, or just vendor > could be aligned in figures and text. As a result this is a quite > high-level review, in which I mainly try to point out ways to improve > the readability. > In more detail: > There are two authorizations in the document: a provisional one and a > definite one. Giving them different names and referring to them by these > names would help. For the moment a reader has to guess what > ???authorized??? means in different parts of the text. The term Zero-touch > approach could be explained in section 1.1. > Page 4. > The 4 questions at the top of page 4 need rephrasing. Especially the > words ???who???, ???mine???, ???it???, and ???I??? are ambiguous. > Suggest to remove in the second paragraph: ???The domain???s decisions ???. > Auditable fashion???. This is difficult to follow and needs information > provided later. > Optimal security (remove optimal) > ???Bootstrapping ??? secure???. Remove, does not help. > Last phrase before 1.1: reduce to: Support of alternative key > infrastructures is discussed. > Page 5: DomainID. Remove ???(a string value ??? is used)???. This > information does not help me. > Pledge: to at the factory (which one to or at?) > belongs with this network (you mean domain?) > section 1.2. I find the discussion in this section very hard to follow. > The general message I receive, is ???constrained networks??? are out of > scope (NO 802.15.4); unless you execute only parts of the bootstrapping > protocol. But executing parts of the protocol is not allowed. On the > other hand an argument is made about the size of the messages being > prohibitive; but it is not clear what sizes we discuss. Later in the > document (section 5.7.5) a discussion about CoAP and DTLS follows; but > the relation with this section is unclear. > My suggestion is to clarify the end state expected from the key > distribution as explained in section 3.1.7. Explain that constrained > devices may need this state, mention the intended use of coap (section > 3.2.1) and point out where the bootstrapping communication may be long > (transport of certificates) and will need the block option of CoAP. > Page 9: Is ownership tracker part of MASA? In the rest of the document > its existence seems not essential. > Section 3. The first paragraph about autonomic fashion should go to > section 1, where the relation with ACP could be clarified. In general: > Ignoring non autonomic aspects will help the readability of this > document. > Figure 2 is quite helpful, but why is there a figure 5 and 6 on pages 29 > and 30; and what are the differences? > Section 3.1 I don???t understand: ???A new entity???. been configured??? > Why not; I assume the protocol detects this behaviour. > Page 12: identify itself AND authenticate Registrar (they have equal > importance) > Page 13: point 3: why the text about nonce? This will be treated several > times later in the text. > Point 4: Very confusing to me. Many terms are used that are explained > much later, like: Audit token, ownership voucher, Registrar server > certificate. > Point 5 ???e.g. EST???. Why e.g. it seems to be the only option later in > the text. If not can it be made more explicit that other methods are > supported. > Section 3.1.1 Discovery. The standardization of the discovery of the > proxy (registrar) does not seem necessary to me. The bootstrapping > protocol is not affected at all when different discovery protocols are > used. Just citing GRASP and mDNS as examples within their context seems > more than sufficient to me. > Section 3.1.2 phrase 1; to what? does the new entity identify itself? > Paragraph 2: What is the bootstrapping protocol server here? The proxy > or the Registrar? Is it the data received from the registrar that is not > trusted? But the data from the new entity is trusted? And why is a TLS > connection needed, if no data is trusted? > Page 15, last phrase before 3.1.3: bootstrapping server -> registrar? > New device -> new entity? > Section 3.1.3. Is this where EST is started? Might be helpful to > indicate which parts are already fixed by EST. > The phrase: ???Since client authentication occurs during TLS handshake??? > is confusing. Is this the TLS handshake discussed under 3.1.2 or a new one? > Neither is it clear if this is the provisional authentication or the > final one. > This section in general needs more clarification and description of the > flow on how redirections to a different Registrar works. > Section 3.1.4 why cite the non autonomic (and non used) enrolment > protocols? > The audit token provides sufficient information to continue, but the > ownership voucher does not? > Section 3.1.5. Why this last paragraph about time distribution? > Section 3.1.6 mentions audit token and ownership voucher; but only > discusses audit token afterwards to start RFC7030 process. > Section 3.1.7 specifies the final purpose of the key distribution? IMO > part of this text should go to the introduction to motivate the > bootstrapping protocol and also show its validity for constrained > devices and networks. > 3.2 facilitates communication between ???. According to figure 2 the > registrar is not necessarily configured on the Proxy. > What is a control plane CPU? Probably text has gone missing. > Not clear from the text how/why a device becomes a proxy and by whom/how > it is configured with the relevant information like the Registrar???s > address. > Section 3.2.1 The choice between DTLS and TLS appears all of the sudden. > All former text discussed TLS; I suggest that a different section is > dedicated to use of CoAP, describes the http/TLS to coap/dtls mapping, > and the draft consistently uses TLS for clarity. Section 3.2.1. is then > more dedicated to the discovery and keeping proxy stateless. > Section 3.2.2 suggests multiple options to proxy the connection to the > Registrar. Can other methods be used beyond that are listed here. > Section 3.3.1 should the out of band be cited here? The draft describes > autonomic behaviour. > End of section 3.3.2; why the emphasis on homenet? > Section 3.3.3, 2nd paragraph; examples might be handy? > Section 3.3.3 Claims for an unauthenticated Registrar are only???; Is this > a viable approach? > Section 3.4 Factory provider? > Section 3.5 As the devices have a common trust anchor??? Please make > devices more explicit. > Section 3.5.1. device -> new entity > The new entity can validate the domain membership after joining? You > mean it can act as proxy? > Section 3.6 Network access Control? Where does this term come from? > What does ???having sufficient connectivity??? mean? > Section 4.4 Zero-touch is an unknown term. > Already enrolled devices -> proxies. > Section 4.5 What are central control functions? > Section 5 repeats much of earlier sections. I suggest to remove text in > earlier sections (or make more abstract) to minimize duplication. > What is an ???air-gapped??? network? Referring in the text to fig 5 and fig > 6 and pointing out the differences helps readability. > Here my review stops; The technology seems already quite solid if the > proxy behaviour with IPIP encapsulation of the TLS messages are better > clarified. The text needs quite some editing to remove duplication, > improve consistency, and remove many of the design decision discussions. > I hope my comments may help. > > Greetings, > > Peter > > -- > Peter van der Stok > > _______________________________________________ > Anima-bootstrap mailing list > Anima-bootstrap@ietf.org > https://www.ietf.org/mailman/listinfo/anima-bootstrap -- --- Toerless Eckert, eckert@cisco.com From nobody Wed Aug 17 01:59:05 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DE012D0B0; Wed, 17 Aug 2016 01:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.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 XV3HGHSrYLbg; Wed, 17 Aug 2016 01:59:01 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0121.outbound.protection.outlook.com [104.47.1.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2330312D08C; Wed, 17 Aug 2016 01:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WjyYz1Ay0axL+SP2F6KJWc4SdkD8p9c0e6yfpbPUDCA=; b=QvZLzlhzWazE6t71aUWbh3rA3HOV72yZ1QHGQWo19vnRqvGxJ4Ms5SHYnUJ6i9znRVE4qbZHzoS++Gy0ktAcCrnmJcXY7g2Cp9loO3QqUJ00FK67IPLoL+9p27OZHumia2+41Q89/kpm0zr1BxI00X6uXYCw2yNJKzw4rYmNKyU= Received: from AM3PR04CA0063.eurprd04.prod.outlook.com (10.164.94.31) by DB5PR04MB1495.eurprd04.prod.outlook.com (10.162.221.153) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.5; Wed, 17 Aug 2016 08:58:57 +0000 Received: from DB3FFO11FD009.protection.gbl (2a01:111:f400:7e04::176) by AM3PR04CA0063.outlook.office365.com (2a01:111:e400:52b6::31) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.5 via Frontend Transport; Wed, 17 Aug 2016 08:58:57 +0000 Authentication-Results: spf=none (sender IP is 40.103.22.84) smtp.mailfrom=philips.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (40.103.22.84) by DB3FFO11FD009.mail.protection.outlook.com (10.47.216.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.567.7 via Frontend Transport; Wed, 17 Aug 2016 08:58:57 +0000 Received: from VI1PR9003MB0237.MGDPHG.emi.philips.com (129.75.99.82) by VI1PR9003MB0238.MGDPHG.emi.philips.com (129.75.99.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Wed, 17 Aug 2016 08:58:54 +0000 Received: from VI1PR9003MB0237.MGDPHG.emi.philips.com ([129.75.99.82]) by VI1PR9003MB0237.MGDPHG.emi.philips.com ([129.75.99.82]) with mapi id 15.01.0549.027; Wed, 17 Aug 2016 08:58:54 +0000 From: "Kumar, Sandeep" To: Anima WG Thread-Topic: [Anima-bootstrap] keyinfra-03 review Thread-Index: AQHR+FPUPUpeI2F640erOWrjfLbVa6BM1IJw Date: Wed, 17 Aug 2016 08:58:54 +0000 Message-ID: References: <681a69f5cae643a7701e0df980c44a0a@xs4all.nl> In-Reply-To: <681a69f5cae643a7701e0df980c44a0a@xs4all.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.108] X-MS-Office365-Filtering-Correlation-Id: 8106c4c4-ed5c-4f51-a78b-08d3c67cb97b Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OrganizationHeadersPreserved: VI1PR9003MB0238.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:40.103.22.84; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(428002)(374574003)(199003)(55904004)(85714005)(377454003)(71364002)(85664002)(189002)(13464003)(7736002)(33646002)(356003)(105586002)(86362001)(305945005)(50466002)(108616004)(92566002)(450100001)(7696003)(106116001)(23676002)(87936001)(81156014)(81166006)(3846002)(6116002)(586003)(626004)(102836003)(7846002)(8676002)(19580405001)(189998001)(19580395003)(110136002)(106466001)(8936002)(66066001)(54356999)(97736004)(101416001)(76176999)(4326007)(10400500002)(11100500001)(50986999)(24736003)(47776003)(16796002)(2900100001)(2950100001)(2906002)(15975445007)(68736007)(69596002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR04MB1495; H:011-smtp-out.Philips.com; FPR:; SPF:None; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD009; 1:uF9CUIIjE5i7Ayk/hwPjynh2g8nktbHiNH2zc0WGDussCia3lLzTPeZrvGjfgeoyhf9KpuDs83rv+RERssxucqSoPrPJAtFAvizOtmQNWNOK45ktJeZKmd5CF+N8EFdYAI/Zu2ahsqignmbYdHVCVqZ/q5k1tB4AOcm86Z2yK4X18l8fLHHrHE2LzVNJNt9+corgZ8MndkGMQVxGdywZVIS/3Y4jbvZZbkizS+CZTaKNf/zRuZAcuofIyZwyWrKRomSwRc/NlmXk7LnRFLFwI50YRnwXI0eL7zaygrKXYNjXLh13gcOSlGi7h2fj+xJreeYMmcFRsLsWEYc3CWJivbvJFovCTklzVqlEvcyOFX/1x1vIZs2KUbRz5S69PGdWx7iUwn6CiRgMsxVcZ9UdFqXxog8YvhcFJ2OWH/qrqFnlqvQnsMg+s2SouJTaDSSwfJwQHWJuZLcbQPV1q0IRYdn3ycKJYgzqqczZeK43ar4= X-CrossPremisesHeadersFiltered: DB3FFO11FD009.protection.gbl X-Microsoft-Exchange-Diagnostics: 1; DB5PR04MB1495; 2:JmAQi//B3P8Tt8yMhcGZv4j9fKUt8dgCdurJ3aS8Rnfo1XPVPtKm/S2XsPpXjFOQu0o5HA5kkH3xmK8sIBypTxr4keHTBvMBTazhuNzvt5kEJe3zT/fkwR1LOaqYQB4Px+T41kClQua5Ztv3Qpr0I2m7BXyTqdq5q4cFos3busV4dhtevUtQSbrCG/wkDvmy; 3:4SKBttuvyKsXeseBDlwD5adb+GlhhZR+4v9BQy35QKzLcGXk965LBt8Tmi2c/QRgPZbTR52JNrHlTxoB+JgdsDu6ULuxcMki8b91UH/GwiQSt0qx2iVHsipoGezu6bxs50Ro9rK+5/hfNNlLBNiTaExFfiB4/tgl2/7lB0FjKMFW+ouiU/dWbphXUHXNu9JCalEGZMi/Z2//YkP/yVnSb/ElKHncjq9O5PoRC+Dhcq4= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR04MB1495; X-Microsoft-Exchange-Diagnostics: 1; DB5PR04MB1495; 25:sQAzk5L6km3d8ztdQpbW0qjwjRnYW6DfwSYd/suCIpWyy5FPoFXYKKUYJqxJ2rMZSAQB1qpp1SE/Gu8MshBtpxokdX5xV2KXVZbjvbs9vnYwJFR/zMnx0pcja7ySnfzfhyRs7oyals7svedNFs/l5+xHDI8uKG77X65Kou+qKpI9ynw2w9Q7AZOwxybMsa8+77klMkc6DRvinslAm6LSo9NpaLKAc//v9jZEgriLb9miFUhKh+Bc8i9p3nVQhvKS2/9fAvbYB3aeA0i+VtTnuj52EfbouvOhCB3LhUPacst7qpykUqi+c4Mgb3AaS0vXFbD2p/V7AesE4TBDpgzJbfNPg8lILPYtFRhWXxEcOX7x9TxG9ma8qCdHIy0nCm7BZEeFY8Zru08tHT58OwwLqRQ6aDMmLPFBt+WSIcTHFowl16PodqXroIE0dOl+RgnwWZHvB0GRNqtyYgl+RWkho6UsPOn25fgn3nnm+iZ5IkDSht1HT0B1RYHADK9qlVyVuLd0MZuzliGiWBJSIi+KBKvfpic6pbgMLPyHBI2D+FQgzG5AnwAU5WNG8MWw/ipf9WnJ0tkaW6mPWMnbFbzX8T0k0Ffl8dYmAWf95sH0Tu8kVtUp+Cj7IS7CPdW0C48LQEJLEf73PQ2DjHAVT7ItBCLI2bg6gAHS/JNNdDKFsCCZMf6Nb6hnQzPNKeBDES1uONqd1x/euNr+DOX6yosCtSbPk8mDDAHggZ49P7xtciGM4CDLkZkWA9C4BvOQU1KBt+Lr6YUx9MjdqqqvncRYTcD7W0wUk5bOnR5ffIHUgoT2a8tfH15QhBNnU3edYMEio4wtlgIOWIU23cwVCYdx6d1ckLDhdwrodiZxM79R1GCm9tuR7D9duM9nnywk1S+AbCO9LqQ4jWPKn/fKN0OrKA== X-Microsoft-Exchange-Diagnostics: 1; DB5PR04MB1495; 31:rMnc3XI9P4SzesvkP1aKkAinsEXSQm80lsPzo6/8YJOY2Asu2E90YUDMcYU5DIcprPft4cr4L8uMtG7SnYwU2zB6B1OduF3mSf/cUAu6e4aRdWzJ5VsTqUqwXahmG33xqxkURZ+66B9RtS1yFiC/3Tv7PXcYhv41lPTJlkkhKqD5Swm/XjeRGo9cE+fMPt6VWbsu3yUFCIjYfclMoV48TrtwST8qTDCpUle4VEsb5Vw=; 20:ZmfSfzM+Vd/Wmr8VvXZaXBwYdgeSWmPcRtBa9k3KCv0isXEeDEyiWS75HMdHiSEMNNfpzs3RIux3FsjjOINqdept+y+3ZuDSP3PPGA3IVH2Xy+Owi2Nyx7CtNkULiuhCaCLQYGddDBzAmbtGJKaZLhwSp7upP+xxjUTQa0LlimY9i0EHj/n8359nJ4aXyLLUdKjV1JCIVcU3drDMmw4D8Ohv4Y5DfSFIX7UaLyPvmX6gefIGVvpRJYq1Yk65JNqW0F4cBHEBy14zboXDPRT/KQaDjG7Z61FVG+F2OzdloW2JHqD/n5igOM/dKI/hdJCD/WRUNHjvwFVGcNLw/1bI/Eib+OL64rCQMAZtyBIDqWXSojzfe1oPNh71wtmm+GlSMy0iJcPo3cP2s0Vs01rcqSEbvxmLWj5myPRq/1INxy8Su0lhoxaIVDA7ETfN9xq0p2M7YoK3R6Rv+dI80JfrXtupSdwbYA03Frt4u74OliCm4ekyxCmhUBe86L9/nIay X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(60795455431006)(158342451672863)(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(13018025)(8121501046)(13016025)(5005006)(10201501046)(3002001)(6055026); SRVR:DB5PR04MB1495; BCL:0; PCL:0; RULEID:; SRVR:DB5PR04MB1495; X-Microsoft-Exchange-Diagnostics: 1; DB5PR04MB1495; 4:tT1jfwV6Oplx9jLbonJ6WRch+GLvEpQwWtwzkuWB8tldYqBfytLq000E9yxn0mOIYO9Nc52svJXKR7znr0PLlf0FaA/Lv3h1pyTFK+MsA61cVe29Zmzx4cRCaDHD6Br18d6/g2xB23zEMXACFuAHy2F/2qb88Rwbk+w0fFpKGfWx8cPLyeYK0tx62SOia8Q60W+/axKA8UomE9Dv+Wf9zlv+NTBiRO/E+uam2gPT70o0j8jcnAgVoOpo9CbGcn3kNHL2pwm58ZiYGEZs2/SH1sOsJDI7l0rPPcPIvpbmNQdA9egsmdZjeDoNV+myXjmKdzyX3t3Vte/BnOfluM58wMNlZf5rc0QFJrlEw6qhvxQEoRC2hnNbEMnzbmJvj4uhlizS9xSb1NNlBRqn5/e88pB/5iiqaXlOxBCc3usnwwR2Y1iUabxjlWaAQKY/JQj44QNypzR6K5xvbdcVnPwbo1mih4pTWNAKlRXgxLU8o8IUHaqJ7mt7fks+pOQzhSUZdzUIHt97eUdjAmQ9B0i3YsgCi6C9SuKI2h9RSHseP9JhRibRsTxEbnzfLvVaDjwy X-Forefront-PRVS: 0037FD6480 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjA0TUIxNDk1OzIzOnRYRkhMbjR5OUxGNkpNeHp1VktEMEs4Z01v?= =?utf-8?B?RWNtenNKeVZNdEtqWUdUcFZ1d2lpL0ErSXVWUFFjVzR4RjNLK0pXcmdjWlNn?= =?utf-8?B?VVRjT3R2bWxrNnBreFdubHhOeFdKT0twM1ZLNERCQ0MyekQwQmY1U0VEY0o0?= =?utf-8?B?TFIrZ2N2VnMrWmdVNWptOXM2UE1KRXp5UWdGcW9LTlRVSnkvclJjazZkbkpD?= =?utf-8?B?ZXAzbXR3N1BiK0k2R2NVRTdvVEFaZjRNY0hxOWdYZjFUclBPUUdnKzgxS05J?= =?utf-8?B?V010RnRiNForNVJkbStlMFU1WEtiMFRTWjcyOEh5L2NsZk5jQ2hKc3BVWENL?= =?utf-8?B?NU13ZjFJRUR1aURsYjJpa3NBckczTmVHdXZBai9RT3l3NU81MW1BNUxESEha?= =?utf-8?B?b1A3VzdNOExKdThEUXE2bW5QL0hkV3JDL2t1Y2pJWE9Udmx0bDlVS3g2RnRk?= =?utf-8?B?Z2pPdlRrRDNyZzdoUVJqRStva29LY3kyRU12OTlWRUxIYmcxYlY3Wk45R1V2?= =?utf-8?B?SVRFUW52SFZIS2dPYUtGZEFxMjVPZHAxKzZVUm9qbU5wYkJzQ05XWURqUTJP?= =?utf-8?B?NFl5eDZQL2tNSGhqNHR4SHJDS3RhUkFqOGlvR0ZQRkhlZGJWVmd2RnJEc2h1?= =?utf-8?B?dmk2Q1FxKzFUeEtWWUJIakNkRHovS29iaXJ5c29mdXRqZnZoUU1kclE5MzZ0?= =?utf-8?B?Z0dWWGNuZlJOVk9Nak84NncrZFhvRnUxdWUydVRELy9SYkZ2RnRDMnFFcnpK?= =?utf-8?B?cEJCUlBXYVdYZURXUzJjYmtMcUptTmVBTXo5R3ZmMGtMRG81UnJlMVBmVW0y?= =?utf-8?B?Um9RSjJpcVVRR3IwT01XSXJTbVZKSGdudmlBRkM2ZHFSSEtzanpaNis5SEht?= =?utf-8?B?eW03c3ZuTlhMNENLM2h1SmVpbk5sQnRFb0xBOU8yNWlrSjcwZStKRWhIRXpP?= =?utf-8?B?TzM4TDlIWFBLcVdtRTV6V1FsanRmdVNxOStDd2RrdzRaZEg0S1h5YkRoQytk?= =?utf-8?B?UGswQTR3Vi8rSVRVdmRzdUJ3OSt3Q0Rmd1VGaDRXWk9xb2d2NVRiL0FzdGhk?= =?utf-8?B?dUJmbUZIRDNmZTAwN29sdkFiOTd4SHord29FZk5RNVNUa1ErUWpLYndaY0ZW?= =?utf-8?B?UXJQcDBXUWt1ZzR0VG93c0xHT1Z1Qk5CN1hSeGRVOEpaeGpINmtIbGVINnpw?= =?utf-8?B?N25OK0ZqY3JQQmMyUGZ5d2VsK2tVZVlXS044MmFDVzdTazVHTEptNVU4VmJ5?= =?utf-8?B?T2ppY0pzV0FiU1pMQzdqellzNXIrSUFBSDFMc3k1WVhUcFNpSWdSY05UNFB2?= =?utf-8?B?bDYrMGJpM2hiRS8vZzgwWEFzeVdnQnlHT0dPbGdJRlNRcGFVTEl3aDU5QmZ4?= =?utf-8?B?Sm9uQXp5NXJSL1VuVU9ZMlRVRDRxczhIUU1wd01pT1pDY05tUHd6aWJEZVlH?= =?utf-8?B?dFYwWjdpWVNNRkdDaktaUUxvOUFPWUdxbHQ3SWlCeEh3djBQZk40TUI5OWpv?= =?utf-8?B?cFZwem5DelNGZ1lXZ0NVNWp3VkR2NW5sTzQ5alVhU0xUeG85Uy95dEl1VWxp?= =?utf-8?B?RzdVYWV6KzBESmJWNmZTeHVEMGlULzhuVTVpci9zNEFJV2x5RmN0S2YyZVpX?= =?utf-8?B?cGRkWnJEMU1XeG5McUU5OWJQN3YyVGo0VUNKdTVtRlhwNEpDYTcwUjNwQm1L?= =?utf-8?B?cUlEeUZ0dDRwM1czUmNqWG9WdE1iSnZ4K1ZMR1ozc2R3NDhmUUFlbGMxalFi?= =?utf-8?B?V3VMR2RUdjlod0JnVnFOckx5cWw4aklaSTJ2T092UUJ3STczUjZDN0hkam05?= =?utf-8?B?N2xxZTJOa3N4NEoyb3haa09ybFdwMUF3Qk03NnIyejhkeGNPSnV1UTZQU3ph?= =?utf-8?B?SndhcWVRQVlpSUJVTkJBYWhZRnROY2d6eUg5NXFlMXRVc0xqQTF4ZkNqaVdy?= =?utf-8?Q?DalCIAbCD0QwRkQWSUFAlg3hlk7G7I=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR04MB1495; 6:wzkQ4d5rRVHU4Wr+JamZeLz//yGXN4tWK5V96J/dCHR52J1bDyk3Tp9/W9KO28JBrOtMf7ZxHnHSrMX7w/6ZcqdGrmJrIewCQsgwVclk6ryASVrTFAZ2UpKa/HgekWJlxYV1g2R4PBu9XXwpY4XMFoFls4uvyfJQGiCa4pgSOWQ1PA3UZ7d+FlEtKA/aCDCVuK0kXSfM15RYxqHKJq/15ImGRNjNGF5SqSjwdW1DlDQiSHaJOnWoTSthBEmnbWjKc37MQq78IsQiocToWkB4IdVznbOEMRjOah9t5qYGdnBybffN0Ie4W4chz1qt/y8+Nf5QX/KEGKt2j3ZncSQmOg==; 5:5p7oTuByO1QPlXkjm5rwzYMJSRK/22OGFjPYvZ3uhlU+rgUtwoXgxPKSZiLAtjfOvhF2qVQUz4RCoQGSVR4E2OPk9Hg2EfZekZMgGbiz/eUdRCxy7h0WtnlGdII5bzZEAFCqOU+XKZTRc3YEjw9Q7Q==; 24:skTpCTrm+qaIY3qPp0Zo7nSW3YU/kYjw2C4qb+1q0kVQ2rP7ttUx6aiEu5bey0/UrBW3D7Nx3qvs2JZz4X7B1APWLNZ2fIk0sb8zlOv5GO8=; 7:0hLB6pLgVyoVfSkc3x7QU2aYtSQVAtkidFp/ZXHtpXK2ugQ+ytuFv22QW/xjlJ3eSPKSr1Pm2MH8VyO2j+LTu73dECz5sg/3hmiOvh80YUyOqBX3NAVW/qEphxRLnNAI5gT21wRs9eWaKkRza38pB0pxB3rs8MJ4Vyk0QdX+0osSMPEyMHjLFWuiIjOMSLz9UN8G7VPxKZnztEI+yYQz0WJjb2333fKcumXWwlnbyzR6lMM6KOu/4GTqltzqBBMf SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2016 08:58:57.2016 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[40.103.22.84]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR04MB1495 X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 40.103.22.84 X-MS-Exchange-CrossPremises-AuthSource: DB3FFO11FD009.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: DB5PR04MB1495.eurprd04.prod.outlook.com Archived-At: Cc: Anima-bootstrap Subject: [Anima-bootstrap] FW: keyinfra-03 review X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 08:59:05 -0000 RGVhciBhbGwNCg0KQWxzbyBmb3J3YXJkaW5nIHRoZSByZXZpZXcgdG8gQW5pbWEgc2luY2UgSSB0 aGluayBQZXRlciByYWlzZXMgc29tZSBpbnRlcmVzdGluZyBwb2ludHMgd2hpY2ggcmVxdWlyZXMg bW9yZSBjbGFyaWZpY2F0aW9uLg0KLSBIb3cgaXMgdGhlIHByb3h5IHNlbGVjdGVkLCBieSB3aG9t IGFuZCBob3cgaXMgaXQgY29uZmlndXJlZCB3aXRoaW4gdGhlIGF1dG9ub21vdXMgZG9tYWluPw0K LSBJcyB0aGUgcmVsYXlpbmcgb2YgVExTIHRocm91Z2ggdGhlIHByb3h5IGZpbmFsaXplZC4gVGhl cmUgYXJlIHZhZ3VlIHJlZmVyZW5jZXMgdG8gbXVsdGlwbGUgb3B0aW9ucyBsaWtlIElQSVAgYW5k IFRDUCBjaXJjdWl0IHByb3h5LiBJcyB0aGUgaW50ZW50aW9uIHRvIHN1cHBvcnQgb25seSBvbmUg b3IgaGF2ZSBvbmUgbWFuZGF0b3J5IHdpdGggbXVsdGlwbGUgb3RoZXIgcHJveHkgdHlwZXMgc3Vw cG9ydGVkIGJ5IHRoZSBSZWdpc3RyYXI/IFRoZSByZWFzb24gSSBhc2sgaXMgYmVjYXVzZSBhIERU TFMgcmVsYXlpbmcgbWV0aG9kIGlzIHdlbGwgZGVmaW5lZCB3aXRoaW4gYW4gZXh0ZXJuYWwgc3Rh bmRhcmRpemF0aW9uIGJvZHkgYW5kIHdvdWxkIGxpa2UgdG8ga25vdyBpZiB0aGF0IGNhbiBiZSBz dXBwb3J0ZWQgZW5kLXRvLWVuZCB3aXRoIHRoZSBSZWdpc3RyYXIuDQoNCkluIGFkZGl0aW9uIHRv IFBldGVyJ3MgY29tbWVudHMgd2hhdCBJIGFkZGl0aW9uYWxseSBtaXNzIGZyb20gdGhlIGN1cnJl bnQgZHJhZnQgYXJlDQotIFRoZXJlIGlzIG5vIGF1dGhvcml6YXRpb24gb2YgdGhlIFJlZ2lzdHJh ciB0byByZXF1ZXN0IGRldmljZSBhdWRpdCB0b2tlbnMsIG1ha2luZyBpdCBlYXN5IGZvciBhbnlv bmUgdG8gc3RlYWwgZGV2aWNlcyBiZXR3ZWVuIHRoZSBpbnN0YWxsYXRpb24gYW5kIGNvbW1pc3Np b25pbmcgcGhhc2UgKHdoaWNoIGNhbiBiZSBxdWl0ZSBsb25nIGluIGNlcnRhaW4gaW5zdGFsbGF0 aW9ucykuIFRoZSBpZGVhIG9mIGFuIG93bmVyc2hpcCB0cmFja2VyIGJhc2VkIG9uIHNhbGVzIGRh dGEgaXMgY29tcGxldGVseSBpbXByYWN0aWNhbCBpbiBtYW55IGluZHVzdHJ5IGRvbWFpbnMuIFRo aXMgbGVhdmVzIGEgY29tbWlzc2lvbmVyIHdobyBhcnJpdmVzIGF0IGEgbG9jYXRpb24gd2l0aCBh IHByb3NwZWN0IHRoYXQgaGUgY2Fubm90IGNvbW1pc3Npb24gdGhlIGRldmljZXMgYW55bW9yZSBz aW5jZSB0aGV5IGhhdmUgYmVlbiBhbHJlYWR5IHN0b2xlbiBhbmQgbmVlZHMgdG8gcmVjYWxsIHRo ZSBpbnN0YWxsYXRpb24gZ3V5cyBiYWNrIHRvIGZhY3RvcnkgcmVzZXQgZGV2aWNlcyAod2hpY2gg bWVhbnMgbGFkZGVycywgcmVtb3ZpbmcgZmFsc2UgY2VpbGluZywgb3IgdG8gc2ltcGx5IHVubmVj ZXNzYXJ5IGNvc3RzKS4NCi0gSW4gbWFueSBzaXR1YXRpb25zIChsaWtlIG5ldyBidWlsZGluZ3Mp IGEgRW50ZXJwcmlzZSBkb21haW4gcmVnaXN0cmFyIGRvZXNuJ3QgZXhpc3QgYW5kIHRoZXJlIGlz IGEgbmVlZCB0byBicmluZyBkZXZpY2VzIGludG8gYSB0ZW1wb3JhcnkgZG9tYWluIChsaWtlIGEg Y29tbWlzc2lvbmluZyB0b29sIGFjdGluZyBhcyB0aGUgcmVnaXN0cmFyKSB0byBiZSBsYXRlciB0 cmFuc2ZlcnJlZCB0byBhIHJlYWwgZG9tYWluIHdoZW4gYXZhaWxhYmxlLiBIb3dldmVyIHRoZSBk cmFmdCBzZWVtcyB0byBjb21wbGV0ZWx5IGlnbm9yZSBhbnkgaGFuZG92ZXIgcmVxdWlyZW1lbnRz IGFuZCBzb2x1dGlvbnMgd2hpY2ggYXJlIHZlcnkgcmVsZXZhbnQgaW4gcHJhY3RpY2UgdG8gbWFr ZSB0aGlzIHVzZWZ1bC4NCg0KS2luZCByZWdhcmRzDQpTYW5kZWVwDQoNCg0KRHIuIFNhbmRlZXAg Uy4gS3VtYXINClNlbmlvciBTY2llbnRpc3QgLSBTZWN1cml0eSwNClBoaWxpcHMgTGlnaHRpbmcg UmVzZWFyY2gsDQpFaW5kaG92ZW4sIFRoZSBOZXRoZXJsYW5kcy4NCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogQW5pbWEtYm9vdHN0cmFwIFttYWlsdG86YW5pbWEtYm9vdHN0 cmFwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBwZXRlciB2YW4gZGVyIFN0b2sNClNl bnQ6IFdlZG5lc2RheSwgQXVndXN0IDE3LCAyMDE2IDg6NTEgQU0NClRvOiBBbmltYS1ib290c3Ry YXAgPGFuaW1hLWJvb3RzdHJhcEBpZXRmLm9yZz4NClN1YmplY3Q6IFtBbmltYS1ib290c3RyYXBd IGtleWluZnJhLTAzIHJldmlldw0KDQpIaSBNYXgsDQoNCkluIEJlcmxpbiB5b3UgYXNrZWQgZm9y IG1vcmUgcmV2aWV3cyBvZiB0aGUga2V5aW5mcmEgKGJvb3RzdHJhcHBpbmcpIGRyYWZ0Lg0KQmVs b3cgbXkgZWZmb3J0cyBmcm9tIGEgY29uc3RyYWluZWQgZGV2aWNlL25ldHdvcmsgcG9pbnQgb2Yg dmlldy4NCkkgaG9wZSB0aGUgcmV2aWV3IGhlbHBzIHRvIGdldCB0aGUgdmFsaWRpdHkgb2YgdGhp cyBkb2N1bWVudCBmb3IgdGhlIGNvbnN0cmFpbmVkIHdvcmxkIGJldHRlciB1bmRlcnN0b29kLg0K DQpHcmVldGluZ3MsDQoNClBldGVyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpBbmltYS1ib290c3RyYXBwaW5nLWtleWluZnJh LTAzDQpJbiBnZW5lcmFsOg0KSSB0aGluayB0aGlzIGlzIHF1aXRlIGFuIGltcG9ydGFudCBkb2N1 bWVudCB0byBzdGFuZGFyZGl6ZSBhdXRvbm9tb3VzIHNlY3VyaXR5IGJvb3RzdHJhcHBpbmcgaW4g dGhlIGNvbnRyb2wgcGxhbmUsIGJ1dCBpdHMgcmVsYXRpb24gdG8gY29uc3RyYWluZWQgZGV2aWNl cyBjb3VsZCBiZSBpbXByb3ZlZCBhbmQgY2xhcmlmaWVkLg0KSSBmb3VuZCBpdCBkaWZmaWN1bHQg dG8gcmV2aWV3IHRoZSBkb2N1bWVudCBiZWNhdXNlIHRoZXJlIGlzIG11Y2ggb3ZlcmxhcHBpbmcg dGV4dCB0aGF0IGRlc2NyaWJlcyB0aGUgc2FtZSBwcm90b2NvbCBvciBmdW5jdGlvbiBidXQgaW4g ZGlmZmVyZW50IHdvcmRzLiBBbHNvIEkgcmVjb21tZW5kIHRoZSB1c2Ugb2YgY29uc2lzdGVudCB0 ZXJtaW5vbG9neS4gRm9yIGV4YW1wbGUsIHRoZSB0ZXJtcyBuZXcgZW50aXR5LCBkZXZpY2UgYW5k IG5ldyBkZXZpY2UsIHByb2JhYmx5IGRlbm90aW5nIHRoZSBzYW1lIHRoaW5nLCBhcmUgdXNlZCB0 aHJvdWdob3V0IHRoZSBkb2N1bWVudC4gQSBjb25zaXN0ZW50IGNob2ljZSB3b3VsZCBoZWxwIHRo ZSByZWFkZXIuIFRoZSB0ZXJtcyB2ZW5kb3Igc2VydmljZSwgTUFTQSwgb3IganVzdCB2ZW5kb3Ig Y291bGQgYmUgYWxpZ25lZCBpbiBmaWd1cmVzIGFuZCB0ZXh0LiAgQXMgYSByZXN1bHQgdGhpcyBp cyBhIHF1aXRlIGhpZ2gtbGV2ZWwgcmV2aWV3LCBpbiB3aGljaCBJIG1haW5seSB0cnkgdG8gcG9p bnQgb3V0IHdheXMgdG8gaW1wcm92ZSB0aGUgcmVhZGFiaWxpdHkuDQpJbiBtb3JlIGRldGFpbDoN ClRoZXJlIGFyZSB0d28gYXV0aG9yaXphdGlvbnMgaW4gdGhlIGRvY3VtZW50OiBhIHByb3Zpc2lv bmFsIG9uZSBhbmQgYSBkZWZpbml0ZSBvbmUuIEdpdmluZyB0aGVtIGRpZmZlcmVudCBuYW1lcyBh bmQgcmVmZXJyaW5nIHRvIHRoZW0gYnkgdGhlc2UgbmFtZXMgd291bGQgaGVscC4gRm9yIHRoZSBt b21lbnQgYSByZWFkZXIgaGFzIHRvIGd1ZXNzIHdoYXQg4oCcYXV0aG9yaXplZOKAnQ0KbWVhbnMg aW4gZGlmZmVyZW50IHBhcnRzIG9mIHRoZSB0ZXh0LiBUaGUgdGVybSBaZXJvLXRvdWNoIGFwcHJv YWNoIGNvdWxkIGJlIGV4cGxhaW5lZCBpbiBzZWN0aW9uIDEuMS4NClBhZ2UgNC4NClRoZSA0IHF1 ZXN0aW9ucyBhdCB0aGUgdG9wIG9mIHBhZ2UgNCBuZWVkIHJlcGhyYXNpbmcuIEVzcGVjaWFsbHkg dGhlIHdvcmRzIOKAnHdob+KAnSwg4oCcbWluZeKAnSwg4oCcaXTigJ0sIGFuZCDigJxJ4oCdIGFy ZSBhbWJpZ3VvdXMuDQpTdWdnZXN0IHRvIHJlbW92ZSBpbiB0aGUgc2Vjb25kIHBhcmFncmFwaDog 4oCcVGhlIGRvbWFpbuKAmXMgZGVjaXNpb25zIOKApi4NCkF1ZGl0YWJsZSBmYXNoaW9u4oCdLiBU aGlzIGlzIGRpZmZpY3VsdCB0byBmb2xsb3cgYW5kIG5lZWRzIGluZm9ybWF0aW9uIHByb3ZpZGVk IGxhdGVyLg0KT3B0aW1hbCBzZWN1cml0eSAocmVtb3ZlIG9wdGltYWwpDQrigJxCb290c3RyYXBw aW5nICDigKYgc2VjdXJl4oCdLiBSZW1vdmUsIGRvZXMgbm90IGhlbHAuDQpMYXN0IHBocmFzZSBi ZWZvcmUgMS4xOiByZWR1Y2UgdG86IFN1cHBvcnQgb2YgYWx0ZXJuYXRpdmUga2V5IGluZnJhc3Ry dWN0dXJlcyBpcyBkaXNjdXNzZWQuDQpQYWdlIDU6IERvbWFpbklELiBSZW1vdmUg4oCcKGEgc3Ry aW5nIHZhbHVlIOKApiBpcyB1c2VkKeKAnS4gVGhpcyBpbmZvcm1hdGlvbiBkb2VzIG5vdCBoZWxw IG1lLg0KUGxlZGdlOiB0byBhdCB0aGUgZmFjdG9yeSAod2hpY2ggb25lIHRvIG9yIGF0PykNCiAg YmVsb25ncyB3aXRoIHRoaXMgbmV0d29yayAoeW91IG1lYW4gZG9tYWluPykgc2VjdGlvbiAxLjIu IEkgZmluZCB0aGUgZGlzY3Vzc2lvbiBpbiB0aGlzIHNlY3Rpb24gdmVyeSBoYXJkIHRvIGZvbGxv dy4NClRoZSBnZW5lcmFsIG1lc3NhZ2UgSSByZWNlaXZlLCBpcyDigJxjb25zdHJhaW5lZCBuZXR3 b3Jrc+KAnSBhcmUgb3V0IG9mIHNjb3BlIChOTyA4MDIuMTUuNCk7IHVubGVzcyB5b3UgZXhlY3V0 ZSBvbmx5IHBhcnRzIG9mIHRoZSBib290c3RyYXBwaW5nIHByb3RvY29sLiBCdXQgZXhlY3V0aW5n IHBhcnRzIG9mIHRoZSBwcm90b2NvbCBpcyBub3QgYWxsb3dlZC4gT24gdGhlIG90aGVyIGhhbmQg YW4gYXJndW1lbnQgaXMgbWFkZSBhYm91dCB0aGUgc2l6ZSBvZiB0aGUgbWVzc2FnZXMgYmVpbmcg cHJvaGliaXRpdmU7IGJ1dCBpdCBpcyBub3QgY2xlYXIgd2hhdCBzaXplcyB3ZSBkaXNjdXNzLiBM YXRlciBpbiB0aGUgZG9jdW1lbnQgKHNlY3Rpb24gNS43LjUpIGEgZGlzY3Vzc2lvbiBhYm91dCBD b0FQIGFuZCBEVExTIGZvbGxvd3M7IGJ1dCB0aGUgcmVsYXRpb24gd2l0aCB0aGlzIHNlY3Rpb24g aXMgdW5jbGVhci4NCk15IHN1Z2dlc3Rpb24gaXMgdG8gY2xhcmlmeSB0aGUgZW5kIHN0YXRlIGV4 cGVjdGVkIGZyb20gdGhlIGtleSBkaXN0cmlidXRpb24gYXMgZXhwbGFpbmVkIGluIHNlY3Rpb24g My4xLjcuIEV4cGxhaW4gdGhhdCBjb25zdHJhaW5lZCBkZXZpY2VzIG1heSBuZWVkIHRoaXMgc3Rh dGUsIG1lbnRpb24gdGhlIGludGVuZGVkIHVzZSBvZiBjb2FwIChzZWN0aW9uDQozLjIuMSkgYW5k IHBvaW50IG91dCB3aGVyZSB0aGUgYm9vdHN0cmFwcGluZyBjb21tdW5pY2F0aW9uIG1heSBiZSBs b25nICh0cmFuc3BvcnQgb2YgY2VydGlmaWNhdGVzKSBhbmQgd2lsbCBuZWVkIHRoZSBibG9jayBv cHRpb24gb2YgQ29BUC4NClBhZ2UgOTogSXMgb3duZXJzaGlwIHRyYWNrZXIgcGFydCBvZiBNQVNB PyBJbiB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQgaXRzIGV4aXN0ZW5jZSBzZWVtcyBub3QgZXNz ZW50aWFsLg0KU2VjdGlvbiAzLiBUaGUgZmlyc3QgcGFyYWdyYXBoIGFib3V0IGF1dG9ub21pYyBm YXNoaW9uIHNob3VsZCBnbyB0byBzZWN0aW9uIDEsIHdoZXJlIHRoZSByZWxhdGlvbiB3aXRoIEFD UCBjb3VsZCBiZSBjbGFyaWZpZWQuIEluIGdlbmVyYWw6DQpJZ25vcmluZyBub24gYXV0b25vbWlj IGFzcGVjdHMgd2lsbCBoZWxwIHRoZSByZWFkYWJpbGl0eSBvZiB0aGlzIGRvY3VtZW50Lg0KRmln dXJlIDIgaXMgcXVpdGUgaGVscGZ1bCwgYnV0IHdoeSBpcyB0aGVyZSBhIGZpZ3VyZSA1IGFuZCA2 IG9uIHBhZ2VzIDI5IGFuZCAzMDsgYW5kIHdoYXQgYXJlIHRoZSBkaWZmZXJlbmNlcz8NClNlY3Rp b24gMy4xIEkgZG9u4oCZdCB1bmRlcnN0YW5kOiDigJxBIG5ldyBlbnRpdHnigKYuIGJlZW4gY29u ZmlndXJlZOKAnSBXaHkgbm90OyBJIGFzc3VtZSB0aGUgcHJvdG9jb2wgZGV0ZWN0cyB0aGlzIGJl aGF2aW91ci4NClBhZ2UgMTI6IGlkZW50aWZ5IGl0c2VsZiBBTkQgYXV0aGVudGljYXRlIFJlZ2lz dHJhciAodGhleSBoYXZlIGVxdWFsDQppbXBvcnRhbmNlKQ0KUGFnZSAxMzogcG9pbnQgMzogd2h5 IHRoZSB0ZXh0IGFib3V0IG5vbmNlPyBUaGlzIHdpbGwgYmUgdHJlYXRlZCBzZXZlcmFsIHRpbWVz IGxhdGVyIGluIHRoZSB0ZXh0Lg0KUG9pbnQgNDogVmVyeSBjb25mdXNpbmcgdG8gbWUuIE1hbnkg dGVybXMgYXJlIHVzZWQgdGhhdCBhcmUgZXhwbGFpbmVkIG11Y2ggbGF0ZXIsIGxpa2U6IEF1ZGl0 IHRva2VuLCBvd25lcnNoaXAgdm91Y2hlciwgUmVnaXN0cmFyIHNlcnZlciBjZXJ0aWZpY2F0ZS4N ClBvaW50IDUg4oCcZS5nLiBFU1TigJ0uIFdoeSBlLmcuIGl0IHNlZW1zIHRvIGJlIHRoZSBvbmx5 IG9wdGlvbiBsYXRlciBpbiB0aGUgdGV4dC4gSWYgbm90IGNhbiBpdCBiZSBtYWRlIG1vcmUgZXhw bGljaXQgdGhhdCBvdGhlciBtZXRob2RzIGFyZSBzdXBwb3J0ZWQuDQpTZWN0aW9uIDMuMS4xIERp c2NvdmVyeS4gVGhlIHN0YW5kYXJkaXphdGlvbiBvZiB0aGUgZGlzY292ZXJ5IG9mIHRoZSBwcm94 eSAocmVnaXN0cmFyKSBkb2VzIG5vdCBzZWVtIG5lY2Vzc2FyeSB0byBtZS4gVGhlIGJvb3RzdHJh cHBpbmcgcHJvdG9jb2wgaXMgbm90IGFmZmVjdGVkIGF0IGFsbCB3aGVuIGRpZmZlcmVudCBkaXNj b3ZlcnkgcHJvdG9jb2xzIGFyZSB1c2VkLiBKdXN0IGNpdGluZyBHUkFTUCBhbmQgbUROUyBhcyBl eGFtcGxlcyB3aXRoaW4gdGhlaXIgY29udGV4dCBzZWVtcyBtb3JlIHRoYW4gc3VmZmljaWVudCB0 byBtZS4NClNlY3Rpb24gMy4xLjIgcGhyYXNlIDE7IHRvIHdoYXQ/IGRvZXMgdGhlIG5ldyBlbnRp dHkgaWRlbnRpZnkgaXRzZWxmPw0KUGFyYWdyYXBoIDI6IFdoYXQgaXMgdGhlIGJvb3RzdHJhcHBp bmcgcHJvdG9jb2wgc2VydmVyIGhlcmU/IFRoZSBwcm94eSBvciB0aGUgUmVnaXN0cmFyPyBJcyBp dCB0aGUgZGF0YSByZWNlaXZlZCBmcm9tIHRoZSByZWdpc3RyYXIgdGhhdCBpcyBub3QgdHJ1c3Rl ZD8gQnV0IHRoZSBkYXRhIGZyb20gdGhlIG5ldyBlbnRpdHkgaXMgdHJ1c3RlZD8gQW5kIHdoeSBp cyBhIFRMUyBjb25uZWN0aW9uIG5lZWRlZCwgaWYgbm8gZGF0YSBpcyB0cnVzdGVkPw0KUGFnZSAx NSwgbGFzdCBwaHJhc2UgYmVmb3JlIDMuMS4zOiBib290c3RyYXBwaW5nIHNlcnZlciAtPiByZWdp c3RyYXI/DQpOZXcgZGV2aWNlIC0+IG5ldyBlbnRpdHk/DQpTZWN0aW9uIDMuMS4zLiBJcyB0aGlz IHdoZXJlIEVTVCBpcyBzdGFydGVkPyBNaWdodCBiZSBoZWxwZnVsIHRvIGluZGljYXRlIHdoaWNo IHBhcnRzIGFyZSBhbHJlYWR5IGZpeGVkIGJ5IEVTVC4NClRoZSBwaHJhc2U6IOKAnFNpbmNlIGNs aWVudCBhdXRoZW50aWNhdGlvbiBvY2N1cnMgZHVyaW5nIFRMUyBoYW5kc2hha2XigJ0gaXMgY29u ZnVzaW5nLiBJcyB0aGlzIHRoZSBUTFMgaGFuZHNoYWtlIGRpc2N1c3NlZCB1bmRlciAzLjEuMiBv ciBhIG5ldyBvbmU/DQpOZWl0aGVyIGlzIGl0IGNsZWFyIGlmIHRoaXMgaXMgdGhlIHByb3Zpc2lv bmFsIGF1dGhlbnRpY2F0aW9uIG9yIHRoZSBmaW5hbCBvbmUuDQpUaGlzIHNlY3Rpb24gaW4gZ2Vu ZXJhbCBuZWVkcyBtb3JlIGNsYXJpZmljYXRpb24gYW5kIGRlc2NyaXB0aW9uIG9mIHRoZSBmbG93 IG9uIGhvdyByZWRpcmVjdGlvbnMgdG8gYSBkaWZmZXJlbnQgUmVnaXN0cmFyIHdvcmtzLg0KU2Vj dGlvbiAzLjEuNCB3aHkgY2l0ZSB0aGUgbm9uIGF1dG9ub21pYyAoYW5kIG5vbiB1c2VkKSBlbnJv bG1lbnQgcHJvdG9jb2xzPw0KVGhlIGF1ZGl0IHRva2VuIHByb3ZpZGVzIHN1ZmZpY2llbnQgaW5m b3JtYXRpb24gdG8gY29udGludWUsIGJ1dCB0aGUgb3duZXJzaGlwIHZvdWNoZXIgZG9lcyBub3Q/ DQpTZWN0aW9uIDMuMS41LiBXaHkgdGhpcyBsYXN0IHBhcmFncmFwaCBhYm91dCB0aW1lIGRpc3Ry aWJ1dGlvbj8NClNlY3Rpb24gMy4xLjYgbWVudGlvbnMgYXVkaXQgdG9rZW4gYW5kIG93bmVyc2hp cCB2b3VjaGVyOyBidXQgb25seSBkaXNjdXNzZXMgYXVkaXQgdG9rZW4gYWZ0ZXJ3YXJkcyB0byBz dGFydCBSRkM3MDMwIHByb2Nlc3MuDQpTZWN0aW9uIDMuMS43IHNwZWNpZmllcyB0aGUgZmluYWwg cHVycG9zZSBvZiB0aGUga2V5IGRpc3RyaWJ1dGlvbj8gSU1PIHBhcnQgb2YgdGhpcyB0ZXh0IHNo b3VsZCBnbyB0byB0aGUgaW50cm9kdWN0aW9uIHRvIG1vdGl2YXRlIHRoZSBib290c3RyYXBwaW5n IHByb3RvY29sIGFuZCBhbHNvIHNob3cgaXRzIHZhbGlkaXR5IGZvciBjb25zdHJhaW5lZCBkZXZp Y2VzIGFuZCBuZXR3b3Jrcy4NCjMuMiBmYWNpbGl0YXRlcyBjb21tdW5pY2F0aW9uIGJldHdlZW4g Pz8/LiBBY2NvcmRpbmcgdG8gZmlndXJlIDIgdGhlIHJlZ2lzdHJhciBpcyBub3QgbmVjZXNzYXJp bHkgY29uZmlndXJlZCBvbiB0aGUgUHJveHkuDQpXaGF0IGlzIGEgY29udHJvbCBwbGFuZSBDUFU/ IFByb2JhYmx5IHRleHQgaGFzIGdvbmUgbWlzc2luZy4NCk5vdCBjbGVhciBmcm9tIHRoZSB0ZXh0 IGhvdy93aHkgYSBkZXZpY2UgYmVjb21lcyBhIHByb3h5IGFuZCBieSB3aG9tL2hvdyBpdCBpcyBj b25maWd1cmVkIHdpdGggdGhlIHJlbGV2YW50IGluZm9ybWF0aW9uIGxpa2UgdGhlIFJlZ2lzdHJh cuKAmXMgYWRkcmVzcy4NClNlY3Rpb24gMy4yLjEgVGhlIGNob2ljZSBiZXR3ZWVuIERUTFMgYW5k IFRMUyBhcHBlYXJzIGFsbCBvZiB0aGUgc3VkZGVuLg0KQWxsIGZvcm1lciB0ZXh0IGRpc2N1c3Nl ZCBUTFM7IEkgc3VnZ2VzdCB0aGF0IGEgZGlmZmVyZW50IHNlY3Rpb24gaXMgZGVkaWNhdGVkIHRv IHVzZSBvZiBDb0FQLCBkZXNjcmliZXMgdGhlIGh0dHAvVExTIHRvIGNvYXAvZHRscyBtYXBwaW5n LCBhbmQgdGhlIGRyYWZ0IGNvbnNpc3RlbnRseSB1c2VzIFRMUyBmb3IgY2xhcml0eS4gU2VjdGlv biAzLjIuMS4gaXMgdGhlbiBtb3JlIGRlZGljYXRlZCB0byB0aGUgZGlzY292ZXJ5IGFuZCBrZWVw aW5nIHByb3h5IHN0YXRlbGVzcy4NClNlY3Rpb24gMy4yLjIgc3VnZ2VzdHMgbXVsdGlwbGUgb3B0 aW9ucyB0byBwcm94eSB0aGUgY29ubmVjdGlvbiB0byB0aGUgUmVnaXN0cmFyLiBDYW4gb3RoZXIg bWV0aG9kcyBiZSB1c2VkIGJleW9uZCB0aGF0IGFyZSBsaXN0ZWQgaGVyZS4NClNlY3Rpb24gMy4z LjEgc2hvdWxkIHRoZSBvdXQgb2YgYmFuZCBiZSBjaXRlZCBoZXJlPyBUaGUgZHJhZnQgZGVzY3Jp YmVzIGF1dG9ub21pYyBiZWhhdmlvdXIuDQpFbmQgb2Ygc2VjdGlvbiAzLjMuMjsgd2h5IHRoZSBl bXBoYXNpcyBvbiBob21lbmV0Pw0KU2VjdGlvbiAzLjMuMywgMm5kIHBhcmFncmFwaDsgZXhhbXBs ZXMgbWlnaHQgYmUgaGFuZHk/DQpTZWN0aW9uIDMuMy4zIENsYWltcyBmb3IgYW4gdW5hdXRoZW50 aWNhdGVkIFJlZ2lzdHJhciBhcmUgb25seeKApjsgSXMgdGhpcyBhIHZpYWJsZSBhcHByb2FjaD8N ClNlY3Rpb24gMy40IEZhY3RvcnkgcHJvdmlkZXI/DQpTZWN0aW9uIDMuNSBBcyB0aGUgZGV2aWNl cyBoYXZlIGEgY29tbW9uIHRydXN0IGFuY2hvcuKApiBQbGVhc2UgbWFrZSBkZXZpY2VzIG1vcmUg ZXhwbGljaXQuDQpTZWN0aW9uIDMuNS4xLiBkZXZpY2UgLT4gbmV3IGVudGl0eQ0KVGhlIG5ldyBl bnRpdHkgY2FuIHZhbGlkYXRlIHRoZSBkb21haW4gbWVtYmVyc2hpcCBhZnRlciBqb2luaW5nPyBZ b3UgbWVhbiBpdCBjYW4gYWN0IGFzIHByb3h5Pw0KU2VjdGlvbiAzLjYgTmV0d29yayBhY2Nlc3Mg Q29udHJvbD8gV2hlcmUgZG9lcyB0aGlzIHRlcm0gY29tZSBmcm9tPw0KV2hhdCBkb2VzIOKAnGhh dmluZyBzdWZmaWNpZW50IGNvbm5lY3Rpdml0eeKAnSBtZWFuPw0KU2VjdGlvbiA0LjQgWmVyby10 b3VjaCBpcyBhbiB1bmtub3duIHRlcm0uDQpBbHJlYWR5IGVucm9sbGVkIGRldmljZXMgLT4gcHJv eGllcy4NClNlY3Rpb24gNC41IFdoYXQgYXJlIGNlbnRyYWwgY29udHJvbCBmdW5jdGlvbnM/DQpT ZWN0aW9uIDUgcmVwZWF0cyBtdWNoIG9mIGVhcmxpZXIgc2VjdGlvbnMuIEkgc3VnZ2VzdCB0byBy ZW1vdmUgdGV4dCBpbiBlYXJsaWVyIHNlY3Rpb25zIChvciBtYWtlIG1vcmUgYWJzdHJhY3QpIHRv IG1pbmltaXplIGR1cGxpY2F0aW9uLg0KV2hhdCBpcyBhbiDigJxhaXItZ2FwcGVk4oCdIG5ldHdv cms/IFJlZmVycmluZyBpbiB0aGUgdGV4dCB0byBmaWcgNSBhbmQgZmlnDQo2IGFuZCBwb2ludGlu ZyBvdXQgdGhlIGRpZmZlcmVuY2VzIGhlbHBzIHJlYWRhYmlsaXR5Lg0KSGVyZSBteSByZXZpZXcg c3RvcHM7IFRoZSB0ZWNobm9sb2d5IHNlZW1zIGFscmVhZHkgcXVpdGUgc29saWQgaWYgdGhlIHBy b3h5IGJlaGF2aW91ciB3aXRoIElQSVAgZW5jYXBzdWxhdGlvbiBvZiB0aGUgVExTIG1lc3NhZ2Vz IGFyZSBiZXR0ZXIgY2xhcmlmaWVkLiBUaGUgdGV4dCBuZWVkcyBxdWl0ZSBzb21lIGVkaXRpbmcg dG8gcmVtb3ZlIGR1cGxpY2F0aW9uLCBpbXByb3ZlIGNvbnNpc3RlbmN5LCBhbmQgcmVtb3ZlIG1h bnkgb2YgdGhlIGRlc2lnbiBkZWNpc2lvbiBkaXNjdXNzaW9ucy4NCkkgaG9wZSBteSBjb21tZW50 cyBtYXkgaGVscC4NCg0KR3JlZXRpbmdzLA0KDQpQZXRlcg0KDQotLQ0KUGV0ZXIgdmFuIGRlciBT dG9rDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpB bmltYS1ib290c3RyYXAgbWFpbGluZyBsaXN0DQpBbmltYS1ib290c3RyYXBAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWEtYm9vdHN0cmFwDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3Rl ZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3Nl bWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJv aGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5k IGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg== From nobody Wed Aug 17 10:45:27 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED95912D954; Wed, 17 Aug 2016 10:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 wcGmUd6Zf9_9; Wed, 17 Aug 2016 10:45:19 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0046512D946; Wed, 17 Aug 2016 10:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1914; q=dns/txt; s=iport; t=1471455919; x=1472665519; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RmFZcI/aBeykbtuLugnANeG9M7rPrd0wcn2qadY5lf0=; b=FQTvkzS+9Lu9035k1LcgPxunk1oK0vIyCFJL/N52Mu0j0O02tLzwxDG7 vXPqtOWLKKBVbA/L3Z+B5b6E/1tSlTcNyfFpdhMu2J94KaOZE/69SApGy vqxGvmbl8NWwf8570REVmYfQQPAOR+MQRU3ndFROt4CUi0yWwY+H6XfHr k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAgC9obRX/4oNJK1VCYNEVnwHuTOBf?= =?us-ascii?q?SSCQoM3AhyBTjgUAgEBAQEBAQFeJ4ReAQEEAQEBIRE6CwULAgEIGAICJgICAiU?= =?us-ascii?q?LFRACBA4FiCkIDq0KkBkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBhyGCVYE5g?= =?us-ascii?q?mAngwErgi8FmUQBjx2PSYw7g3cBHjaCHyaBNW6FdX8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,535,1464652800"; d="scan'208";a="310539963" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Aug 2016 17:45:18 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u7HHjI5G021376 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Aug 2016 17:45:18 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 17 Aug 2016 12:45:17 -0500 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Wed, 17 Aug 2016 12:45:17 -0500 From: "Max Pritikin (pritikin)" To: Michael Richardson Thread-Topic: [Anima-bootstrap] [Netconf] minutes for anima-bootstrap design team meeting, 2016-08-16 Thread-Index: AQHR9/vYepfUxY+FxUu8HZIY/Q/TqqBMhcuAgAAPAACAAS1IAA== Date: Wed, 17 Aug 2016 17:45:17 +0000 Message-ID: <9F5B50E2-DFE5-443B-B150-DA30CF8B90D8@cisco.com> References: <13187.1471375632@obiwan.sandelman.ca> <3A795BB6-03A8-46B0-9EAD-1607427EE0CD@cisco.com> <7698.1471391216@obiwan.sandelman.ca> In-Reply-To: <7698.1471391216@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.10] Content-Type: text/plain; charset="utf-8" Content-ID: <1E351652970CF345931359A94AE6B6C0@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: anima-bootstrap , "netconf@ietf.org" Subject: Re: [Anima-bootstrap] [Netconf] minutes for anima-bootstrap design team meeting, 2016-08-16 X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 17:45:21 -0000 DQo+IE9uIEF1ZyAxNiwgMjAxNiwgYXQgNTo0NiBQTSwgTWljaGFlbCBSaWNoYXJkc29uIDxtY3Ir aWV0ZkBzYW5kZWxtYW4uY2E+IHdyb3RlOg0KPiANCj4gDQo+IE1heCBQcml0aWtpbiAocHJpdGlr aW4pIDxwcml0aWtpbkBjaXNjby5jb20+IHdyb3RlOg0KPj4gVGhlIGNvbW1vbiBlbGVtZW50cyB3 ZeKAmXZlIGRpc2N1c3NlZCBhcmU6DQo+IA0KPj4gMSkgc29tZSB0eXBlIGluZm9ybWF0aW9uDQo+ PiAyKSBzaWduYXR1cmUgYW5kL29yIGVuY3J5cHRpb24gbWV0aG9kDQo+PiAzKSB2YWxpZGl0eSBw ZXJpb2QgLyBub25jZSB2ZXJpZmljYXRpb24NCj4+IDQpIGNsaWVudCBkZXZpY2UgaWRlbnRpdHkN Cj4+IDUpIGRvbWFpbiBpZGVudGl0eQ0KPj4gNykgYWJpbGl0eSBmb3IgZXh0ZW5zaWJpbGl0eSg/ KQ0KPiANCj4+IFRoZXJlIGlzIGFsc28gdGhlIGVuY29kaW5nIGNob2ljZXMgdGhhdCBuZWVkIHRv IGJlIG1hZGUuIElmIGl0IHR1cm5zDQo+PiBvdXQgYW5pbWEgYW5kIG5ldGNvbmYsIGZvciBleGFt cGxlLCBoYXZlIGVudGlyZWx5IGRpZmZlcmVudA0KPj4gcmVxdWlyZW1lbnRzIGZvciBlbmNvZGlu ZyAoZS5nLiBvbmUgcmVxdWlyZXMganNvbiBhbmQgdGhlIG90aGVyIGNib3Igb3INCj4+IHNvbWV0 aGluZykgdGhlbiB0aGVyZSBpcyBhIHByb2JsZW0uDQo+IA0KPiBPa2F5LCBzbyBpZiB3ZSBhcmUg Z29pbmcgdG8gY3JlYXRlIGEgb3duZXJzaGlwIHZvdWNoZXIgZm9ybWF0LCB3aGVyZSB3aWxsIHdl DQo+IGRvIGl0PyAgIEkgZG9uJ3QgdGhpbmsgaXQncyBhIHF1ZXN0aW9uIGlmIGl0IGZpdHMgaW50 byB0aGUgdmFyaW91cyBjaGFydGVycywNCj4gc28gbXVjaCBhcyB3aGljaCBvbmUgaXQgc2hvdWxk IGZpdCBpbnRvLg0KDQpCUlNLSSBzZWN0aW9uIDUuMyBzZWVtcyBsb2dpY2FsIHRvIG1lLiA6KSBX ZSBuZWVkIHNvbWV0aGluZyB0aGVyZSBhbmQsIGxvLCB0aGVyZSBpcyBhIGN1cnJlbnQgZm9ybWF0 IGRlc2NyaWJlZC4gSW4gbXkgbWluZCB3ZeKAmXJlIGRpc2N1c3NpbmcgaWYgdGhpcyBpcyB0aGUg Y29ycmVjdCBhbmQgY29tcGxldGUgZm9ybWF0IG9yIGlmIHdlIG5lZWQgdG8gc3BlY2lmeSBpdCBm dXJ0aGVyLg0KDQotIG1heA0KDQo+IA0KPiAtLQ0KPiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJ RVRGQHNhbmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrcw0KPiAtPSBJUHY2IElv VCBjb25zdWx0aW5nID0tDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IEFuaW1hLWJvb3RzdHJhcCBtYWlsaW5nIGxpc3QNCj4g QW5pbWEtYm9vdHN0cmFwQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYW5pbWEtYm9vdHN0cmFwDQoNCg== From nobody Thu Aug 18 06:04:44 2016 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3539412DDBA; Thu, 18 Aug 2016 06:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 2Hq-JE_YcIvh; Thu, 18 Aug 2016 06:04:39 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2D6212DDC8; Thu, 18 Aug 2016 06:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5694; q=dns/txt; s=iport; t=1471525473; x=1472735073; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=h+hzAOMORCB852K2G3sXMXR06UsSkCJbc2rW0KXTSDo=; b=MA6wNjPE2bfCNWsV03PWDREC9WHJhk9dEXXdC9FdYV1pf7KyPjysFvU6 FpPbAUQyKUtEjxWFbIFyijE1jGCMSXj6ER09BzibYKhpIueMd8PI45or+ 3FDxydSW4rebhYYzawqrOlxdwMHUGQuP7sAHln3LBD9y0ckDqs8qH4Pdo Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AgDdsbVX/4gNJK1dg0OBUge3V4F9g?= =?us-ascii?q?maDNwKBbTgUAgEBAQEBAQFeJ4ReAQEFeQwEAgEIEQQBASgHMhQJCAIEAQ0FCBI?= =?us-ascii?q?BiBa8BwEBAQEBAQEBAQEBAQEBAQEBAQEBARyGKoRNgTkBgmOFfgWOVopuAYkeh?= =?us-ascii?q?XiBco1ehmeFVIN3AR42g3puhWlFfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,539,1464652800"; d="scan'208";a="139223293" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Aug 2016 13:04:32 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u7ID4Wgu015660 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 Aug 2016 13:04:32 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 18 Aug 2016 08:04:31 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Thu, 18 Aug 2016 08:04:31 -0500 From: "Pascal Thubert (pthubert)" To: Michael Richardson , tisch-security <6tisch-security@ietf.org> Thread-Topic: [6tisch-security] developments on 6tisch join scheduling Thread-Index: AQHR+BAV/+KBXOtlnU+yNvEKrwkQAKBOrVlw Date: Thu, 18 Aug 2016 13:04:17 +0000 Deferred-Delivery: Thu, 18 Aug 2016 13:03:59 +0000 Message-ID: <1ed0a6c6bbbe481fab1bc1c6e36c53d2@XCH-RCD-001.cisco.com> References: <24944.1471387601@obiwan.sandelman.ca> In-Reply-To: <24944.1471387601@obiwan.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.28] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "anima-bootstrap@ietf.org" Subject: Re: [Anima-bootstrap] [6tisch-security] developments on 6tisch join scheduling X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 13:04:43 -0000 Hello Michael About your subdivision: One may note that to root sees it all, and it the ultimate limit of the ban= dwidth that may be given to join process.=20 The bigger the network the slower a given JA can accept new joins. And the = deeper the JA, the more overall resources will be consumed by a join. Since this is dynamic and dependent on the network, it may be that we need = the root to provide JAs with a MTBJ (mean time between joins) that depends = on the rank or something. We can wonder if the root itself could be the proxy, being triggered by a D= AR message as you described. The root can afford to maintain an EST session= . The root would arbitrate when that request is being served. And that the ro= ot may instruct in the DAC when the device is entitled to continue its join= process. For this purpose, the DIO may contain new information about root capabiliti= es in the DODAG Configuration option.=20 Cheers, Pascal > -----Original Message----- > From: 6tisch-security [mailto:6tisch-security-bounces@ietf.org] On Behalf= Of > Michael Richardson > Sent: mercredi 17 ao=FBt 2016 00:47 > To: tisch-security <6tisch-security@ietf.org> > Cc: anima-bootstrap@ietf.org > Subject: [6tisch-security] developments on 6tisch join scheduling >=20 >=20 > During discussions at IETF96, it became clear that the join ordering/time > sequence envisioned for 6tisch would be less possible than I thought. > The bad news is that a new mechanism might be hard to actually design. > The good news is that I think a new mechanism would put 6tisch join and A= NIMA > bootstrap almost identical. >=20 > To go back, the proposal was: > 1) a new pledge would send a NA with an EARO, which would turn into a > DAC/DAR process up to the 6LBR. The 6LBR would let the JCE know > about the new node through mechanism TBD. > The new pledge would receive a NA in reply, which, for the pledge > would acknowledge that they might be knocking on the right door. > (A network which didn't like that node would reply in some negative > fashion, which naturally could also be forged) >=20 > 2) the JCE would reach out (via the proxy) to the pledge, on a schedule > determined by the JCE. The JCE would control the order of joining, > and since CoAP would be used with using something like: > draft-wang-6tisch-6top-protocol-00 > all joining nodes would remain quiet except when responding to > queries from the JCE. >=20 > The goal of having the pledge be passive was one of bandwidth conservatio= n, > the JCE would enroll only as many pledges as it felt it had available ban= dwidth in > the upper parts of the MESH DODAG tree. A 6tisch network might allocate = a > rather small amount of bandwidth for join messages, and utilizing the ban= dwidth > responsabily is important. That means never wasting any energy among the > lower parts of the DODAG when the packets would just get dropped further > upwards. >=20 > In discussions, it appears that the EARO as described in > draft-thubert-6lo-rfc6775-update-00 might be replaced by the Crypto-ID of > draft-sarikaya-6lo-ap-nd-02, and the process is slightly different. >=20 > One additional reason why the passive pledge turns out to be a problem is= that > the JCE does not actually know the wake/sleep schedule for the pledge. > In the 6tisch case, it ought to be possible for the pledge to sync up to = the > schedule and so the proxy will know when it can transmit to it, but in or= der to > keep the proxy from having to store a lot of data coming from the JCE, th= e JCE > also needs to know the schedule out at the edge. This does not seem > unsolveable, but it was an additional concern raised. >=20 > Meanwhile, in ANIMA bootstrap, the initial contact is through a GRASP dis= covery > (or DNSSD) to find a proxy. The new pledge uses the proxy to initiate an= EST > session using the proxy. The enrollment process in the ANIMA case is dri= ven by > the pledge, on the assumption that the ANIMA ACP has sufficient bandwidth= for > normal congestion control present in TCP and CoAP to deal with a limits. >=20 > What is needed is a way to adjust things so that the pledges will attempt= to join > in a way that does not overwhelm the network, and more so, that the proxy > nodes can easily police that they are doing so. >=20 > So the idea is to use the ANIMA GRASP discovery mechanism to find a proxy= , but > in addition, in the reply, to get some kind of number to seed a backoff a= lgorithm > that causes the pledge to attempt to initiate the join process at times > deterministic to the network. I'm not talking about an exponential backo= ff. >=20 > This is where the hard part is, how to come up with a simple to describe,= and > simple to code algorithm which would fill up the available bandwidth, and= be > easily subdividable. >=20 > By subdividable, I mean, if we pass 5% of the join bandwidth to proxy A, = at rank > 3, that it would be able to easily pass some percent of that bandwidth to= a new > proxy at rank 4 in a way that does not mean reconfiguring the entire mesh= to > delegate bandwidth. >=20 > Removing the subdivable property, some simple pseudo-random number > generator, > with the right seed would be the right idea. A good PRNG ought to span > the available time space evenly. I don't have a solution, but I'm trying= to write > up the requirements more clearly. >=20 > -- > Michael Richardson , Sandelman Software Works -= =3D > IPv6 IoT consulting =3D- >=20 >=20