[Anima-bootstrap] a repost of summary
Michael Richardson <mcr+ietf@sandelman.ca> Wed, 24 June 2015 14:07 UTC
Return-Path: <mcr@sandelman.ca>
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 00DAC1A92E7 for <anima-bootstrap@ietfa.amsl.com>; Wed, 24 Jun 2015 07:07:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.012
X-Spam-Level:
X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 vWdKptHoF3DZ for <anima-bootstrap@ietfa.amsl.com>; Wed, 24 Jun 2015 07:07:33 -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 8C0B71A92F4 for <anima-bootstrap@ietf.org>; Wed, 24 Jun 2015 07:06:30 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 663B82002A for <anima-bootstrap@ietf.org>; Wed, 24 Jun 2015 10:21:39 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 9EEDF63AE8; Wed, 24 Jun 2015 10:06:29 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 864C563AD9 for <anima-bootstrap@ietf.org>; Wed, 24 Jun 2015 10:06:29 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima-bootstrap@ietf.org
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Wed, 24 Jun 2015 10:06:29 -0400
Message-ID: <11466.1435154789@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima-bootstrap/sYj1QgQxjWrOPftIqAOnbmBl9mw>
Subject: [Anima-bootstrap] a repost of summary
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 <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jun 2015 14:07:36 -0000
[this is a repost to put something in this list] The bootstrap design team is still bootstrapping, but Max, Toerless and I have had three 1hr phone conferences (May 29 meeting cancelled). They have been Friday at 1700UTC, but are now Thursday at 1400UTC, and will occur June 11 as well. A doodle poll to confirm a regular time will go out next week once the list of parties has been identified. I think that the AD still has to approve things. We started with a discussion of the charter for the DT, and how it relates to the charter for the WG, and the result is at: https://tools.ietf.org/wg/anima/trac/wiki/Bootstrap the places where it says "OWN" means, it's in scope for this DT, where it says REQUIRE, means that we are assuming it as input, and where it says PROVIDE, means that they are outputs. We continued with a recap discussion and partial walkthrough of draft-pritikin-anima-bootstrapping-keyinfra-01 We have some ideas about terminology that we think might be useful along the lines of ducking/imprinting (cf: Konrad Lorenz and http://en.wikipedia.org/wiki/Imprinting_(psychology) ), but we also thought of fraternities and pledges. If you didn't grow up with http://en.wikipedia.org/wiki/Animal_House, or http://en.wikipedia.org/wiki/Revenge_of_the_Nerds, then let me provide some explanation. The idea that during the bootstrap process, there is a period when the network (the ACP aka fraternity) and the new node (the peldge) check each other out for fitness. Wikipedia says this about fraternities: Requirements may be imposed on those wishing to pledge either by the school or the organization itself, often including a minimum grade point average, wearing a pledge pin, learning about the history and structure of the organization, and performing public service. When a school places an age or tenure requirement on joining, this is called "deferred recruitment", as joining is deferred for a semester or year. The pledgeship period also serves as a probationary period in which both the organization and the pledge decide if they are compatible and will have a fulfilling experience. In today's telecon, we discussed some of the 6tisch specific requirements on bootstrap, specifically: 1) the "pledges" (or joining nodes) are constrained in CPU, code space, and energy (if battery powered, etc) 2) more importantly, the network is very constrained, 250Kbit/s max, 127 byte fraglets, and 6tisch likely would be configured to further restricts the bandwidth in the network available to joining nodes. Calculations suggest that just transmitting a DH pair and associated parts between adjacent nodes could take between 2 and 40s. 3) most protocols will require an authorization protocol that will need to travel through the LLN mesh up to a non-constrained node. The convergence of many such setup processes may well overwhelm the parts of the network closer to the root of the tree. Congestion is an issue, and retransmissions cost energy. I explained some the ideas/conclusions from draft-richardson-6tisch-security-architecture-02 and draft-richardson-6tisch--security-6top-04, which were: a) using CBOR encoded YANG over CoAP/DTLS leverages 6tisch ("6top") plans for 6tisch node/PCE communication, maximizing code reuse. b) initiating the secure bootstrap process from the non-constrained side, and having the constrained nodes remain silent after an initial "hello" packet, allowed the network manager to protect, conserve and prioritize the join bandwidth. c) it turns out there is an additional benefit in making the constrained node the TLS "Server" -- side. Specifically, it means that the selection of crypto parameters is done by the more constrained device, and the Server sends it's certificate payload first. The non-constrained node (or "JCE" == Join Coordination Entity) will receive that certificate, and can consult whatever network (or human) resources is needs to before responding with a Client Certificate that will satisfy the constrained node. It can also know via Trusted CA extension what certificate chain (if any) it needs to provide. It is observed that point (c) is not essential; that a similiar thing can be accomplished with less grace using SNI (RFC6066) and some other extensions. Note that while 6tisch is/plans-to specify that 6top is the protocol that runs over the resulting CoAP/DTLS channel, and that secure join to 6tisch consists of provisioning certain identities and parameters through that channel, the resulting channel could be used for anything. We also noted that in the context of two routers plugged in together on a lonesome grassy knoll would need to form a secure connection; that one needs to be the initiator ("client") and the other the responder ("server") is obvious, but whether both systems need to always support both roles is open for discussion. Perhaps in the constrained case, it is acceptable that constrained devices can always be responders, and in the non-constrained case, they assume both roles. I also note, recalling I was told that one implementation of the ACP consists of IKEv2 initiated channels over IPv6-link-local addresses, that the essential properties the bootstrap design team intends to provide work just fine for IKEv2 as they do for DTLS. I don't know if the ANIMA signaling protocol should occur before such a channel is established, or inside of this (provisional) channel, or whether it should instead run inside IKEv2 (maybe inside EAP). I note that 6tisch has a few potential, "I am here" messages, with RPL DAOs and Efficient-ND (E)AROs being the two ones. GDNP or HNCP or just IKE-port-500 messages are in my opinion also possibilities. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Anima-bootstrap] a repost of summary Michael Richardson
- Re: [Anima-bootstrap] a repost of summary Michael Behringer (mbehring)
- [Anima-bootstrap] MB review of Bootstrap charter … Michael Richardson
- [Anima-bootstrap] Crypto parameters [Re: a repost… Brian E Carpenter
- Re: [Anima-bootstrap] Crypto parameters [Re: a re… Michael Richardson