[Anima-signaling] some small summary of bootstrap conversation
Michael Richardson <mcr+ietf@sandelman.ca> Thu, 04 June 2015 16:56 UTC
Return-Path: <mcr@sandelman.ca>
X-Original-To: anima-signaling@ietfa.amsl.com
Delivered-To: anima-signaling@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63611A0065; Thu, 4 Jun 2015 09:56:46 -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 Yzi0WUmdqfm8; Thu, 4 Jun 2015 09:56:43 -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 AC4F41A0067; Thu, 4 Jun 2015 09:56:43 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id DC4C420098; Thu, 4 Jun 2015 13:10:43 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id F282863AE8; Thu, 4 Jun 2015 12:56:41 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D1FF6637FE; Thu, 4 Jun 2015 12:56:41 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima@ietf.org
In-Reply-To: <556F8C12.7060003@gmail.com>
References: <556F8C12.7060003@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<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Thu, 04 Jun 2015 12:56:41 -0400
Message-ID: <6996.1433437001@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: <http://mailarchive.ietf.org/arch/msg/anima-signaling/oJzM0fuaniZ_PxO27Bcg_la4MdU>
Cc: Anima signaling DT <anima-signaling@ietf.org>
Subject: [Anima-signaling] some small summary of bootstrap conversation
X-BeenThere: anima-signaling@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mailing list for the signaling design team of the ANIMA WG <anima-signaling.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-signaling>, <mailto:anima-signaling-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/anima-signaling/>
List-Post: <mailto:anima-signaling@ietf.org>
List-Help: <mailto:anima-signaling-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-signaling>, <mailto:anima-signaling-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2015 16:56:47 -0000
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-signaling] JSONizing GDNP Brian E Carpenter
- Re: [Anima-signaling] JSONizing GDNP Michael Richardson
- [Anima-signaling] some small summary of bootstrap… Michael Richardson
- Re: [Anima-signaling] JSONizing GDNP Joe Hildebrand (jhildebr)
- Re: [Anima-signaling] JSONizing GDNP Toerless Eckert
- Re: [Anima-signaling] JSONizing GDNP Joe Hildebrand (jhildebr)
- Re: [Anima-signaling] JSONizing GDNP Brian E Carpenter
- Re: [Anima-signaling] some small summary of boots… Brian E Carpenter
- Re: [Anima-signaling] JSONizing GDNP Brian E Carpenter