From nobody Wed Sep 2 07:06:24 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F21F1B4432 for ; Wed, 2 Sep 2015 07:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.612 X-Spam-Level: X-Spam-Status: No, score=-12.612 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ZUAPS9n0nfIS for ; Wed, 2 Sep 2015 07:06:17 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAD5D1B4412 for ; Wed, 2 Sep 2015 07:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=82; q=dns/txt; s=iport; t=1441202777; x=1442412377; h=date:from:to:subject:message-id:mime-version; bh=zbPRAJ2OkbVLlLT+kW3drtRP7KYzCfxTyMLfKJU1REs=; b=B7m+i2IhXWvRZB5i/C35fIdzjydP707amRu5yueEWHD3avLQJm5bWJhz i9iTpiIKS1L2Hk3v0Ke10jFqsTHevxA6pWl9nStna8Uts1Dk4g1+3LO1s CI1bZcLh5mEX7afjPxWuJkSqIdVulrxlY2T0nB3O9gtVN5kBlQDXhL4N9 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CwAgA8AedV/51dJa1dgxu/BQEJiSk4FAEBAQEBAQGBCoRkezQFiQqmYqRdAQoBAQEekReEFQWNaIdhcIwDA5pvJoQfHoMAAQEB X-IronPort-AV: E=Sophos;i="5.17,453,1437436800"; d="scan'208";a="183677177" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 02 Sep 2015 14:06:17 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t82E6Gft017691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Sep 2015 14:06:17 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 t82E6GgN027125 for ; Wed, 2 Sep 2015 07:06:16 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t82E6GIS027124 for anima-bootstrap@ietf.org; Wed, 2 Sep 2015 07:06:16 -0700 Date: Wed, 2 Sep 2015 07:06:16 -0700 From: Toerless Eckert To: anima-bootstrap@ietf.org Message-ID: <20150902140616.GZ14573@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: Subject: [Anima-bootstrap] Anyone joining ? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2015 14:06:22 -0000 Hi folks Anyone planning to join the bootstrap call ? Cheers Toerless From nobody Wed Sep 2 07:42:29 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A792C1B2AD7 for ; Wed, 2 Sep 2015 07:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.012 X-Spam-Level: X-Spam-Status: No, score=-12.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 NRPbNDpsD29Y for ; Wed, 2 Sep 2015 07:42:27 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8FC81B3E64 for ; Wed, 2 Sep 2015 07:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1782; q=dns/txt; s=iport; t=1441204943; x=1442414543; h=from:date:to:subject:message-id:mime-version; bh=xbCh7jOquRISrLrhYKcivpP+eS1nnaL3+nj5Lg9Rsxk=; b=QHH0deEwDGJOOYVzLaFLuNrghbQ16tC+C5cfx93S9w/5c4jxARb+c9RC w3qR5r0ZYgodBStBL3cIj0tcofJr6fzTLGLr/Zdk7symc22mefkn3MG5x 7EMzqcAhHFTpTL5pzsacSDwcgajhx5ETYOJ9fXz7+OYIEwCyzSu/ZCaeB E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CwAgAPCudV/4gNJK1dgxu/BQEJiSk4FAEBAQEBAQGBCoRREzEDRzQFiQqnAaRYAQEIAQEBAQEdkReDAYEUBY1oh2GMcwOBSoQylHMmhB8egwABAQE X-IronPort-AV: E=Sophos;i="5.17,453,1437436800"; d="scan'208";a="25611084" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP; 02 Sep 2015 14:42:21 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t82EgLtC023135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Sep 2015 14:42:21 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 t82EgLod028443 for ; Wed, 2 Sep 2015 07:42:21 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t82EgKr1028442 for anima-bootstrap@ietf.org; Wed, 2 Sep 2015 07:42:20 -0700 From: Toerless Eckert Date: Wed, 2 Sep 2015 07:42:20 -0700 To: anima-bootstrap@ietf.org Message-ID: <20150902144220.GA14573@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Archived-At: Subject: [Anima-bootstrap] Notes 150902-anima-bootstrap.txt X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2015 14:42:28 -0000 Participants: Kent Watson Robert Cragie Michael Behringer Toerless Eckert TODO: Editors: Max/Michael: can you please communicate on the mailing list agenda for the next two weeks, toerless will be on PTO Kent - working on updating zeroconf draft Toerless: working on finalizing proposal for signaling of ES for ANIMA bootstrap (see below) Notes: Kent: work for bootstrap potentially going on in CORE WG -> Ask Andy Berman. Using COMI protocol Toerless/Robert: discussing possible signaling mechanism for EST during initial bootstrap. Toerless suggesting TCP-proxy (on mailing list), Robert explaining past work on other WG, pointing to EAP-TLS/EAP-TTLS - EAP-TLS can not be used to exchange EST messages, only initial TSL authentication. - EAP-TTLS could do this, but no known deployments. Might be intrusive if this is the only place where/when EAP is used in ANIMA. Reporting from Max'es suggestion May need to consider to make ANIMA compatible with NAC (Network Access Control) framework. Aka: Initially network ports may be closed and require 802.1x authentication - this originally lead to the thought that enrollment should be via EAP which is part of 802.1x. Better modular approach: - Make ANIMA devices support 802.1x. Whenever necessary have them first authenticate via 802.1x (with their IDevID redential). - Other side is then permitting access to a quarantine network where ONLY the ANIMA enrollment protocol would be permitted. - then run ANIMA enrollment == TCP proxy. Need to vet this with NAC experts -> Brian Weis From nobody Mon Sep 7 18:15:15 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED3A1B3FFA for ; Mon, 7 Sep 2015 18:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 O3QaJlwEqzJ2 for ; Mon, 7 Sep 2015 18:15:12 -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 9A4DD1B40F9 for ; Mon, 7 Sep 2015 18:15:12 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 24E5120098 for ; Mon, 7 Sep 2015 21:15:28 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9FB0E63B18; Mon, 7 Sep 2015 21:15:11 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8A59963AEC for ; Mon, 7 Sep 2015 21:15:11 -0400 (EDT) From: Michael Richardson To: anima-bootstrap X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: [Anima-bootstrap] EAP-over-CoAP X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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, 08 Sep 2015 01:15:14 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable BCC to the anima-bootstrap list. To: Alexander Pelov cc: Giuseppe Piro , "6tisch@ietf.org" <6tisch@ietf.org>, Rafa Marin Lopez Subject: Re: [6tisch] about the secure join process In-Reply-To: <9C9D4508-E0A7-475C-9465-7F4F2BDC6FCA@telecom-bretagne.eu> References: <9C9D4508-E0A7-475C-9465-7F4F2BDC6FCA@telecom-bretagne.eu> FCC: +outgoing =2D------- Alexander Pelov wrote: > In our proposal for managing long-range radio networks with CoAP ( > https://tools.ietf.org/html/draft-pelov-core-cosol-00 ) we=E2=80=99re= using > EAP-over-CoAP. The use of CoAP as signaling protocol, makes it natural > to go to this solution, as this way we can reuse the whole EAP > framework that=E2=80=99s already in place. EAP-over-CoAP is probably a better choice than over PANA :-) But, it seems to me that it ought to be EAP-over-DTLS-over-CoAP, with the result being creation of a CoAPS context. In either case, if you are really doing EAP-TLS, then you wind up with a ridiculous number of layers. One can then run EST or something similar over it. Your document seems to intersect with a bunch of other work, I hope to get back to you with some additional comments. =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.4.12 (GNU/Linux) iQEVAwUBVe42n4CLcPvd0N1lAQKBQgf8DRaDLgfxRkr7jx4q0dsAnsrv0i3C3PAk Mu1CTOj1VURWca5NkpA0mGFxBAEDzhaochrP5vB61R56SHS+VkT24P33I6cZthH2 l+lObNBOYrkhWhRDJx8Rk/vlwqEMqluJZ3KU2C41hd9jQ7if9E9m0jnLwmTeWHbl 2kg9dJfTz1YaV8agE5lkXggMNQxpVSxQIf1N7UFoE7SUux5JYrA7jUTUrBTjYBgJ NQg35g5sD4yUOI+XXegHXRfdgMlZPqGB3j0PjPw4NWyF6V4jDd7MxXUg0aaO7Mp7 MaXQcoYkW5JSiLBlH1EE20bwqEWi7a0eA3kpOCmsY9rt8WuVlm2hDg== =WkHk -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Sep 9 20:44:50 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C4A1B3AB8 for ; Wed, 9 Sep 2015 20:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 erpkKRn4zRMc for ; Wed, 9 Sep 2015 20:44:46 -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 1A95B1B3A9E for ; Wed, 9 Sep 2015 20:44:46 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 51514200A3 for ; Wed, 9 Sep 2015 23:45:08 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id BFBBD63B18; Wed, 9 Sep 2015 23:44:44 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A0B4C63AEC for ; Wed, 9 Sep 2015 23:44:44 -0400 (EDT) From: Michael Richardson To: anima-bootstrap@ietf.org In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305A033@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305A033@xmb-rcd-x14.cisco.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of combined? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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, 10 Sep 2015 03:44:48 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: > Can you write down your thoughts on this topic, so that I can > understand it? > To me, ACP and bootstrap have nothing to do with each other; and I seem > to hear from you that they are joined through IKE? Assumption 1 (to be confirmed/denied elsewhere): - that the ACP is formed by a series of transport-mode IPsec tunnels setup to carry IP(proto-41) traffic. (i.e. tunnel-mode without the tunnel mode SPD restrictions). Assumption 2: - that we run a routing protocol over these virtual IPIP interfaces, such as RPL, and the result is the ACP. RPL takes care of numbering the ACP through it's PIO payloads, with the resulting /128s being aliases on a "loopback" interface (i.e. not attached to any specific IPIP interface). All of this happens in a VRF; but in some cases, it may not be totally isolated from some of the data planes. In order to build these tunnels, we have to run IKEv2 over link-layer addresses. To do this we have to have the addresses of the peers that run ANIMA. On a link without layer-2 security (1x/WPA) then we have to have a way to discover the peers; this could be GRASP in some insecure formulation, or some other service discovery. We could even do this with multicast on UDP port 500 (the IKE port). Assumption 3: - a node really has no idea what constitutes a "domain certificate", it comes with with one IDevIDs, and may have one or more LDevIDs, but the enrollment process may either replace the IDevID, or argument it with LDevIDs instead. As such, a node is always able to join a new network that provides the right credentials, and in some cases, it could be even "pre-enrolled" (it already has the right certificates). So upon discovering peers, or being discovered, a node should bring up it's ACP. That means doing an IKEv2 PARENT SA, and in this process it should offer both RSA signature authentication (including a CERT, and a CERTREQ), as well as offer PARENT SA authentication mechanism of EAP. Note: RFC7296 says that the initiator signals it's interest in doing EAP by leaving out the AUTH payload from I2. I don't see anything in the protocol that would forbid a responder from asking for EAP activities if it is unable to validate the signature in the AUTH payload. We might need a Notify to indicate that this is an ANIMA process. I could go on about how we actually need to always be ready for a new enrollment, because the device may have moved, been sold, etc. The device also may *not* have moved or been sold, but simply could have had a new cable plugged in, and perhaps *that* side will be participating in a different domain. This is why I think that enrollment needs to happen as a result of a failure to authenticate the ACP connection, not prior to it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVfD8qYCLcPvd0N1lAQLliQf+Pvf/j8SByCA+83fifxAxdhp+MVWs8CHo nj19W7FedcU2ypqNctRmw7iWvUN8HjtXX5LpGMbAwjrIqJvIYKKBqJP19c0IzhP/ MYb92OW7ZrcU09z3UQiLY0m8VlAYFqO9RJG7KclJnO7zYLHwYVOnneESXEhcBTnM kY8JkWJ+d1RrC3xr/ls5WZZHhZGL+ORQG1fcuM65ze5XoAGFp2JGo1MPL0qThFl4 xQBe9tTnlwtXy9jHMsX4kg2dZJt7GG91oCjukCDQXGrdhvu10UHAo4FS/zrfzU/G 6dbj/i8LmXSLkTH5RWGQyPH6HiGxITe8c3SguK/1drVrraiiyRLpoQ== =1ohX -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 10 00:18:40 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334E71B3058 for ; Thu, 10 Sep 2015 00:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ZqlcZeiDwRIE for ; Thu, 10 Sep 2015 00:18:36 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EFD01B2E45 for ; Thu, 10 Sep 2015 00:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6750; q=dns/txt; s=iport; t=1441869516; x=1443079116; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=eQfKBRR7gxeuEcWn/lFAh2oeHAGBwUft6vnp9hw6ZGw=; b=ipCZw/P/lYRt/YZqXKxUuCtNws6dyx3O1JX9o7F31DnJwD9DeolPm4JH d8BGRdRTXEjq5OHVJ/nj/Y4zeRXgpkJExnk9b455FI9o65mHnPV9xXbHL 3+SmC2I8gCUbJ3UhiyB1jj8eg+Lhd5MSNx0I6b9bGkFA614x++EANeGEK w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BNAgBILvFV/4cNJK1UCYMjgT0GvSQBDYQ6gzYCgT44FAEBAQEBAQGBCoQjAQEBAwE6DSANCgcEAgEIEQQBAQEKFAkHMhQJCAIEARIIiB4IvB6OfAEBAQEBAQEBAQEBAQEBAQEBAQEBAReGc4R7hCgIKwYyBoMSgRQBBIcsBYZ0hzEBh3aGT5VAg2wfAQFChABxhwMlHIEFAQEB X-IronPort-AV: E=Sophos;i="5.17,502,1437436800"; d="scan'208";a="27679094" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP; 10 Sep 2015 07:18:35 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8A7IZRb018131 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 10 Sep 2015 07:18:35 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 10 Sep 2015 02:18:34 -0500 Received: from xhc-aln-x10.cisco.com (173.36.12.84) by xch-aln-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 10 Sep 2015 02:18:34 -0500 Received: from xmb-rcd-x14.cisco.com ([169.254.4.116]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0248.002; Thu, 10 Sep 2015 02:18:34 -0500 From: "Michael Behringer (mbehring)" To: Michael Richardson , "anima-bootstrap@ietf.org" Thread-Topic: [Anima-bootstrap] Bootstrap and ACP creation: Separate of combined? Thread-Index: AQHQ63sO9I1wnABXsU236ksKsAwPbJ41UX4Q Date: Thu, 10 Sep 2015 07:18:33 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305AA13@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305A033@xmb-rcd-x14.cisco.com> <32334.1441856684@sandelman.ca> In-Reply-To: <32334.1441856684@sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of combined? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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, 10 Sep 2015 07:18:39 -0000 Thanks for this long response. Inline...=20 > -----Original Message----- > From: Anima-bootstrap [mailto:anima-bootstrap-bounces@ietf.org] On=20 > Behalf Of Michael Richardson > Sent: 10 September 2015 05:45 > To: anima-bootstrap@ietf.org > Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of=20 > combined? >=20 >=20 > Michael Behringer (mbehring) wrote: > > Can you write down your thoughts on this topic, so that I can > > understand it? >=20 > > To me, ACP and bootstrap have nothing to do with each other; and=20 > I seem > > to hear from you that they are joined through IKE? >=20 > Assumption 1 (to be confirmed/denied elsewhere): > - that the ACP is formed by a series of transport-mode IPsec > tunnels setup to carry IP(proto-41) traffic. (i.e. tunnel-mode > without the tunnel mode SPD restrictions). Actually the ACP must be tunnel mode, because it carries packets that come = from and go to , ie are routed through a specific AC= P tunnel.=20 > Assumption 2: > - that we run a routing protocol over these virtual IPIP interfaces, > such as RPL, and the result is the ACP. RPL takes care of numbering > the ACP through it's PIO payloads, with the resulting /128s being > aliases on a "loopback" interface (i.e. not attached to any specific > IPIP interface). All of this happens in a VRF; but in some cases, > it may not be totally isolated from some of the data planes. OK.=20 > In order to build these tunnels, we have to run IKEv2 over link-layer=20 > addresses. To do this we have to have the addresses of the peers that=20 > run ANIMA. On a link without layer-2 security (1x/WPA) then we have=20 > to have a way to discover the peers; this could be GRASP in some=20 > insecure formulation, or some other service discovery. We could even=20 > do this with multicast on UDP port 500 (the IKE port). My view is also that this should be GRASP. Using IKE for that sounds really= strange to me, but need to think more about it.=20 =20 > Assumption 3: > - a node really has no idea what constitutes a "domain certificate", I don't understand that statement. There is a series of interactions that w= e're specifying here, ANIMA transactions, and the result of those will be t= he device getting the "domain certificate". What do you mean by the above?= =20 > it comes with with one IDevIDs, and may have one or more LDevIDs, > but the enrollment process may either replace the IDevID, or argument > it with LDevIDs instead. =20 The enrolment process provides the device with an LDevID. I see that in par= allel to the IDevID, I don't see why it would "replace" that. But that's a = detail I guess.=20 > As such, a node is always able to join a > new network that provides the right credentials, and in some cases, > it could be even "pre-enrolled" (it already has the right certificate= s). Right. Small addition: Once a device has a domain certificate, it will stop= the enrolment process.=20 > So upon discovering peers, or being discovered, a node should bring up=20 > it's ACP. That means doing an IKEv2 PARENT SA, and in this process it=20 > should offer both RSA signature authentication (including a CERT, and=20 > a CERTREQ), as well as offer PARENT SA authentication mechanism of EAP. This is where we're going apart: I see that as two distinct steps. Not sayi= ng it couldn't be possibly done with one mechanism, but frankly, I don't se= e the benefit, and a lot more complication.=20 > Note: RFC7296 says that the initiator signals it's interest in doing=20 > EAP by leaving out the AUTH payload from I2. I don't see anything in=20 > the protocol that would forbid a responder from asking for EAP=20 > activities if it is unable to validate the signature in the AUTH=20 > payload. We might need a Notify to indicate that this is an ANIMA proces= s. This is all assuming we WANT to combine. I would like to understand why we = want to go down that route.=20 > I could go on about how we actually need to always be ready for a new=20 > enrollment, because the device may have moved, been sold, etc. > The device also may *not* have moved or been sold, but simply could=20 > have had a new cable plugged in, and perhaps *that* side will be=20 > participating in a different domain. In my view: Once a device has a domain cert, it stops enrolment. If you wan= t to move the device to another domain, you have to "push a button" to rese= t it.=20 I hope we agree that a topological move in the same domain shouldn't matter= since the ACP address is an identifier, not locator, and since topology is= discovered anyway.=20 =20 > This is why I think that enrollment needs to happen as a result of a=20 > failure to authenticate the ACP connection, not prior to it. I see it differently, here is the way I see it happen:=20 1 - A new node discovers link local what's around it. Since it has only its= IDevID at the time, it cannot really validate anyone else quite yet. GRASP= seems the right protocol for that.=20 2 - The result is an adjacency table. It'll say something like=20 <...> Where is either an IDevID, an LDevID, empty, or maybe something else l= ater.=20 Validity will likely be "not valid" because most cases we won't be able to = validate at this stage.=20 Now the device knows what's around it. But can't validate most of it.=20 Now, sequentially for each device with a domain certificate a la ANIMA, the= device starts a bootstrap process, one after the other.=20 Let's assume that one neighbour can bootstrap the device. The result is tha= t the device now has a domain cert. But NO ACP yet!!!=20 The status now is the same adjacency table as above, BUT, now it should be = able to validate the identity of at least the device that bootstrapped it.= =20 Draw a big line here. (and this line is really what we're arguing about, ri= ght? ;-)=20 -------------------------------------------------------------------- New discussion: A domain device sees another, validated domain device. Next= step: Establish the ACP.=20 Now we do IKE and the rest of the story, using the domain certs for authent= ication.=20 One reason to keep those beasts separate is because the domain cert might a= lso get to the device by other means, or be pre-installed. So the ACP proce= ss should really be different.=20 Michael=20 > -- > Michael Richardson , Sandelman Software Works=20 > -=3D IPv6 IoT consulting =3D- From nobody Thu Sep 10 10:11:39 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B08B1B6BE0 for ; Thu, 10 Sep 2015 10:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 GQPVDYUP_L9g for ; Thu, 10 Sep 2015 10:11:32 -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 71F701AC3C4 for ; Thu, 10 Sep 2015 10:11:31 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 99F0F20098; Thu, 10 Sep 2015 13:11:55 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 27EE063B18; Thu, 10 Sep 2015 13:11:30 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 07FB763AEC; Thu, 10 Sep 2015 13:11:30 -0400 (EDT) From: Michael Richardson To: "Michael Behringer \(mbehring\)" In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305AA13@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305A033@xmb-rcd-x14.cisco.com> <32334.1441856684@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305AA13@xmb-rcd-x14.cisco.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Cc: "anima-bootstrap@ietf.org" Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of combined? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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, 10 Sep 2015 17:11:38 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: >> Assumption 1 (to be confirmed/denied elsewhere): - that the ACP is >> formed by a series of transport-mode IPsec tunnels setup to carry >> IP(proto-41) traffic. (i.e. tunnel-mode without the tunnel mode SPD >> restrictions). > Actually the ACP must be tunnel mode, because it carries packets that > come from and go to , ie are routed through a > specific ACP tunnel. No, the ACP must have a tunnel, but because it doesn't know what the source/destination of the packets is going to be, it can't use IPsec tunnel mode. Rather it has to use IPsec transport mode for IPIP packets. The distinction is subtle, since the packets look the same on the wire. Both look like: IP1 / ESP / IP2 / ulp In IPsec tunnel mode: XXXXXXXXXXXXXXX In IPsec transport mode: YYYYYYYYYY In tunnel mode the IPsec system is responsible for validating that the src/dst of IP2 match the policy (the X part). Since we will run a routing protocol on top, and the addresses will be assigned inside, we can't even know what the addresses are going to be, and we can't just guess the entire /48 (or /64) of the ULA, because that's not precise enough for IPsec. In transport mode, the IPsec system just validates that the thing inside the ESP is a proto=41, and leaves it at that. >> In order to build these tunnels, we have to run IKEv2 over link-layer >> addresses. To do this we have to have the addresses of the peers that >> run ANIMA. On a link without layer-2 security (1x/WPA) then we have >> to have a way to discover the peers; this could be GRASP in some >> insecure formulation, or some other service discovery. We could even >> do this with multicast on UDP port 500 (the IKE port). > My view is also that this should be GRASP. Using IKE for that sounds > really strange to me, but need to think more about it. If we let GRASP talk to the bare wire, we open up GRASP to new kinds of attacks that it wouldn't otherwise see if it's always inside the ACP. (I would personally implement it as a seperate process if we did that) On the other hand, IKEv2 has to deal with all those attacks ANYWAY. Yes, multicasting an IKEv2 I1 packet is definitely odd.... but go read RFC7296, section 2.6. Essentially, a responder would agree that they exist, but could consider the multicast destination address as an attack and demand a COOKIE. The initiator should really pick a new Ni. If we wanted to do this, I could write an ID explaining how; I don't know how controversial it might be. >> Assumption 3: - a node really has no idea what constitutes a "domain >> certificate", > I don't understand that statement. There is a series of interactions > that we're specifying here, ANIMA transactions, and the result of those > will be the device getting the "domain certificate". What do you mean > by the above? How does one know what a domain certificate is? The IDevID shipped in the system might already be signed by the correct Registrar. The system could have been a new certificate (an LDevID), which after the system is moved, is now wrong. Maybe the system didn't move, but just had a new interface attached, and the existing LDevID is wrong for *that* interface. >> it comes with with one IDevIDs, and may have one or more LDevIDs, but >> the enrollment process may either replace the IDevID, or argument it >> with LDevIDs instead. > The enrolment process provides the device with an LDevID. I see that in > parallel to the IDevID, I don't see why it would "replace" that. But > that's a detail I guess. The reason to replace the IDevID is to avoid being vulnerable to an attack by the vendor (or an attack where the vendor's CA is compromised, or an attack where a National Security Letter forces the vendor's hand). >> As such, a node is always able to join a new network that provides the >> right credentials, and in some cases, it could be even "pre-enrolled" >> (it already has the right certificates). > Right. Small addition: Once a device has a domain certificate, it will > stop the enrolment process. No, it can't do that. It has to always be willing to do a new enrollment, potentially on a new interface. If it does that then the system can never be relocated, repurposed or sold without touching the device before shutting it down from the place it is. >> I could go on about how we actually need to always be ready for a new >> enrollment, because the device may have moved, been sold, etc. The >> device also may *not* have moved or been sold, but simply could have >> had a new cable plugged in, and perhaps *that* side will be >> participating in a different domain. > In my view: Once a device has a domain cert, it stops enrolment. If you > want to move the device to another domain, you have to "push a button" > to reset it. That just doesn't fly for me. What happens if I walk up to a device that is operating and push that button? Wouldn't that be a denial of service? > I hope we agree that a topological move in the same domain shouldn't > matter since the ACP address is an identifier, not locator, and since > topology is discovered anyway. I agree, as long as it's within the same ACP (and the ACP isn't partitioned in a pathological way), then the move not a problem. > -------------------------------------------------------------------- > New discussion: A domain device sees another, validated domain > device. Next step: Establish the ACP. > Now we do IKE and the rest of the story, using the domain certs for > authentication. > One reason to keep those beasts separate is because the domain cert > might also get to the device by other means, or be pre-installed. So > the ACP process should really be different. If the domain cert is already there via other means (perhaps installed as the IDevID), then the IKEv2 process just uses it, and the enrollment process isn't necessary. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVfG5voCLcPvd0N1lAQLj3gf6AjgV4dwZyY8dA8w5mCC2/7Wr+ZTNhrNn uhZDRUSplRcDdmcBv8bNy2+ZGmnUFC/dDCtE/mC1nkysEODPMBga9HFxGPuNy5Gz OpG4ppfYUMMxf8Teep9ojv38sLm9lti45W6UB0waIjZj2XGH9qHHb9PEk9CqjQ8/ PVoDNalmMGA37nC500NGxtrtfFzZBeg8N6zXhZGuiDuSOJ8wx2YOH6qadTmLwoKq FJxEoJD3N0fVytf9UBUPNCzq+L5aqkjLnCLw41FNgGPkJM4Z/c5fDrcpjfILSR1J oFLTBPy54w1FK/vRJFlDZ4Ul3kiltf2ouNWJGyE+/QI2ng4Eq6BFfw== =0I7A -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 10 13:15:08 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FC51B3C24 for ; Thu, 10 Sep 2015 13:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 JOGm8Dx2r7t3 for ; Thu, 10 Sep 2015 13:15:05 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (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 BAD191B3BDF for ; Thu, 10 Sep 2015 13:15:05 -0700 (PDT) Received: by pacfv12 with SMTP id fv12so53074242pac.2 for ; Thu, 10 Sep 2015 13:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=nEradXDmicoJZ+8xog/AMVDj6MM2L/bmJMZgnJqJQpI=; b=BSx0y+PQgISwgmCwxBa3fu0Ydh04f+CA1lFjOjhNc5sCNpNnVdplULub+Oxj7uxw1Z Eunoxo8tpDBGv3/VUW42l5dIl0dPYaSpmxpbfaFv7iLbK740A8wkj2IK3fGIwjW/tqPy H3dbUIVkLvFuOsVQA2vDOoFPFVIFUhe9HyywKg1oXyrcfdQe8j3ItkABKRlTvfHtk2z7 6r4G/pUgHmJyF4FYSeqXxEB4Sip+vCuGUvKVvLc9NoiZivYoK9X+h8qsvXZRebUEHlHE Bht1VgnS+VxyKgxPOkziO66JuUl9F3ucoKST9z06mTlweFGJfKgSD47nVCUFq12MjfqK rOrQ== X-Received: by 10.68.233.200 with SMTP id ty8mr86918650pbc.80.1441916105399; Thu, 10 Sep 2015 13:15:05 -0700 (PDT) Received: from [192.168.178.25] (3.219.69.111.dynamic.snap.net.nz. [111.69.219.3]) by smtp.gmail.com with ESMTPSA id fd5sm13605237pbb.53.2015.09.10.13.15.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Sep 2015 13:15:03 -0700 (PDT) To: anima-bootstrap@ietf.org References: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305A033@xmb-rcd-x14.cisco.com> <32334.1441856684@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305AA13@xmb-rcd-x14.cisco.com> <3004.1441905090@sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <55F1E4B8.1010802@gmail.com> Date: Fri, 11 Sep 2015 08:14:48 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <3004.1441905090@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of combined? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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, 10 Sep 2015 20:15:07 -0000 On 11/09/2015 05:11, Michael Richardson wrote: ... > If we let GRASP talk to the bare wire, we open up GRASP to new kinds of attacks that it wouldn't otherwise see if it's always inside the ACP. I don't see how the first stage of discovery (GRASP or non-GRASP) after power-up can be anything but bare wire. Once you've found somebody to talk to, you can presumably use some pre-loaded credentials to join the ACP. Is this fundamentally different from DICE (which I recently reviewed with my Gen-ART hat)? https://tools.ietf.org/html/draft-ietf-dice-profile-16#section-4.1 A feature of the DICE profile is that it doesn't pick one of the three options, which IMNSHO is very bad for interoperability. Brian From nobody Fri Sep 11 01:11:42 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A818F1B4014 for ; Fri, 11 Sep 2015 01:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.511 X-Spam-Level: X-Spam-Status: No, score=-16.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 BHBqmvffF33O for ; Fri, 11 Sep 2015 01:11:38 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4601B3AB4 for ; Fri, 11 Sep 2015 01:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12468; q=dns/txt; s=iport; t=1441959092; x=1443168692; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SiKwjsQCMayYFM0BZbSmNTEN2AcD7yjUqaW7GMc9Pmg=; b=FUJUzpB2VvtXzI4YUmPMRif8l5Sm2xmdjK3hAj+/+kFPmj8RCtg1Ps34 d+fHbWhDK4MddxIpO9dPCE0A7OCLjP5On1ryimdfbmnn2OLbGj2cyECdg Wk3SIzHak3E6j2CGtSd+BeNxOKXQrL6+7MxDQ9OExFW7xSf8i6tHdVPh9 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AZAgC1i/JV/5ldJa1dgyOBPQa9LAENh3ECgU44FAEBAQEBAQGBCoQjAQEBAwE6LRIFBwQCAQgRBAEBAQoUCQcyFAkIAgQOBQiIHgjLYwEBAQEBAQEBAQEBAQEBAQEBAQEBAReGc4R9hFwxBwaDEoEUAQSHLAUChUSBLocxAYd2hk+HU41ug2wfAQFCgg0DHIFUcYhZJRyBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,511,1437436800"; d="scan'208";a="187138297" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 11 Sep 2015 08:11:31 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t8B8BVgt029829 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 11 Sep 2015 08:11:31 GMT Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 11 Sep 2015 03:11:30 -0500 Received: from xhc-aln-x15.cisco.com (173.36.12.89) by xch-rcd-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 11 Sep 2015 03:11:30 -0500 Received: from xmb-rcd-x14.cisco.com ([169.254.4.116]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0248.002; Fri, 11 Sep 2015 03:11:30 -0500 From: "Michael Behringer (mbehring)" To: Michael Richardson Thread-Topic: [Anima-bootstrap] Bootstrap and ACP creation: Separate of combined? Thread-Index: AQHQ6+vEksMdqzGR7UKWNJUcSN3zdp425KsQ Date: Fri, 11 Sep 2015 08:11:29 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305BE9C@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305A033@xmb-rcd-x14.cisco.com> <32334.1441856684@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305AA13@xmb-rcd-x14.cisco.com> <3004.1441905090@sandelman.ca> In-Reply-To: <3004.1441905090@sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.238.136] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "anima-bootstrap@ietf.org" Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of combined? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 11 Sep 2015 08:11:40 -0000 > -----Original Message----- > From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael > Richardson > Sent: 10 September 2015 19:12 > To: Michael Behringer (mbehring) > Cc: anima-bootstrap@ietf.org > Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of > combined? >=20 >=20 > Michael Behringer (mbehring) wrote: > >> Assumption 1 (to be confirmed/denied elsewhere): - that the ACP is > >> formed by a series of transport-mode IPsec tunnels setup to carry > >> IP(proto-41) traffic. (i.e. tunnel-mode without the tunnel mode SP= D > >> restrictions). >=20 > > Actually the ACP must be tunnel mode, because it carries packets th= at > > come from and go to , ie are routed through = a > > specific ACP tunnel. >=20 > No, the ACP must have a tunnel, but because it doesn't know what the > source/destination of the packets is going to be, it can't use IPsec tunn= el > mode. Rather it has to use IPsec transport mode for IPIP packets. > The distinction is subtle, since the packets look the same on the wire. >=20 > Both look like: > IP1 / ESP / IP2 / ulp > In IPsec tunnel mode: XXXXXXXXXXXXXXX > In IPsec transport mode: YYYYYYYYYY Yes, I think you're right, it's been a while that I looked at the details. = BTW, I suggest to use GRE rather than IPIP. Costs 4 bytes, but gives more f= lexibility. Thoughts?=20 =20 > In tunnel mode the IPsec system is responsible for validating that the sr= c/dst > of IP2 match the policy (the X part). Since we will run a routing protoc= ol on > top, and the addresses will be assigned inside, we can't even know what t= he > addresses are going to be, and we can't just guess the entire > /48 (or /64) of the ULA, because that's not precise enough for IPsec. I'm not arguing about transport mode, I think you're right, but just for my= understanding: Why would a policy "any to any" not be sufficient here? See= ms to me that would do the job?=20 > In transport mode, the IPsec system just validates that the thing inside = the > ESP is a proto=3D41, and leaves it at that. >=20 > >> In order to build these tunnels, we have to run IKEv2 over link-la= yer > >> addresses. To do this we have to have the addresses of the peers = that > >> run ANIMA. On a link without layer-2 security (1x/WPA) then we ha= ve > >> to have a way to discover the peers; this could be GRASP in some > >> insecure formulation, or some other service discovery. We could e= ven > >> do this with multicast on UDP port 500 (the IKE port). >=20 > > My view is also that this should be GRASP. Using IKE for that sound= s > > really strange to me, but need to think more about it. >=20 > If we let GRASP talk to the bare wire, we open up GRASP to new kinds of > attacks that it wouldn't otherwise see if it's always inside the ACP. That is true. On the other hand, I think we'll end up in situations where a= n ASA will talk to another ASA over the data plane, in which case that migh= t happen anyway.=20 The other thought is: Well, there will have to be some negotiation before s= etting up a tunnel, using protocol x. So we need to secure protocol x, what= ever it is, against DoS, spoofing etc, as much as we can. Why does it matte= r whether x is GRASP or another protocol? Because some checks may not be ne= eded if it's ACP only and the implementation would be more complex? But the= n, having another protocol just moves that complexity?=20 > (I would personally implement it as a seperate process if we did that) On= the > other hand, IKEv2 has to deal with all those attacks ANYWAY. >=20 > Yes, multicasting an IKEv2 I1 packet is definitely odd.... but go read RF= C7296, > section 2.6. Essentially, a responder would agree that they exist, but c= ould > consider the multicast destination address as an attack and demand a > COOKIE. The initiator should really pick a new Ni. If we wanted to do t= his, I > could write an ID explaining how; I don't know how controversial it might= be. Hmmm.... I start to see where you're going. Basically, use IKEv2 to do adja= cency discovery, because it has already the required security mechanisms, a= nd because you shouldn't re-invent something that works. Thinking out loud = here...=20 If you're sitting on a subnet where an IPsec gateway is connected, you'd pr= obably confuse the hell out of that, so we'd need a different port to run o= n.=20 Now there will be following cases:=20 - the other node is not autonomic: Will not respond. That's ok - the other node is autonomic: + in the same domain: authenticates, all good.=20 + but not enrolled: How would it respond?=20 + in a different domain: How would it respond?=20 Looks like, probably we'd need to modify/extend IKE somehow.=20 But yes, it would integrate nicely with building the tunnel, of course.=20 Interesting idea.=20 OTOH, how would it integrate with the enrolment process? The EAP / EST stor= y sounds pretty clean to me. Would you do IKE first, and if the other node = has no LDevID, kick off EAP/EST?=20 > >> Assumption 3: - a node really has no idea what constitutes a "doma= in > >> certificate", >=20 > > I don't understand that statement. There is a series of interaction= s > > that we're specifying here, ANIMA transactions, and the result of t= hose > > will be the device getting the "domain certificate". What do you me= an > > by the above? >=20 > How does one know what a domain certificate is? > The IDevID shipped in the system might already be signed by the correct > Registrar. The system could have been a new certificate (an LDevID), whi= ch > after the system is moved, is now wrong. Maybe the system didn't move, > but just had a new interface attached, and the existing LDevID is wrong f= or > *that* interface. It's a system requirement.=20 1) A device must *know* what its IDevID is. It must also know if it DOESN'T= have an IDevID. 2) Anything that came through the bootstrap process we're defining here is = by definition an LDevID, what I call the "domain certificate". That's clear= .=20 3) That leaves the case where an operator installs a certificate by other m= eans. And I guess we have two cases here:=20 a) this is really meant as an IDevID: Example: integrator buys white lab= el cheap boxes, resells them under his name to various customers, that will= use their own LDevID.=20 b) it's meant as an LDevID: Example: SP pre-installs devices for specifi= c customers.=20 Bottom line: When installing certs through other means than AN, we need to = be able to distinguish.=20 =20 > >> it comes with with one IDevIDs, and may have one or more LDevIDs, = but > >> the enrollment process may either replace the IDevID, or argument = it > >> with LDevIDs instead. >=20 > > The enrolment process provides the device with an LDevID. I see tha= t in > > parallel to the IDevID, I don't see why it would "replace" that. Bu= t > > that's a detail I guess. >=20 > The reason to replace the IDevID is to avoid being vulnerable to an attac= k by > the vendor (or an attack where the vendor's CA is compromised, or an atta= ck > where a National Security Letter forces the vendor's hand). Let's not call this "replace", but "disable". Then the above distinction re= main correct, and we just have to think about how to disable. The IDevID is exclusively used after a factory reset. Once enrolled in a do= main, it's only the LDevID that's used, and renewed when needed.=20 So we could define a mechanism, where, after successful enrolment into a do= main, the admin can change the behaviour of the device.=20 Thinking about this, we don't want to "disable" nor "replace", but we want= to change the startup behaviour. We want to say "henceforth, you will NO L= ONGER require an authorization token." And flag in internal systems (regist= rar, etc) that the IDevID is no longer trusted, and that we don't consult t= he MASA (for this or all devices). That's it, then I have no more links wit= h the vendor. Now, this has a lot of security consequences, and I'd really want to look c= losely at them, so not sure we want to actually go down this route, but tec= hnically it looks possible to me.=20 > >> As such, a node is always able to join a new network that provides= the > >> right credentials, and in some cases, it could be even "pre-enroll= ed" > >> (it already has the right certificates). >=20 > > Right. Small addition: Once a device has a domain certificate, it w= ill > > stop the enrolment process. >=20 > No, it can't do that. > It has to always be willing to do a new enrollment, potentially on a new > interface. > If it does that then the system can never be relocated, repurposed or sol= d > without touching the device before shutting it down from the place it is. Agreed, and I call that a "feature" :-)=20 Re-location to another place in the same domain works anyway, no problem. W= hen plugging the device into another domain, you move the device physically= anyway, so a factory reset is perfectly acceptable.=20 And in the way it is currently, nobody can hijack a device into another dom= ain without physical access. That's a very nice security feature to have!!= =20 > >> I could go on about how we actually need to always be ready for a = new > >> enrollment, because the device may have moved, been sold, etc. Th= e > >> device also may *not* have moved or been sold, but simply could ha= ve > >> had a new cable plugged in, and perhaps *that* side will be > >> participating in a different domain. >=20 > > In my view: Once a device has a domain cert, it stops enrolment. If= you > > want to move the device to another domain, you have to "push a > button" > > to reset it. >=20 > That just doesn't fly for me. > What happens if I walk up to a device that is operating and push that but= ton? > Wouldn't that be a denial of service? What if I unplug the device? Much easier and much more efficient :-)=20 And, re-enrolment is actually also automatic, so this isn't a good DoS atta= ck, compared to unplugging.=20 =20 > > I hope we agree that a topological move in the same domain shouldn'= t > > matter since the ACP address is an identifier, not locator, and sin= ce > > topology is discovered anyway. >=20 > I agree, as long as it's within the same ACP (and the ACP isn't partition= ed in a > pathological way), then the move not a problem. OK. =20 > > -------------------------------------------------------------------= - >=20 > > New discussion: A domain device sees another, validated domain > > device. Next step: Establish the ACP. >=20 > > Now we do IKE and the rest of the story, using the domain certs for > > authentication. >=20 > > One reason to keep those beasts separate is because the domain cert > > might also get to the device by other means, or be pre-installed. S= o > > the ACP process should really be different. >=20 > If the domain cert is already there via other means (perhaps installed as= the > IDevID), then the IKEv2 process just uses it, and the enrollment process = isn't > necessary. This now makes sense with your explanation on how you'd use IKE.=20 So, the main questions at hand now are (in my head):=20 1 - whether we can/should use IKEv2 in a modified form for adjacency discov= ery (leave alone everything else for now!). In that function, it must also = show AN nodes from other domains, and be able to build an adjacency table w= ith that information.=20 (the fact that on discovery of a neighbour in the same domain, you can now = move straight to establishing the IPsec tunnels is not really the question = for this point, but certainly elegant) 2 - How we'd have to modify IKE.=20 3 - How this would integrate with the enrolment process. Would you still su= ggest EAP/EST, and keep things separate?=20 And of course, once we have answers to those questions, compare to a GRASP = approach.=20 Good discussion!! Thanks, lots of good input!=20 Michael From nobody Fri Sep 11 07:09:26 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179851B3800 for ; Fri, 11 Sep 2015 07:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 uQvfotcHKm7T for ; Fri, 11 Sep 2015 07:09:22 -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 DFFB41B45FC for ; Fri, 11 Sep 2015 07:09:21 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CB48120098; Fri, 11 Sep 2015 10:09:48 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5E37763B18; Fri, 11 Sep 2015 10:09:20 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3B64463AEC; Fri, 11 Sep 2015 10:09:20 -0400 (EDT) From: Michael Richardson To: "Michael Behringer \(mbehring\)" In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305BE9C@xmb-rcd-x14.cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305A033@xmb-rcd-x14.cisco.com> <32334.1441856684@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305AA13@xmb-rcd-x14.cisco.com> <3004.1441905090@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305BE9C@xmb-rcd-x14.cisco.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Cc: "anima-bootstrap@ietf.org" Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of combined? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 11 Sep 2015 14:09:25 -0000 --=-=-= Content-Type: text/plain Michael Behringer (mbehring) wrote: >> Both look like: IP1 / ESP / IP2 / ulp In IPsec tunnel mode: >> XXXXXXXXXXXXXXX In IPsec transport mode: YYYYYYYYYY > Yes, I think you're right, it's been a while that I looked at the > details. BTW, I suggest to use GRE rather than IPIP. Costs 4 bytes, but > gives more flexibility. Thoughts? I don't object, but I see that flexibility as an interoperability hurdle. How does having an extra layer-2 header help us at all? I note that IKE could offer different things, which provides for some degree off transition/upgrade if we found a use for GRE. >> In tunnel mode the IPsec system is responsible for validating that the >> src/dst of IP2 match the policy (the X part). Since we will run a >> routing protocol on top, and the addresses will be assigned inside, we >> can't even know what the addresses are going to be, and we can't just >> guess the entire /48 (or /64) of the ULA, because that's not precise >> enough for IPsec. > I'm not arguing about transport mode, I think you're right, but just > for my understanding: Why would a policy "any to any" not be sufficient > here? Seems to me that would do the job? The "any to any" policy results in creation of a default route on many systems, because the policy negotiated determines what traffic goes into the tunnel. >> If we let GRASP talk to the bare wire, we open up GRASP to new kinds >> of attacks that it wouldn't otherwise see if it's always inside the >> ACP. > That is true. On the other hand, I think we'll end up in situations > where an ASA will talk to another ASA over the data plane, in which > case that might happen anyway. > The other thought is: Well, there will have to be some negotiation > before setting up a tunnel, using protocol x. So we need to secure > protocol x, whatever it is, against DoS, spoofing etc, as much as we > can. Why does it matter whether x is GRASP or another protocol? Because > some checks may not be needed if it's ACP only and the implementation > would be more complex? But then, having another protocol just moves > that complexity? Because IKEv2 is *already* secured against these things. > If you're sitting on a subnet where an IPsec gateway is connected, > you'd probably confuse the hell out of that, so we'd need a different > port to run on. I actually doubt it binds the link-layer multicast address. But, we certainly could ask for a different port number anyway. > Now there will be following cases: > - the other node is not autonomic: Will not respond. That's ok > - the other node is autonomic: > + in the same domain: authenticates, all good. > + but not enrolled: How would it respond? > + in a different domain: How would it respond? Actually, one can't know if you are in the same domain or not until you see the identities, which IKEv2 sends in the (encrypted) I2/R2 messages. So the last three cases are identical. That's also good because it means that a not-yet-enrolled node doesn't necessarily reveal that fact. >> after the system is moved, is now wrong. Maybe the system didn't move, >> but just had a new interface attached, and the existing LDevID is >> wrong for >> *that* interface. > It's a system requirement. > 1) A device must *know* what its IDevID is. It must also know if it > DOESN'T have an IDevID. If it doesn't have an IDevID at all, then that's fine. But, given a certificate, how can it know it's a domain certificate? They are all: Issuer FOO says that Public Key BAR belongs to DN BAZ. Only if you know if "FOO" is a domain certificate can you know what's going on. > 2) Anything that came through the bootstrap process we're defining here > is by definition an LDevID, what I call the "domain > certificate". That's clear. I disagree, the process might replace/update the IDevID. That's explicitely supported in 802.1AR. > 3) That leaves the case where an operator installs a certificate by > other means. And I guess we have two cases here: > a) this is really meant as an IDevID: Example: integrator buys white > label cheap boxes, resells them under his name to various customers, > that will use their own LDevID. Sure. But that can be done via ANIMA bootstrap protocol. And customer A can easily resell the box to customer B. > Bottom line: When installing certs through other means than AN, we need > to be able to distinguish. I just don't think it matters. >> The reason to replace the IDevID is to avoid being vulnerable to an >> attack by the vendor (or an attack where the vendor's CA is >> compromised, or an attack where a National Security Letter forces the >> vendor's hand). > Let's not call this "replace", but "disable". Then the above > distinction remain correct, and we just have to think about how to > disable. 802.1AR supports replace, rather explicitely. > The IDevID is exclusively used after a factory reset. Once enrolled in > a domain, it's only the LDevID that's used, and renewed when needed. Are you saying that after a factor reset that the disabled IDevID will become enabled again? > Thinking about this, we don't want to "disable" nor "replace", but we > want to change the startup behaviour. We want to say "henceforth, you > will NO LONGER require an authorization token." And flag in internal The word "require" is wrong -- it should be "accept" > Now, this has a lot of security consequences, and I'd really want to > look closely at them, so not sure we want to actually go down this > route, but technically it looks possible to me. >> It has to always be willing to do a new enrollment, potentially on a new >> interface. >> If it does that then the system can never be relocated, repurposed or >> sold without touching the device before shutting it down from the >> place it is. > Agreed, and I call that a "feature" :-) I sure do not. I'm pretty sure no military or humanitarian organization that wants to do rapid deployment would want this feature. > Re-location to another place in the same domain works anyway, no > problem. When plugging the device into another domain, you move the > device physically anyway, so a factory reset is perfectly acceptable. > And in the way it is currently, nobody can hijack a device into another > domain without physical access. That's a very nice security feature to > have!! Physical access is not a problem for many devices we care about :-) >> That just doesn't fly for me. >> What happens if I walk up to a device that is operating and push that button? >> Wouldn't that be a denial of service? > What if I unplug the device? Much easier and much more efficient :-) > And, re-enrolment is actually also automatic, so this isn't a good DoS > attack, compared to unplugging. If loss of power is a concern, you can deal with that using internal batteries. Every home alarm system has that battery locked inside the box. >> If the domain cert is already there via other means (perhaps installed >> as the IDevID), then the IKEv2 process just uses it, and the >> enrollment process isn't necessary. > This now makes sense with your explanation on how you'd use IKE. > So, the main questions at hand now are (in my head): > 1 - whether we can/should use IKEv2 in a modified form for adjacency > discovery (leave alone everything else for now!). In that function, it > must also show AN nodes from other domains, and be able to build an > adjacency table with that information. > (the fact that on discovery of a neighbour in the same domain, you can > now move straight to establishing the IPsec tunnels is not really the > question for this point, but certainly elegant) > 2 - How we'd have to modify IKE. > 3 - How this would integrate with the enrolment process. Would you > still suggest EAP/EST, and keep things separate? Yes, I think that I'd still use EAP/EST, although I have some qualms about how silly it is to run TLS inside IKEv2, but that's the reality of EST. > Good discussion!! Thanks, lots of good input! yes! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVfLgjICLcPvd0N1lAQKdpAgAmVEdpUetosRs/NIuqVVJzEsHNggs25gN vHgYPiHlRceooJkjtWNnW7fdlU6kAKrGeV5guDdLk12TTHAbrhYy5zgvTFwd03RJ 9Nrdcl2a5P9VdRkeB4DxcwcNY5j9HSSV3OhxoiWEmfbEWzlARtJRZTLTqaHptbRU elg5+tfO2ctG9IdXU73iS1Y01Y7rbBcNlqugAGBeGj3BZjkl2+GnNV3C4F9shgK5 uNNSHb0pgT8kcuhHqwOIA9+iVyQZdwiK3ATHJW084FBtW5Q/7hSTnOeg1jZDPvUA NdZMJ+jN0deaUfitLTAGaDbSAL2L5Dzm6bDVzib2gfDrzzDr5TIRSg== =Td6q -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Sep 11 07:23:15 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B847D1B3CA4 for ; Fri, 11 Sep 2015 07:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.511 X-Spam-Level: X-Spam-Status: No, score=-16.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 6HFUAL4UnXID for ; Fri, 11 Sep 2015 07:23:11 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A55371B2F26 for ; Fri, 11 Sep 2015 07:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13303; q=dns/txt; s=iport; t=1441981391; x=1443190991; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=0N/UiZIEo3GML5vTt6qu7utmaKZwF7854Qh4b0f7lnI=; b=VqbviVOE4gh5EfdafBUBOM1RcJyBQhr8Yi5CvYHg0jDCIrKi66loyvIq sr3N5+rY/URDmv/MeDYBbIfA0yTGQADBxYKcFb9hKfYLs/H0GL/qnVnb5 6k8yKYE4w3kue7RvgqGmLqpKSyjUs/OSViVOVObTBJemwjtSLws8y12IL w=; X-IronPort-AV: E=Sophos;i="5.17,511,1437436800"; d="scan'208";a="26227141" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-8.cisco.com with ESMTP; 11 Sep 2015 14:23:11 +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 t8BENA8i030308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Sep 2015 14:23:10 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 t8BENAEu017520; Fri, 11 Sep 2015 07:23:10 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t8BEN977017519; Fri, 11 Sep 2015 07:23:09 -0700 Date: Fri, 11 Sep 2015 07:23:09 -0700 From: Toerless Eckert To: "Michael Behringer (mbehring)" Message-ID: <20150911142309.GS14573@cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305A033@xmb-rcd-x14.cisco.com> <32334.1441856684@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305AA13@xmb-rcd-x14.cisco.com> <3004.1441905090@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305BE9C@xmb-rcd-x14.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305BE9C@xmb-rcd-x14.cisco.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Michael Richardson , "anima-bootstrap@ietf.org" Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of combined? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 11 Sep 2015 14:23:14 -0000 Tunnel mode sounds right. The problem with encap really is that there will be different optimized HW-forwardable encaps in different spaces. Most likely 802.1ae on "switch" equipment and maybe IPsec over GRE across routers. Just the Cisco example. For interop, we need an MTI (mandatory to implement). I fear that IPsec (with either GRE or IPIP) is not a good MTI. (IPsec, etc..) on top of UDP would make it possible to get through most NAT/FW and to implement in userland/unprivileged apps. Toerless On Fri, Sep 11, 2015 at 08:11:29AM +0000, Michael Behringer (mbehring) wrote: > > -----Original Message----- > > From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael > > Richardson > > Sent: 10 September 2015 19:12 > > To: Michael Behringer (mbehring) > > Cc: anima-bootstrap@ietf.org > > Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of > > combined? > > > > > > Michael Behringer (mbehring) wrote: > > >> Assumption 1 (to be confirmed/denied elsewhere): - that the ACP is > > >> formed by a series of transport-mode IPsec tunnels setup to carry > > >> IP(proto-41) traffic. (i.e. tunnel-mode without the tunnel mode SPD > > >> restrictions). > > > > > Actually the ACP must be tunnel mode, because it carries packets that > > > come from and go to , ie are routed through a > > > specific ACP tunnel. > > > > No, the ACP must have a tunnel, but because it doesn't know what the > > source/destination of the packets is going to be, it can't use IPsec tunnel > > mode. Rather it has to use IPsec transport mode for IPIP packets. > > The distinction is subtle, since the packets look the same on the wire. > > > > Both look like: > > IP1 / ESP / IP2 / ulp > > In IPsec tunnel mode: XXXXXXXXXXXXXXX > > In IPsec transport mode: YYYYYYYYYY > > Yes, I think you're right, it's been a while that I looked at the details. BTW, I suggest to use GRE rather than IPIP. Costs 4 bytes, but gives more flexibility. Thoughts? > > > In tunnel mode the IPsec system is responsible for validating that the src/dst > > of IP2 match the policy (the X part). Since we will run a routing protocol on > > top, and the addresses will be assigned inside, we can't even know what the > > addresses are going to be, and we can't just guess the entire > > /48 (or /64) of the ULA, because that's not precise enough for IPsec. > > I'm not arguing about transport mode, I think you're right, but just for my understanding: Why would a policy "any to any" not be sufficient here? Seems to me that would do the job? > > > In transport mode, the IPsec system just validates that the thing inside the > > ESP is a proto=41, and leaves it at that. > > > > >> In order to build these tunnels, we have to run IKEv2 over link-layer > > >> addresses. To do this we have to have the addresses of the peers that > > >> run ANIMA. On a link without layer-2 security (1x/WPA) then we have > > >> to have a way to discover the peers; this could be GRASP in some > > >> insecure formulation, or some other service discovery. We could even > > >> do this with multicast on UDP port 500 (the IKE port). > > > > > My view is also that this should be GRASP. Using IKE for that sounds > > > really strange to me, but need to think more about it. > > > > If we let GRASP talk to the bare wire, we open up GRASP to new kinds of > > attacks that it wouldn't otherwise see if it's always inside the ACP. > > That is true. On the other hand, I think we'll end up in situations where an ASA will talk to another ASA over the data plane, in which case that might happen anyway. > > The other thought is: Well, there will have to be some negotiation before setting up a tunnel, using protocol x. So we need to secure protocol x, whatever it is, against DoS, spoofing etc, as much as we can. Why does it matter whether x is GRASP or another protocol? Because some checks may not be needed if it's ACP only and the implementation would be more complex? But then, having another protocol just moves that complexity? > > > (I would personally implement it as a seperate process if we did that) On the > > other hand, IKEv2 has to deal with all those attacks ANYWAY. > > > > Yes, multicasting an IKEv2 I1 packet is definitely odd.... but go read RFC7296, > > section 2.6. Essentially, a responder would agree that they exist, but could > > consider the multicast destination address as an attack and demand a > > COOKIE. The initiator should really pick a new Ni. If we wanted to do this, I > > could write an ID explaining how; I don't know how controversial it might be. > > Hmmm.... I start to see where you're going. Basically, use IKEv2 to do adjacency discovery, because it has already the required security mechanisms, and because you shouldn't re-invent something that works. Thinking out loud here... > > If you're sitting on a subnet where an IPsec gateway is connected, you'd probably confuse the hell out of that, so we'd need a different port to run on. > > Now there will be following cases: > - the other node is not autonomic: Will not respond. That's ok > - the other node is autonomic: > + in the same domain: authenticates, all good. > + but not enrolled: How would it respond? > + in a different domain: How would it respond? > > Looks like, probably we'd need to modify/extend IKE somehow. > But yes, it would integrate nicely with building the tunnel, of course. > Interesting idea. > > OTOH, how would it integrate with the enrolment process? The EAP / EST story sounds pretty clean to me. Would you do IKE first, and if the other node has no LDevID, kick off EAP/EST? > > > >> Assumption 3: - a node really has no idea what constitutes a "domain > > >> certificate", > > > > > I don't understand that statement. There is a series of interactions > > > that we're specifying here, ANIMA transactions, and the result of those > > > will be the device getting the "domain certificate". What do you mean > > > by the above? > > > > How does one know what a domain certificate is? > > The IDevID shipped in the system might already be signed by the correct > > Registrar. The system could have been a new certificate (an LDevID), which > > after the system is moved, is now wrong. Maybe the system didn't move, > > but just had a new interface attached, and the existing LDevID is wrong for > > *that* interface. > > It's a system requirement. > 1) A device must *know* what its IDevID is. It must also know if it DOESN'T have an IDevID. > 2) Anything that came through the bootstrap process we're defining here is by definition an LDevID, what I call the "domain certificate". That's clear. > 3) That leaves the case where an operator installs a certificate by other means. And I guess we have two cases here: > a) this is really meant as an IDevID: Example: integrator buys white label cheap boxes, resells them under his name to various customers, that will use their own LDevID. > b) it's meant as an LDevID: Example: SP pre-installs devices for specific customers. > > Bottom line: When installing certs through other means than AN, we need to be able to distinguish. > > > >> it comes with with one IDevIDs, and may have one or more LDevIDs, but > > >> the enrollment process may either replace the IDevID, or argument it > > >> with LDevIDs instead. > > > > > The enrolment process provides the device with an LDevID. I see that in > > > parallel to the IDevID, I don't see why it would "replace" that. But > > > that's a detail I guess. > > > > The reason to replace the IDevID is to avoid being vulnerable to an attack by > > the vendor (or an attack where the vendor's CA is compromised, or an attack > > where a National Security Letter forces the vendor's hand). > > Let's not call this "replace", but "disable". Then the above distinction remain correct, and we just have to think about how to disable. > > The IDevID is exclusively used after a factory reset. Once enrolled in a domain, it's only the LDevID that's used, and renewed when needed. > > So we could define a mechanism, where, after successful enrolment into a domain, the admin can change the behaviour of the device. > > Thinking about this, we don't want to "disable" nor "replace", but we want to change the startup behaviour. We want to say "henceforth, you will NO LONGER require an authorization token." And flag in internal systems (registrar, etc) that the IDevID is no longer trusted, and that we don't consult the MASA (for this or all devices). That's it, then I have no more links with the vendor. > > Now, this has a lot of security consequences, and I'd really want to look closely at them, so not sure we want to actually go down this route, but technically it looks possible to me. > > > >> As such, a node is always able to join a new network that provides the > > >> right credentials, and in some cases, it could be even "pre-enrolled" > > >> (it already has the right certificates). > > > > > Right. Small addition: Once a device has a domain certificate, it will > > > stop the enrolment process. > > > > No, it can't do that. > > It has to always be willing to do a new enrollment, potentially on a new > > interface. > > If it does that then the system can never be relocated, repurposed or sold > > without touching the device before shutting it down from the place it is. > > Agreed, and I call that a "feature" :-) > > Re-location to another place in the same domain works anyway, no problem. When plugging the device into another domain, you move the device physically anyway, so a factory reset is perfectly acceptable. > > And in the way it is currently, nobody can hijack a device into another domain without physical access. That's a very nice security feature to have!! > > > >> I could go on about how we actually need to always be ready for a new > > >> enrollment, because the device may have moved, been sold, etc. The > > >> device also may *not* have moved or been sold, but simply could have > > >> had a new cable plugged in, and perhaps *that* side will be > > >> participating in a different domain. > > > > > In my view: Once a device has a domain cert, it stops enrolment. If you > > > want to move the device to another domain, you have to "push a > > button" > > > to reset it. > > > > That just doesn't fly for me. > > What happens if I walk up to a device that is operating and push that button? > > Wouldn't that be a denial of service? > > What if I unplug the device? Much easier and much more efficient :-) > And, re-enrolment is actually also automatic, so this isn't a good DoS attack, compared to unplugging. > > > > I hope we agree that a topological move in the same domain shouldn't > > > matter since the ACP address is an identifier, not locator, and since > > > topology is discovered anyway. > > > > I agree, as long as it's within the same ACP (and the ACP isn't partitioned in a > > pathological way), then the move not a problem. > > OK. > > > > -------------------------------------------------------------------- > > > > > New discussion: A domain device sees another, validated domain > > > device. Next step: Establish the ACP. > > > > > Now we do IKE and the rest of the story, using the domain certs for > > > authentication. > > > > > One reason to keep those beasts separate is because the domain cert > > > might also get to the device by other means, or be pre-installed. So > > > the ACP process should really be different. > > > > If the domain cert is already there via other means (perhaps installed as the > > IDevID), then the IKEv2 process just uses it, and the enrollment process isn't > > necessary. > > This now makes sense with your explanation on how you'd use IKE. > > So, the main questions at hand now are (in my head): > 1 - whether we can/should use IKEv2 in a modified form for adjacency discovery (leave alone everything else for now!). In that function, it must also show AN nodes from other domains, and be able to build an adjacency table with that information. > (the fact that on discovery of a neighbour in the same domain, you can now move straight to establishing the IPsec tunnels is not really the question for this point, but certainly elegant) > 2 - How we'd have to modify IKE. > 3 - How this would integrate with the enrolment process. Would you still suggest EAP/EST, and keep things separate? > > And of course, once we have answers to those questions, compare to a GRASP approach. > > Good discussion!! Thanks, lots of good input! > Michael > > > _______________________________________________ > Anima-bootstrap mailing list > Anima-bootstrap@ietf.org > https://www.ietf.org/mailman/listinfo/anima-bootstrap -- --- Toerless Eckert, eckert@cisco.com From nobody Fri Sep 11 13:10:16 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009CD1B37FB for ; Fri, 11 Sep 2015 13:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 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, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham 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 BnsvLSJRujmz for ; Fri, 11 Sep 2015 13:10:11 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (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 0AF491B4878 for ; Fri, 11 Sep 2015 13:10:09 -0700 (PDT) Received: by padhk3 with SMTP id hk3so83464255pad.3 for ; Fri, 11 Sep 2015 13:10:08 -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-type :content-transfer-encoding; bh=PG3WpRxsoofrHCbRdALPjIBsBVEn5RnTYaHxeQ94FSA=; b=gz5h1+U7+3otijMCfuhXtomOCHFZNQmfqYsdx1EdpBXDLSndxrx3NvG9oqFX35mHx4 Yja9JtDfmEDxds1S+W8quaHMjzVtJXZxPFyKSSywfqYQIVB7+wRwrPl/x2obYNWjFJKP k/axFCfxKT+XCuR8Pe+1njS0lFA6kI1EZFHyOVazo3KDtdPIL1tTGu8ChoX0Lb41J7cC X7JLcFXPaFrBc+yFrqgm0WXclRo9H8+IJReE2H1SbqQxeTELGQv58YQddwkCLuHZ7ImH afEsZxdO/RoFtkqkbFho3Kln/Rn8g66W6VzWQaF6GekNfdW3PvbzvG/ykPtz8x8tx5Ku WbPQ== X-Received: by 10.68.176.227 with SMTP id cl3mr1329858pbc.8.1442002208523; Fri, 11 Sep 2015 13:10:08 -0700 (PDT) Received: from [192.168.178.25] (39.218.69.111.dynamic.snap.net.nz. [111.69.218.39]) by smtp.gmail.com with ESMTPSA id wj12sm1964860pac.9.2015.09.11.13.09.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Sep 2015 13:10:07 -0700 (PDT) To: "Michael Behringer (mbehring)" , Michael Richardson References: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305A033@xmb-rcd-x14.cisco.com> <32334.1441856684@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305AA13@xmb-rcd-x14.cisco.com> <3004.1441905090@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305BE9C@xmb-rcd-x14.cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <55F3350A.9090008@gmail.com> Date: Sat, 12 Sep 2015 08:09:46 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305BE9C@xmb-rcd-x14.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima-bootstrap@ietf.org" Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of combined? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 11 Sep 2015 20:10:15 -0000 Just one point in line... On 11/09/2015 20:11, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael >> Richardson >> Sent: 10 September 2015 19:12 >> To: Michael Behringer (mbehring) >> Cc: anima-bootstrap@ietf.org >> Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of >> combined? >> >> >> Michael Behringer (mbehring) wrote: >> >> Assumption 1 (to be confirmed/denied elsewhere): - that the ACP is >> >> formed by a series of transport-mode IPsec tunnels setup to carry >> >> IP(proto-41) traffic. (i.e. tunnel-mode without the tunnel mode SPD >> >> restrictions). >> >> > Actually the ACP must be tunnel mode, because it carries packets that >> > come from and go to , ie are routed through a >> > specific ACP tunnel. >> >> No, the ACP must have a tunnel, but because it doesn't know what the >> source/destination of the packets is going to be, it can't use IPsec tunnel >> mode. Rather it has to use IPsec transport mode for IPIP packets. >> The distinction is subtle, since the packets look the same on the wire. >> >> Both look like: >> IP1 / ESP / IP2 / ulp >> In IPsec tunnel mode: XXXXXXXXXXXXXXX >> In IPsec transport mode: YYYYYYYYYY > > Yes, I think you're right, it's been a while that I looked at the details. BTW, I suggest to use GRE rather than IPIP. Costs 4 bytes, but gives more flexibility. Thoughts? > >> In tunnel mode the IPsec system is responsible for validating that the src/dst >> of IP2 match the policy (the X part). Since we will run a routing protocol on >> top, and the addresses will be assigned inside, we can't even know what the >> addresses are going to be, and we can't just guess the entire >> /48 (or /64) of the ULA, because that's not precise enough for IPsec. > > I'm not arguing about transport mode, I think you're right, but just for my understanding: Why would a policy "any to any" not be sufficient here? Seems to me that would do the job? > >> In transport mode, the IPsec system just validates that the thing inside the >> ESP is a proto=41, and leaves it at that. >> >> >> In order to build these tunnels, we have to run IKEv2 over link-layer >> >> addresses. To do this we have to have the addresses of the peers that >> >> run ANIMA. On a link without layer-2 security (1x/WPA) then we have >> >> to have a way to discover the peers; this could be GRASP in some >> >> insecure formulation, or some other service discovery. We could even >> >> do this with multicast on UDP port 500 (the IKE port). >> >> > My view is also that this should be GRASP. Using IKE for that sounds >> > really strange to me, but need to think more about it. >> >> If we let GRASP talk to the bare wire, we open up GRASP to new kinds of >> attacks that it wouldn't otherwise see if it's always inside the ACP. > > That is true. On the other hand, I think we'll end up in situations where an ASA will talk to another ASA over the data plane, in which case that might happen anyway. GRASP currently requires TLS for this case (except for the outbound discovery multicast, if needed). Brian > The other thought is: Well, there will have to be some negotiation before setting up a tunnel, using protocol x. So we need to secure protocol x, whatever it is, against DoS, spoofing etc, as much as we can. Why does it matter whether x is GRASP or another protocol? Because some checks may not be needed if it's ACP only and the implementation would be more complex? But then, having another protocol just moves that complexity? > >> (I would personally implement it as a seperate process if we did that) On the >> other hand, IKEv2 has to deal with all those attacks ANYWAY. >> >> Yes, multicasting an IKEv2 I1 packet is definitely odd.... but go read RFC7296, >> section 2.6. Essentially, a responder would agree that they exist, but could >> consider the multicast destination address as an attack and demand a >> COOKIE. The initiator should really pick a new Ni. If we wanted to do this, I >> could write an ID explaining how; I don't know how controversial it might be. > > Hmmm.... I start to see where you're going. Basically, use IKEv2 to do adjacency discovery, because it has already the required security mechanisms, and because you shouldn't re-invent something that works. Thinking out loud here... > > If you're sitting on a subnet where an IPsec gateway is connected, you'd probably confuse the hell out of that, so we'd need a different port to run on. > > Now there will be following cases: > - the other node is not autonomic: Will not respond. That's ok > - the other node is autonomic: > + in the same domain: authenticates, all good. > + but not enrolled: How would it respond? > + in a different domain: How would it respond? > > Looks like, probably we'd need to modify/extend IKE somehow. > But yes, it would integrate nicely with building the tunnel, of course. > Interesting idea. > > OTOH, how would it integrate with the enrolment process? The EAP / EST story sounds pretty clean to me. Would you do IKE first, and if the other node has no LDevID, kick off EAP/EST? > >> >> Assumption 3: - a node really has no idea what constitutes a "domain >> >> certificate", >> >> > I don't understand that statement. There is a series of interactions >> > that we're specifying here, ANIMA transactions, and the result of those >> > will be the device getting the "domain certificate". What do you mean >> > by the above? >> >> How does one know what a domain certificate is? >> The IDevID shipped in the system might already be signed by the correct >> Registrar. The system could have been a new certificate (an LDevID), which >> after the system is moved, is now wrong. Maybe the system didn't move, >> but just had a new interface attached, and the existing LDevID is wrong for >> *that* interface. > > It's a system requirement. > 1) A device must *know* what its IDevID is. It must also know if it DOESN'T have an IDevID. > 2) Anything that came through the bootstrap process we're defining here is by definition an LDevID, what I call the "domain certificate". That's clear. > 3) That leaves the case where an operator installs a certificate by other means. And I guess we have two cases here: > a) this is really meant as an IDevID: Example: integrator buys white label cheap boxes, resells them under his name to various customers, that will use their own LDevID. > b) it's meant as an LDevID: Example: SP pre-installs devices for specific customers. > > Bottom line: When installing certs through other means than AN, we need to be able to distinguish. > >> >> it comes with with one IDevIDs, and may have one or more LDevIDs, but >> >> the enrollment process may either replace the IDevID, or argument it >> >> with LDevIDs instead. >> >> > The enrolment process provides the device with an LDevID. I see that in >> > parallel to the IDevID, I don't see why it would "replace" that. But >> > that's a detail I guess. >> >> The reason to replace the IDevID is to avoid being vulnerable to an attack by >> the vendor (or an attack where the vendor's CA is compromised, or an attack >> where a National Security Letter forces the vendor's hand). > > Let's not call this "replace", but "disable". Then the above distinction remain correct, and we just have to think about how to disable. > > The IDevID is exclusively used after a factory reset. Once enrolled in a domain, it's only the LDevID that's used, and renewed when needed. > > So we could define a mechanism, where, after successful enrolment into a domain, the admin can change the behaviour of the device. > > Thinking about this, we don't want to "disable" nor "replace", but we want to change the startup behaviour. We want to say "henceforth, you will NO LONGER require an authorization token." And flag in internal systems (registrar, etc) that the IDevID is no longer trusted, and that we don't consult the MASA (for this or all devices). That's it, then I have no more links with the vendor. > > Now, this has a lot of security consequences, and I'd really want to look closely at them, so not sure we want to actually go down this route, but technically it looks possible to me. > >> >> As such, a node is always able to join a new network that provides the >> >> right credentials, and in some cases, it could be even "pre-enrolled" >> >> (it already has the right certificates). >> >> > Right. Small addition: Once a device has a domain certificate, it will >> > stop the enrolment process. >> >> No, it can't do that. >> It has to always be willing to do a new enrollment, potentially on a new >> interface. >> If it does that then the system can never be relocated, repurposed or sold >> without touching the device before shutting it down from the place it is. > > Agreed, and I call that a "feature" :-) > > Re-location to another place in the same domain works anyway, no problem. When plugging the device into another domain, you move the device physically anyway, so a factory reset is perfectly acceptable. > > And in the way it is currently, nobody can hijack a device into another domain without physical access. That's a very nice security feature to have!! > >> >> I could go on about how we actually need to always be ready for a new >> >> enrollment, because the device may have moved, been sold, etc. The >> >> device also may *not* have moved or been sold, but simply could have >> >> had a new cable plugged in, and perhaps *that* side will be >> >> participating in a different domain. >> >> > In my view: Once a device has a domain cert, it stops enrolment. If you >> > want to move the device to another domain, you have to "push a >> button" >> > to reset it. >> >> That just doesn't fly for me. >> What happens if I walk up to a device that is operating and push that button? >> Wouldn't that be a denial of service? > > What if I unplug the device? Much easier and much more efficient :-) > And, re-enrolment is actually also automatic, so this isn't a good DoS attack, compared to unplugging. > >> > I hope we agree that a topological move in the same domain shouldn't >> > matter since the ACP address is an identifier, not locator, and since >> > topology is discovered anyway. >> >> I agree, as long as it's within the same ACP (and the ACP isn't partitioned in a >> pathological way), then the move not a problem. > > OK. > >> > -------------------------------------------------------------------- >> >> > New discussion: A domain device sees another, validated domain >> > device. Next step: Establish the ACP. >> >> > Now we do IKE and the rest of the story, using the domain certs for >> > authentication. >> >> > One reason to keep those beasts separate is because the domain cert >> > might also get to the device by other means, or be pre-installed. So >> > the ACP process should really be different. >> >> If the domain cert is already there via other means (perhaps installed as the >> IDevID), then the IKEv2 process just uses it, and the enrollment process isn't >> necessary. > > This now makes sense with your explanation on how you'd use IKE. > > So, the main questions at hand now are (in my head): > 1 - whether we can/should use IKEv2 in a modified form for adjacency discovery (leave alone everything else for now!). In that function, it must also show AN nodes from other domains, and be able to build an adjacency table with that information. > (the fact that on discovery of a neighbour in the same domain, you can now move straight to establishing the IPsec tunnels is not really the question for this point, but certainly elegant) > 2 - How we'd have to modify IKE. > 3 - How this would integrate with the enrolment process. Would you still suggest EAP/EST, and keep things separate? > > And of course, once we have answers to those questions, compare to a GRASP approach. > > Good discussion!! Thanks, lots of good input! > Michael > > > _______________________________________________ > Anima-bootstrap mailing list > Anima-bootstrap@ietf.org > https://www.ietf.org/mailman/listinfo/anima-bootstrap > . > From nobody Sun Sep 13 16:53:10 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C89D1B39DA for ; Sun, 13 Sep 2015 16:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ImTr3-HEcik4 for ; Sun, 13 Sep 2015 16:53:05 -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 8BE141B43FF for ; Sun, 13 Sep 2015 16:53:05 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5DE422002A for ; Sun, 13 Sep 2015 19:53:40 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9283663B18; Sun, 13 Sep 2015 19:53:03 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7502A63AEC for ; Sun, 13 Sep 2015 19:53:03 -0400 (EDT) From: Michael Richardson To: "anima-bootstrap\@ietf.org" In-Reply-To: <20150911142309.GS14573@cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305A033@xmb-rcd-x14.cisco.com> <32334.1441856684@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305AA13@xmb-rcd-x14.cisco.com> <3004.1441905090@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305BE9C@xmb-rcd-x14.cisco.com> <20150911142309.GS14573@cisco.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of combined? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 13 Sep 2015 23:53:08 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > The problem with encap really is that there will be different optimized > HW-forwardable encaps in different spaces. Most likely 802.1ae on > "switch" equipment and maybe IPsec over GRE across routers. Just the Cisco > example. For interop, we need an MTI (mandatory to implement). I fear that > IPsec (with either GRE or IPIP) is not a good MTI. (IPsec, etc..) > on top of UDP would make it possible to get through most NAT/FW and to > implement in userland/unprivileged apps. ESP already runs over UDP, and runs through NAT and FW already. I don't think that this matters though as these are all hop-by-hop links. I think you are very confused here. We are discussing what the IPsec policy for the thing that lives inside the tunnel. As for what is easy to implement on hardware; I think that this irrelevant, as the ACP is better implemented on the control plane CPU, in order to be free to completely reprogram the data plane ASICs. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVfYMXoCLcPvd0N1lAQLQcAgArLQJ/ShhB9+7/7R9LAhY/8X7ikriKJPq I+vZHSC/7FbnelKSRF3YMYkeadmapoV5StgQnFV2qeTP9sn9BNglkMxxgi1W5LHx t03FM6wpUK17zWfH1QrNYw8LO2tA4GYYBokvz735UZ/YMmMwUgWkS1nKrsbUs32A 69E4ufcLjWsHoa2x0aNFUlG5ab0Y5QiYKztDc2RnHUdePQJtftI5sm2EFpf7eaQA /F0AMxI/4Q53N/qcdkbQjxpSsrJZiXVDRb/6L5WarbBjeqYwUGD3JM/uY8OFtFYk f/0L8eh6DQVYHDKS/Qy1AXyO+xzIEhUqbVFx30JPkvFRnsmi6XV3wQ== =oGNa -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Sep 13 17:44:28 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CBA1AC409 for ; Sun, 13 Sep 2015 17:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 NgPOUqcX4zsS for ; Sun, 13 Sep 2015 17:44:25 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71631A8A79 for ; Sun, 13 Sep 2015 17:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1494; q=dns/txt; s=iport; t=1442191464; x=1443401064; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=iHCWk7gpIxtqziQBlIi9xUke7geTHoCXIt6nH1bm35E=; b=ZsgoR80+O4qHb+Nx8RiPB+adCRRKwxtzc3T7NNokZ58YKAl8pXGWhpi/ f39KgIaPdHv0fOXRtvh4ee3X6DLnzCJDa7Mb4Bh7t1IaPR1T89+4vU2nL J5BInHrPRlUeo5VY6qWYSdHUusgmN0xNfyg1o/2EcSPg4hw8qjXPLALkb s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BQAgDTF/ZV/49dJa1dgyOBPb0xAQ2EO4M2AoEkOBQBAQEBAQEBgQqEIwEBAQMBOj8FCwsYCSUPBUkTiCYIyVsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi3CFDQeELAWNbYdqh3uFAAOafh8BAUKEIR4zin0BAQE X-IronPort-AV: E=Sophos;i="5.17,525,1437436800"; d="scan'208";a="186887519" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP; 14 Sep 2015 00:44:24 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t8E0iNqq011056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Sep 2015 00:44:23 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 t8E0iM2H024237; Sun, 13 Sep 2015 17:44:22 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t8E0iMmQ024236; Sun, 13 Sep 2015 17:44:22 -0700 Date: Sun, 13 Sep 2015 17:44:22 -0700 From: Toerless Eckert To: Michael Richardson Message-ID: <20150914004422.GX14573@cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305A033@xmb-rcd-x14.cisco.com> <32334.1441856684@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305AA13@xmb-rcd-x14.cisco.com> <3004.1441905090@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305BE9C@xmb-rcd-x14.cisco.com> <20150911142309.GS14573@cisco.com> <1819.1442188383@sandelman.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1819.1442188383@sandelman.ca> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: "anima-bootstrap@ietf.org" Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of combined? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Sep 2015 00:44:26 -0000 inline, On Sun, Sep 13, 2015 at 07:53:03PM -0400, Michael Richardson wrote: > Toerless Eckert wrote: > > The problem with encap really is that there will be different optimized > > HW-forwardable encaps in different spaces. Most likely 802.1ae on > > "switch" equipment and maybe IPsec over GRE across routers. Just the Cisco > > example. For interop, we need an MTI (mandatory to implement). I fear that > > IPsec (with either GRE or IPIP) is not a good MTI. (IPsec, etc..) > > on top of UDP would make it possible to get through most NAT/FW and to > > implement in userland/unprivileged apps. > > ESP already runs over UDP, and runs through NAT and FW already. Ok, good point. RFC3948 ?! > I don't think that this matters though as these are all hop-by-hop links. > I think you are very confused here. > > We are discussing what the IPsec policy for the thing that lives inside the > tunnel. As for what is easy to implement on hardware; I think that this > irrelevant, as the ACP is better implemented on the control plane CPU, in > order to be free to completely reprogram the data plane ASICs. Depends really on how one wants to use the ACP. I do agree that the MTI should be one that's most portable. IPsec+RFC3948 might be that. How would you compare it to dTLS ? Cheers Toerless > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- From nobody Sun Sep 13 20:43:12 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759551B5924 for ; Sun, 13 Sep 2015 20:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 AZKLsxlyKY0i for ; Sun, 13 Sep 2015 20:43:09 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 2706A1B5A48 for ; Sun, 13 Sep 2015 20:43:09 -0700 (PDT) Received: by padhk3 with SMTP id hk3so130212219pad.3 for ; Sun, 13 Sep 2015 20:43:08 -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-type :content-transfer-encoding; bh=NGUDHU/rIJB9nBGJIqjLJDmOdNQK+yPf+7Viu7NmXGU=; b=DrxwqDB3jUSPVDKeP3dRgyVJ0wMRmsZHzhX61siVtitUy6KUCTffK14H4OU/dvDz/t 0nMa95ywR1W9ZC1XmiuVsGrSHkkYS1sgDkJogUlXksV7wafNQyLayJCDpdwa0EYMZvol nkpS3M5SKpE1fGXTxpD57Hm0EUr6ptos4vwuTkq8C8y+SWMsQcJqDNNCGl2hKAcSCOUl Lc+7FdMAbLCcRoAhJWXDpQB2PtcG3IreSh8y+N/m/nbvch5Q6G1UO2DvfnFFbOgM1U8M H2v2ex3PQ6x+FrZlJeEE9zGK/255a8RtI54BxK74bkDm4FDS3dSDLFkiDSbzCc5OHLnX 9BFA== X-Received: by 10.66.146.69 with SMTP id ta5mr28886891pab.46.1442202188686; Sun, 13 Sep 2015 20:43:08 -0700 (PDT) Received: from [192.168.178.25] (38.224.69.111.dynamic.snap.net.nz. [111.69.224.38]) by smtp.gmail.com with ESMTPSA id lq10sm13010267pab.18.2015.09.13.20.43.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Sep 2015 20:43:07 -0700 (PDT) To: Toerless Eckert , Michael Richardson References: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305A033@xmb-rcd-x14.cisco.com> <32334.1441856684@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305AA13@xmb-rcd-x14.cisco.com> <3004.1441905090@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305BE9C@xmb-rcd-x14.cisco.com> <20150911142309.GS14573@cisco.com> <1819.1442188383@sandelman.ca> <20150914004422.GX14573@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <55F6424A.5030701@gmail.com> Date: Mon, 14 Sep 2015 15:43:06 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150914004422.GX14573@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima-bootstrap@ietf.org" Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of combined? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Sep 2015 03:43:10 -0000 On 14/09/2015 12:44, Toerless Eckert wrote: > inline, > > On Sun, Sep 13, 2015 at 07:53:03PM -0400, Michael Richardson wrote: >> Toerless Eckert wrote: >> > The problem with encap really is that there will be different optimized >> > HW-forwardable encaps in different spaces. Most likely 802.1ae on >> > "switch" equipment and maybe IPsec over GRE across routers. Just the Cisco >> > example. For interop, we need an MTI (mandatory to implement). I fear that >> > IPsec (with either GRE or IPIP) is not a good MTI. (IPsec, etc..) >> > on top of UDP would make it possible to get through most NAT/FW and to >> > implement in userland/unprivileged apps. >> >> ESP already runs over UDP, and runs through NAT and FW already. > > Ok, good point. RFC3948 ?! > >> I don't think that this matters though as these are all hop-by-hop links. >> I think you are very confused here. >> >> We are discussing what the IPsec policy for the thing that lives inside the >> tunnel. As for what is easy to implement on hardware; I think that this >> irrelevant, as the ACP is better implemented on the control plane CPU, in >> order to be free to completely reprogram the data plane ASICs. > > Depends really on how one wants to use the ACP. I do agree that > the MTI should be one that's most portable. IPsec+RFC3948 might be > that. How would you compare it to dTLS ? Are we really requiring the ACP to cross NAT or firewalls inside an autonomic domain? Sorry, I just don't see that. I thought all ACP packets would be link local, with ACP nodes forwarding between links. There are no NATs or firewalls in that picture. Also where does DTLS fit in (rather than TLS)? (Secure multicast?) Brian From nobody Sun Sep 13 21:24:21 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA45B1B5226 for ; Sun, 13 Sep 2015 21:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 vrHaXzEYPAdM for ; Sun, 13 Sep 2015 21:24:18 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0511B5AB8 for ; Sun, 13 Sep 2015 21:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1176; q=dns/txt; s=iport; t=1442204653; x=1443414253; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ETP/JQOyb6i/NsBnZLrFunrk/iNSy0QQ7uI6if83884=; b=QcDAJukzEeYKmrRLvYN3i/MSjPWocj/kA1fuDruDIqDp6nIU6ksg8tgm DoTCm1KQfLEojK31O0mdOmpSRB92C2dEyTM2TugHN85XoqWD4CMBReK8z H/XHEmZY7oovUxOHpn7iW966PIEMjFGcUEaj7iDccwRBhwS9ofe/TT7i6 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D3AQBIS/ZV/4MNJK1dgyO+bwENh3ECgSk4FAEBAQEBAQGBCoQkAQEEOj8QCxgJJQ8FSS6IE8lgAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4twhQ0HgxiBFAWNbYdqjHsDmn4fAQFChCEeizABAQE X-IronPort-AV: E=Sophos;i="5.17,525,1437436800"; d="scan'208";a="187667117" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP; 14 Sep 2015 04:24:13 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t8E4OCRK006229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Sep 2015 04:24:13 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 t8E4OBuA030936; Sun, 13 Sep 2015 21:24:11 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id t8E4OACn030935; Sun, 13 Sep 2015 21:24:10 -0700 Date: Sun, 13 Sep 2015 21:24:10 -0700 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20150914042410.GA14573@cisco.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305A033@xmb-rcd-x14.cisco.com> <32334.1441856684@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305AA13@xmb-rcd-x14.cisco.com> <3004.1441905090@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305BE9C@xmb-rcd-x14.cisco.com> <20150911142309.GS14573@cisco.com> <1819.1442188383@sandelman.ca> <20150914004422.GX14573@cisco.com> <55F6424A.5030701@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55F6424A.5030701@gmail.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Michael Richardson , "anima-bootstrap@ietf.org" Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of combined? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Sep 2015 04:24:20 -0000 On Mon, Sep 14, 2015 at 03:43:06PM +1200, Brian E Carpenter wrote: > Are we really requiring the ACP to cross NAT or firewalls inside an autonomic > domain? Sorry, I just don't see that. I thought all ACP packets would be link > local, with ACP nodes forwarding between links. There are no NATs or firewalls > in that picture. > > Also where does DTLS fit in (rather than TLS)? (Secure multicast?) I have no strong opiniuon about NAT. passing through FW might be quite useful for OAM operations. But more fundamentally, solutions over UDP make it most easily portable. Thats why (d)TLS or ESP over UDP are interesting IMHO. I don't like to put IP packets (which is whats inside ACP) on top of a flow-controlled reliable connection. That just leads to terrible performance behavior because of congestion control inside congestion control (for any reliable connection inside ACP). I do like to put GARP into TLS directly though. I was wondering if one could start with a TLS connection for GARP, inherit the security association for dTLS of ACP as the MTI and use GRP to optionally negotiate a better ACP encryption than dTLS. Cheers Toerless From nobody Mon Sep 14 07:18:37 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22B41A8851 for ; Mon, 14 Sep 2015 07:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 IyjjIz5Y1ZgK for ; Mon, 14 Sep 2015 07:18:35 -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 E0E711A000D for ; Mon, 14 Sep 2015 07:18:34 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B0AA82002A; Mon, 14 Sep 2015 10:19:12 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 047FF63B18; Mon, 14 Sep 2015 10:18:33 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E235163AD9; Mon, 14 Sep 2015 10:18:33 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <55F6424A.5030701@gmail.com> References: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305A033@xmb-rcd-x14.cisco.com> <32334.1441856684@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305AA13@xmb-rcd-x14.cisco.com> <3004.1441905090@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305BE9C@xmb-rcd-x14.cisco.com> <20150911142309.GS14573@cisco.com> <1819.1442188383@sandelman.ca> <20150914004422.GX14573@cisco.com> <55F6424A.5030701@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Cc: Toerless Eckert , "anima-bootstrap@ietf.org" Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of combined? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Sep 2015 14:18:36 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > Are we really requiring the ACP to cross NAT or firewalls inside an > autonomic domain? Sorry, I just don't see that. I thought all ACP > packets would be link local, with ACP nodes forwarding between > links. There are no NATs or firewalls in that picture. +10. I don't understand Toerless' point either. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVfbXNoCLcPvd0N1lAQJ1SAf/ZCzL8/cya3OEz3892XId+FnOxPbt1Nob +9doHOUjAVmgEDmXIE06072gWkYaR8ha1Gh2kqbdenA85cMcZEI9L4Wke0vti4+M nWga5rRWueIYfEGmNReeB1mDuPCbkNIFAedNtqRa/7c3wOn2pzVGB4ntyCfW8kdd EHSxZJWI0URgSODtqSOy6G5RexEuuly7A2i0BYkj8iNDDTVMTVYkuQPfHjBRjHHE Cg0cveZX8D9AVNmrSuimOYkBE41TKu+rU8S/+8CmsmirfZwmPyBokAYj5cGNCEgD y4Yx+LTrsBaOCvfIRr/O+7ULn3JneZOumpQHO8ewplZY2QOWm2WW4A== =iHL7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Sep 14 12:56:31 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8221B3EA4 for ; Mon, 14 Sep 2015 12:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 p8F4z46lOSk4 for ; Mon, 14 Sep 2015 12:56:28 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 875CB1B3587 for ; Mon, 14 Sep 2015 12:56:28 -0700 (PDT) Received: by pacex6 with SMTP id ex6so152812219pac.0 for ; Mon, 14 Sep 2015 12:56:28 -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-type :content-transfer-encoding; bh=Ta1RTf5HPToZyVIEcTqdZ/ZSz020bqseCksZG7Hl1O8=; b=0m9CFG7sH9aP6hloTQsQZNOQ/4L0Jg39iV1oC4ttQHpIIdW4pkuYWGle2dzbNg/AUL 1in338QHpEYrUYXzcw8r02XSHqbtBVKTjKBt3hqQ/7JrwPWX48NaYWITGZmu94LJkivp Ohox8t/aHEZg9pYsT6+uWdfsRtw7WqjUZHkxsCxy8qgFpRiZiBlgIGcLkYYpklnAPSGC mdPILXCwD2U3G7YTLQFwXKukneHpNr1OcvhKXxOSwQOd917lH5U/pDgrRMd+4UQE8iZK 02Q+6rEqr5jmGahDr+ijw/y6I8h2YgbFGG3opdrkJuoY1+2XVjgLGXy1IG7fcebKvE2c 65KQ== X-Received: by 10.69.26.38 with SMTP id iv6mr38234072pbd.151.1442260588182; Mon, 14 Sep 2015 12:56:28 -0700 (PDT) Received: from [192.168.178.25] ([163.47.222.112]) by smtp.gmail.com with ESMTPSA id vw7sm17841197pab.15.2015.09.14.12.56.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Sep 2015 12:56:27 -0700 (PDT) To: Toerless Eckert References: <3AA7118E69D7CD4BA3ECD5716BAF28DF2305A033@xmb-rcd-x14.cisco.com> <32334.1441856684@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305AA13@xmb-rcd-x14.cisco.com> <3004.1441905090@sandelman.ca> <3AA7118E69D7CD4BA3ECD5716BAF28DF2305BE9C@xmb-rcd-x14.cisco.com> <20150911142309.GS14573@cisco.com> <1819.1442188383@sandelman.ca> <20150914004422.GX14573@cisco.com> <55F6424A.5030701@gmail.com> <20150914042410.GA14573@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <55F72665.8080909@gmail.com> Date: Tue, 15 Sep 2015 07:56:21 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150914042410.GA14573@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Michael Richardson , "anima-bootstrap@ietf.org" Subject: Re: [Anima-bootstrap] Bootstrap and ACP creation: Separate of combined? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Sep 2015 19:56:30 -0000 On 14/09/2015 16:24, Toerless Eckert wrote: > On Mon, Sep 14, 2015 at 03:43:06PM +1200, Brian E Carpenter wrote: >> Are we really requiring the ACP to cross NAT or firewalls inside an autonomic >> domain? Sorry, I just don't see that. I thought all ACP packets would be link >> local, with ACP nodes forwarding between links. There are no NATs or firewalls >> in that picture. >> >> Also where does DTLS fit in (rather than TLS)? (Secure multicast?) > > I have no strong opiniuon about NAT. passing through FW might be quite > useful for OAM operations. But more fundamentally, solutions over UDP > make it most easily portable. Thats why (d)TLS or ESP over UDP are > interesting IMHO. > > I don't like to put IP packets (which is whats inside > ACP) on top of a flow-controlled reliable connection. That just leads > to terrible performance behavior because of congestion control inside > congestion control (for any reliable connection inside ACP). Yes, good point. > > I do like to put GARP into TLS directly though. I was wondering if one > could start with a TLS connection for GARP, inherit the security association > for dTLS of ACP as the MTI and use GRP to optionally negotiate a better > ACP encryption than dTLS. GRASP can certainly use TLS directly and that's what I expect will happen for any inter-domain use of GRASP anyway. Brian > > Cheers > Toerless > From nobody Tue Sep 15 19:52:55 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75551B31FE for ; Tue, 15 Sep 2015 19:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham 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 VVAmGYPDkkgE for ; Tue, 15 Sep 2015 19:52:52 -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 E58C21B31FD for ; Tue, 15 Sep 2015 19:52:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EAD5320098 for ; Tue, 15 Sep 2015 22:53:33 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 08F4363B18; Tue, 15 Sep 2015 22:52:49 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E002D63AD9 for ; Tue, 15 Sep 2015 22:52:49 -0400 (EDT) From: Michael Richardson To: anima-bootstrap X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: [Anima-bootstrap] anima bootstrap design team -- admin and logistics X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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, 16 Sep 2015 02:52:53 -0000 --=-=-= Content-Type: text/plain Hi, this email is long overdue, and I appologize for it; start of school year stuff, vacations... The ANIMA bootstrap design team meets weekly at 10am EDT (7am PDT; I write EDT, because it is unclear what will happen when DST is over). We use audio from webex, but rarely any other of its' mechanisms, at: https://cisco.webex.com/ciscosales/j.php?MTID=ma5a7178d02a2edcb0c6d7b43e5315f08 Meeting number: 200 557 721 Meeting password: boot dial: +1-866-432-9903 Call-in toll-free number (US/Canada) +1-408-525-6800 Call-in toll number (US/Canada) We use an etherpad for notes and minutes, which for reasons of a typo is at: http://etherpad.tools.ietf.org:9000/p/anima-boostrapping?useMonospaceFont=true People who have been participating include: Our schedule was set in August as: 2015-09-02 * CANCELLED (but some people met anyway) 2015-09-09 2015-09-16 * tomorrow 2015-09-23 2015-09-30 2015-10-07 2015-10-14 2015-10-21 2015-11-01 is IETF94 week; we plan to find time for a lunch. My job is to post a set of minutes, and it is in this regard that I'm remiss, and so I'll be sending a few emails as replies to this one because writing one big long one will take long enough that I'll never get done. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVfjZfoCLcPvd0N1lAQKrKQf/TcEN8IDloXp0Y3LXaberL/AUOv5nwsLK rGAY4CuKCoFgfAZyVSi3qg2yZbfw8O8vQhlpTxgLDqSCRDm7I4T4mdUNKvxjC5YW OuQrFl7mGpfUsQmJiect5iWg0uXUS78n7/zRtIKBjNHeL7QUvh5IlyNNlZ5QE+J2 goJEdp+PRmKLC4N38OSqTAoK7jGKIPWTuHiO8erAFs5xPyZFko/d9ZiYM7DvxWJs wwFL+2nnbSZwJ/Wux+elJaJmMhcYC7SUbGA6yV/JyOxUT5iOUAWgUpFQnTGyBA6m sVaUnCShHsKm2oRFyaf3fYORDQ1x4F1vuO9ptDsLOxujxnIs5yh0UA== =NjBW -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 15 20:01:43 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9451B3213 for ; Tue, 15 Sep 2015 20:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 dHFa_-DG7rcZ for ; Tue, 15 Sep 2015 20:01:40 -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 A1E571B320D for ; Tue, 15 Sep 2015 20:01:40 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B4B4C20098 for ; Tue, 15 Sep 2015 23:02:23 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B504963B18; Tue, 15 Sep 2015 23:01:39 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 96D9463AD9 for ; Tue, 15 Sep 2015 23:01:39 -0400 (EDT) From: Michael Richardson to: anima-bootstrap In-Reply-To: <2035.1442371969@sandelman.ca> References: <2035.1442371969@sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima-bootstrap] anima bootstrap design team participation so far (blue sheet) X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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, 16 Sep 2015 03:01:42 -0000 --=-=-= Content-Type: text/plain Michael Richardson wrote: > People who have been participating include: forgot to fill this in: Max Pritikin Michael Richardson Michael Behringer Sandeep Kumar (did I get that right?) Kent Watsen Robert Craigie Toerless Eckert not everyone has been at every call. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVfjbkICLcPvd0N1lAQL7uwgApEaVnErWSwOYyLVZWCY1Yk/e1Cv9VKJL D3TTrw1IflEooDnkB9Uq34sAERMgU6dSsaAhqReOFVHAH03xJm3ex7ovPHkO1qYP eThvSEKLB32MDmdsXPVEL0cm4Wk/i1OAgv1fO0jDdbZqT+5kRuWRV16CfYxu/zb7 jBUEELWdHLlOXd5Z+/iJF+P7eIw+AtrRSIabUSkee8AXLMxjAeKPqDdfQmxXu9cB QCHuYt1QItWwnUjROkyheDYuEF/z9C6Mg3m2f63c25HDfqtn2iu6p/Ty6hVyO6ob aQpYo2qi7v6UHrxFTXLpy58f6l7R5qq7NMwHMVBG+uuPF8nRXO68cA== =InER -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 15 20:07:17 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAB21B321F for ; Tue, 15 Sep 2015 20:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7SZNQ4McHlj6 for ; Tue, 15 Sep 2015 20:07:15 -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 69FD61B322B for ; Tue, 15 Sep 2015 20:07:15 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8EB6920098 for ; Tue, 15 Sep 2015 23:07:58 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 878A263B18; Tue, 15 Sep 2015 23:07:14 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6D6AF63AD9 for ; Tue, 15 Sep 2015 23:07:14 -0400 (EDT) From: Michael Richardson to: anima-bootstrap In-Reply-To: <2035.1442371969@sandelman.ca> References: <2035.1442371969@sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima-bootstrap] anima bootstrap design team notes from June/July 2015 X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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, 16 Sep 2015 03:07:16 -0000 --=-=-= Content-Type: text/plain Our first meeting was something like June 4, with meetings being mostly Thursdays or Fridays that month. What happened was that Max and I went through draft-pritikin-anima-bootstrapping-keyinfra carefully and made sure that we agreed on terminology, and what new things to bring in. We updated the XML, and got it ready for submission as -01. We also went through to produce the anima-bootstrap design team charter text, which we edited onto the wiki in that period, and emails were produced detailing that. The notes from July/June can be seen in the anima-boostrap etherpad from the point: "POST IETF93 action items:" We did not meet much in July due to travel and vacations and IETF coming up. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVfjc34CLcPvd0N1lAQJubwf/bd+gQcLjg/Mvsd2sH61yH/TQOFKEylgI aN+J+30n5n6BhzNS8fPil5/fGpgVEC7P4nsVPr1jbVSeoVC9bOBBv6qP+bLz16G1 cayoVEqr8L4ex96L1f+GS5H/UQhmfWZfImb87f/zRy3g2U2PUK1jv6CjZmoO08yN Y3s4FwcGcDsMwsxFVaKnV5Uvh9JMfXHZC/JGUkMRkDkXgVYb/7usN2ziowCbL3Qx FHMABVdxEjGfFD1hNol3q9nptmbrCXk+MXgE3b8H6aZipYXNPHxjCaT8kjloUfL4 ZNcTelmtX7X3aeLrmnrLReiBZlO3HwvEW/7BsprpCRDSK7aU1Ey5wg== =p+TM -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 15 20:27:41 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5351B3276 for ; Tue, 15 Sep 2015 20:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 O8JPB-p54vOZ for ; Tue, 15 Sep 2015 20:27:37 -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 6B7AE1B3270 for ; Tue, 15 Sep 2015 20:27:37 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6001A20098 for ; Tue, 15 Sep 2015 23:28:20 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 43B4563B22; Tue, 15 Sep 2015 23:27:36 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2118563AD9 for ; Tue, 15 Sep 2015 23:27:36 -0400 (EDT) From: Michael Richardson to: anima-bootstrap In-Reply-To: <2035.1442371969@sandelman.ca> References: <2035.1442371969@sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima-bootstrap] anima bootstrap design team -- August/September mess of notes X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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, 16 Sep 2015 03:27:40 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The next meeting was August 5. August 5th meeting: present Max Pritikin, Michael Richardson Some specific result was: The bootstrapping document might be able to get away with indicating a requirement to signaling team (e.g. "end to end connectivity for EAP messages" or something). We are not sure we can require a "concentric = tree ring" growth process. Might be reasonable to have a second doc that that meeting went into the next week, and there was some multiple iterations of recap... August 12: present were: Max Pritikin, Michael Richardson and Michael Behringer (We didn't have the host key for sharing so we moved to: cisco.webex.com/join/mbehring, and max stayed on the original webex as well to watch for late attendees. ) behringer shared a bootstrapping process slide to build on the discussion of (1) and (2) from last week's meeting. MCR: Need to capture a key point: - the designation of something as the Registrar is a non-autonomic operation! MCR thinks that this is controversial, and needs to be brought to the WG for consensus. - the administrator is involved because an ACL or pointer to a trusted cloud ACL or [whatever] is an administrative action This is equivalent to the "intent" abstraction During parts of July and August, we discussed the idea of a prospective ACP; or an ACP which is isolated from the production ACP and which is created without full authentication. The purpose is to provide enough connectivity so that the devices can enroll. We constrasted this to a proxied, or EAP/1x type of process, where new nodes communicate over the layer-2 to a proxy (or authenticator, or join-assistant....) which then relays the EAP messages to a registrar. Such a system requires a concentric inside to outside enrollment process. Michael shared the description a requirement to do bootstrapping in a non-concentric way, but the details could not be shared publically (as yet: these notes are BCCed to the party in question) We constrasted this to systems like TR-069 (used to supply configurations to cables modems and some DSL models), but in those situations the the modems never validate the ISP. MCR called the proxy process as "layer-5 routing" while Max preferred to think of this in 1x terms as selective layer-2 EAP-encapsulation. Vs a pro= spective ACP method which would be layer-3 forwarding, something we know how to do quite well. A prospective ACP could make use of routing protocols and have multip= le paths/redundancy and even do discovery such the registry function might not need to be "decreed by god" In particular, MCR does not have a problem with the layer2-5 approach. He is concerned about 'creep' on that approach wrt identifying new nodes, redundancy, load balancing registrars, etc. Eventually he argues you've re-invented the ACP but in an ad hoc fashion. Other notes that discuss this say: MCR argues that the complexity of (2) is hidden at first but once the system is "at scale" the complexity grows to match the (1) but is now haphazard and not as well thought out. Suggests it is better to go head with (1) but flag the overlay as "for bootstrapping" On the other hand (2) could be designed rather quickly: just add an EAP role as an 'authenticator forwarding'. So this would be less a reinvention but rather leveraging the existing EAP architecture. August 19 was cancelled for vacations. 2015-08-26 meeting notes present: Max, Sandeep, Kent, Michael, Robert Craigie We set the schedule for schedule for future meetings: 2. 2015-09-02 * CANCELLED. 2. 2015-09-09 2. 2015-09-16 2. 2015-09-23 2. 2015-09-30 2. 2015-10-07 2. 2015-10-14 2. 2015-10-21 2. 2015-11-01 is IETF94 week, should plan a lunch. ** need to be more rigorous with notes to mailing lists ** We set out to start: review of the requirements section of draft-ietf-anima-grasp-00:https://tools.ietf.org/html/draft-ietf-anima-g= rasp-00#section-2The requirements are numbered 1..25. If you have comments, please mentionthe requirement number, or propose a completely new requirement. We started on item 25, and it occupied most of the meeting, I think, as we cycled through the prospective ACP vs proxy discussion again. MCR concluded that the afore-mentioned requirement for non-concentric bootstrap was incorrectly conceived. What that situation actually needs a non-concentric configuration of the data plane, and the tool to that is a functional ACP, and it matters not if the ACP is bootstraped concentrically, as long as it can then be used to build non-concentric (and possibly non-connected) data-plane instance in each "apartment" re: =E2=80=9CRe: [Anima-bootstrap] issues and trees [was schedules and agendas]=E2=80=9DM. Behringer, do you agree with B. Carpenter's statemen= t that =E2=80=9CGRASP may have to run insecure discovery=E2=80=9D? That positio= ns GRASP as the communications method even over the =E2=80=9CIPv6 link local=E2=80=9D in= your diagram (albeit an unsecured instantiation of it)? What are our requirements on GRASP? (If GRASP is to be used as the ipv6 link layer communication...) * must be able to come up protected from passive attacks but not active, in some form of quarantine mode. This speaks to req 25: 25. The protocol needs to be fully secured against forged messages and man-in-the middle attacks, and secured as much as reasonably possible against denial of service attacks. It needs to be capable of encryption in order to resist unwanted monitoring, although this capability may not be required in all deployments. However, it is not required that the protocol itself provides these security features; it may depend on an existing secure environment. We discussed IKEv2 as the hop-by-hop security method, noting that it can use EAP as well as PANA and has some other advantages, but it does not provide discovery. NOTE: If GRASP uses ikev2 then PANA/EAP methods are possible. It would be possible to do all key bootstrapping over an EAP method and then GRASP comes up without ever having run insecurely. This wouldn't be a requirement on GRASP so much as a requiement on the ACP transport that GRASP runs over. * Is there a clear statement about how GRASP/ACP comes up in a mesh[terminology? when there is no infrastructure] state? ACTION: MCR to ask this question of the GRASP team (from 'bootstrapping' to 'signaling') * bootstrapping key infrastructures requires some key infrastructure; we do not care if the key infrastructure itself we as autonomically created MCR's concern here: what is the registrar is booted a while after the connectivity components. Should basic connectivity be provided even before the registrar is available for bootstrapping? MCP: I agree with this discussion but contend that to bootstrap a device in to the key infrastructure this must already be solved. MCR to fomulate autonomic-registrar use case. 4. push out anima version of doc !!) Can we resolve the "constrained networks" statement before it becomes an anima doc (replace word in the abstract) MCR did resolve this, and we pushed a new document, see: https://github.com/ietf-roll/anima-bootstrap/commit/f9616a33d78a4a0= ecc54d63ee6fa87a573b33394 5. For the transitive introduction can we choose between "end 2 end transpo= rt security" (e.g. HTTPS) vs "message based" (e.g. MASA) or do we need to be able to do both? If we blend them can we limit the discrete message types. 6. re: =E2=80=9Cadopt draft-pritikin-anima-bootstrapping-keyinfra as ANIMA = WG document=E2=80=9DThe tail end of this thread has some terminology discussio= nsref: RFC6973 (I don=E2=80=99t see the terms Hannes is pointing to here)ref: RFC7= 228 (about constrained devices/networks)there is a note here as well about =E2=80=9Cbootstrapping=E2=80=9D vs =E2=80=9Cmanagement=E2=80=9D. sigh. what= about =E2=80=9Ckeystrapping=E2=80=9D!? 7. re: =E2=80=9CEST in anima thoughts=E2=80=9D This thread trails off with = questions about PANA. What is our overlap with PANA? 2015-09-09 meeting notes: present: mcr, 0. mcp recaps current bootstrapping section 5 1. mcr recaps lighting problem, suggests that lighting "bootstrap" is really network provisioning. We take this as a set of requirements: a) concentric bring up is ok b) devices that can't reach the registrar "wait" c) once a registrar is identified everything comes up in a timely fashion might require some sort of 'advertisement' (TBD mechanism) 2. We can't populate s5.1 of bootstrapping until we better understand: is this 802.1x or is this ikev2 during an ACP handshake? DISCUSSION about whether or not the bootstrap process is seperate, or an integral part of forming the ACP. Michael Behringer describes scenario where bootstrap could be proxied, but ACP would not be: MCR would like to see this clearly articulated as a useca= se that we should solve. MCR thinks that the point of the bootstraping is to bring up the ACP, and in some cases, that the 802.1AR certificates might be in-them-selves completely acceptable to forming the ACP, but you can't know that until you actually t= ry using them when forming the ACP. MCR re-iterates his TODO items, btw: 1. nail down for dtbootstrap what device types are in scope (constrained d= evices and challenged networks) 2. requirements from bootstrap to signaling 3. write summary, minutes and plans to list (including schedule of calls) [this email makes this DONE] =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.4.12 (GNU/Linux) iQEVAwUBVfjhpYCLcPvd0N1lAQK++ggAm5qTuZ0daty5XSJnD/mgeuBukNYyIdQ+ r8ryM4jo9xEiJ7chI9THLQGBIhFnV1XcBWxVsPbKWZ5R0IBxyHZZmzB3xjlTY3Fd iDDIwRwvdDVQeAQbupj5VuvtN4GJ4Ri1UPVT46Nn4NG8rJjXxi8NaUzZwhFXaxUH ewRpzgkr3QnOzLOApSDdQW1QBhZziFWpsRGih3ZSPxs3QI6fZwJdMS2Jvtiv3+Nv 1lKjdiq7V0ysi1A3sxZwZ/wxoRD8phbbrDE44zJGVhIcAgb337VNhCBEv+99dnnG yDtYZ0YxKbZhFUSFxnqloVfOZOj538wLqzFj/n3Yn2lhsDMx6ZOA0g== =Zdxs -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 22 18:59:46 2015 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03AB41B308D for ; Tue, 22 Sep 2015 18:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 oq1Ip1-bWAqA for ; Tue, 22 Sep 2015 18:59:42 -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 E0E2B1B30A0 for ; Tue, 22 Sep 2015 18:59:38 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8F46F20098 for ; Tue, 22 Sep 2015 22:00:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id CCE7B637F8; Tue, 22 Sep 2015 21:59:37 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A654B637F7 for ; Tue, 22 Sep 2015 21:59:37 -0400 (EDT) From: Michael Richardson To: anima-bootstrap X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: [Anima-bootstrap] notes from 2015-09-16 design team call, and details for 2016-09-23 call X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.15 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, 23 Sep 2015 01:59:45 -0000 --=-=-= Content-Type: text/plain 2015-09-16 meeting notes present: mcr, max, Michael Behringer, Kent Watsen, Robert Craigie some homework: http://threadgroup.org/Portals/0/documents/whitepapers/Thread%20Commissioning%20white%20paper_v2_public.pdf (discussion for another time) schedule for future meetings 1. 2015-09-23 1. 2015-09-30 1. 2015-10-07 1. 2015-10-14 1. 2015-10-21 1. 2015-11-01 is IETF94 week, should plan a lunch. Call in details for tomorrow: https://cisco.webex.com/ciscosales/j.php?MTID=ma5a7178d02a2edcb0c6d7b43e5315f08 Meeting number: 200 557 721 Meeting password: boot 10am EDT dialin at: 18664329903 We created an agenda 1. ACP bootstrap, combined vs separate: whether IKEv2/ACP initiates bootstrap, or if discovery causes bootstrap. 2. what other sections of the documents can we move forward on 1. is it always going to EAP-TLS over SOMETHING to get to EST, or are other EAP methods useable? 2. what about non-EAP methods? how do they get to EST? * connects to saag story in 3.1. 3. IETF94 - coral some of the saag conversation? * Kent will speak about server keychain model at saag (from netconf: draft-ietf-netconf-server-model-07 ) Exec Summary: we spent most of the time talking about we can/want to do EAP-in-IKEv2 to do bootstrap, and this fundamentally went back to questions about whether or not bootstrap is per-interface or per-machine, and if there are use cases where we can create an ACP with only the IDevID identities. A strong desire was expressed to be able to something with no PKI, and public key pinning (in particular, given that we have an ACP to existing machines, and updating configurations to include new pins is not a big hurdle anymore). The conclusion was that once bootstrapped, machines never do it again, and further that it was acceptable that a machine could not be moved to a new location (where it would need to bootstrap again) in a zero-touch fashion: it would have to be reset in some sophisticated way. on 2015-09-23 we will continue with question 2 above. Some raw notes from the ACP bootstrap discussion * should devices bootstrap the device, or the interface? (e.g. is the domain * identity paired to a device or an interface?) * Do we want to use the IDevID only for bootstrap, or also for general networking? * IDevID is *always* there? 802.1ar mentions that IDevID can be disabled, but * not deleted? Normally in a write-once memory. * Max: Concern about changing iDev to LDev and then bootstrapping based on LDev. * Device should do (successfully) bootstrap only once; once bootstrap'ed, * it should never perform that operation again unless factory reset. * Consensus: IDevID is RECOMMENDED only used for bootstrap, and not for ACP formation. * action item: Max to update doc with this assertion (e.g. as a "SHOULD") * update 'security considerations' to explain that this is so the [compromised] vendor can't compromise the customer network [explain the threat] * Kent points out that deploying an LDevID requires creation of a PKI; continuing to use the IDevID may be better. (e.g. argues for "should" in combination with with some form of "pinning" if you do not, or leveraging TPM type hardware as discussed. but declare that all out of scope for now) * we agree with the value of IDevID via pinning or manual key distribution or [whatever] but all agree it is not a necessary method in the bootstrapping document * Consensus: !!ACP formation trusts the LDevID only!! !!ACP formation MUST include authorization checks against either (pinned?) IDevID or LDevID!! Max restates in TCG words: the LDevID would be signed by the TPM module's EK certificate's private key, so the chain would be either: platform-vendor->IDevID->LDevID or would be TPM-vendor->TPMEKKEY->LDevID. But, consensus is that rather than creating a locally signed LDevID, we would permit use of IDevID (with security considerations). -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVgIHiYCLcPvd0N1lAQLKlAgAjDI5RWnbO+GLRBPyVndgBBiTlqGsrVzb BkSRvZIPCNAYt8mGTH4J2MAkG3HEGTk2VZh5lw4FwzrSfZJNxtJuCNMWbUF7WG0M HzluEpFhWRe7fLS9fmyu2oXRbKY4JofN0TpUAzplQQl6s5FnjKMK5Ef1j5vI9Ou0 xVLb9U/xl24NYrCWLiEsguTbyb/zF266axDgF4xJG5MyCR1Z7tEGNMGVSHk4AOWB NUXhdw1H35xUX+CCFU10ggAiTSNRyBMTQRUzEeUwlXA6lBM5uoZdNjQzN7Py2F7U jK5ZxH+CxTcUxuj/lrJRh5pT8M0+xLqJMqLfMmPw4P9ueBhm2rCtZQ== =xK6I -----END PGP SIGNATURE----- --=-=-=--