From nobody Mon Aug 1 22:02:04 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51CC12D0E0 for ; Mon, 1 Aug 2016 22:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTc0gdrTDWvv for ; Mon, 1 Aug 2016 22:02:02 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (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 18A10120727 for ; Mon, 1 Aug 2016 22:02:02 -0700 (PDT) Received: by mail-pa0-x233.google.com with SMTP id b2so6812775pat.0 for ; Mon, 01 Aug 2016 22:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=PbYyWm17rbzZ+nBCyf9w5LvgE0/lvnkNDhfRQz1xx2c=; b=pEb4Pr3r+RFhkBm2vrVm1LX7so8AcP0GJvQ1Sigvovdb3VPzHwx78ba9sBB4AHoPKQ NAkYKHiUdjnUJsxV5A6nf6l+wofxboy5y4uuh9HcO8TSgY5VEQ6KqeQMqYRFrT9OBAl7 geghoS2TNQz0F5am0QYLRc/pSpWHDBvjjugL7+51qS0WNSvMyhWw0E/6PsvkIkrFtVGJ EMaRfKXPqHIO5YRHs/mhXT6aZlrxZfeVFjrZq528DHGWS9ZCsKRM9F0R9J73KJFSXQff mSRfhcmuJqLdJwjsH6ej9JVl67djZuo1aOxq4QIXj1nuuRTTsGz1fefUkFCs1m/U+OlB zlsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-transfer-encoding; bh=PbYyWm17rbzZ+nBCyf9w5LvgE0/lvnkNDhfRQz1xx2c=; b=cJHU8ijTEj6qqs1mzQ0MvYB5HO9avQQQ26T7YFXP8G8z8DWx7JuDLNU6EVzTplW/Md K6CUfxOzCqVS66RGh6m3+NjgFnfp3y+9F09rmTdMImgLm5fGzxZlRemuRWycKSFluCXt csrEy1Vvv6AxQA09fdRpR9lgF1goKWPQglgmzfcJiT6SH8hcY9m8AzMS16ZDyNMhA6do gGZRObf9xOaRKqf6UYYJsC8expLvjnh3FWw6DqytVZnrY207/dll+XT8S0mOJ5tqKV/O ktLNQQka/9uF9eOLADujFDwhp7fOq1cec8rUbcvGq/D64qz3WWFRbx5Tr9DTii97chgs pGaw== X-Gm-Message-State: AEkooutaixGZEZezkCnfpODVMKZT3gKzU+uYxoVOrraWWXE6cTNPbBkafjOWugMZqzp2vg== X-Received: by 10.66.88.131 with SMTP id bg3mr103492746pab.43.1470114121430; Mon, 01 Aug 2016 22:02:01 -0700 (PDT) Received: from ?IPv6:2406:e007:5f50:1:28cc:dc4c:9703:6781? ([2406:e007:5f50:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id h125sm923277pfg.54.2016.08.01.22.01.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Aug 2016 22:02:00 -0700 (PDT) To: Anima WG From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 2 Aug 2016 17:02:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] Active issues in GRASP X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 05:02:04 -0000 Hi, Here's a summary of the active open issues in GRASP following IETF 96. Not all of these were listed in the -06 draft. Comments please! It would be helpful to include the issue number in the Subject. 43. Rapid mode synchronization and negotiation is currently limited to a single objective for simplicity of design and implementation. A future consideration is to allow multiple objectives in rapid mode for greater efficiency. ==> Proposed resolution is to simply include this statement in the main text. 48. Should the Appendix "Capability Analysis of Current Protocols" be deleted before RFC publication? ==> We got the message from the meeting that we should keep this. 49. Section 3.3.1 should say more about signaling between two autonomic networks/domains. ==> Proposed resolution is to briefly describe a separate GRASP instance to allow this without risking the security of the normal GRASP instance. 50. Is Rapid mode limited to on-link only? What happens if first discovery responder does not support Rapid Mode? (Section 3.3.4, Section 3.3.5) ==> This is somewhat complicated. The signaling design team will think about it, but WG input is very welcome. 51. Should flooded objectives have a time-to-live before they are deleted from the flood cache? And should they be tagged in the cache with their source locator? ==> Proposed resolution is to note that an objective could contain its own timestamp or refresh interval data. And yes, cached values should be tagged with their source. 52. Describe in detail what is allowed and disallowed in an insecure instance of GRASP. ==> This is at the request of the secure bootstrap and ACP teams. Text will be proposed. 53. Tune IANA Considerations to support early assignment request. ==> This is not hard, text will be proposed. Regards Brian Carpenter Anima signaling design team From nobody Tue Aug 2 10:16:38 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9A312D0A6 for ; Tue, 2 Aug 2016 10:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2fiVwBHpfDA for ; Tue, 2 Aug 2016 10:16:36 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6028312B01B for ; Tue, 2 Aug 2016 10:16:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 403C42411E8; Tue, 2 Aug 2016 10:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1470158196; bh=UZUeNa9X9cW+2JLxbBB/Mh7CTkWGNK6LdyCvhJdk5Kk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=bU+XQY/WmWXLcxrSYLcs76XP3CFq95ybQ9R0fe/tmBl4F8A/RBTb6CWDfWXVzgMRI EeJaGwD4Cp3fX1pHOGU+pnHEjQWF3UBbvwEyX+dCsNASjUtDeK3SIbgcWHQ7Aeqje0 FhlC2GnTXLmk7PbAurBhbAs83aQ+mKdzmEwCrb0M= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id C036A24066C; Tue, 2 Aug 2016 10:16:35 -0700 (PDT) To: Brian E Carpenter , Anima WG References: From: "Joel M. Halpern" Message-ID: Date: Tue, 2 Aug 2016 13:16:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Active issues in GRASP - issue 49 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 17:16:37 -0000 It strikes me that if we wish to allow for inter-domain communication using GRASP, in conjunction with intra-domain usage, then the security considerations are more complex than noted so far. I think this can be addressed by writing security considerations text that explicitly talks about the need to be careful about what information is exchanged between intra and inter-domain grasp instances, so as to avoid either leakage or contamination. If this is done, then additional text in 3.3.1 could point to that to make sure that these limited instances are properly limited. I do wonder, given the possibility of such information leakage, if there is an added complication of information being improperly attributed after such exchanges. I would hope we can avoid a Grasp version of the famous cases of BGP information being injected into IGPs, and then re-exported as if it were locally sourced information. Yours, Joel On 8/2/16 1:02 AM, Brian E Carpenter wrote: > Hi, > > Here's a summary of the active open issues in GRASP following > IETF 96. Not all of these were listed in the -06 draft. > > Comments please! It would be helpful to include the issue number in the Subject. ... > 49. Section 3.3.1 should say more about signaling between two > autonomic networks/domains. > > ==> Proposed resolution is to briefly describe a separate GRASP instance > to allow this without risking the security of the normal GRASP instance. ... > Regards > Brian Carpenter > Anima signaling design team From nobody Tue Aug 2 12:07:09 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B913D12D8DD for ; Tue, 2 Aug 2016 12:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3If5MgDL8Y-Q for ; Tue, 2 Aug 2016 12:07:06 -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 3233D12D8C0 for ; Tue, 2 Aug 2016 12:07:06 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A1AF92009E; Tue, 2 Aug 2016 15:17:20 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 08461638D1; Tue, 2 Aug 2016 15:07:05 -0400 (EDT) From: Michael Richardson To: "Joel M. Halpern" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Anima WG Subject: Re: [Anima] Active issues in GRASP - issue 49 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 19:07:07 -0000 --=-=-= Content-Type: text/plain Joel M. Halpern wrote: > It strikes me that if we wish to allow for inter-domain communication using > GRASP, in conjunction with intra-domain usage, then the security > considerations are more complex than noted so far. I agree strongly. In particular, I would suggest that this really calls for a different instance/profile of GRASP. I.e. that routers should run a different context (same as running OSPF in different VRFs), and that we should even consider that it should do discovery on a different port. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV6DvVoCLcPvd0N1lAQKGOgf/X4Pn7G26cU4ytceGplqiCWo3IahHJaoX 9Cp5/0DJrT9hO3vD2Gr+jISYXW/ekFrFdNO6YjYaMSt5SuQVHUFxP3YbKF7l5ZPe 3c1l8cD2XdXAFlFN4qLSIIoUawDkl6bSSMbCehwt57yuHOQiWugt19Y1cP/ZEqn+ gsvGm8tsndlR0IMNHvE2g/JcNDr7jeN4LxHRQMYpkuyG5V1Lw5N/jcVXXkrDiAXm EzCktRaSAWNcF2Lvb5239WZuOoVekeXP6JjdnrqXslJXZ7oqRNyUyzlYWNAMvoLy NDzMovcTW/DlJ9ohIx7yI9ZPkJMlwWFvm4HCC56jBHKS2F0Fqd1EvA== =dRBY -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 2 13:57:37 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B571C12D961 for ; Tue, 2 Aug 2016 13:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJ3KVzOl1jyf for ; Tue, 2 Aug 2016 13:57:34 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 2AB2D12D95E for ; Tue, 2 Aug 2016 13:57:34 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id h186so69598644pfg.3 for ; Tue, 02 Aug 2016 13:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=plMYLWfr0VZo6Y7avKJixPMfXmMUhgQd7/NKR0xMbNE=; b=GWI861kIiT31ijD1weCKko7OXQU3TulMQES3y9MqUBrGZudjuLROVNnOOvLW9cp34a zoScNhNU3YZogHTPidsdj5XAwsXK3BJiFz6YwcA0kz4UKTafFlvOGidcFrp9UggK33+F +I8WqNJ75ds/YebmUMymw0NqGRqoK9NCscr6lhQonEirMcVHZGmsUoFz9XL0EGR3JwlC Dwj+PlQBS+qFF9GneMPuEPm6zpW/6ukQR6wdrnE9Yl4DAySZRXPu7Ep/Ng+XZRgwlYHd g1aMwJmuREnddlehuhNNe1t0rQ+8tw4ptGl0m2dxCD/AiHx0k1oOCEWyYcjZ5S2VzUYL V5/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=plMYLWfr0VZo6Y7avKJixPMfXmMUhgQd7/NKR0xMbNE=; b=j5ILJ6QOhsDRuK0raEcIy7UnT1C3NtUYzOR8NC0eKC8tyX/ya7YtZ8Zw5yLyAJnPL7 0zP/dtA1D1VxZ57pICSSFjw7DRKAdpN9Pc5BVK4ajyT2rsnudW4+Rt70KJt1jC4unrt6 LZhBKD0RCdvorI8U/xX3OTHg1flcA8j289xQc1+JuuTct08MQp0eocS7plKLLgUF779x TOXuIDwOxwkBl07+BpOUhf0BRe26PETv3fytXOtWnhw0cKpDPSxvNV7eds4D4XOeNNUw B4dog+DL882zb1EE1MFU8ASxX699dfW6+TKAvtS6+yW8wmhEpVSom2KBxOrd5/2yFTOn cGwQ== X-Gm-Message-State: AEkoouv8a2SAKPUWAl6yPatWiwcyywOOERFxlWGUy7gGf8LjSyrZM2lLSQSBzcUo52yZPg== X-Received: by 10.98.86.154 with SMTP id h26mr109755798pfj.22.1470171452881; Tue, 02 Aug 2016 13:57:32 -0700 (PDT) Received: from [192.168.178.23] ([118.148.76.250]) by smtp.gmail.com with ESMTPSA id b134sm6930446pfb.55.2016.08.02.13.57.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Aug 2016 13:57:31 -0700 (PDT) To: Michael Richardson , "Joel M. Halpern" References: <7918.1470164824@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 3 Aug 2016 08:57:33 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7918.1470164824@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] Active issues in GRASP - issue 49 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 20:57:36 -0000 On 03/08/2016 07:07, Michael Richardson wrote: > > Joel M. Halpern wrote: > > It strikes me that if we wish to allow for inter-domain communication using > > GRASP, in conjunction with intra-domain usage, then the security > > considerations are more complex than noted so far. > > I agree strongly. > > In particular, I would suggest that this really calls for a different > instance/profile of GRASP. I.e. that routers should run a different context > (same as running OSPF in different VRFs), and that we should even consider > that it should do discovery on a different port. I agree too. But there's an inevitable risk. One use case for this is a little bit 'back to the future' - consider ASAs that act as bandwidth brokers. Network A has a bandwidth broker. Network B has a bandwidth broker. They communicate between domains using separate TLS-based GRASP instances. Faulty information from A contaminates B's state, in complete security. Brian From nobody Tue Aug 2 18:38:41 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5AD12D14A for ; Tue, 2 Aug 2016 18:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGHBn8_whpY9 for ; Tue, 2 Aug 2016 18:38:37 -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 A4CBD12D143 for ; Tue, 2 Aug 2016 18:38:37 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A40462047C; Tue, 2 Aug 2016 21:48:52 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 18899638D1; Tue, 2 Aug 2016 21:38:36 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: References: <7918.1470164824@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: "Joel M. Halpern" , Anima WG Subject: Re: [Anima] Active issues in GRASP - issue 49 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 01:38:39 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > I agree too. But there's an inevitable risk. One use case for this is a > little bit 'back to the future' - consider ASAs that act as bandwidth > brokers. Network > A has a bandwidth broker. Network B has a bandwidth broker. They > communicate > between domains using separate TLS-based GRASP instances. Faulty > information > from A contaminates B's state, in complete security. Sure.. but I'll bet that it's more reliable than the old-fashioned way of picking up the telephone or the email, and say, "So, Bob, how much transit did we buy again from you this week?" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV6FLGYCLcPvd0N1lAQIIOAgAuSPsBAOzeEYt7K0wMHKX+MAhmGR6CPh7 lF9KS3GHlQtU2c398qOuzKgnnBrkRcg+Py7kk0+7mEm/X1x9p7cxF1dd2G+xMni7 KaKX7R0235iW/bJb/oFDq5z73tPdtQ3P9zfEE25VnJuHtMETvDMdstycRqx9TEPS HcHf5f+EaU8CbtobIpHFkhccoJJ9m3iR8EJOwgBkcA93tGjWoFToZSXI5nGJa1A5 hrTPmbHzoy63JGI2NbbKKsEx4R02dvAw9kHtHs/beZCF/847nY0doTOJj3+VxM6m 7KIEeL7hfwE7gmbs+l+qQeC48PMbpUlIfYBKF+Atj2K6XBxgtcerTg== =YQIY -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 3 07:02:03 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECAE12DC69 for ; Wed, 3 Aug 2016 07:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k60bSsQCZBfe for ; Wed, 3 Aug 2016 07:02:01 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937F612DD81 for ; Wed, 3 Aug 2016 06:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2148; q=dns/txt; s=iport; t=1470232539; x=1471442139; h=to:cc:from:subject:message-id:date:mime-version; bh=r0LHUszZ26kpCj4wAzdfQUL4xwUDOj/VUxl3AFwCDZ0=; b=YMYqLAIMVJ7hKmX0CFbtfk+1bF27dS1uH4t/C29wB7XPfOmAt8aTorw+ nxxe9Et7Q9FCoNN21+ZSPEM16E0sy1I/FlA1rWJGjD7d5+mAEKsJjOInm hauPbAD2AApC3mHXbH0IoMBYyvC43k2cW2KlaDCpV+WgJi+/DYtlprEpS s=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbCgCf9qFX/xbLJq1chBsqu32GHYIcA?= =?us-ascii?q?QEBAQEBXieFCFZdAmwIAQGILa8VjzQBCxcOEYgRh2GCNYJaBZk0gzqBcIlViVS?= =?us-ascii?q?FbJAnVIN8OokOAQEB?= X-IronPort-AV: E=Sophos;i="5.28,465,1464652800"; d="asc'?scan'208";a="639330718" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Aug 2016 13:55:37 +0000 Received: from [10.61.193.171] ([10.61.193.171]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u73Dtb3w016987; Wed, 3 Aug 2016 13:55:37 GMT To: draft-ietf-anima-bootstrapping-keyinfra.all@tools.ietf.org From: Eliot Lear Message-ID: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> Date: Wed, 3 Aug 2016 15:55:36 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jxWJRU25NS6qQG74GvEv34gEvJmeef66g" X-Auto-Response-Suppress: DR, OOF, AutoReply Archived-At: Cc: anima@ietf.org Subject: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 14:02:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jxWJRU25NS6qQG74GvEv34gEvJmeef66g Content-Type: multipart/mixed; boundary="3TAESspxpVSRDJlrEpjplmKcn9pd5T0Q7" From: Eliot Lear To: draft-ietf-anima-bootstrapping-keyinfra.all@tools.ietf.org Cc: anima@ietf.org Message-ID: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> Subject: CoAP et al --3TAESspxpVSRDJlrEpjplmKcn9pd5T0Q7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear authors of draft-ietf-anima-bootstrapping-keyinfra and WG, The Fairhair alliance focuses on lighting and building automation. Our security team has been reviewing your draft, and we appreciate the effort that you are devoting in this direction. We would just like to highlight at this junction that there is a preference for device communications from the autonomic device to the registrar to be via COAP over DTLS rather than HTTP over TLS, primarily because the devices that we are working with will already have a CoAP implementation. As such, there is some interest in draft-pritikin-coap-bootstrap-03.txt. We look forward to seeing that work further developed. On behalf of the Fairhair security subgroup, Eliot ps: as usual, I will encourage fairhair members to directly chime in with their own views on this matter. --3TAESspxpVSRDJlrEpjplmKcn9pd5T0Q7-- --jxWJRU25NS6qQG74GvEv34gEvJmeef66g Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXoffZAAoJEIe2a0bZ0nozVFAH/j6ezIH2BrajOZxEfsn4rHY7 C97JTmP//u16nJbhn7cMAETu2t2qUlHzfl/KyV/OeK9Q5bFjB1U382rWW4ge8qvF /vMOlkzcHa0IyLVIXBz939QXmfa/7p3Sb78TCGtXHgzdxbkvQMhwBs7766iNq3q6 f7AkOYg+fpIb97BxU4V7lT/R6sLLQZAz2WPt8KNCvPmxj/2TTsvQu/aceOwL8FFa WKxa84fNXyTdsuBB3fYdl2FmiUUo0n0w1Xm3KFgy5Q6jAFf4a2I11Q0VYmkubReE /ucoqNwodJV16WSPFHmmLMATfNx6jojZoDg/46rhrT9O5j1OZdoTXR5otfTfY5M= =YI3Q -----END PGP SIGNATURE----- --jxWJRU25NS6qQG74GvEv34gEvJmeef66g-- From nobody Wed Aug 3 07:20:40 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836B212DCDA for ; Wed, 3 Aug 2016 07:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyzvZTTejxGJ for ; Wed, 3 Aug 2016 07:20:36 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D33612D18E for ; Wed, 3 Aug 2016 07:14:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 238809E0079; Wed, 3 Aug 2016 07:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1470233681; bh=Psn6J38FzbmCBFsZuyobjQxTbLJrKtdTvHvgcY2+ZnA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=mP+flBNbvqT0je5gELvqTe4dvzGkPkhHH0+8gpqkzOjC3PtWmqiLf5Q5MOfSi42UF l3K9XKhQ9/2rFNaVQnY6YahCRv7yTT7hsJomkZpR1GvPLcmYbmciAeN/CjJBivT9Cs PqfaMJZqYKhC/HJdcBZaREmJVMGL5dx7o6OnjbdY= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 9BABE9E0096; Wed, 3 Aug 2016 07:14:40 -0700 (PDT) To: Eliot Lear References: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> From: "Joel M. Halpern" Message-ID: Date: Wed, 3 Aug 2016 10:14:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: anima@ietf.org Subject: Re: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 14:20:38 -0000 COuld any of the folks involved with low power answer one question this note suggests? As I understqnd it, low power devices are usually viewed as having limited capabilities. Thus, I would normally expect to see their autonomic functions handled by a proxy, much as a COAP gateway provides connectivity to the rest of the Internet for such devices. If that is the case, then I would not expect to run GRASP or ANIMA bootstrap on the low end devices, but rather on the proxy. I would instead expect a more specialized protocol (presumabvly over CoAP) for the last leg. Without ANIMA discovery, etc. What am I missing? Yours, Joel On 8/3/16 9:55 AM, Eliot Lear wrote: > Dear authors of draft-ietf-anima-bootstrapping-keyinfra and WG, > > The Fairhair alliance focuses on lighting and building automation. Our > security team has been reviewing your draft, and we appreciate the > effort that you are devoting in this direction. We would just like to > highlight at this junction that there is a preference for device > communications from the autonomic device to the registrar to be via COAP > over DTLS rather than HTTP over TLS, primarily because the devices that > we are working with will already have a CoAP implementation. As such, > there is some interest in draft-pritikin-coap-bootstrap-03.txt. We look > forward to seeing that work further developed. > > On behalf of the Fairhair security subgroup, > > Eliot > > ps: as usual, I will encourage fairhair members to directly chime in > with their own views on this matter. > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Aug 3 07:36:10 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988E312DC6B for ; Wed, 3 Aug 2016 07:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNRnTeLzRXMr for ; Wed, 3 Aug 2016 07:36:06 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBCD412DC7E for ; Wed, 3 Aug 2016 07:33:43 -0700 (PDT) Received: from webmail.xs4all.nl ([194.109.20.212]) by smtp-cloud2.xs4all.net with ESMTP id SeZh1t00G4aYjWA01eZhyr; Wed, 03 Aug 2016 16:33:41 +0200 Received: from 2001:983:a264:1:1180:27db:fe27:60a by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 03 Aug 2016 16:33:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 03 Aug 2016 16:33:41 +0200 From: peter van der Stok To: "Joel M. Halpern" Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> Message-ID: <3cc019d8e19b90fdfbf0a43a4cd5aa4d@xs4all.nl> X-Sender: stokcons@xs4all.nl (iggoaj4nohOzQWdm9/2XphyUDOx+ni0Z) User-Agent: XS4ALL Webmail Archived-At: Cc: anima@ietf.org, Eliot Lear Subject: Re: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 14:36:08 -0000 Hi Joel, There are many scenarios with low power devices that depend on their application area. Life for homenet devices is very different from life of devices in a well structured lighting installation. In the latter case, the devices will follow one industry standard to provide interoperability between devices. This standard can include many IETF standards. I will expect that the devices in the installation will follow their own favored discovery mechanism. Therefore, in their context the discovery is not essential. The bootstrapping protocol after discovery can be adhered to, although none of the recommended discovery mechanisms were followed. However, in the home context, or campus context, I can imagine that mDNS is important. Hope this answers your question, Peter Joel M. Halpern schreef op 2016-08-03 16:14: > COuld any of the folks involved with low power answer one question > this note suggests? > > As I understqnd it, low power devices are usually viewed as having > limited capabilities. > Thus, I would normally expect to see their autonomic functions handled > by a proxy, much as a COAP gateway provides connectivity to the rest > of the Internet for such devices. > > If that is the case, then I would not expect to run GRASP or ANIMA > bootstrap on the low end devices, but rather on the proxy. > I would instead expect a more specialized protocol (presumabvly over > CoAP) for the last leg. Without ANIMA discovery, etc. > > What am I missing? > Yours, > Joel > > On 8/3/16 9:55 AM, Eliot Lear wrote: >> Dear authors of draft-ietf-anima-bootstrapping-keyinfra and WG, >> >> The Fairhair alliance focuses on lighting and building automation. >> Our >> security team has been reviewing your draft, and we appreciate the >> effort that you are devoting in this direction. We would just like to >> highlight at this junction that there is a preference for device >> communications from the autonomic device to the registrar to be via >> COAP >> over DTLS rather than HTTP over TLS, primarily because the devices >> that >> we are working with will already have a CoAP implementation. As such, >> there is some interest in draft-pritikin-coap-bootstrap-03.txt. We >> look >> forward to seeing that work further developed. >> >> On behalf of the Fairhair security subgroup, >> >> Eliot >> >> ps: as usual, I will encourage fairhair members to directly chime in >> with their own views on this matter. >> >> >> >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Wed Aug 3 07:41:49 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE4712D563 for ; Wed, 3 Aug 2016 07:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Rda1jLpH0-A for ; Wed, 3 Aug 2016 07:41:45 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4550D12D5B5 for ; Wed, 3 Aug 2016 07:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2147; q=dns/txt; s=iport; t=1470235304; x=1471444904; h=reply-to:subject:references:to:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Y8ye+p3KAE6pILyS7muggBT9jthsw1eILLPr7impL9A=; b=CZEkfqlnuSB4eHVUFd1FLGx6ty8LS5SxxaAM2fqB+6Ke1bDLnPU+H2UC ZA62BjPjoo0v1Aucg2tYabMbTPEZNppZVxEKJAf3aEiSE0SuiMzJw46Z4 a9ix9VAddFjE6BF4CzWj0Tk97n1zSc1uRpK1+zumCixed5niSZoCrU/wE E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkCgBnAaJX/xbLJq1chBsqUrsrJIV5A?= =?us-ascii?q?oIYAQEBAQEBXieEXwEFAQE2NhsLGC4nMBMGAgEBiC0OtS6JEAEBAQEBBQEBAQE?= =?us-ascii?q?eBYYqgXiCVYQcCmaFDwEEmG1Hjn+JVIVsiGiDSIN3VIQWIDKHF4FFAQEB?= X-IronPort-AV: E=Sophos;i="5.28,465,1464652800"; d="scan'208";a="639339239" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Aug 2016 14:41:42 +0000 Received: from [10.131.65.120] (dhcp-10-131-65-120.cisco.com [10.131.65.120]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u73Eff14023079 for ; Wed, 3 Aug 2016 14:41:42 GMT References: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> To: anima@ietf.org From: Paul Duffy Organization: Cisco Systems Message-ID: <86d67eee-9ec7-76d0-58ea-895d12e7e22e@cisco.com> Date: Wed, 3 Aug 2016 10:41:41 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: paduffy@cisco.com List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 14:41:48 -0000 This is not just a constrained device issue. Open Connectivity Foundation is also using CoAP across a wide range of platform capabilities. On 8/3/2016 10:14 AM, Joel M. Halpern wrote: > COuld any of the folks involved with low power answer one question > this note suggests? > > As I understqnd it, low power devices are usually viewed as having > limited capabilities. > Thus, I would normally expect to see their autonomic functions handled > by a proxy, much as a COAP gateway provides connectivity to the rest > of the Internet for such devices. > > If that is the case, then I would not expect to run GRASP or ANIMA > bootstrap on the low end devices, but rather on the proxy. > I would instead expect a more specialized protocol (presumabvly over > CoAP) for the last leg. Without ANIMA discovery, etc. > > What am I missing? > Yours, > Joel > > On 8/3/16 9:55 AM, Eliot Lear wrote: >> Dear authors of draft-ietf-anima-bootstrapping-keyinfra and WG, >> >> The Fairhair alliance focuses on lighting and building automation. Our >> security team has been reviewing your draft, and we appreciate the >> effort that you are devoting in this direction. We would just like to >> highlight at this junction that there is a preference for device >> communications from the autonomic device to the registrar to be via COAP >> over DTLS rather than HTTP over TLS, primarily because the devices that >> we are working with will already have a CoAP implementation. As such, >> there is some interest in draft-pritikin-coap-bootstrap-03.txt. We look >> forward to seeing that work further developed. >> >> On behalf of the Fairhair security subgroup, >> >> Eliot >> >> ps: as usual, I will encourage fairhair members to directly chime in >> with their own views on this matter. >> >> >> >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > . > From nobody Wed Aug 3 08:04:59 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53A012D5AF for ; Wed, 3 Aug 2016 08:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5Kfa0h13WU0 for ; Wed, 3 Aug 2016 08:04:57 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E77B512D767 for ; Wed, 3 Aug 2016 08:04:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id A86AE1C02C3; Wed, 3 Aug 2016 08:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1470236677; bh=ClnLLNX6T5pWxba/Xntwn8sLjO6rKGGLp2p5P8xcO1g=; h=Subject:To:References:From:Date:In-Reply-To:From; b=X9hZpxgxwP40HQbQtXnKG+q7lweZAhSEAaVUEcY8x2ezSpQxIZvT6WajkQhhmPLsS xm4n5x/quXu1xgbWSbWZ9EQBDjPA7erdICv19vymv1mVT52FO8Fq5O48H5ssdoe/eD UgHa7B5T+cx/wfiT6mL1zY+f9R4DL1ndN50QQ3UE= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 3F1DCA46B8E; Wed, 3 Aug 2016 08:04:37 -0700 (PDT) To: paduffy@cisco.com, Anima WG References: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> <86d67eee-9ec7-76d0-58ea-895d12e7e22e@cisco.com> From: "Joel M. Halpern" Message-ID: <11fe616e-60a4-7538-a392-e0d494fdcf05@joelhalpern.com> Date: Wed, 3 Aug 2016 11:04:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <86d67eee-9ec7-76d0-58ea-895d12e7e22e@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 15:04:59 -0000 That is interesting and helpful. It does bring us to the problem of what we should require as mandatory to implement. But that can wait while we work out what the important cases are. Yours, Joel On 8/3/16 10:41 AM, Paul Duffy wrote: > This is not just a constrained device issue. > > Open Connectivity Foundation is also using CoAP across a wide range of > platform capabilities. > > > > On 8/3/2016 10:14 AM, Joel M. Halpern wrote: >> COuld any of the folks involved with low power answer one question >> this note suggests? >> >> As I understqnd it, low power devices are usually viewed as having >> limited capabilities. >> Thus, I would normally expect to see their autonomic functions handled >> by a proxy, much as a COAP gateway provides connectivity to the rest >> of the Internet for such devices. >> >> If that is the case, then I would not expect to run GRASP or ANIMA >> bootstrap on the low end devices, but rather on the proxy. >> I would instead expect a more specialized protocol (presumabvly over >> CoAP) for the last leg. Without ANIMA discovery, etc. >> >> What am I missing? >> Yours, >> Joel >> >> On 8/3/16 9:55 AM, Eliot Lear wrote: >>> Dear authors of draft-ietf-anima-bootstrapping-keyinfra and WG, >>> >>> The Fairhair alliance focuses on lighting and building automation. Our >>> security team has been reviewing your draft, and we appreciate the >>> effort that you are devoting in this direction. We would just like to >>> highlight at this junction that there is a preference for device >>> communications from the autonomic device to the registrar to be via COAP >>> over DTLS rather than HTTP over TLS, primarily because the devices that >>> we are working with will already have a CoAP implementation. As such, >>> there is some interest in draft-pritikin-coap-bootstrap-03.txt. We look >>> forward to seeing that work further developed. >>> >>> On behalf of the Fairhair security subgroup, >>> >>> Eliot >>> >>> ps: as usual, I will encourage fairhair members to directly chime in >>> with their own views on this matter. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> . >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Aug 3 09:33:45 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E544D12D15A for ; Wed, 3 Aug 2016 09:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wp5KfK6uUdC0 for ; Wed, 3 Aug 2016 09:33:36 -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 CDF0A12D099 for ; Wed, 3 Aug 2016 09:33:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5C073200A5; Wed, 3 Aug 2016 12:43:54 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A72F2638D1; Wed, 3 Aug 2016 12:33:35 -0400 (EDT) From: Michael Richardson To: "Joel M. Halpern" In-Reply-To: References: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: anima@ietf.org, Eliot Lear Subject: Re: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 16:33:41 -0000 --=-=-= Content-Type: text/plain Joel M. Halpern wrote: > As I understqnd it, low power devices are usually viewed as having limited > capabilities. > Thus, I would normally expect to see their autonomic functions handled > by a > proxy, much as a COAP gateway provides connectivity to the rest of the > Internet for such devices. > If that is the case, then I would not expect to run GRASP or ANIMA > bootstrap on the low end devices, but rather on the proxy. The goal is not to run GRASP or ACP on the low-end devices (the lightbulbs), but rather to be able to use common infrastructure for bootstrapping. > What am I missing? It's not about running GRASP over an ACP between lightbulbs, it's about enrollment/bootstrap. It might be about running GRASP over an ACP between lighting controllers, and that may well involve the proxies you mention. (It's also worth making a comparison to what we consider "limited capabilities" to what we had as control plane CPUs 20 years years ago) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV6Ic3ICLcPvd0N1lAQKA7wf+MmEIRvuichAAp5t6PuBcjDn9ZAQVteo8 XQFDaxrlzWlR5qwXkuyPsmV+bupex0lBDYDj4gYgg3xe/TwHtio1qzMymV3gXWCN 2KfPfD8waXTo1DqkNX41GMnjzXRKnREv5ViN2zqrALPy499Gbth5gUkh5qdnpL5y mP4u4AHkTDOXM062e+ZUpxwBWlfYbJI2lsuHBZzIOmAZZOliCuvkpibn454bSqvU oqC9n8SSVCOD0OWUMoJro/c9/dmkcTL+pLWN8q5RwvEh1OWzuA3U4si/gfpVAD86 pK1y98NAsJ2K6UPZeZae5JC87ROwYPNxFlLhh2xSi5yT4qzXT8OHaA== =6hfL -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 3 13:49:35 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812D912D661 for ; Wed, 3 Aug 2016 13:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3j-LTO0i2HZ for ; Wed, 3 Aug 2016 13:49:32 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 9FE0412D831 for ; Wed, 3 Aug 2016 13:49:32 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id y134so80758345pfg.0 for ; Wed, 03 Aug 2016 13:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=MGa0f+R6cAWe4+R9WsGjO8wXNYUF5nXbbfOD+/IjO1k=; b=C55Z9Nk2jzmgd8LV5GxCIPoyMwzgYhAVxt5aLgEicfOTcw1G7Od8BXzdb/tWW/DCa+ mVfnWbAB4VBYnq1VH/kgTItwQ+qxtdKqA7B72fsbx+6xKCOn/jiXVgg2M4HyowDWIs55 Tv4XUr/rHS21tKNv7z2XXn2gEhEnWF4n9vDxQlB4QPi+lijztjNFJgCLQ6t9JdeICLRB StYXBwbcCCz2/G6Svk73vGyFk5yfcd6gNJu/nCwFgoC3aIumB7XgvUVzZuY0CUNwJkBr RjqR7Dc1mpkECLxKLYMYlO9Qas3dUEXDK9gmNB8hb6RroqYneoL9fpI9s9Y/dP5a5YXs 78LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=MGa0f+R6cAWe4+R9WsGjO8wXNYUF5nXbbfOD+/IjO1k=; b=GYMi/1hZ2cvNKrzPXbz7rPxyJhh1ZaYBCwQzQn4RwvQ8tcJjOTttg5s5Cm7PePR5Dw Q1JlUCerntb9TfzL1KH3DPUi8hNfvonNbIbF/NS76hvMw94rPUSQQTY3iceh8ULmuqLx iS6mgnM8fs0FML0xhvcIrUrVGIGDLw43mqcUbYOyyPA9huaZSf3sHPsGa0CqT+ORDVqY NzTOzTYJqc+KhAV491idxo9skjElcTN+M401PG+16PrhHjhCNccXqLArP3qIwvm50NWd W4hGJvVpGGfglObWmedzzNJeVIqM1xpB/qV5GJp67JdYsV6Z1PFxfqC3pPFzXMBGeYCZ GDFg== X-Gm-Message-State: AEkooutyUj0zIVFbDFnvRFKls7qCgBglSjE3H+0xUcDVqejZgW2NhWQGCrqf9lpgnDqSow== X-Received: by 10.98.201.2 with SMTP id k2mr119173822pfg.95.1470257372205; Wed, 03 Aug 2016 13:49:32 -0700 (PDT) Received: from [192.168.178.23] ([118.148.120.128]) by smtp.gmail.com with ESMTPSA id ty6sm14776706pac.18.2016.08.03.13.49.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Aug 2016 13:49:31 -0700 (PDT) To: Michael Richardson , "Joel M. Halpern" References: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> <22607.1470242015@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 4 Aug 2016 08:49:36 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <22607.1470242015@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Eliot Lear , anima@ietf.org Subject: Re: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 20:49:34 -0000 I assume people have looked at draft-pritikin-coap-bootstrap. I don't see any discrepancy between that and Eliot's message. Brian On 04/08/2016 04:33, Michael Richardson wrote: > > Joel M. Halpern wrote: > > As I understqnd it, low power devices are usually viewed as having limited > > capabilities. > > Thus, I would normally expect to see their autonomic functions handled > > by a > > proxy, much as a COAP gateway provides connectivity to the rest of the > > Internet for such devices. > > > If that is the case, then I would not expect to run GRASP or ANIMA > > bootstrap on the low end devices, but rather on the proxy. > > The goal is not to run GRASP or ACP on the low-end devices (the lightbulbs), > but rather to be able to use common infrastructure for bootstrapping. > > > What am I missing? > > It's not about running GRASP over an ACP between lightbulbs, it's about > enrollment/bootstrap. It might be about running GRASP over an ACP > between lighting controllers, and that may well involve the proxies you > mention. > > (It's also worth making a comparison to what we consider "limited > capabilities" to what we had as control plane CPUs 20 years years ago) > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Thu Aug 11 14:15:35 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB1612D639 for ; Thu, 11 Aug 2016 14:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-uKxMWZU5SN for ; Thu, 11 Aug 2016 14:15:32 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 222FE12B063 for ; Thu, 11 Aug 2016 14:15:32 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id h186so2108739pfg.3 for ; Thu, 11 Aug 2016 14:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Sp/5wncW60EQZaouBqgXTHXhU7jqARY/dhLFf146XkI=; b=N4IAUlwR4nm99GgkkKa/XjaZb9XFK6slQ5abts3J9mZ3Teoo+BvuHqsEYVPn4pTe/k H6xfuq7NKjozUET1wyexZq4xuSoW96ygTZVpSObWjhLq8qGP0y3BvC36PZ0xBT3CNKRg sueMvynvss5JNiOwHc8O8ScqvVV+u3KJo/hXF/tGVA9Q0/1CYjMx5MWIhZfBhszUUKMs 5HMnwcYqCTh9V5wtLVMflQvqDHkQxlMJpF0hinVgAvUy2ISOtgqhCJDrZ8I1WXYUMTsf 212PR4I5YZ5+2rJk2RYrURBzWU/cOT3T8RQeJUJ95OPgffHIixf4Yqh3wy+OrruiJcyC HUXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Sp/5wncW60EQZaouBqgXTHXhU7jqARY/dhLFf146XkI=; b=GEtxL2+bq7K9G8/9vBo93RXjzS0eTTRVXHBotm1rnEBUr21Qpn/2uRBHHp7yChZrCt XMtt9vIW/g46SF/Ar/wRZgoiyRV8UcPzdfQlVOOqc0SRmfutfw/Sry3Onh8sUXcua1Hz CKADO6a2F0i13RTJsyWYPqR5gmdTH7eH8VQKmkCY0DijQMttn6xoocoiCVAVwloWzerX M0ToAromFiD4DJ2dXew+Tdnb/3YZ6cqLj60xTqVn6xKSoWG2LN+SEsv1Ra1pGYO7aFXs aR0EVrmrgo7IjTEW/upW15csWSrUiD2E1WtcfkUUXkbfVowaVQe5sCSKQcLni+bhl0lZ d3hA== X-Gm-Message-State: AEkoouvy6YPN9LpxKJSbxRIX4JWr1EpJGweM5QtnNFOFbF3pqi9o1/zYYPgpGfGJiNq13Q== X-Received: by 10.98.78.138 with SMTP id c132mr20650710pfb.67.1470950131477; Thu, 11 Aug 2016 14:15:31 -0700 (PDT) Received: from ?IPv6:2406:e007:7535:1:28cc:dc4c:9703:6781? ([2406:e007:7535:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id cp11sm7441645pac.28.2016.08.11.14.15.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Aug 2016 14:15:30 -0700 (PDT) From: Brian E Carpenter To: Anima WG References: <47c158b3-92f4-8a36-1bc1-c5c19afdc6b3@gmail.com> <20160801085529.GT21039@cisco.com> <97815aec-a36f-8dda-6798-eb0c1c5eda17@gmail.com> <20160805083457.GH21039@cisco.com> <20160808140326.GA6295@cisco.com> <20160809063909.GZ21039@cisco.com> <9e003de0-8351-650c-dca7-50472a0570ee@gmail.com> <20160810064103.GM21039@cisco.com> Organization: University of Auckland Message-ID: Date: Fri, 12 Aug 2016 09:15:36 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160810064103.GM21039@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Anima] GRASP issue 51: Flooded objectives X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 21:15:34 -0000 Hi WG, This rather long message expands on GRASP issue 51, which is summarised as: 51. Should flooded objectives have a time-to-live before they are deleted from the flood cache? And should they be tagged in the cache with their source locator? This has led to a complicated discussion in the signaling design time (mainly between me and Toerless) and we would like feedback from the WG before taking any firm decisions. Breaking it down into separate issues: 51.1 Should flooded objectives have a time-to-live before they are deleted from the flood cache? Cutting a complex discussion short, it seems that we will surely have use cases where a time-to-live is needed. It might be infinity, of course, but we might also want to be sure that a flooded objective vanishes after 30 seconds. To do that, we need to add a TTL field. Q1: Does the WG agree to add a TTL to the Flood message? 51.2 We do have at least one use case where more than one source floods the same objective, and the recipient ASAs need to distinguish the results. (That use case is when more than one Registrar or Proxy announces its availability via a flooded objective, so that joining nodes don't need to send an insecure Discovery message during bootstrap.) So the flood cache needs to record the source of the flooded objective. 51.3 That leads to another complication. Suppose that more than one ASA in a given node floods the same objective. Side issue: I (Brian) had been working on the assumption that only one ASA in a given node can manage a given objective. "Manage" means being willing to act as a negotiation responder, a synchronization responder, or as a source of flooding. But in fact, although there might be a reason for that limitation in a particular use case, GRASP as a protocol could perfectly well handle several ASAs managing the same objective. [My prototype implementation cannot really do so, but that's an implementation choice.] Return from side issue: If more than one ASA in the same node floods the same objective, recording the source (as mentioned under 51.2) is not enough. We would need to separate multiple instances from the same source node. There is a use case for this too: if we want to make a soft changeover from version N to version N+1 of a given ASA, where version N is not switched off until all current sessions end, but all new sessions will involve version N+1. This will not cause any protocol changes for GRASP discovery (which already returns a locator as a 3-tuple {IP address, protocol, port}. Therefore, it won't cause any changes for synchronization or negotiation, which are based on discovery results. But it does mean that to distinguish flooded objectives from each other, we will need to tag them too with a 3-tuple {IP address, protocol, port}. Q2: Does the WG agree to add a locator 3-tuple to the Flood message? When considering these additions to Flood messages, which add a few bytes of overhead, please consider that for most use cases, the frequency of flooding would be quite low. Regards Brian + signaling design team From nobody Sun Aug 14 05:05:25 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8456612D19B for ; Sun, 14 Aug 2016 05:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUgce426mcC3 for ; Sun, 14 Aug 2016 05:05:22 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 11C9312D14A for ; Sun, 14 Aug 2016 05:05:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id AE92943B31; Sun, 14 Aug 2016 14:05:20 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nzLX2RdG1oyJ; Sun, 14 Aug 2016 14:05:20 +0200 (CEST) Received: from [192.168.1.40] (167.red-83-36-85.dynamicip.rima-tde.net [83.36.85.167]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon21.um.es (Postfix) with ESMTPSA id ABED443B30; Sun, 14 Aug 2016 14:05:15 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin Lopez In-Reply-To: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> Date: Sun, 14 Aug 2016 14:05:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1156D983-9628-41BC-8180-66999CABE3F6@um.es> References: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> To: Eliot Lear , draft-ietf-anima-bootstrapping-keyinfra.all@tools.ietf.org, anima@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: =?utf-8?Q?Dan_Garc=C3=ADa_Carrillo?= , Rafa Marin Lopez Subject: Re: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2016 12:05:24 -0000 Dear all: Related with the usage of CoAP for bootstrapping in constrained devices = (using EAP and AAA infrastructures) we wrote this I-D: https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-03 and wrote this paper that may be of your interest: http://www.mdpi.com/1424-8220/16/3/358 Comments are welcome. Best Regards. > El 3 ago 2016, a las 15:55, Eliot Lear escribi=C3=B3: >=20 > Dear authors of draft-ietf-anima-bootstrapping-keyinfra and WG, >=20 > The Fairhair alliance focuses on lighting and building automation. = Our > security team has been reviewing your draft, and we appreciate the > effort that you are devoting in this direction. We would just like to > highlight at this junction that there is a preference for device > communications from the autonomic device to the registrar to be via = COAP > over DTLS rather than HTTP over TLS, primarily because the devices = that > we are working with will already have a CoAP implementation. As such, > there is some interest in draft-pritikin-coap-bootstrap-03.txt. We = look > forward to seeing that work further developed. >=20 > On behalf of the Fairhair security subgroup, >=20 > Eliot >=20 > ps: as usual, I will encourage fairhair members to directly chime in > with their own views on this matter. >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Mon Aug 15 00:32:02 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EF712D88F; Mon, 15 Aug 2016 00:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.467 X-Spam-Level: X-Spam-Status: No, score=-5.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-BQUzPZx2al; Mon, 15 Aug 2016 00:31:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F39412D88D; Mon, 15 Aug 2016 00:31:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUI37543; Mon, 15 Aug 2016 07:31:55 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 15 Aug 2016 08:31:54 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Mon, 15 Aug 2016 15:31:44 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: ANIMA minutes - IETF 96, Berlin Thread-Index: AdH2xxFDsJi2ptxCTm+3QyPYb8RzJw== Date: Mon, 15 Aug 2016 07:31:44 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CAD153B@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CAD153BNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57B16FEB.0119, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6fe9c8c27c16e5be0de15403ef963942 Archived-At: Cc: "anima-chairs@ietf.org" Subject: [Anima] ANIMA minutes - IETF 96, Berlin X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 07:32:01 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CAD153BNKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGFsbCwNCg0KVGhlIG1pbnV0ZXMgZm9yIHRoZSBBTklNQSBzZXNzaW9ucyBhdCBJRVRGOTYg aW4gQmVybGluIGNhbiBiZSBmb3VuZCBhdDoNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvOTYvbWludXRlcy9taW51dGVzLTk2LWFuaW1hDQoNCk1hbnkgdGhhbmtzIHRvIEJpbmcg TGl1IGZvciB0YWtpbmcgbWludXRlcy4NCg0KUGxlYXNlIHNlbmQgYW55IGNvcnJlY3Rpb25zIHRv IHRoZSBjaGFpcnMuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcgKyBUb2VybGVzcw0K --_000_5D36713D8A4E7348A7E10DF7437A4B927CAD153BNKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEg NiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRl b2dyYXBoOw0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWlseTrlrovk vZM7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KLyog UGFnZSBEZWZpbml0aW9ucyAqLw0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJa SC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9InRleHQtanVzdGlmeS10cmlt OnB1bmN0dWF0aW9uIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWu i+S9kztjb2xvcjpibGFjayI+SGksIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTt2ZXJ0aWNhbC1hbGlnbjpiYXNl bGluZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OuWui+S9kztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7dmVydGljYWwtYWxpZ246 YmFzZWxpbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTrlrovkvZM7Y29sb3I6YmxhY2siPlRoZSBtaW51dGVzIGZvciB0aGUgQU5JTUEgc2Vz c2lvbnMgYXQgSUVURjk2IGluIEJlcmxpbiBjYW4gYmUgZm91bmQgYXQ6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7dmVy dGljYWwtYWxpZ246YmFzZWxpbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl O3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmJsYWNrIj5odHRwczovL3d3dy5p ZXRmLm9yZy9wcm9jZWVkaW5ncy85Ni9taW51dGVzL21pbnV0ZXMtOTYtYW5pbWE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGU7dmVydGljYWwtYWxpZ246YmFzZWxpbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6YmxhY2siPk1hbnkgdGhh bmtzIHRvIEJpbmcgTGl1IGZvciB0YWtpbmcgbWludXRlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTt2ZXJ0aWNhbC1h bGlnbjpiYXNlbGluZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7dmVydGlj YWwtYWxpZ246YmFzZWxpbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6YmxhY2siPlBsZWFzZSBzZW5kIGFueSBjb3Jy ZWN0aW9ucyB0byB0aGUgY2hhaXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5l Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 5a6L5L2TO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTt2ZXJ0aWNhbC1hbGlnbjpiYXNl bGluZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OuWui+S9kztjb2xvcjpibGFjayI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlO3ZlcnRpY2Fs LWFsaWduOmJhc2VsaW5lIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTt2ZXJ0 aWNhbC1hbGlnbjpiYXNlbGluZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjpibGFjayI+U2hlbmcgJiM0MzsgVG9lcmxl c3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5D36713D8A4E7348A7E10DF7437A4B927CAD153BNKGEML515MBXchi_-- From nobody Mon Aug 15 09:18:52 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0228C12B050 for ; Mon, 15 Aug 2016 09:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDHJjmh2R_W4 for ; Mon, 15 Aug 2016 09:18:49 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 D07A712D1C0 for ; Mon, 15 Aug 2016 09:18:48 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id n59so80380940uan.2 for ; Mon, 15 Aug 2016 09:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=os9jggnzrpWYMCF9Jm8tjff+XV7wVnADlsRPD0mvb0c=; b=p+ZEzPjTfa50xuhFyLab9JHG/yP/qohGbijMrgkDcYTcv5zXTocnEf7Pzy/zmEHZCH MX9WTlWwlFo8h5bloDZmqiGxdJABMs3426RZU3InB9+l2elmjjW5JDw+yocp1Q8lVA01 g6UYb68ZxLa6hJggO5q+Up9MVQh1n8mLAz5qntPU7USMDfBoM476rpTrtvkYFgSPGgOZ VHrqRVltq6eqDjv2wzua4NCke/yueHlnKz2nOz/K5/WIQgpQXe/8e6Os5T4STsepou+d Q1KahokLIDCUV3xYjfmecqDdXARuWAUdSaA54SGwDtrifDtsR8oN8td14rjOqlseuQaH 5L3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=os9jggnzrpWYMCF9Jm8tjff+XV7wVnADlsRPD0mvb0c=; b=bAcNyC3GgDSnForFbl07T+FSvEAzyojWEwFSCnYaDzS6cDscxALvMTSKp/p6A11Via Qho6AbADom0+v5EMVP7mH1Og1fPzn16Aef8sH+psmT/gXUjZb3W/q88xDNExjqNLzRbo O9RwgXBoPqKs9MoxT6PHYsxiEaTXIlHx8lifshW0WfPv5VheQVxVENOa0t2AJ7heiYKv NdOIhO08AphLbcqVpBowXol96i7AvpAI+d2WpLgQ/2bQyH+cGSEuN5u9GcTnWv0cuET1 mXG4WVqxIi63XvngOeERHmqsVsPFD8MyC057g8hnhyNr/7BNi7+VmE6p55fpNQ7Ojgjh irww== X-Gm-Message-State: AEkoouvOSYmgZ4soMSKY6uNvITdeMGldekQkhYSQaTe9GAk8qmXQkxouZNnGN7wIufGbKvdJNJWNxFcDuFLEYg== X-Received: by 10.31.47.207 with SMTP id v198mr13923494vkv.109.1471277927845; Mon, 15 Aug 2016 09:18:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.40.167 with HTTP; Mon, 15 Aug 2016 09:18:47 -0700 (PDT) In-Reply-To: <1156D983-9628-41BC-8180-66999CABE3F6@um.es> References: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> <1156D983-9628-41BC-8180-66999CABE3F6@um.es> From: Behcet Sarikaya Date: Mon, 15 Aug 2016 11:18:47 -0500 Message-ID: To: Rafa Marin Lopez Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Mohit Sethi M , "anima@ietf.org" , draft-ietf-anima-bootstrapping-keyinfra.all@tools.ietf.org, Eliot Lear , =?UTF-8?Q?Dan_Garc=C3=ADa_Carrillo?= Subject: Re: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 16:18:51 -0000 Hi Rafa, On Sun, Aug 14, 2016 at 7:05 AM, Rafa Marin Lopez wrote: > Dear all: > > Related with the usage of CoAP for bootstrapping in constrained devices (= using EAP and AAA infrastructures) we wrote this I-D: > > https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-03 > > and wrote this paper that may be of your interest: > > http://www.mdpi.com/1424-8220/16/3/358 > Thanks for your work. One thing I would like to clarify: IoT bootstrapping should be done before the device gets an IP address. I think that CoAP works over IP, i.e.e the device already has been assigned an IP address. So whatever you do can not be called bootstrapping maybe something else which is security related, maybe some application layer key establishment. Regards, Behcet > Comments are welcome. > > Best Regards. > >> El 3 ago 2016, a las 15:55, Eliot Lear escribi=C3=B3: >> >> Dear authors of draft-ietf-anima-bootstrapping-keyinfra and WG, >> >> The Fairhair alliance focuses on lighting and building automation. Our >> security team has been reviewing your draft, and we appreciate the >> effort that you are devoting in this direction. We would just like to >> highlight at this junction that there is a preference for device >> communications from the autonomic device to the registrar to be via COAP >> over DTLS rather than HTTP over TLS, primarily because the devices that >> we are working with will already have a CoAP implementation. As such, >> there is some interest in draft-pritikin-coap-bootstrap-03.txt. We look >> forward to seeing that work further developed. >> >> On behalf of the Fairhair security subgroup, >> >> Eliot >> >> ps: as usual, I will encourage fairhair members to directly chime in >> with their own views on this matter. >> >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Aug 15 16:58:34 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041A812D572 for ; Mon, 15 Aug 2016 16:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.468 X-Spam-Level: X-Spam-Status: No, score=-5.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNIGeMbKwhzx for ; Mon, 15 Aug 2016 16:58:30 -0700 (PDT) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 1C92A12D1C2 for ; Mon, 15 Aug 2016 16:58:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 3DA73139A8; Tue, 16 Aug 2016 01:58:27 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6tb3NNWB9Hcv; Tue, 16 Aug 2016 01:58:27 +0200 (CEST) Received: from [192.168.1.40] (167.red-83-36-85.dynamicip.rima-tde.net [83.36.85.167]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon23.um.es (Postfix) with ESMTPSA id 52518139A7; Tue, 16 Aug 2016 01:58:19 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin Lopez In-Reply-To: Date: Tue, 16 Aug 2016 01:58:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> <1156D983-9628-41BC-8180-66999CABE3F6@um.es> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: =?utf-8?Q?Dan_Garc=C3=ADa_Carrillo?= , Eliot Lear , Mohit Sethi M , draft-ietf-anima-bootstrapping-keyinfra.all@tools.ietf.org, Rafa Marin Lopez , "anima@ietf.org" Subject: Re: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 23:58:33 -0000 Hi Behcet: > El 15 ago 2016, a las 18:18, Behcet Sarikaya = escribi=C3=B3: >=20 > Hi Rafa, >=20 > On Sun, Aug 14, 2016 at 7:05 AM, Rafa Marin Lopez wrote: >> Dear all: >>=20 >> Related with the usage of CoAP for bootstrapping in constrained = devices (using EAP and AAA infrastructures) we wrote this I-D: >>=20 >> https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-03 >>=20 >> and wrote this paper that may be of your interest: >>=20 >> http://www.mdpi.com/1424-8220/16/3/358 >>=20 >=20 >=20 > Thanks for your work. [Rafa] Thanks for your comments. >=20 > One thing I would like to clarify: > IoT bootstrapping should be done before the device gets an IP address. [Rafa] As you may know IPv6 link-local address may be used. I may agree = with your statement in a =E2=80=9Cglobal=E2=80=9D or =E2=80=9Croutable" = IP address. But, I guess, it will depend on the scenario. In any case, I = think we should first agree in what IoT bootstrapping means and what are = the requirements (MAY, MUST, SHOULD, =E2=80=A6) > I think that CoAP works over IP, i.e.e the device already has been > assigned an IP address. [Rafa] CoAP is being considered to be transported over the link-layer = directly (e.g. draft-bormann-6lo-coap-802-15-ie-00 or = draft-wang-6tisch-6top-coapie-01). Another example in LP-WAN = (draft-pelov-core-cosol-01) Btw there are also other protocols working on top of UDP (as CoAP) = considered to be transported directly over the link-layer (e.g. IKEv2) = as you may know.=20 >=20 > So whatever you do can not be called bootstrapping maybe something > else which is security related, maybe some application layer key > establishment. [Rafa] For the reasons mentioned above, I still call it bootstrapping Best Regards. >=20 > Regards, >=20 > Behcet >> Comments are welcome. >>=20 >> Best Regards. >>=20 >>> El 3 ago 2016, a las 15:55, Eliot Lear escribi=C3=B3:= >>>=20 >>> Dear authors of draft-ietf-anima-bootstrapping-keyinfra and WG, >>>=20 >>> The Fairhair alliance focuses on lighting and building automation. = Our >>> security team has been reviewing your draft, and we appreciate the >>> effort that you are devoting in this direction. We would just like = to >>> highlight at this junction that there is a preference for device >>> communications from the autonomic device to the registrar to be via = COAP >>> over DTLS rather than HTTP over TLS, primarily because the devices = that >>> we are working with will already have a CoAP implementation. As = such, >>> there is some interest in draft-pritikin-coap-bootstrap-03.txt. We = look >>> forward to seeing that work further developed. >>>=20 >>> On behalf of the Fairhair security subgroup, >>>=20 >>> Eliot >>>=20 >>> ps: as usual, I will encourage fairhair members to directly chime in >>> with their own views on this matter. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>=20 >> ------------------------------------------------------- >> Rafael Marin Lopez, PhD >> Dept. Information and Communications Engineering (DIIC) >> Faculty of Computer Science-University of Murcia >> 30100 Murcia - Spain >> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >> ------------------------------------------------------- >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Mon Aug 15 17:48:12 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A4D12D5CB for ; Mon, 15 Aug 2016 17:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7SQOs_85pi1 for ; Mon, 15 Aug 2016 17:48:09 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 0F56F12D593 for ; Mon, 15 Aug 2016 17:48:09 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id y134so21528663pfg.0 for ; Mon, 15 Aug 2016 17:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=CaU4EV6p9/ygkq7S9NJd4ocR2NJz09ivUwHD7s2aVJA=; b=iVGvlXEajMugytZzqjvOXhpjPfC6P4R5MxkwPtGHjvoP4FatH24UD+8/gqG8jk543R NNnhbuiCKSkfyztDd+nQbHgVsaFNC7Mcft8TkYnSPdSpxHGeXZEabpWwdvCErFzWmJsv 6+db7Hja8OUYndWuO9CpXSOUdJMOChxgUc6XqKi/QaqNkAkRN5ZZh2MYt6DEO6vk2vsX +SKeZOtjB3QwXO7b47rGpdJA4uOyjrYTxrkYR662+eKsOiZFnD9iy+3W+Ujj301N3gsY x54ua6JQSG7wj/F9dIQt8OwJS6o7dP9jNwsrpTBNpcThFVr8BYNvvVjGnLoNGpCAR43e KknQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=CaU4EV6p9/ygkq7S9NJd4ocR2NJz09ivUwHD7s2aVJA=; b=PlA6OYfdG+Bx4o7QQgHRffWEXhDJEWRp99PoEj2eeAaRiLpeO/MK8TOpefxSZn6avP rWosWkvVcAZ4uoj7c++fJILXMSQtxLOc84tZhzDrxicJ/YwlBneb9c/aLhhQii+baOaW rRoBJkM5399m3hMAqFxtw8w6eAGgij39VGAUdjlqclSUZa/+jwdsc9ZMlO6KUCvlcztQ sxyGja6YG6bo2yJj9JNKKW+SqomEJd89hxSYKZSW2Qi6FJ0jXD8nhF5kFUh19n6OIXuj gvkdD+hJtfKr4hCViXofrVoU3Yd7lrTb1FcLyUlD+QmcdwGjs3qXrp3dMsBetZ4ZIk72 CjGA== X-Gm-Message-State: AEkoousxH5d/DE1dUvMsZpSzRR43kh7hPG4buWx/zO5OtwMyOeXVmgg1iS5j+rHqs5IK3Q== X-Received: by 10.98.11.86 with SMTP id t83mr59063124pfi.51.1471308488555; Mon, 15 Aug 2016 17:48:08 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id e2sm34118443pfd.45.2016.08.15.17.48.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Aug 2016 17:48:07 -0700 (PDT) To: Rafa Marin Lopez , sarikaya@ieee.org References: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> <1156D983-9628-41BC-8180-66999CABE3F6@um.es> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 16 Aug 2016 12:48:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "anima@ietf.org" , Mohit Sethi M , draft-ietf-anima-bootstrapping-keyinfra.all@tools.ietf.org, Eliot Lear , =?UTF-8?Q?Dan_Garc=c3=ada_Carrillo?= Subject: Re: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 00:48:10 -0000 Let's be clear about the Anima context for "bootstrapping". You don't hav= e to look beyond the document abstract: " This document specifies automated bootstrapping of a remote secure key infrastructure (BRSKI) using vendor installed IEEE 802.1AR manufacturing installed certificates, in combination with a vendor based service on the Internet." Obviously it's assumed that there is some kind of *insecure* connectivity= first. Which obviously implies a preceding insecure bootstrap of some kind, but that is not the topic. And, repeating myself I think, Anima is primarily aimed at nodes that manage devices, not at the devices themselves. However, we'd like BRSKI to be available to all devices, hence Max wrote draft-pritikin-coap-boots= trap. Again, please read the abstract: " This document provides an initial discussion of Bootstrapping of Remote Secure key infrastructures (BRSKI) when the device being bootstrapped speaks CoAP." Regards Brian On 16/08/2016 11:58, Rafa Marin Lopez wrote: > Hi Behcet: >=20 >> El 15 ago 2016, a las 18:18, Behcet Sarikaya = escribi=C3=B3: >> >> Hi Rafa, >> >> On Sun, Aug 14, 2016 at 7:05 AM, Rafa Marin Lopez wrote: >>> Dear all: >>> >>> Related with the usage of CoAP for bootstrapping in constrained devic= es (using EAP and AAA infrastructures) we wrote this I-D: >>> >>> https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-03 >>> >>> and wrote this paper that may be of your interest: >>> >>> http://www.mdpi.com/1424-8220/16/3/358 >>> >> >> >> Thanks for your work. >=20 > [Rafa] Thanks for your comments. >> >> One thing I would like to clarify: >> IoT bootstrapping should be done before the device gets an IP address.= >=20 > [Rafa] As you may know IPv6 link-local address may be used. I may agree= with your statement in a =E2=80=9Cglobal=E2=80=9D or =E2=80=9Croutable" = IP address. But, I guess, it will depend on the scenario. In any case, I = think we should first agree in what IoT bootstrapping means and what are = the requirements (MAY, MUST, SHOULD, =E2=80=A6) >=20 >> I think that CoAP works over IP, i.e.e the device already has been >> assigned an IP address. >=20 > [Rafa] CoAP is being considered to be transported over the link-layer d= irectly (e.g. draft-bormann-6lo-coap-802-15-ie-00 or draft-wang-6tisch-6t= op-coapie-01). Another example in LP-WAN (draft-pelov-core-cosol-01) >=20 > Btw there are also other protocols working on top of UDP (as CoAP) cons= idered to be transported directly over the link-layer (e.g. IKEv2) as you= may know.=20 >=20 >> >> So whatever you do can not be called bootstrapping maybe something >> else which is security related, maybe some application layer key >> establishment. >=20 > [Rafa] For the reasons mentioned above, I still call it bootstrapping >=20 > Best Regards. >=20 >> >> Regards, >> >> Behcet >>> Comments are welcome. >>> >>> Best Regards. >>> >>>> El 3 ago 2016, a las 15:55, Eliot Lear escribi=C3=B3= : >>>> >>>> Dear authors of draft-ietf-anima-bootstrapping-keyinfra and WG, >>>> >>>> The Fairhair alliance focuses on lighting and building automation. = Our >>>> security team has been reviewing your draft, and we appreciate the >>>> effort that you are devoting in this direction. We would just like = to >>>> highlight at this junction that there is a preference for device >>>> communications from the autonomic device to the registrar to be via = COAP >>>> over DTLS rather than HTTP over TLS, primarily because the devices t= hat >>>> we are working with will already have a CoAP implementation. As suc= h, >>>> there is some interest in draft-pritikin-coap-bootstrap-03.txt. We = look >>>> forward to seeing that work further developed. >>>> >>>> On behalf of the Fairhair security subgroup, >>>> >>>> Eliot >>>> >>>> ps: as usual, I will encourage fairhair members to directly chime in= >>>> with their own views on this matter. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima >>> >>> ------------------------------------------------------- >>> Rafael Marin Lopez, PhD >>> Dept. Information and Communications Engineering (DIIC) >>> Faculty of Computer Science-University of Murcia >>> 30100 Murcia - Spain >>> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >>> ------------------------------------------------------- >>> >>> >>> >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- >=20 >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Mon Aug 15 22:27:01 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B09112D0C1 for ; Mon, 15 Aug 2016 22:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.769 X-Spam-Level: X-Spam-Status: No, score=-15.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsHvrgzIIHS9 for ; Mon, 15 Aug 2016 22:26:58 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABBE012B019 for ; Mon, 15 Aug 2016 22:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3504; q=dns/txt; s=iport; t=1471325218; x=1472534818; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=iOkdFnYVlWdsCNQ7nRyHYCdavqOH7wXPQbUHTDHcmYg=; b=Kd6EVHWcRKV3AE+lRgovOVFEpFXO6A/Gwv34GEglg/0HVbYfMJwCuRqu iZlxUnwds/c8sci1JMog8dTlo9/lZWWVhjaZsYwqgQ1o0q2W2FZ4gydX7 ytTw2LDXB7nVy7K+Jd2ElwV9qKabXddCsx57vGt9R+fYeXkEdetS5ygK7 M=; X-IronPort-AV: E=Sophos;i="5.28,528,1464652800"; d="scan'208";a="311340679" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Aug 2016 05:26:57 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u7G5QvYM009474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Aug 2016 05:26:57 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 u7G5QuJ5005043; Mon, 15 Aug 2016 22:26:56 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u7G5Qthr005039; Mon, 15 Aug 2016 22:26:55 -0700 Date: Mon, 15 Aug 2016 22:26:55 -0700 From: Toerless Eckert To: Rafa Marin Lopez Message-ID: <20160816052655.GA4333@cisco.com> References: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> <1156D983-9628-41BC-8180-66999CABE3F6@um.es> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1156D983-9628-41BC-8180-66999CABE3F6@um.es> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Dan Garcia , anima@ietf.org, draft-ietf-anima-bootstrapping-keyinfra.all@tools.ietf.org, Eliot Lear Subject: Re: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 05:27:00 -0000 Thanks, Rafa The combination of CoAP and EAP is certainly interesting. Let me quickly summarize how in ANIMA we got to not consider EAP when we looked at it without CoAP in the picture: 1. We did earlier in Anima investigate if/how we could/should use EAP to perform ANIMA bootstrap. It turned out that transporting all the desired key-infrastructure bootstrap messages across EAP would have been quite cumbersome. It would have been necesssary to use eg: EAP-TTLS which seems not to have seen wider use, and which would have required to much around with the client side TLS stack (those where the salient points if memory serves me right on this discussion). 2. Likewise, it seemed more appropriate for us to rely simply on IPv6 link-local addressing to first exist on clients than to figure out how to make sure L2-only solutions like EAPoL exist everywhere and would work across all L2 media - and having to tie ANIMA code into such L2 code. I can see how different industry groups that specifically work only with one particular L2 technology are happy to base more design on direct L2 layered protocols, but for ANIMA trying to be easily applicable across any L2 technology, IPv6-LL seemed like the best first approach. If specific L2 technologies have reasons not to use it, i think we could add-on optimizations for those link technologies. Cheers Toerless On Sun, Aug 14, 2016 at 02:05:14PM +0200, Rafa Marin Lopez wrote: > Dear all: > > Related with the usage of CoAP for bootstrapping in constrained devices (using EAP and AAA infrastructures) we wrote this I-D: > > https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-03 > > and wrote this paper that may be of your interest: > > http://www.mdpi.com/1424-8220/16/3/358 > > Comments are welcome. > > Best Regards. > > > El 3 ago 2016, a las 15:55, Eliot Lear escribió: > > > > Dear authors of draft-ietf-anima-bootstrapping-keyinfra and WG, > > > > The Fairhair alliance focuses on lighting and building automation. Our > > security team has been reviewing your draft, and we appreciate the > > effort that you are devoting in this direction. We would just like to > > highlight at this junction that there is a preference for device > > communications from the autonomic device to the registrar to be via COAP > > over DTLS rather than HTTP over TLS, primarily because the devices that > > we are working with will already have a CoAP implementation. As such, > > there is some interest in draft-pritikin-coap-bootstrap-03.txt. We look > > forward to seeing that work further developed. > > > > On behalf of the Fairhair security subgroup, > > > > Eliot > > > > ps: as usual, I will encourage fairhair members to directly chime in > > with their own views on this matter. > > > > > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Aug 15 22:43:05 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F70C12D0EA for ; Mon, 15 Aug 2016 22:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T23gif4-3Ggu for ; Mon, 15 Aug 2016 22:43:02 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94A3612D0C2 for ; Mon, 15 Aug 2016 22:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4081; q=dns/txt; s=iport; t=1471326182; x=1472535782; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=BbRSpt+sRJIRuu2v6/FXW1dpuyYswDGfz5sgG289E9c=; b=bJnk94xHDixhTTzZkBl22HNz8oltes+jrbT6VwxTqPrPr96V+obparm3 WuSNQPjw1r8yOb//L1jjg5v0aQJBXZ/Ay6sWbyddKelqRBYdIUUay7DBz jWe2sUS4g0hSE5GOqvvTODLaHEK00RC41JWVZf36DU2McPfp5GwIVmbtL w=; X-IronPort-AV: E=Sophos;i="5.28,528,1464652800"; d="scan'208";a="138062078" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Aug 2016 05:43:02 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u7G5h1mL032624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Aug 2016 05:43:01 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 u7G5h1sQ005666; Mon, 15 Aug 2016 22:43:01 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u7G5h1Gf005665; Mon, 15 Aug 2016 22:43:01 -0700 Date: Mon, 15 Aug 2016 22:43:01 -0700 From: Toerless Eckert To: Rafa Marin Lopez Message-ID: <20160816054301.GB4333@cisco.com> References: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> <1156D983-9628-41BC-8180-66999CABE3F6@um.es> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1156D983-9628-41BC-8180-66999CABE3F6@um.es> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Dan Garcia , anima@ietf.org, draft-ietf-anima-bootstrapping-keyinfra.all@tools.ietf.org, Eliot Lear Subject: Re: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 05:43:04 -0000 Rafa, I have not managed to figure out from your draft what exactly you consider to be bootstrapping. It seems you primarily refer to draft-ohba-core-eap-based-bootstrapping, which seems to be expired. To quickly summarize what in anima we call bootstrap: The ANIMA key bootstrap protocol primarily tries to get a credential installed on a device. This is based on RFC7030 (eg: cert enrolment) and adds all the functions we have identified as being necessary on top of this: 1. Initial signaling so the client can trust the server from which it gets the credential - server can be from some owner of the device and it's producing a credential from the vendor of the device that makes the device trust the server. As a result for example the client install the servers CA cert into its cert trustpool list. 2. Requesting parameters to be associated with the credential. These parameters are then useable by next steps. In Anima, these credentials are parameters to the client cert, and those are then used in building the ACP after bootstrap. 3. Installing the credential - in ANIMA devices the AN Certificate. Note: We did discuss but have not decided on options where for example this step could be optional, eg: where in very low-end devices the vendor installed credential is sufficient, and no new credential is desired, but instead only 1., 2., 4., 5. are performed. 4. Diagnostics so the server side will know if/how steps 1..3 where successful. 5. Next step to take by the device - eg: build ACP or for non ANIMA devices, maybe "here is your next provisioning connection to build". (we're just discussing this step). So, i am not aware that existing EAP mechanisms offer any such bootstrap functionality. I am not even aware they offer an equivalent of rfc7030 with EAP. On Sun, Aug 14, 2016 at 02:05:14PM +0200, Rafa Marin Lopez wrote: > Dear all: > > Related with the usage of CoAP for bootstrapping in constrained devices (using EAP and AAA infrastructures) we wrote this I-D: > > https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-03 > > and wrote this paper that may be of your interest: > > http://www.mdpi.com/1424-8220/16/3/358 > > Comments are welcome. > > Best Regards. > > > El 3 ago 2016, a las 15:55, Eliot Lear escribió: > > > > Dear authors of draft-ietf-anima-bootstrapping-keyinfra and WG, > > > > The Fairhair alliance focuses on lighting and building automation. Our > > security team has been reviewing your draft, and we appreciate the > > effort that you are devoting in this direction. We would just like to > > highlight at this junction that there is a preference for device > > communications from the autonomic device to the registrar to be via COAP > > over DTLS rather than HTTP over TLS, primarily because the devices that > > we are working with will already have a CoAP implementation. As such, > > there is some interest in draft-pritikin-coap-bootstrap-03.txt. We look > > forward to seeing that work further developed. > > > > On behalf of the Fairhair security subgroup, > > > > Eliot > > > > ps: as usual, I will encourage fairhair members to directly chime in > > with their own views on this matter. > > > > > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- Toerless Eckert, eckert@cisco.com From nobody Tue Aug 16 01:06:36 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE6E12D09B for ; Tue, 16 Aug 2016 01:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.282 X-Spam-Level: X-Spam-Status: No, score=-14.282 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjN0tFKC0dnn for ; Tue, 16 Aug 2016 01:06:33 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2EF127078 for ; Tue, 16 Aug 2016 01:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1652; q=dns/txt; s=iport; t=1471334793; x=1472544393; h=date:from:to:cc:subject:message-id:mime-version; bh=qry+f1zjyHp+NyFzkLup7o3GzvcCFu9GWmVxrpQIGXQ=; b=ATNezRB99HewsRIC1Lxn7/QIZtPNA+YaBw4F7EbbdgD+b5YNcljsRDPo RUCJu8xYzA4MfsFACvTImZdv4IyFZmi1miYNmtnV1sUSEdIlwKQ2ozUTW do40rgn/Gv78eAPBNZJRV7yHn1Bz0PfT1sbcPqrbIpvXFOB9wVDggDQKl Y=; X-IronPort-AV: E=Sophos;i="5.28,529,1464652800"; d="scan'208";a="310636996" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Aug 2016 08:06:32 +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 u7G86W4L028179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Aug 2016 08:06:32 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 u7G86We2012017; Tue, 16 Aug 2016 01:06:32 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u7G86V9f012016; Tue, 16 Aug 2016 01:06:31 -0700 Date: Tue, 16 Aug 2016 01:06:31 -0700 From: Toerless Eckert To: Eliot Lear Message-ID: <20160816080631.GC4333@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: Cc: anima@ietf.org, draft-ietf-anima-bootstrapping-keyinfra.all@tools.ietf.org Subject: Re: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 08:06:35 -0000 Thanks, Eliott Quick questions: a) Would those Fairhair devices ever be transit nodes ("routers") in the network itself ? Or even when only being leafs of the topology, would they intend to run RPL ? b) Any specific way how these devices get their IP (IPv6 ?) addresses ? I am wondering, because i wonder how much more anima than bootstrap could be applicable to Fairhair devices. Cheers Toerless In-Reply-To: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> On Wed, Aug 03, 2016 at 03:55:36PM +0200, Eliot Lear wrote: > Dear authors of draft-ietf-anima-bootstrapping-keyinfra and WG, > > The Fairhair alliance focuses on lighting and building automation. Our > security team has been reviewing your draft, and we appreciate the > effort that you are devoting in this direction. We would just like to > highlight at this junction that there is a preference for device > communications from the autonomic device to the registrar to be via COAP > over DTLS rather than HTTP over TLS, primarily because the devices that > we are working with will already have a CoAP implementation. As such, > there is some interest in draft-pritikin-coap-bootstrap-03.txt. We look > forward to seeing that work further developed. > > On behalf of the Fairhair security subgroup, > > Eliot > > ps: as usual, I will encourage fairhair members to directly chime in > with their own views on this matter. > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- Toerless Eckert, eckert@cisco.com From nobody Tue Aug 16 01:17:43 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE2F12D0DC for ; Tue, 16 Aug 2016 01:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.769 X-Spam-Level: X-Spam-Status: No, score=-15.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUNW7O_B5NkV for ; Tue, 16 Aug 2016 01:17:41 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B677012D090 for ; Tue, 16 Aug 2016 01:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2139; q=dns/txt; s=iport; t=1471335460; x=1472545060; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=r5MuJDhS7xbLw83o/5/KslJ9CXTBP6wlltattYz4Jxg=; b=BiWBuhQtCIPG2U21/MtG7zQhgTCZbShbBXjwHhyaTXx7eI19idKcRM/I 3vQ45EZVg/Vtgk3dECDflLHO/LYRnAfL78uBn5KqPIPekKkrs6wI0aspb pDYuRMBOQDQBWLHvV0CvYtAfe3kgKKAuRCJHMm1CfZu0Dxzbo//IsHnrL E=; X-Files: signature.asc : 481 X-IronPort-AV: E=Sophos;i="5.28,529,1464652800"; d="asc'?scan'208";a="643984369" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Aug 2016 08:17:38 +0000 Received: from [10.61.169.115] ([10.61.169.115]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u7G8Hc7O001873; Tue, 16 Aug 2016 08:17:38 GMT To: Toerless Eckert References: <20160816080631.GC4333@cisco.com> From: Eliot Lear Message-ID: <3ad13eb3-e7d1-40ea-54d9-93a16a525313@cisco.com> Date: Tue, 16 Aug 2016 10:17:37 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160816080631.GC4333@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VaxU4e9CwrhMF0okUnujuAxa7oeMhPX2q" Archived-At: Cc: anima@ietf.org, draft-ietf-anima-bootstrapping-keyinfra.all@tools.ietf.org Subject: Re: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 08:17:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VaxU4e9CwrhMF0okUnujuAxa7oeMhPX2q Content-Type: multipart/mixed; boundary="x2c7D7PFksttpXVCpcSxpUBwNt2Mwriak" From: Eliot Lear To: Toerless Eckert Cc: draft-ietf-anima-bootstrapping-keyinfra.all@tools.ietf.org, anima@ietf.org Message-ID: <3ad13eb3-e7d1-40ea-54d9-93a16a525313@cisco.com> Subject: Re: [Anima] CoAP et al References: <20160816080631.GC4333@cisco.com> In-Reply-To: <20160816080631.GC4333@cisco.com> --x2c7D7PFksttpXVCpcSxpUBwNt2Mwriak Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/16/16 10:06 AM, Toerless Eckert wrote: > Thanks, Eliott > > Quick questions: > > a) Would those Fairhair devices ever be transit nodes ("routers") in th= e > network itself ? Or even when only being leafs of the topology, > would they intend to run RPL ? TBD, I think. > > b) Any specific way how these devices get their IP (IPv6 ?) addresses ?= There will be multiple models in play, based on the operational environment. In some cases, 802.15.4 networks will be used, in others, wired, in some cases WiFi. Likely devices will start out with IPv4 and require DHCP, and then in IPv6 both SLAAC and DHCP will be required. But this is my personal view. Eliot --x2c7D7PFksttpXVCpcSxpUBwNt2Mwriak-- --VaxU4e9CwrhMF0okUnujuAxa7oeMhPX2q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXsswiAAoJEIe2a0bZ0nozVtUH/2+V97iJjouekvx/UkSNmyn/ V77o1mPxB+TL3qlmYN+teKK644BdbCatZKBC6jm7vIpcOiv+p1YyK/rpOCsQVa3e khIi+Y9ASV99C78jlQqhtl6FTpM2VQcJ2baYyv2huOJG3JWfZDHm2mEUhSIxZIWH s/dNgjjHFs1Dw4AeazXYcZEw+CwmOtd78ZNp/zMbHhfzkTJ9Nywv6xKnuSo845U1 ib19F9nF7IneuBv/7wExTz/pxZAxGK5SmuSMnOJqHItmaiJw8+i6m08t2fQo1lx1 ehappL9fRCPPxgkYo90+Q05iWMR7Q6b9CfWF2pGSgtlh5jf8FmIsPa/LSoiwO3I= =w8t4 -----END PGP SIGNATURE----- --VaxU4e9CwrhMF0okUnujuAxa7oeMhPX2q-- From nobody Tue Aug 16 05:04:20 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34FAE12DDEA for ; Tue, 16 Aug 2016 05:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0133xupA0-n for ; Tue, 16 Aug 2016 05:04:17 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2603E12D907 for ; Tue, 16 Aug 2016 04:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2201; q=dns/txt; s=iport; t=1471348255; x=1472557855; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=32k1cTvC+O0BPm2RwGWid21ruVCqJU+SBJsNzfuz3XU=; b=Onhvmmq2RDG5lzBA91+9vGeK8wl080O+8wiFct0Y+jgWEduz6PFlLRIN ZCb5xZqWt5rrxcQTBtNEMQB8UGWYaAfyFQty84FcGGqq4/kdIYpsHjnq1 3DbZucRMI3X41I65/LHbnnuY3wlLNxdIHjo/xkShXDSxMFJSA65iXwwak s=; X-IronPort-AV: E=Sophos;i="5.28,529,1464652800"; d="scan'208";a="309539730" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Aug 2016 11:50:54 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u7GBor57005778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Aug 2016 11:50:54 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 u7GBordO021843; Tue, 16 Aug 2016 04:50:53 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u7GBorkg021842; Tue, 16 Aug 2016 04:50:53 -0700 Date: Tue, 16 Aug 2016 04:50:53 -0700 From: Toerless Eckert To: Eliot Lear Message-ID: <20160816115053.GD4333@cisco.com> References: <20160816080631.GC4333@cisco.com> <3ad13eb3-e7d1-40ea-54d9-93a16a525313@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ad13eb3-e7d1-40ea-54d9-93a16a525313@cisco.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: anima@ietf.org, draft-ietf-anima-bootstrapping-keyinfra.all@tools.ietf.org Subject: Re: [Anima] Fairhair (Re: CoAP et al) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 12:04:19 -0000 Thanks Eliot Would be useful i think to have the fairhair group consider some options: - If devices use some "mesh" like topology, they easily could become transit node, then RPL is a very lightweight routing option. - Even if device is a leaf, participating in RPL would be comparable lightweight to eg: DHCP or other protocols (hopefully some expecrts can chime in to refute or support that statement ;-). And RPL would allow to simplify learning parameters and addressing. - Instead of SLAAC/DHCP, it might be quite interesting to consider an addressing model as we have it in ANIMA: Where the address is effectively configured during bootstrap (in ANIMA case into the Certificate). - With this type of statically provisioned IPv6 address on device and RPL, it is extremely simple to keep track of the device in a database (no dynamic remapping of IP address to device required), and on the RPL root (which could be co-located with a controller, you would also see as RPL routes all devices present in the network by their address. These IMHO are the most attractive options from the full anima model (beyond bootstrap) for lightweight IoT devices - RPL routing/bootstrap provisioned static IPv6 addresses. Eliminates IMHO some layers of complexity. Cheers Toerless On Tue, Aug 16, 2016 at 10:17:37AM +0200, Eliot Lear wrote: > > > On 8/16/16 10:06 AM, Toerless Eckert wrote: > > Thanks, Eliott > > > > Quick questions: > > > > a) Would those Fairhair devices ever be transit nodes ("routers") in the > > network itself ? Or even when only being leafs of the topology, > > would they intend to run RPL ? > > TBD, I think. > > > > > b) Any specific way how these devices get their IP (IPv6 ?) addresses ? > > There will be multiple models in play, based on the operational > environment. In some cases, 802.15.4 networks will be used, in others, > wired, in some cases WiFi. Likely devices will start out with IPv4 and > require DHCP, and then in IPv6 both SLAAC and DHCP will be required. > > But this is my personal view. > > Eliot > > -- --- Toerless Eckert, eckert@cisco.com From nobody Tue Aug 16 06:27:28 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD5A12D7A3 for ; Tue, 16 Aug 2016 06:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByKyjWe7fqTs for ; Tue, 16 Aug 2016 06:27:25 -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 16C3F12D82C for ; Tue, 16 Aug 2016 06:27:19 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 056C22009E for ; Tue, 16 Aug 2016 09:38:20 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4830D639DC for ; Tue, 16 Aug 2016 09:27:18 -0400 (EDT) From: Michael Richardson To: anima@ietf.org In-Reply-To: <20160816052655.GA4333@cisco.com> References: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> <1156D983-9628-41BC-8180-66999CABE3F6@um.es> <20160816052655.GA4333@cisco.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 13:27:27 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > 1. We did earlier in Anima investigate if/how we could/should use EAP > to perform ANIMA bootstrap. It turned out that transporting all the > desired key-infrastructure bootstrap messages across EAP would have There are two other key issues with the 1x-architecture of supplicants, authenticators and authorization servers (AS). The architecture usually looks like: (nice picture at: https://en.wikipedia.org/wiki/IEEE_802.1X ) S<--EAP-TLS over EAP over 1x/PANA->Authenticator<--EAP-over-radius-->AS The problem with this architecture is that it: a) always creates state on the authenticator b) requires a secure relationship between Authenticator and Radius Server. (a radius secret, and an entry in the Radius Server's client table) c) And we'd then have to run EST over the EAP/TLS connection, and do it not with the radius server, but with the Registar. (a) is a cost to absorb. (b) could be mitigated by changing the Authenticator to really be: Authenticator . o O ( -----EAP-over-GRASP--- ) and having no radius server at all. Of course, having got rid of that compoennt, the commonality with the various 1x infrastructures is really non-existant. All we've done is introduce EAP fragmentation (and code paths) in a place where it will get used only once. Instead, a good way to think about ANIMA bootstrap is that it's the way in which you get credentials which you can *then* use for 1x, if that's what your infrastructure wants. Today, those credentials are distributed out-of-band. Seperating bootstrap from the 1x process not only simplifies the bootstrap process, but it also simplifies the 1x code base, as it doesn't have to figure out if the new pledge is trying to join the network, or trying to bootstrap. (I'm reminded of the Robert Frost poem about The Road Not Taken. Often it is thought to be about taking chances in life. I tend to think that when it comes to security, that it's best not have divergent paths in code, unless both have regularly used test cases: "I doubted if I should ever come back") -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV7MUs4CLcPvd0N1lAQIAvQf9EvYTHI9nXZtTSTBdjkG/xwGXs2gIIhzV DyacUKDgPqJra62KXNUEanZxOG7H0EnDEJQStoPWikJbP7Ji6FVJVD2PDkm3qfn0 IS3XL7xgD8jXfv60CXsbQqy6V5vVkjtQEG/jQYPTSlnzgQ9EZyqwhqFTrdZaXUgW zjWlnN+N3PAjRahtquDxnJ1+h1EBmG1qcrB0wWrG7U4iLdFUHnkgQUnQ/xqsQNgT MgPBVarFxlM9AGNabW6t3Tb73MFJfrCcIYG12B3UveeN0v0IH0gZNNmpC8DTKLSb A8GYCK/oBU81C2wxSKK2ynFk4++5P3MqGheM1bSEgA+lNGqMOZ4rZQ== =y1gv -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 16 15:28:31 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9932612D8CB for ; Tue, 16 Aug 2016 15:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.468 X-Spam-Level: X-Spam-Status: No, score=-5.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfsYOga04PLR for ; Tue, 16 Aug 2016 15:28:26 -0700 (PDT) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 8D43112D519 for ; Tue, 16 Aug 2016 15:28:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id E8FD2BEF9; Wed, 17 Aug 2016 00:28:24 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bbUXQzFHbAL8; Wed, 17 Aug 2016 00:28:24 +0200 (CEST) Received: from [192.168.1.34] (199.red-88-14-208.dynamicip.rima-tde.net [88.14.208.199]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon23.um.es (Postfix) with ESMTPSA id 1A1D3BECC; Wed, 17 Aug 2016 00:28:22 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin Lopez In-Reply-To: Date: Wed, 17 Aug 2016 00:28:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3B0EDD77-24D5-41D0-A4EE-BD58E6ED602B@um.es> References: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> <1156D983-9628-41BC-8180-66999CABE3F6@um.es> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 22:28:29 -0000 Hi Brian: Thanks for the clarification. The only intention of my e-mail was to = show that the usage of CoAP for bootstrapping (in constrained devices) = was also considered in our work. The abstract you mention and the work you are doing in ANIMA are both = fine with me.=20 Best Regards. > El 16 ago 2016, a las 2:48, Brian E Carpenter = escribi=C3=B3: >=20 > Let's be clear about the Anima context for "bootstrapping". You don't = have > to look beyond the document abstract: >=20 > " This document specifies automated bootstrapping of a remote secure > key infrastructure (BRSKI) using vendor installed IEEE 802.1AR > manufacturing installed certificates, in combination with a vendor > based service on the Internet." >=20 > Obviously it's assumed that there is some kind of *insecure* = connectivity > first. Which obviously implies a preceding insecure bootstrap of > some kind, but that is not the topic. >=20 > And, repeating myself I think, Anima is primarily aimed at nodes that > manage devices, not at the devices themselves. However, we'd like = BRSKI > to be available to all devices, hence Max wrote = draft-pritikin-coap-bootstrap. > Again, please read the abstract: >=20 > " This document provides an initial discussion of Bootstrapping of > Remote Secure key infrastructures (BRSKI) when the device being > bootstrapped speaks CoAP." >=20 > Regards > Brian >=20 > On 16/08/2016 11:58, Rafa Marin Lopez wrote: >> Hi Behcet: >>=20 >>> El 15 ago 2016, a las 18:18, Behcet Sarikaya = escribi=C3=B3: >>>=20 >>> Hi Rafa, >>>=20 >>> On Sun, Aug 14, 2016 at 7:05 AM, Rafa Marin Lopez = wrote: >>>> Dear all: >>>>=20 >>>> Related with the usage of CoAP for bootstrapping in constrained = devices (using EAP and AAA infrastructures) we wrote this I-D: >>>>=20 >>>> https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-03 >>>>=20 >>>> and wrote this paper that may be of your interest: >>>>=20 >>>> http://www.mdpi.com/1424-8220/16/3/358 >>>>=20 >>>=20 >>>=20 >>> Thanks for your work. >>=20 >> [Rafa] Thanks for your comments. >>>=20 >>> One thing I would like to clarify: >>> IoT bootstrapping should be done before the device gets an IP = address. >>=20 >> [Rafa] As you may know IPv6 link-local address may be used. I may = agree with your statement in a =E2=80=9Cglobal=E2=80=9D or =E2=80=9Croutab= le" IP address. But, I guess, it will depend on the scenario. In any = case, I think we should first agree in what IoT bootstrapping means and = what are the requirements (MAY, MUST, SHOULD, =E2=80=A6) >>=20 >>> I think that CoAP works over IP, i.e.e the device already has been >>> assigned an IP address. >>=20 >> [Rafa] CoAP is being considered to be transported over the link-layer = directly (e.g. draft-bormann-6lo-coap-802-15-ie-00 or = draft-wang-6tisch-6top-coapie-01). Another example in LP-WAN = (draft-pelov-core-cosol-01) >>=20 >> Btw there are also other protocols working on top of UDP (as CoAP) = considered to be transported directly over the link-layer (e.g. IKEv2) = as you may know.=20 >>=20 >>>=20 >>> So whatever you do can not be called bootstrapping maybe something >>> else which is security related, maybe some application layer key >>> establishment. >>=20 >> [Rafa] For the reasons mentioned above, I still call it bootstrapping >>=20 >> Best Regards. >>=20 >>>=20 >>> Regards, >>>=20 >>> Behcet >>>> Comments are welcome. >>>>=20 >>>> Best Regards. >>>>=20 >>>>> El 3 ago 2016, a las 15:55, Eliot Lear escribi=C3=B3= : >>>>>=20 >>>>> Dear authors of draft-ietf-anima-bootstrapping-keyinfra and WG, >>>>>=20 >>>>> The Fairhair alliance focuses on lighting and building automation. = Our >>>>> security team has been reviewing your draft, and we appreciate the >>>>> effort that you are devoting in this direction. We would just = like to >>>>> highlight at this junction that there is a preference for device >>>>> communications from the autonomic device to the registrar to be = via COAP >>>>> over DTLS rather than HTTP over TLS, primarily because the devices = that >>>>> we are working with will already have a CoAP implementation. As = such, >>>>> there is some interest in draft-pritikin-coap-bootstrap-03.txt. = We look >>>>> forward to seeing that work further developed. >>>>>=20 >>>>> On behalf of the Fairhair security subgroup, >>>>>=20 >>>>> Eliot >>>>>=20 >>>>> ps: as usual, I will encourage fairhair members to directly chime = in >>>>> with their own views on this matter. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >>>>=20 >>>> ------------------------------------------------------- >>>> Rafael Marin Lopez, PhD >>>> Dept. Information and Communications Engineering (DIIC) >>>> Faculty of Computer Science-University of Murcia >>>> 30100 Murcia - Spain >>>> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >>>> ------------------------------------------------------- >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima >>>=20 >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>=20 >> ------------------------------------------------------- >> Rafael Marin Lopez, PhD >> Dept. Information and Communications Engineering (DIIC) >> Faculty of Computer Science-University of Murcia >> 30100 Murcia - Spain >> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >> ------------------------------------------------------- >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >>=20 >=20 ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Tue Aug 16 16:00:52 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E1112D58D for ; Tue, 16 Aug 2016 16:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyssrE36F5mg for ; Tue, 16 Aug 2016 16:00:48 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 093F712B05E for ; Tue, 16 Aug 2016 16:00:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id DAB2240FEC; Wed, 17 Aug 2016 01:00:45 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mzzz+koyvasn; Wed, 17 Aug 2016 01:00:45 +0200 (CEST) Received: from [192.168.1.34] (199.red-88-14-208.dynamicip.rima-tde.net [88.14.208.199]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon21.um.es (Postfix) with ESMTPSA id B1FCF3FDC6; Wed, 17 Aug 2016 01:00:44 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin Lopez In-Reply-To: <20160816052655.GA4333@cisco.com> Date: Wed, 17 Aug 2016 01:00:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <49D7DCC0-6843-4098-97F9-CD852DB377B7@um.es> References: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> <1156D983-9628-41BC-8180-66999CABE3F6@um.es> <20160816052655.GA4333@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: anima@ietf.org, Rafa Marin Lopez Subject: Re: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 23:00:50 -0000 Hi Toerless: > El 16 ago 2016, a las 7:26, Toerless Eckert = escribi=C3=B3: >=20 > Thanks, Rafa >=20 > The combination of CoAP and EAP is certainly interesting. [Rafa] Thank you. > Let me > quickly summarize how in ANIMA we got to not consider EAP when we > looked at it without CoAP in the picture: >=20 > 1. We did earlier in Anima investigate if/how we could/should use > EAP to perform ANIMA bootstrap. It turned out that transporting > all the desired key-infrastructure bootstrap messages across EAP > would have been quite cumbersome. It would have been necesssary to > use eg: EAP-TTLS which seems not to have seen wider use, and which = would > have required to much around with the client side TLS stack (those > where the salient points if memory serves me right on this = discussion). [Rafa] EAP can be used for authentication and because its well = established key management framework (RFC 5247). However, the transport = of additional information could be performed also by using the EAP = lower-layer (e.g. CoAP), which makes the solution EAP method independent = (e.g. EAP=E2=80=94TTLS is an EAP method).=20 Having said this, I remember this was deeply discussed long time ago in = the context of MIPv6 bootstrapping (RFC 4640): that is, 1) distributing = bootstrapping information inside the EAP method, as you mention in = EAP-TTLS (in general, a tunneled EAP method), or using another protocol = after EAP authentication. In any case, in that time, the usage of AAA = infrastructures for bootstrapping was considered. >=20 > 2. Likewise, it seemed more appropriate for us to rely simply on IPv6 > link-local addressing to first exist on clients than to figure out how = to > make sure L2-only solutions like EAPoL exist everywhere and would > work across all L2 media - and having to tie ANIMA code into > such L2 code. I can see how different industry groups that > specifically work only with one particular L2 technology are happy to > base more design on direct L2 layered protocols, but for ANIMA trying > to be easily applicable across any L2 technology, IPv6-LL seemed like > the best first approach. If specific L2 technologies have reasons > not to use it, i think we could add-on optimizations for those link = technologies. [Rafa] I agree with this. >=20 > Cheers > Toerless >=20 > On Sun, Aug 14, 2016 at 02:05:14PM +0200, Rafa Marin Lopez wrote: >> Dear all: >>=20 >> Related with the usage of CoAP for bootstrapping in constrained = devices (using EAP and AAA infrastructures) we wrote this I-D: >>=20 >> https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-03 >>=20 >> and wrote this paper that may be of your interest: >>=20 >> http://www.mdpi.com/1424-8220/16/3/358 >>=20 >> Comments are welcome. >>=20 >> Best Regards. >>=20 >>> El 3 ago 2016, a las 15:55, Eliot Lear escribi=C3=B3:= >>>=20 >>> Dear authors of draft-ietf-anima-bootstrapping-keyinfra and WG, >>>=20 >>> The Fairhair alliance focuses on lighting and building automation. = Our >>> security team has been reviewing your draft, and we appreciate the >>> effort that you are devoting in this direction. We would just like = to >>> highlight at this junction that there is a preference for device >>> communications from the autonomic device to the registrar to be via = COAP >>> over DTLS rather than HTTP over TLS, primarily because the devices = that >>> we are working with will already have a CoAP implementation. As = such, >>> there is some interest in draft-pritikin-coap-bootstrap-03.txt. We = look >>> forward to seeing that work further developed. >>>=20 >>> On behalf of the Fairhair security subgroup, >>>=20 >>> Eliot >>>=20 >>> ps: as usual, I will encourage fairhair members to directly chime in >>> with their own views on this matter. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>=20 >> ------------------------------------------------------- >> Rafael Marin Lopez, PhD >> Dept. Information and Communications Engineering (DIIC) >> Faculty of Computer Science-University of Murcia >> 30100 Murcia - Spain >> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >> ------------------------------------------------------- >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Tue Aug 16 16:22:04 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D0312D182 for ; Tue, 16 Aug 2016 16:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMKvBXX2MKOU for ; Tue, 16 Aug 2016 16:22:01 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id E910412D0FE for ; Tue, 16 Aug 2016 16:22:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 375B840FEC; Wed, 17 Aug 2016 01:22:00 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id psY1I26C2uPK; Wed, 17 Aug 2016 01:22:00 +0200 (CEST) Received: from [192.168.1.34] (199.red-88-14-208.dynamicip.rima-tde.net [88.14.208.199]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon21.um.es (Postfix) with ESMTPSA id D22B23FDC6; Wed, 17 Aug 2016 01:21:57 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin Lopez In-Reply-To: <20160816054301.GB4333@cisco.com> Date: Wed, 17 Aug 2016 01:21:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <974D14F7-0301-46AD-B759-B8C4A5BCB98F@um.es> References: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> <1156D983-9628-41BC-8180-66999CABE3F6@um.es> <20160816054301.GB4333@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Dan Garcia , Eliot Lear , draft-ietf-anima-bootstrapping-keyinfra.all@tools.ietf.org, anima@ietf.org, Rafa Marin Lopez Subject: Re: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 23:22:03 -0000 Hi Toerless: > El 16 ago 2016, a las 7:43, Toerless Eckert = escribi=C3=B3: >=20 >=20 > Rafa, >=20 > I have not managed to figure out from your draft what exactly > you consider to be bootstrapping. It seems you primarily refer > to draft-ohba-core-eap-based-bootstrapping, which seems to be expired. Just a clarification, draft-marin-ace-wg-coap-eap-03 is just presenting = a transport of EAP in CoAP (CoAP used as EAP lower-layer). The = bootstrapping service is in the paper. =09 > To quickly summarize what in anima we call bootstrap: >=20 > The ANIMA key bootstrap protocol primarily tries to get a credential > installed on a device. This is based on RFC7030 (eg: cert enrolment) > and adds all the functions we have identified as being necessary on = top of this: >=20 > 1. Initial signaling so the client can trust the server from which > it gets the credential - server can be from some owner of the > device and it's producing a credential from the vendor of the > device that makes the device trust the server. As a result > for example the client install the servers CA cert into its > cert trustpool list. >=20 > 2. Requesting parameters to be associated with the credential. These > parameters are then useable by next steps. In Anima, these > credentials are parameters to the client cert, and those are > then used in building the ACP after bootstrap. >=20 > 3. Installing the credential - in ANIMA devices the AN Certificate. >=20 > Note: We did discuss but have not decided on options where > for example this step could be optional, eg: where in very low-end > devices the vendor installed credential is sufficient, and no new = credential is > desired, but instead only 1., 2., 4., 5. are performed. >=20 > 4. Diagnostics so the server side will know if/how steps 1..3 where > successful. >=20 > 5. Next step to take by the device - eg: build ACP or for non > ANIMA devices, maybe "here is your next provisioning connection > to build". (we're just discussing this step). >=20 > So, i am not aware that existing EAP mechanisms offer any such = bootstrap > functionality. I am not even aware they offer an equivalent of rfc7030 = with > EAP. [Rafa] Thanks for this clear summary. I have to say that EAP is a = protocol for authentication and key management mainly. You have several = "EAP methods=E2=80=9D that define the authentication mechanisms in EAP. = As I mentioned, previous work about MIPv6 bootstrapping used tunneling = capabilities in certain EAP methods to =E2=80=9Cinject=E2=80=9D that = configuration information (e.g. draft-giaretta-mip6-authorization-eap-04 = , old draft but interesting). Other alternative is just to use EAP for = authentication key material generation to protect the signaling of other = protocol/s that allows to transfer the information you need.=20 In the context of "IoT bootstrapping", I must say that we are not the = only one proposing the usage of EAP (the novelty of our solution is the = usage of CoAP as EAP lower-layer).=20 Best Regards. >=20 >=20 > On Sun, Aug 14, 2016 at 02:05:14PM +0200, Rafa Marin Lopez wrote: >> Dear all: >>=20 >> Related with the usage of CoAP for bootstrapping in constrained = devices (using EAP and AAA infrastructures) we wrote this I-D: >>=20 >> https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-03 >>=20 >> and wrote this paper that may be of your interest: >>=20 >> http://www.mdpi.com/1424-8220/16/3/358 >>=20 >> Comments are welcome. >>=20 >> Best Regards. >>=20 >>> El 3 ago 2016, a las 15:55, Eliot Lear escribi=C3=B3:= >>>=20 >>> Dear authors of draft-ietf-anima-bootstrapping-keyinfra and WG, >>>=20 >>> The Fairhair alliance focuses on lighting and building automation. = Our >>> security team has been reviewing your draft, and we appreciate the >>> effort that you are devoting in this direction. We would just like = to >>> highlight at this junction that there is a preference for device >>> communications from the autonomic device to the registrar to be via = COAP >>> over DTLS rather than HTTP over TLS, primarily because the devices = that >>> we are working with will already have a CoAP implementation. As = such, >>> there is some interest in draft-pritikin-coap-bootstrap-03.txt. We = look >>> forward to seeing that work further developed. >>>=20 >>> On behalf of the Fairhair security subgroup, >>>=20 >>> Eliot >>>=20 >>> ps: as usual, I will encourage fairhair members to directly chime in >>> with their own views on this matter. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>=20 >> ------------------------------------------------------- >> Rafael Marin Lopez, PhD >> Dept. Information and Communications Engineering (DIIC) >> Faculty of Computer Science-University of Murcia >> 30100 Murcia - Spain >> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >> ------------------------------------------------------- >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 > --=20 > --- > Toerless Eckert, eckert@cisco.com >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Tue Aug 16 16:51:56 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A385E12B044 for ; Tue, 16 Aug 2016 16:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPDmDYeTwq18 for ; Tue, 16 Aug 2016 16:51:52 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0F912B02C for ; Tue, 16 Aug 2016 16:51:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id A98174100D; Wed, 17 Aug 2016 01:51:51 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GGuTCTuqoIID; Wed, 17 Aug 2016 01:51:51 +0200 (CEST) Received: from [192.168.1.34] (199.red-88-14-208.dynamicip.rima-tde.net [88.14.208.199]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon21.um.es (Postfix) with ESMTPSA id 7D05B4100A; Wed, 17 Aug 2016 01:51:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin Lopez In-Reply-To: <29091.1471354038@obiwan.sandelman.ca> Date: Wed, 17 Aug 2016 01:51:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7C775290-74A7-428D-8ECE-792A2EA3CDFB@um.es> References: <4108581b-d6b8-b284-eb26-d3c047372aae@cisco.com> <1156D983-9628-41BC-8180-66999CABE3F6@um.es> <20160816052655.GA4333@cisco.com> <29091.1471354038@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: anima@ietf.org, Rafa Marin Lopez Subject: Re: [Anima] CoAP et al X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 23:51:54 -0000 Hi Michael: Just a clarification. If you are referring to IEEE 802.1X with 1x , then = I have to say that IEEE 802.1X is not EAP but it is using EAP. More = specifically, IEEE 802.1X is an EAP lower-layer. More comments inline. > El 16 ago 2016, a las 15:27, Michael Richardson = escribi=C3=B3: >=20 >=20 > Toerless Eckert wrote: >> 1. We did earlier in Anima investigate if/how we could/should use EAP >> to perform ANIMA bootstrap. It turned out that transporting all the >> desired key-infrastructure bootstrap messages across EAP would have >=20 > There are two other key issues with the 1x-architecture of = supplicants, > authenticators and authorization servers (AS). >=20 > The architecture usually looks like: (nice picture at: > https://en.wikipedia.org/wiki/IEEE_802.1X ) >=20 > S<--EAP-TLS over EAP over = 1x/PANA->Authenticator<--EAP-over-radius-->AS >=20 > The problem with this architecture is that it: > a) always creates state on the authenticator [Rafa] How do you perform an authentication exchange otherwise? Unless = you are thinking something like Kerberos where the KDC is stateless. >=20 > b) requires a secure relationship between Authenticator and Radius = Server. > (a radius secret, and an entry in the Radius Server's client table) [Rafa] I think we should talk about AAA server in general because other = protocols as Diameter can be used. Moreover the authenticator has to = have a secure relationship with the next hop AAA server (AAA proxy) not = with the (home) AAA server. Hence, the scalability. >=20 > c) And we'd then have to run EST over the EAP/TLS connection, and do = it > not with the radius server, but with the Registar. [Rafa] That is why I mentioned that, perhaps, the assistance of the EAP = lower-layer (e.g. CoAP) could help with this task. >=20 > (a) is a cost to absorb. > (b) could be mitigated by changing the Authenticator to really be: >=20 > Authenticator . o O ( -----EAP-over-GRASP--- ) >=20 > and having no radius server at all. [Rafa] That is called in EAP: EAP Stand-Alone authenticator.=20 > Of course, having got rid of that > compoennt, the commonality with the various 1x infrastructures is = really > non-existant. All we've done is introduce EAP fragmentation (and code = paths) > in a place where it will get used only once. >=20 > Instead, a good way to think about ANIMA bootstrap is that it's the = way in > which you get credentials which you can *then* use for 1x, if that's = what > your infrastructure wants. > Today, those credentials are distributed > out-of-band. [Rafa] Precisely this is the kind of separation we are proposing in our = work for IoT bootstrapping. Best Regards. > Seperating bootstrap from the 1x process not only simplifies > the bootstrap process, but it also simplifies the 1x code base, as it = doesn't > have to figure out if the new pledge is trying to join the network, or = trying > to bootstrap. >=20 > (I'm reminded of the Robert Frost poem about The Road Not Taken. Often > it is thought to be about taking chances in life. I tend to think = that > when it comes to security, that it's best not have divergent paths in = code, > unless both have regularly used test cases: "I doubted if I should = ever come > back") >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Wed Aug 17 01:59:08 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DE012D0B0; Wed, 17 Aug 2016 01:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XV3HGHSrYLbg; Wed, 17 Aug 2016 01:59:01 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0121.outbound.protection.outlook.com [104.47.1.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2330312D08C; Wed, 17 Aug 2016 01:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WjyYz1Ay0axL+SP2F6KJWc4SdkD8p9c0e6yfpbPUDCA=; b=QvZLzlhzWazE6t71aUWbh3rA3HOV72yZ1QHGQWo19vnRqvGxJ4Ms5SHYnUJ6i9znRVE4qbZHzoS++Gy0ktAcCrnmJcXY7g2Cp9loO3QqUJ00FK67IPLoL+9p27OZHumia2+41Q89/kpm0zr1BxI00X6uXYCw2yNJKzw4rYmNKyU= Received: from AM3PR04CA0063.eurprd04.prod.outlook.com (10.164.94.31) by DB5PR04MB1495.eurprd04.prod.outlook.com (10.162.221.153) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.5; Wed, 17 Aug 2016 08:58:57 +0000 Received: from DB3FFO11FD009.protection.gbl (2a01:111:f400:7e04::176) by AM3PR04CA0063.outlook.office365.com (2a01:111:e400:52b6::31) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.5 via Frontend Transport; Wed, 17 Aug 2016 08:58:57 +0000 Authentication-Results: spf=none (sender IP is 40.103.22.84) smtp.mailfrom=philips.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (40.103.22.84) by DB3FFO11FD009.mail.protection.outlook.com (10.47.216.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.567.7 via Frontend Transport; Wed, 17 Aug 2016 08:58:57 +0000 Received: from VI1PR9003MB0237.MGDPHG.emi.philips.com (129.75.99.82) by VI1PR9003MB0238.MGDPHG.emi.philips.com (129.75.99.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Wed, 17 Aug 2016 08:58:54 +0000 Received: from VI1PR9003MB0237.MGDPHG.emi.philips.com ([129.75.99.82]) by VI1PR9003MB0237.MGDPHG.emi.philips.com ([129.75.99.82]) with mapi id 15.01.0549.027; Wed, 17 Aug 2016 08:58:54 +0000 From: "Kumar, Sandeep" To: Anima WG Thread-Topic: [Anima-bootstrap] keyinfra-03 review Thread-Index: AQHR+FPUPUpeI2F640erOWrjfLbVa6BM1IJw Date: Wed, 17 Aug 2016 08:58:54 +0000 Message-ID: References: <681a69f5cae643a7701e0df980c44a0a@xs4all.nl> In-Reply-To: <681a69f5cae643a7701e0df980c44a0a@xs4all.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.108] X-MS-Office365-Filtering-Correlation-Id: 8106c4c4-ed5c-4f51-a78b-08d3c67cb97b Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OrganizationHeadersPreserved: VI1PR9003MB0238.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:40.103.22.84; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(428002)(374574003)(199003)(55904004)(85714005)(377454003)(71364002)(85664002)(189002)(13464003)(7736002)(33646002)(356003)(105586002)(86362001)(305945005)(50466002)(108616004)(92566002)(450100001)(7696003)(106116001)(23676002)(87936001)(81156014)(81166006)(3846002)(6116002)(586003)(626004)(102836003)(7846002)(8676002)(19580405001)(189998001)(19580395003)(110136002)(106466001)(8936002)(66066001)(54356999)(97736004)(101416001)(76176999)(4326007)(10400500002)(11100500001)(50986999)(24736003)(47776003)(16796002)(2900100001)(2950100001)(2906002)(15975445007)(68736007)(69596002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR04MB1495; H:011-smtp-out.Philips.com; FPR:; SPF:None; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD009; 1:uF9CUIIjE5i7Ayk/hwPjynh2g8nktbHiNH2zc0WGDussCia3lLzTPeZrvGjfgeoyhf9KpuDs83rv+RERssxucqSoPrPJAtFAvizOtmQNWNOK45ktJeZKmd5CF+N8EFdYAI/Zu2ahsqignmbYdHVCVqZ/q5k1tB4AOcm86Z2yK4X18l8fLHHrHE2LzVNJNt9+corgZ8MndkGMQVxGdywZVIS/3Y4jbvZZbkizS+CZTaKNf/zRuZAcuofIyZwyWrKRomSwRc/NlmXk7LnRFLFwI50YRnwXI0eL7zaygrKXYNjXLh13gcOSlGi7h2fj+xJreeYMmcFRsLsWEYc3CWJivbvJFovCTklzVqlEvcyOFX/1x1vIZs2KUbRz5S69PGdWx7iUwn6CiRgMsxVcZ9UdFqXxog8YvhcFJ2OWH/qrqFnlqvQnsMg+s2SouJTaDSSwfJwQHWJuZLcbQPV1q0IRYdn3ycKJYgzqqczZeK43ar4= X-CrossPremisesHeadersFiltered: DB3FFO11FD009.protection.gbl X-Microsoft-Exchange-Diagnostics: 1; DB5PR04MB1495; 2:JmAQi//B3P8Tt8yMhcGZv4j9fKUt8dgCdurJ3aS8Rnfo1XPVPtKm/S2XsPpXjFOQu0o5HA5kkH3xmK8sIBypTxr4keHTBvMBTazhuNzvt5kEJe3zT/fkwR1LOaqYQB4Px+T41kClQua5Ztv3Qpr0I2m7BXyTqdq5q4cFos3busV4dhtevUtQSbrCG/wkDvmy; 3:4SKBttuvyKsXeseBDlwD5adb+GlhhZR+4v9BQy35QKzLcGXk965LBt8Tmi2c/QRgPZbTR52JNrHlTxoB+JgdsDu6ULuxcMki8b91UH/GwiQSt0qx2iVHsipoGezu6bxs50Ro9rK+5/hfNNlLBNiTaExFfiB4/tgl2/7lB0FjKMFW+ouiU/dWbphXUHXNu9JCalEGZMi/Z2//YkP/yVnSb/ElKHncjq9O5PoRC+Dhcq4= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR04MB1495; X-Microsoft-Exchange-Diagnostics: 1; DB5PR04MB1495; 25:sQAzk5L6km3d8ztdQpbW0qjwjRnYW6DfwSYd/suCIpWyy5FPoFXYKKUYJqxJ2rMZSAQB1qpp1SE/Gu8MshBtpxokdX5xV2KXVZbjvbs9vnYwJFR/zMnx0pcja7ySnfzfhyRs7oyals7svedNFs/l5+xHDI8uKG77X65Kou+qKpI9ynw2w9Q7AZOwxybMsa8+77klMkc6DRvinslAm6LSo9NpaLKAc//v9jZEgriLb9miFUhKh+Bc8i9p3nVQhvKS2/9fAvbYB3aeA0i+VtTnuj52EfbouvOhCB3LhUPacst7qpykUqi+c4Mgb3AaS0vXFbD2p/V7AesE4TBDpgzJbfNPg8lILPYtFRhWXxEcOX7x9TxG9ma8qCdHIy0nCm7BZEeFY8Zru08tHT58OwwLqRQ6aDMmLPFBt+WSIcTHFowl16PodqXroIE0dOl+RgnwWZHvB0GRNqtyYgl+RWkho6UsPOn25fgn3nnm+iZ5IkDSht1HT0B1RYHADK9qlVyVuLd0MZuzliGiWBJSIi+KBKvfpic6pbgMLPyHBI2D+FQgzG5AnwAU5WNG8MWw/ipf9WnJ0tkaW6mPWMnbFbzX8T0k0Ffl8dYmAWf95sH0Tu8kVtUp+Cj7IS7CPdW0C48LQEJLEf73PQ2DjHAVT7ItBCLI2bg6gAHS/JNNdDKFsCCZMf6Nb6hnQzPNKeBDES1uONqd1x/euNr+DOX6yosCtSbPk8mDDAHggZ49P7xtciGM4CDLkZkWA9C4BvOQU1KBt+Lr6YUx9MjdqqqvncRYTcD7W0wUk5bOnR5ffIHUgoT2a8tfH15QhBNnU3edYMEio4wtlgIOWIU23cwVCYdx6d1ckLDhdwrodiZxM79R1GCm9tuR7D9duM9nnywk1S+AbCO9LqQ4jWPKn/fKN0OrKA== X-Microsoft-Exchange-Diagnostics: 1; DB5PR04MB1495; 31:rMnc3XI9P4SzesvkP1aKkAinsEXSQm80lsPzo6/8YJOY2Asu2E90YUDMcYU5DIcprPft4cr4L8uMtG7SnYwU2zB6B1OduF3mSf/cUAu6e4aRdWzJ5VsTqUqwXahmG33xqxkURZ+66B9RtS1yFiC/3Tv7PXcYhv41lPTJlkkhKqD5Swm/XjeRGo9cE+fMPt6VWbsu3yUFCIjYfclMoV48TrtwST8qTDCpUle4VEsb5Vw=; 20:ZmfSfzM+Vd/Wmr8VvXZaXBwYdgeSWmPcRtBa9k3KCv0isXEeDEyiWS75HMdHiSEMNNfpzs3RIux3FsjjOINqdept+y+3ZuDSP3PPGA3IVH2Xy+Owi2Nyx7CtNkULiuhCaCLQYGddDBzAmbtGJKaZLhwSp7upP+xxjUTQa0LlimY9i0EHj/n8359nJ4aXyLLUdKjV1JCIVcU3drDMmw4D8Ohv4Y5DfSFIX7UaLyPvmX6gefIGVvpRJYq1Yk65JNqW0F4cBHEBy14zboXDPRT/KQaDjG7Z61FVG+F2OzdloW2JHqD/n5igOM/dKI/hdJCD/WRUNHjvwFVGcNLw/1bI/Eib+OL64rCQMAZtyBIDqWXSojzfe1oPNh71wtmm+GlSMy0iJcPo3cP2s0Vs01rcqSEbvxmLWj5myPRq/1INxy8Su0lhoxaIVDA7ETfN9xq0p2M7YoK3R6Rv+dI80JfrXtupSdwbYA03Frt4u74OliCm4ekyxCmhUBe86L9/nIay X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(60795455431006)(158342451672863)(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(13018025)(8121501046)(13016025)(5005006)(10201501046)(3002001)(6055026); SRVR:DB5PR04MB1495; BCL:0; PCL:0; RULEID:; SRVR:DB5PR04MB1495; X-Microsoft-Exchange-Diagnostics: 1; DB5PR04MB1495; 4:tT1jfwV6Oplx9jLbonJ6WRch+GLvEpQwWtwzkuWB8tldYqBfytLq000E9yxn0mOIYO9Nc52svJXKR7znr0PLlf0FaA/Lv3h1pyTFK+MsA61cVe29Zmzx4cRCaDHD6Br18d6/g2xB23zEMXACFuAHy2F/2qb88Rwbk+w0fFpKGfWx8cPLyeYK0tx62SOia8Q60W+/axKA8UomE9Dv+Wf9zlv+NTBiRO/E+uam2gPT70o0j8jcnAgVoOpo9CbGcn3kNHL2pwm58ZiYGEZs2/SH1sOsJDI7l0rPPcPIvpbmNQdA9egsmdZjeDoNV+myXjmKdzyX3t3Vte/BnOfluM58wMNlZf5rc0QFJrlEw6qhvxQEoRC2hnNbEMnzbmJvj4uhlizS9xSb1NNlBRqn5/e88pB/5iiqaXlOxBCc3usnwwR2Y1iUabxjlWaAQKY/JQj44QNypzR6K5xvbdcVnPwbo1mih4pTWNAKlRXgxLU8o8IUHaqJ7mt7fks+pOQzhSUZdzUIHt97eUdjAmQ9B0i3YsgCi6C9SuKI2h9RSHseP9JhRibRsTxEbnzfLvVaDjwy X-Forefront-PRVS: 0037FD6480 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjA0TUIxNDk1OzIzOnRYRkhMbjR5OUxGNkpNeHp1VktEMEs4Z01v?= =?utf-8?B?RWNtenNKeVZNdEtqWUdUcFZ1d2lpL0ErSXVWUFFjVzR4RjNLK0pXcmdjWlNn?= =?utf-8?B?VVRjT3R2bWxrNnBreFdubHhOeFdKT0twM1ZLNERCQ0MyekQwQmY1U0VEY0o0?= =?utf-8?B?TFIrZ2N2VnMrWmdVNWptOXM2UE1KRXp5UWdGcW9LTlRVSnkvclJjazZkbkpD?= =?utf-8?B?ZXAzbXR3N1BiK0k2R2NVRTdvVEFaZjRNY0hxOWdYZjFUclBPUUdnKzgxS05J?= =?utf-8?B?V010RnRiNForNVJkbStlMFU1WEtiMFRTWjcyOEh5L2NsZk5jQ2hKc3BVWENL?= =?utf-8?B?NU13ZjFJRUR1aURsYjJpa3NBckczTmVHdXZBai9RT3l3NU81MW1BNUxESEha?= =?utf-8?B?b1A3VzdNOExKdThEUXE2bW5QL0hkV3JDL2t1Y2pJWE9Udmx0bDlVS3g2RnRk?= =?utf-8?B?Z2pPdlRrRDNyZzdoUVJqRStva29LY3kyRU12OTlWRUxIYmcxYlY3Wk45R1V2?= =?utf-8?B?SVRFUW52SFZIS2dPYUtGZEFxMjVPZHAxKzZVUm9qbU5wYkJzQ05XWURqUTJP?= =?utf-8?B?NFl5eDZQL2tNSGhqNHR4SHJDS3RhUkFqOGlvR0ZQRkhlZGJWVmd2RnJEc2h1?= =?utf-8?B?dmk2Q1FxKzFUeEtWWUJIakNkRHovS29iaXJ5c29mdXRqZnZoUU1kclE5MzZ0?= =?utf-8?B?Z0dWWGNuZlJOVk9Nak84NncrZFhvRnUxdWUydVRELy9SYkZ2RnRDMnFFcnpK?= =?utf-8?B?cEJCUlBXYVdYZURXUzJjYmtMcUptTmVBTXo5R3ZmMGtMRG81UnJlMVBmVW0y?= =?utf-8?B?Um9RSjJpcVVRR3IwT01XSXJTbVZKSGdudmlBRkM2ZHFSSEtzanpaNis5SEht?= =?utf-8?B?eW03c3ZuTlhMNENLM2h1SmVpbk5sQnRFb0xBOU8yNWlrSjcwZStKRWhIRXpP?= =?utf-8?B?TzM4TDlIWFBLcVdtRTV6V1FsanRmdVNxOStDd2RrdzRaZEg0S1h5YkRoQytk?= =?utf-8?B?UGswQTR3Vi8rSVRVdmRzdUJ3OSt3Q0Rmd1VGaDRXWk9xb2d2NVRiL0FzdGhk?= =?utf-8?B?dUJmbUZIRDNmZTAwN29sdkFiOTd4SHord29FZk5RNVNUa1ErUWpLYndaY0ZW?= =?utf-8?B?UXJQcDBXUWt1ZzR0VG93c0xHT1Z1Qk5CN1hSeGRVOEpaeGpINmtIbGVINnpw?= =?utf-8?B?N25OK0ZqY3JQQmMyUGZ5d2VsK2tVZVlXS044MmFDVzdTazVHTEptNVU4VmJ5?= =?utf-8?B?T2ppY0pzV0FiU1pMQzdqellzNXIrSUFBSDFMc3k1WVhUcFNpSWdSY05UNFB2?= =?utf-8?B?bDYrMGJpM2hiRS8vZzgwWEFzeVdnQnlHT0dPbGdJRlNRcGFVTEl3aDU5QmZ4?= =?utf-8?B?Sm9uQXp5NXJSL1VuVU9ZMlRVRDRxczhIUU1wd01pT1pDY05tUHd6aWJEZVlH?= =?utf-8?B?dFYwWjdpWVNNRkdDaktaUUxvOUFPWUdxbHQ3SWlCeEh3djBQZk40TUI5OWpv?= =?utf-8?B?cFZwem5DelNGZ1lXZ0NVNWp3VkR2NW5sTzQ5alVhU0xUeG85Uy95dEl1VWxp?= =?utf-8?B?RzdVYWV6KzBESmJWNmZTeHVEMGlULzhuVTVpci9zNEFJV2x5RmN0S2YyZVpX?= =?utf-8?B?cGRkWnJEMU1XeG5McUU5OWJQN3YyVGo0VUNKdTVtRlhwNEpDYTcwUjNwQm1L?= =?utf-8?B?cUlEeUZ0dDRwM1czUmNqWG9WdE1iSnZ4K1ZMR1ozc2R3NDhmUUFlbGMxalFi?= =?utf-8?B?V3VMR2RUdjlod0JnVnFOckx5cWw4aklaSTJ2T092UUJ3STczUjZDN0hkam05?= =?utf-8?B?N2xxZTJOa3N4NEoyb3haa09ybFdwMUF3Qk03NnIyejhkeGNPSnV1UTZQU3ph?= =?utf-8?B?SndhcWVRQVlpSUJVTkJBYWhZRnROY2d6eUg5NXFlMXRVc0xqQTF4ZkNqaVdy?= =?utf-8?Q?DalCIAbCD0QwRkQWSUFAlg3hlk7G7I=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR04MB1495; 6:wzkQ4d5rRVHU4Wr+JamZeLz//yGXN4tWK5V96J/dCHR52J1bDyk3Tp9/W9KO28JBrOtMf7ZxHnHSrMX7w/6ZcqdGrmJrIewCQsgwVclk6ryASVrTFAZ2UpKa/HgekWJlxYV1g2R4PBu9XXwpY4XMFoFls4uvyfJQGiCa4pgSOWQ1PA3UZ7d+FlEtKA/aCDCVuK0kXSfM15RYxqHKJq/15ImGRNjNGF5SqSjwdW1DlDQiSHaJOnWoTSthBEmnbWjKc37MQq78IsQiocToWkB4IdVznbOEMRjOah9t5qYGdnBybffN0Ie4W4chz1qt/y8+Nf5QX/KEGKt2j3ZncSQmOg==; 5:5p7oTuByO1QPlXkjm5rwzYMJSRK/22OGFjPYvZ3uhlU+rgUtwoXgxPKSZiLAtjfOvhF2qVQUz4RCoQGSVR4E2OPk9Hg2EfZekZMgGbiz/eUdRCxy7h0WtnlGdII5bzZEAFCqOU+XKZTRc3YEjw9Q7Q==; 24:skTpCTrm+qaIY3qPp0Zo7nSW3YU/kYjw2C4qb+1q0kVQ2rP7ttUx6aiEu5bey0/UrBW3D7Nx3qvs2JZz4X7B1APWLNZ2fIk0sb8zlOv5GO8=; 7:0hLB6pLgVyoVfSkc3x7QU2aYtSQVAtkidFp/ZXHtpXK2ugQ+ytuFv22QW/xjlJ3eSPKSr1Pm2MH8VyO2j+LTu73dECz5sg/3hmiOvh80YUyOqBX3NAVW/qEphxRLnNAI5gT21wRs9eWaKkRza38pB0pxB3rs8MJ4Vyk0QdX+0osSMPEyMHjLFWuiIjOMSLz9UN8G7VPxKZnztEI+yYQz0WJjb2333fKcumXWwlnbyzR6lMM6KOu/4GTqltzqBBMf SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2016 08:58:57.2016 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[40.103.22.84]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR04MB1495 X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 40.103.22.84 X-MS-Exchange-CrossPremises-AuthSource: DB3FFO11FD009.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: DB5PR04MB1495.eurprd04.prod.outlook.com Archived-At: Cc: Anima-bootstrap Subject: [Anima] FW: [Anima-bootstrap] keyinfra-03 review X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 08:59:05 -0000 RGVhciBhbGwNCg0KQWxzbyBmb3J3YXJkaW5nIHRoZSByZXZpZXcgdG8gQW5pbWEgc2luY2UgSSB0 aGluayBQZXRlciByYWlzZXMgc29tZSBpbnRlcmVzdGluZyBwb2ludHMgd2hpY2ggcmVxdWlyZXMg bW9yZSBjbGFyaWZpY2F0aW9uLg0KLSBIb3cgaXMgdGhlIHByb3h5IHNlbGVjdGVkLCBieSB3aG9t IGFuZCBob3cgaXMgaXQgY29uZmlndXJlZCB3aXRoaW4gdGhlIGF1dG9ub21vdXMgZG9tYWluPw0K LSBJcyB0aGUgcmVsYXlpbmcgb2YgVExTIHRocm91Z2ggdGhlIHByb3h5IGZpbmFsaXplZC4gVGhl cmUgYXJlIHZhZ3VlIHJlZmVyZW5jZXMgdG8gbXVsdGlwbGUgb3B0aW9ucyBsaWtlIElQSVAgYW5k IFRDUCBjaXJjdWl0IHByb3h5LiBJcyB0aGUgaW50ZW50aW9uIHRvIHN1cHBvcnQgb25seSBvbmUg b3IgaGF2ZSBvbmUgbWFuZGF0b3J5IHdpdGggbXVsdGlwbGUgb3RoZXIgcHJveHkgdHlwZXMgc3Vw cG9ydGVkIGJ5IHRoZSBSZWdpc3RyYXI/IFRoZSByZWFzb24gSSBhc2sgaXMgYmVjYXVzZSBhIERU TFMgcmVsYXlpbmcgbWV0aG9kIGlzIHdlbGwgZGVmaW5lZCB3aXRoaW4gYW4gZXh0ZXJuYWwgc3Rh bmRhcmRpemF0aW9uIGJvZHkgYW5kIHdvdWxkIGxpa2UgdG8ga25vdyBpZiB0aGF0IGNhbiBiZSBz dXBwb3J0ZWQgZW5kLXRvLWVuZCB3aXRoIHRoZSBSZWdpc3RyYXIuDQoNCkluIGFkZGl0aW9uIHRv IFBldGVyJ3MgY29tbWVudHMgd2hhdCBJIGFkZGl0aW9uYWxseSBtaXNzIGZyb20gdGhlIGN1cnJl bnQgZHJhZnQgYXJlDQotIFRoZXJlIGlzIG5vIGF1dGhvcml6YXRpb24gb2YgdGhlIFJlZ2lzdHJh ciB0byByZXF1ZXN0IGRldmljZSBhdWRpdCB0b2tlbnMsIG1ha2luZyBpdCBlYXN5IGZvciBhbnlv bmUgdG8gc3RlYWwgZGV2aWNlcyBiZXR3ZWVuIHRoZSBpbnN0YWxsYXRpb24gYW5kIGNvbW1pc3Np b25pbmcgcGhhc2UgKHdoaWNoIGNhbiBiZSBxdWl0ZSBsb25nIGluIGNlcnRhaW4gaW5zdGFsbGF0 aW9ucykuIFRoZSBpZGVhIG9mIGFuIG93bmVyc2hpcCB0cmFja2VyIGJhc2VkIG9uIHNhbGVzIGRh dGEgaXMgY29tcGxldGVseSBpbXByYWN0aWNhbCBpbiBtYW55IGluZHVzdHJ5IGRvbWFpbnMuIFRo aXMgbGVhdmVzIGEgY29tbWlzc2lvbmVyIHdobyBhcnJpdmVzIGF0IGEgbG9jYXRpb24gd2l0aCBh IHByb3NwZWN0IHRoYXQgaGUgY2Fubm90IGNvbW1pc3Npb24gdGhlIGRldmljZXMgYW55bW9yZSBz aW5jZSB0aGV5IGhhdmUgYmVlbiBhbHJlYWR5IHN0b2xlbiBhbmQgbmVlZHMgdG8gcmVjYWxsIHRo ZSBpbnN0YWxsYXRpb24gZ3V5cyBiYWNrIHRvIGZhY3RvcnkgcmVzZXQgZGV2aWNlcyAod2hpY2gg bWVhbnMgbGFkZGVycywgcmVtb3ZpbmcgZmFsc2UgY2VpbGluZywgb3IgdG8gc2ltcGx5IHVubmVj ZXNzYXJ5IGNvc3RzKS4NCi0gSW4gbWFueSBzaXR1YXRpb25zIChsaWtlIG5ldyBidWlsZGluZ3Mp IGEgRW50ZXJwcmlzZSBkb21haW4gcmVnaXN0cmFyIGRvZXNuJ3QgZXhpc3QgYW5kIHRoZXJlIGlz IGEgbmVlZCB0byBicmluZyBkZXZpY2VzIGludG8gYSB0ZW1wb3JhcnkgZG9tYWluIChsaWtlIGEg Y29tbWlzc2lvbmluZyB0b29sIGFjdGluZyBhcyB0aGUgcmVnaXN0cmFyKSB0byBiZSBsYXRlciB0 cmFuc2ZlcnJlZCB0byBhIHJlYWwgZG9tYWluIHdoZW4gYXZhaWxhYmxlLiBIb3dldmVyIHRoZSBk cmFmdCBzZWVtcyB0byBjb21wbGV0ZWx5IGlnbm9yZSBhbnkgaGFuZG92ZXIgcmVxdWlyZW1lbnRz IGFuZCBzb2x1dGlvbnMgd2hpY2ggYXJlIHZlcnkgcmVsZXZhbnQgaW4gcHJhY3RpY2UgdG8gbWFr ZSB0aGlzIHVzZWZ1bC4NCg0KS2luZCByZWdhcmRzDQpTYW5kZWVwDQoNCg0KRHIuIFNhbmRlZXAg Uy4gS3VtYXINClNlbmlvciBTY2llbnRpc3QgLSBTZWN1cml0eSwNClBoaWxpcHMgTGlnaHRpbmcg UmVzZWFyY2gsDQpFaW5kaG92ZW4sIFRoZSBOZXRoZXJsYW5kcy4NCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogQW5pbWEtYm9vdHN0cmFwIFttYWlsdG86YW5pbWEtYm9vdHN0 cmFwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBwZXRlciB2YW4gZGVyIFN0b2sNClNl bnQ6IFdlZG5lc2RheSwgQXVndXN0IDE3LCAyMDE2IDg6NTEgQU0NClRvOiBBbmltYS1ib290c3Ry YXAgPGFuaW1hLWJvb3RzdHJhcEBpZXRmLm9yZz4NClN1YmplY3Q6IFtBbmltYS1ib290c3RyYXBd IGtleWluZnJhLTAzIHJldmlldw0KDQpIaSBNYXgsDQoNCkluIEJlcmxpbiB5b3UgYXNrZWQgZm9y IG1vcmUgcmV2aWV3cyBvZiB0aGUga2V5aW5mcmEgKGJvb3RzdHJhcHBpbmcpIGRyYWZ0Lg0KQmVs b3cgbXkgZWZmb3J0cyBmcm9tIGEgY29uc3RyYWluZWQgZGV2aWNlL25ldHdvcmsgcG9pbnQgb2Yg dmlldy4NCkkgaG9wZSB0aGUgcmV2aWV3IGhlbHBzIHRvIGdldCB0aGUgdmFsaWRpdHkgb2YgdGhp cyBkb2N1bWVudCBmb3IgdGhlIGNvbnN0cmFpbmVkIHdvcmxkIGJldHRlciB1bmRlcnN0b29kLg0K DQpHcmVldGluZ3MsDQoNClBldGVyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpBbmltYS1ib290c3RyYXBwaW5nLWtleWluZnJh LTAzDQpJbiBnZW5lcmFsOg0KSSB0aGluayB0aGlzIGlzIHF1aXRlIGFuIGltcG9ydGFudCBkb2N1 bWVudCB0byBzdGFuZGFyZGl6ZSBhdXRvbm9tb3VzIHNlY3VyaXR5IGJvb3RzdHJhcHBpbmcgaW4g dGhlIGNvbnRyb2wgcGxhbmUsIGJ1dCBpdHMgcmVsYXRpb24gdG8gY29uc3RyYWluZWQgZGV2aWNl cyBjb3VsZCBiZSBpbXByb3ZlZCBhbmQgY2xhcmlmaWVkLg0KSSBmb3VuZCBpdCBkaWZmaWN1bHQg dG8gcmV2aWV3IHRoZSBkb2N1bWVudCBiZWNhdXNlIHRoZXJlIGlzIG11Y2ggb3ZlcmxhcHBpbmcg dGV4dCB0aGF0IGRlc2NyaWJlcyB0aGUgc2FtZSBwcm90b2NvbCBvciBmdW5jdGlvbiBidXQgaW4g ZGlmZmVyZW50IHdvcmRzLiBBbHNvIEkgcmVjb21tZW5kIHRoZSB1c2Ugb2YgY29uc2lzdGVudCB0 ZXJtaW5vbG9neS4gRm9yIGV4YW1wbGUsIHRoZSB0ZXJtcyBuZXcgZW50aXR5LCBkZXZpY2UgYW5k IG5ldyBkZXZpY2UsIHByb2JhYmx5IGRlbm90aW5nIHRoZSBzYW1lIHRoaW5nLCBhcmUgdXNlZCB0 aHJvdWdob3V0IHRoZSBkb2N1bWVudC4gQSBjb25zaXN0ZW50IGNob2ljZSB3b3VsZCBoZWxwIHRo ZSByZWFkZXIuIFRoZSB0ZXJtcyB2ZW5kb3Igc2VydmljZSwgTUFTQSwgb3IganVzdCB2ZW5kb3Ig Y291bGQgYmUgYWxpZ25lZCBpbiBmaWd1cmVzIGFuZCB0ZXh0LiAgQXMgYSByZXN1bHQgdGhpcyBp cyBhIHF1aXRlIGhpZ2gtbGV2ZWwgcmV2aWV3LCBpbiB3aGljaCBJIG1haW5seSB0cnkgdG8gcG9p bnQgb3V0IHdheXMgdG8gaW1wcm92ZSB0aGUgcmVhZGFiaWxpdHkuDQpJbiBtb3JlIGRldGFpbDoN ClRoZXJlIGFyZSB0d28gYXV0aG9yaXphdGlvbnMgaW4gdGhlIGRvY3VtZW50OiBhIHByb3Zpc2lv bmFsIG9uZSBhbmQgYSBkZWZpbml0ZSBvbmUuIEdpdmluZyB0aGVtIGRpZmZlcmVudCBuYW1lcyBh bmQgcmVmZXJyaW5nIHRvIHRoZW0gYnkgdGhlc2UgbmFtZXMgd291bGQgaGVscC4gRm9yIHRoZSBt b21lbnQgYSByZWFkZXIgaGFzIHRvIGd1ZXNzIHdoYXQg4oCcYXV0aG9yaXplZOKAnQ0KbWVhbnMg aW4gZGlmZmVyZW50IHBhcnRzIG9mIHRoZSB0ZXh0LiBUaGUgdGVybSBaZXJvLXRvdWNoIGFwcHJv YWNoIGNvdWxkIGJlIGV4cGxhaW5lZCBpbiBzZWN0aW9uIDEuMS4NClBhZ2UgNC4NClRoZSA0IHF1 ZXN0aW9ucyBhdCB0aGUgdG9wIG9mIHBhZ2UgNCBuZWVkIHJlcGhyYXNpbmcuIEVzcGVjaWFsbHkg dGhlIHdvcmRzIOKAnHdob+KAnSwg4oCcbWluZeKAnSwg4oCcaXTigJ0sIGFuZCDigJxJ4oCdIGFy ZSBhbWJpZ3VvdXMuDQpTdWdnZXN0IHRvIHJlbW92ZSBpbiB0aGUgc2Vjb25kIHBhcmFncmFwaDog 4oCcVGhlIGRvbWFpbuKAmXMgZGVjaXNpb25zIOKApi4NCkF1ZGl0YWJsZSBmYXNoaW9u4oCdLiBU aGlzIGlzIGRpZmZpY3VsdCB0byBmb2xsb3cgYW5kIG5lZWRzIGluZm9ybWF0aW9uIHByb3ZpZGVk IGxhdGVyLg0KT3B0aW1hbCBzZWN1cml0eSAocmVtb3ZlIG9wdGltYWwpDQrigJxCb290c3RyYXBw aW5nICDigKYgc2VjdXJl4oCdLiBSZW1vdmUsIGRvZXMgbm90IGhlbHAuDQpMYXN0IHBocmFzZSBi ZWZvcmUgMS4xOiByZWR1Y2UgdG86IFN1cHBvcnQgb2YgYWx0ZXJuYXRpdmUga2V5IGluZnJhc3Ry dWN0dXJlcyBpcyBkaXNjdXNzZWQuDQpQYWdlIDU6IERvbWFpbklELiBSZW1vdmUg4oCcKGEgc3Ry aW5nIHZhbHVlIOKApiBpcyB1c2VkKeKAnS4gVGhpcyBpbmZvcm1hdGlvbiBkb2VzIG5vdCBoZWxw IG1lLg0KUGxlZGdlOiB0byBhdCB0aGUgZmFjdG9yeSAod2hpY2ggb25lIHRvIG9yIGF0PykNCiAg YmVsb25ncyB3aXRoIHRoaXMgbmV0d29yayAoeW91IG1lYW4gZG9tYWluPykgc2VjdGlvbiAxLjIu IEkgZmluZCB0aGUgZGlzY3Vzc2lvbiBpbiB0aGlzIHNlY3Rpb24gdmVyeSBoYXJkIHRvIGZvbGxv dy4NClRoZSBnZW5lcmFsIG1lc3NhZ2UgSSByZWNlaXZlLCBpcyDigJxjb25zdHJhaW5lZCBuZXR3 b3Jrc+KAnSBhcmUgb3V0IG9mIHNjb3BlIChOTyA4MDIuMTUuNCk7IHVubGVzcyB5b3UgZXhlY3V0 ZSBvbmx5IHBhcnRzIG9mIHRoZSBib290c3RyYXBwaW5nIHByb3RvY29sLiBCdXQgZXhlY3V0aW5n IHBhcnRzIG9mIHRoZSBwcm90b2NvbCBpcyBub3QgYWxsb3dlZC4gT24gdGhlIG90aGVyIGhhbmQg YW4gYXJndW1lbnQgaXMgbWFkZSBhYm91dCB0aGUgc2l6ZSBvZiB0aGUgbWVzc2FnZXMgYmVpbmcg cHJvaGliaXRpdmU7IGJ1dCBpdCBpcyBub3QgY2xlYXIgd2hhdCBzaXplcyB3ZSBkaXNjdXNzLiBM YXRlciBpbiB0aGUgZG9jdW1lbnQgKHNlY3Rpb24gNS43LjUpIGEgZGlzY3Vzc2lvbiBhYm91dCBD b0FQIGFuZCBEVExTIGZvbGxvd3M7IGJ1dCB0aGUgcmVsYXRpb24gd2l0aCB0aGlzIHNlY3Rpb24g aXMgdW5jbGVhci4NCk15IHN1Z2dlc3Rpb24gaXMgdG8gY2xhcmlmeSB0aGUgZW5kIHN0YXRlIGV4 cGVjdGVkIGZyb20gdGhlIGtleSBkaXN0cmlidXRpb24gYXMgZXhwbGFpbmVkIGluIHNlY3Rpb24g My4xLjcuIEV4cGxhaW4gdGhhdCBjb25zdHJhaW5lZCBkZXZpY2VzIG1heSBuZWVkIHRoaXMgc3Rh dGUsIG1lbnRpb24gdGhlIGludGVuZGVkIHVzZSBvZiBjb2FwIChzZWN0aW9uDQozLjIuMSkgYW5k IHBvaW50IG91dCB3aGVyZSB0aGUgYm9vdHN0cmFwcGluZyBjb21tdW5pY2F0aW9uIG1heSBiZSBs b25nICh0cmFuc3BvcnQgb2YgY2VydGlmaWNhdGVzKSBhbmQgd2lsbCBuZWVkIHRoZSBibG9jayBv cHRpb24gb2YgQ29BUC4NClBhZ2UgOTogSXMgb3duZXJzaGlwIHRyYWNrZXIgcGFydCBvZiBNQVNB PyBJbiB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQgaXRzIGV4aXN0ZW5jZSBzZWVtcyBub3QgZXNz ZW50aWFsLg0KU2VjdGlvbiAzLiBUaGUgZmlyc3QgcGFyYWdyYXBoIGFib3V0IGF1dG9ub21pYyBm YXNoaW9uIHNob3VsZCBnbyB0byBzZWN0aW9uIDEsIHdoZXJlIHRoZSByZWxhdGlvbiB3aXRoIEFD UCBjb3VsZCBiZSBjbGFyaWZpZWQuIEluIGdlbmVyYWw6DQpJZ25vcmluZyBub24gYXV0b25vbWlj IGFzcGVjdHMgd2lsbCBoZWxwIHRoZSByZWFkYWJpbGl0eSBvZiB0aGlzIGRvY3VtZW50Lg0KRmln dXJlIDIgaXMgcXVpdGUgaGVscGZ1bCwgYnV0IHdoeSBpcyB0aGVyZSBhIGZpZ3VyZSA1IGFuZCA2 IG9uIHBhZ2VzIDI5IGFuZCAzMDsgYW5kIHdoYXQgYXJlIHRoZSBkaWZmZXJlbmNlcz8NClNlY3Rp b24gMy4xIEkgZG9u4oCZdCB1bmRlcnN0YW5kOiDigJxBIG5ldyBlbnRpdHnigKYuIGJlZW4gY29u ZmlndXJlZOKAnSBXaHkgbm90OyBJIGFzc3VtZSB0aGUgcHJvdG9jb2wgZGV0ZWN0cyB0aGlzIGJl aGF2aW91ci4NClBhZ2UgMTI6IGlkZW50aWZ5IGl0c2VsZiBBTkQgYXV0aGVudGljYXRlIFJlZ2lz dHJhciAodGhleSBoYXZlIGVxdWFsDQppbXBvcnRhbmNlKQ0KUGFnZSAxMzogcG9pbnQgMzogd2h5 IHRoZSB0ZXh0IGFib3V0IG5vbmNlPyBUaGlzIHdpbGwgYmUgdHJlYXRlZCBzZXZlcmFsIHRpbWVz IGxhdGVyIGluIHRoZSB0ZXh0Lg0KUG9pbnQgNDogVmVyeSBjb25mdXNpbmcgdG8gbWUuIE1hbnkg dGVybXMgYXJlIHVzZWQgdGhhdCBhcmUgZXhwbGFpbmVkIG11Y2ggbGF0ZXIsIGxpa2U6IEF1ZGl0 IHRva2VuLCBvd25lcnNoaXAgdm91Y2hlciwgUmVnaXN0cmFyIHNlcnZlciBjZXJ0aWZpY2F0ZS4N ClBvaW50IDUg4oCcZS5nLiBFU1TigJ0uIFdoeSBlLmcuIGl0IHNlZW1zIHRvIGJlIHRoZSBvbmx5 IG9wdGlvbiBsYXRlciBpbiB0aGUgdGV4dC4gSWYgbm90IGNhbiBpdCBiZSBtYWRlIG1vcmUgZXhw bGljaXQgdGhhdCBvdGhlciBtZXRob2RzIGFyZSBzdXBwb3J0ZWQuDQpTZWN0aW9uIDMuMS4xIERp c2NvdmVyeS4gVGhlIHN0YW5kYXJkaXphdGlvbiBvZiB0aGUgZGlzY292ZXJ5IG9mIHRoZSBwcm94 eSAocmVnaXN0cmFyKSBkb2VzIG5vdCBzZWVtIG5lY2Vzc2FyeSB0byBtZS4gVGhlIGJvb3RzdHJh cHBpbmcgcHJvdG9jb2wgaXMgbm90IGFmZmVjdGVkIGF0IGFsbCB3aGVuIGRpZmZlcmVudCBkaXNj b3ZlcnkgcHJvdG9jb2xzIGFyZSB1c2VkLiBKdXN0IGNpdGluZyBHUkFTUCBhbmQgbUROUyBhcyBl eGFtcGxlcyB3aXRoaW4gdGhlaXIgY29udGV4dCBzZWVtcyBtb3JlIHRoYW4gc3VmZmljaWVudCB0 byBtZS4NClNlY3Rpb24gMy4xLjIgcGhyYXNlIDE7IHRvIHdoYXQ/IGRvZXMgdGhlIG5ldyBlbnRp dHkgaWRlbnRpZnkgaXRzZWxmPw0KUGFyYWdyYXBoIDI6IFdoYXQgaXMgdGhlIGJvb3RzdHJhcHBp bmcgcHJvdG9jb2wgc2VydmVyIGhlcmU/IFRoZSBwcm94eSBvciB0aGUgUmVnaXN0cmFyPyBJcyBp dCB0aGUgZGF0YSByZWNlaXZlZCBmcm9tIHRoZSByZWdpc3RyYXIgdGhhdCBpcyBub3QgdHJ1c3Rl ZD8gQnV0IHRoZSBkYXRhIGZyb20gdGhlIG5ldyBlbnRpdHkgaXMgdHJ1c3RlZD8gQW5kIHdoeSBp cyBhIFRMUyBjb25uZWN0aW9uIG5lZWRlZCwgaWYgbm8gZGF0YSBpcyB0cnVzdGVkPw0KUGFnZSAx NSwgbGFzdCBwaHJhc2UgYmVmb3JlIDMuMS4zOiBib290c3RyYXBwaW5nIHNlcnZlciAtPiByZWdp c3RyYXI/DQpOZXcgZGV2aWNlIC0+IG5ldyBlbnRpdHk/DQpTZWN0aW9uIDMuMS4zLiBJcyB0aGlz IHdoZXJlIEVTVCBpcyBzdGFydGVkPyBNaWdodCBiZSBoZWxwZnVsIHRvIGluZGljYXRlIHdoaWNo IHBhcnRzIGFyZSBhbHJlYWR5IGZpeGVkIGJ5IEVTVC4NClRoZSBwaHJhc2U6IOKAnFNpbmNlIGNs aWVudCBhdXRoZW50aWNhdGlvbiBvY2N1cnMgZHVyaW5nIFRMUyBoYW5kc2hha2XigJ0gaXMgY29u ZnVzaW5nLiBJcyB0aGlzIHRoZSBUTFMgaGFuZHNoYWtlIGRpc2N1c3NlZCB1bmRlciAzLjEuMiBv ciBhIG5ldyBvbmU/DQpOZWl0aGVyIGlzIGl0IGNsZWFyIGlmIHRoaXMgaXMgdGhlIHByb3Zpc2lv bmFsIGF1dGhlbnRpY2F0aW9uIG9yIHRoZSBmaW5hbCBvbmUuDQpUaGlzIHNlY3Rpb24gaW4gZ2Vu ZXJhbCBuZWVkcyBtb3JlIGNsYXJpZmljYXRpb24gYW5kIGRlc2NyaXB0aW9uIG9mIHRoZSBmbG93 IG9uIGhvdyByZWRpcmVjdGlvbnMgdG8gYSBkaWZmZXJlbnQgUmVnaXN0cmFyIHdvcmtzLg0KU2Vj dGlvbiAzLjEuNCB3aHkgY2l0ZSB0aGUgbm9uIGF1dG9ub21pYyAoYW5kIG5vbiB1c2VkKSBlbnJv bG1lbnQgcHJvdG9jb2xzPw0KVGhlIGF1ZGl0IHRva2VuIHByb3ZpZGVzIHN1ZmZpY2llbnQgaW5m b3JtYXRpb24gdG8gY29udGludWUsIGJ1dCB0aGUgb3duZXJzaGlwIHZvdWNoZXIgZG9lcyBub3Q/ DQpTZWN0aW9uIDMuMS41LiBXaHkgdGhpcyBsYXN0IHBhcmFncmFwaCBhYm91dCB0aW1lIGRpc3Ry aWJ1dGlvbj8NClNlY3Rpb24gMy4xLjYgbWVudGlvbnMgYXVkaXQgdG9rZW4gYW5kIG93bmVyc2hp cCB2b3VjaGVyOyBidXQgb25seSBkaXNjdXNzZXMgYXVkaXQgdG9rZW4gYWZ0ZXJ3YXJkcyB0byBz dGFydCBSRkM3MDMwIHByb2Nlc3MuDQpTZWN0aW9uIDMuMS43IHNwZWNpZmllcyB0aGUgZmluYWwg cHVycG9zZSBvZiB0aGUga2V5IGRpc3RyaWJ1dGlvbj8gSU1PIHBhcnQgb2YgdGhpcyB0ZXh0IHNo b3VsZCBnbyB0byB0aGUgaW50cm9kdWN0aW9uIHRvIG1vdGl2YXRlIHRoZSBib290c3RyYXBwaW5n IHByb3RvY29sIGFuZCBhbHNvIHNob3cgaXRzIHZhbGlkaXR5IGZvciBjb25zdHJhaW5lZCBkZXZp Y2VzIGFuZCBuZXR3b3Jrcy4NCjMuMiBmYWNpbGl0YXRlcyBjb21tdW5pY2F0aW9uIGJldHdlZW4g Pz8/LiBBY2NvcmRpbmcgdG8gZmlndXJlIDIgdGhlIHJlZ2lzdHJhciBpcyBub3QgbmVjZXNzYXJp bHkgY29uZmlndXJlZCBvbiB0aGUgUHJveHkuDQpXaGF0IGlzIGEgY29udHJvbCBwbGFuZSBDUFU/ IFByb2JhYmx5IHRleHQgaGFzIGdvbmUgbWlzc2luZy4NCk5vdCBjbGVhciBmcm9tIHRoZSB0ZXh0 IGhvdy93aHkgYSBkZXZpY2UgYmVjb21lcyBhIHByb3h5IGFuZCBieSB3aG9tL2hvdyBpdCBpcyBj b25maWd1cmVkIHdpdGggdGhlIHJlbGV2YW50IGluZm9ybWF0aW9uIGxpa2UgdGhlIFJlZ2lzdHJh cuKAmXMgYWRkcmVzcy4NClNlY3Rpb24gMy4yLjEgVGhlIGNob2ljZSBiZXR3ZWVuIERUTFMgYW5k IFRMUyBhcHBlYXJzIGFsbCBvZiB0aGUgc3VkZGVuLg0KQWxsIGZvcm1lciB0ZXh0IGRpc2N1c3Nl ZCBUTFM7IEkgc3VnZ2VzdCB0aGF0IGEgZGlmZmVyZW50IHNlY3Rpb24gaXMgZGVkaWNhdGVkIHRv IHVzZSBvZiBDb0FQLCBkZXNjcmliZXMgdGhlIGh0dHAvVExTIHRvIGNvYXAvZHRscyBtYXBwaW5n LCBhbmQgdGhlIGRyYWZ0IGNvbnNpc3RlbnRseSB1c2VzIFRMUyBmb3IgY2xhcml0eS4gU2VjdGlv biAzLjIuMS4gaXMgdGhlbiBtb3JlIGRlZGljYXRlZCB0byB0aGUgZGlzY292ZXJ5IGFuZCBrZWVw aW5nIHByb3h5IHN0YXRlbGVzcy4NClNlY3Rpb24gMy4yLjIgc3VnZ2VzdHMgbXVsdGlwbGUgb3B0 aW9ucyB0byBwcm94eSB0aGUgY29ubmVjdGlvbiB0byB0aGUgUmVnaXN0cmFyLiBDYW4gb3RoZXIg bWV0aG9kcyBiZSB1c2VkIGJleW9uZCB0aGF0IGFyZSBsaXN0ZWQgaGVyZS4NClNlY3Rpb24gMy4z LjEgc2hvdWxkIHRoZSBvdXQgb2YgYmFuZCBiZSBjaXRlZCBoZXJlPyBUaGUgZHJhZnQgZGVzY3Jp YmVzIGF1dG9ub21pYyBiZWhhdmlvdXIuDQpFbmQgb2Ygc2VjdGlvbiAzLjMuMjsgd2h5IHRoZSBl bXBoYXNpcyBvbiBob21lbmV0Pw0KU2VjdGlvbiAzLjMuMywgMm5kIHBhcmFncmFwaDsgZXhhbXBs ZXMgbWlnaHQgYmUgaGFuZHk/DQpTZWN0aW9uIDMuMy4zIENsYWltcyBmb3IgYW4gdW5hdXRoZW50 aWNhdGVkIFJlZ2lzdHJhciBhcmUgb25seeKApjsgSXMgdGhpcyBhIHZpYWJsZSBhcHByb2FjaD8N ClNlY3Rpb24gMy40IEZhY3RvcnkgcHJvdmlkZXI/DQpTZWN0aW9uIDMuNSBBcyB0aGUgZGV2aWNl cyBoYXZlIGEgY29tbW9uIHRydXN0IGFuY2hvcuKApiBQbGVhc2UgbWFrZSBkZXZpY2VzIG1vcmUg ZXhwbGljaXQuDQpTZWN0aW9uIDMuNS4xLiBkZXZpY2UgLT4gbmV3IGVudGl0eQ0KVGhlIG5ldyBl bnRpdHkgY2FuIHZhbGlkYXRlIHRoZSBkb21haW4gbWVtYmVyc2hpcCBhZnRlciBqb2luaW5nPyBZ b3UgbWVhbiBpdCBjYW4gYWN0IGFzIHByb3h5Pw0KU2VjdGlvbiAzLjYgTmV0d29yayBhY2Nlc3Mg Q29udHJvbD8gV2hlcmUgZG9lcyB0aGlzIHRlcm0gY29tZSBmcm9tPw0KV2hhdCBkb2VzIOKAnGhh dmluZyBzdWZmaWNpZW50IGNvbm5lY3Rpdml0eeKAnSBtZWFuPw0KU2VjdGlvbiA0LjQgWmVyby10 b3VjaCBpcyBhbiB1bmtub3duIHRlcm0uDQpBbHJlYWR5IGVucm9sbGVkIGRldmljZXMgLT4gcHJv eGllcy4NClNlY3Rpb24gNC41IFdoYXQgYXJlIGNlbnRyYWwgY29udHJvbCBmdW5jdGlvbnM/DQpT ZWN0aW9uIDUgcmVwZWF0cyBtdWNoIG9mIGVhcmxpZXIgc2VjdGlvbnMuIEkgc3VnZ2VzdCB0byBy ZW1vdmUgdGV4dCBpbiBlYXJsaWVyIHNlY3Rpb25zIChvciBtYWtlIG1vcmUgYWJzdHJhY3QpIHRv IG1pbmltaXplIGR1cGxpY2F0aW9uLg0KV2hhdCBpcyBhbiDigJxhaXItZ2FwcGVk4oCdIG5ldHdv cms/IFJlZmVycmluZyBpbiB0aGUgdGV4dCB0byBmaWcgNSBhbmQgZmlnDQo2IGFuZCBwb2ludGlu ZyBvdXQgdGhlIGRpZmZlcmVuY2VzIGhlbHBzIHJlYWRhYmlsaXR5Lg0KSGVyZSBteSByZXZpZXcg c3RvcHM7IFRoZSB0ZWNobm9sb2d5IHNlZW1zIGFscmVhZHkgcXVpdGUgc29saWQgaWYgdGhlIHBy b3h5IGJlaGF2aW91ciB3aXRoIElQSVAgZW5jYXBzdWxhdGlvbiBvZiB0aGUgVExTIG1lc3NhZ2Vz IGFyZSBiZXR0ZXIgY2xhcmlmaWVkLiBUaGUgdGV4dCBuZWVkcyBxdWl0ZSBzb21lIGVkaXRpbmcg dG8gcmVtb3ZlIGR1cGxpY2F0aW9uLCBpbXByb3ZlIGNvbnNpc3RlbmN5LCBhbmQgcmVtb3ZlIG1h bnkgb2YgdGhlIGRlc2lnbiBkZWNpc2lvbiBkaXNjdXNzaW9ucy4NCkkgaG9wZSBteSBjb21tZW50 cyBtYXkgaGVscC4NCg0KR3JlZXRpbmdzLA0KDQpQZXRlcg0KDQotLQ0KUGV0ZXIgdmFuIGRlciBT dG9rDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpB bmltYS1ib290c3RyYXAgbWFpbGluZyBsaXN0DQpBbmltYS1ib290c3RyYXBAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWEtYm9vdHN0cmFwDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3Rl ZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3Nl bWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJv aGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5k IGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg== From nobody Mon Aug 29 18:24:06 2016 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4CF12D0C0 for ; Mon, 29 Aug 2016 18:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDkwCYVSpgNK for ; Mon, 29 Aug 2016 18:24:03 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 978CC12B063 for ; Mon, 29 Aug 2016 18:24:03 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id h186so1786550pfg.3 for ; Mon, 29 Aug 2016 18:24:03 -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-transfer-encoding; bh=IrtZn5rqvc+3yEWZxPu8TjuTmMDnyZIVqfLcM0LNv4w=; b=0zxfim6k6TS55QHWs9Zbae6mu0wxq9aijZig2Z0wiFM4wGzoOzzrNfNCOzljmC7mGu X/eCiAJEmUBKDjsyLUrItBjJFqvcp/VXsIH9Wem0xYQhpAaOnFwcOMevKgnpeYlH7yIv 2pYNQmIC/i3N5VL9habqjS2RZ5OLSUWHdAw+YFU35UXoXW4pzGeHh93wnFi5Gf+qNPfY Qhfw48sd0SIGSihkhHjJb73Qq5LSU6s46BLAOkOV8JakCOoZAniIkdGaHxOYfbibB7++ fQ9R+H3Xk/NWxge4XWc60vUvo8z1fJXZAFkFynKL7sr2rYqLmU0xifEa8bgK1G4Bn9OV 1iHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=IrtZn5rqvc+3yEWZxPu8TjuTmMDnyZIVqfLcM0LNv4w=; b=IPSnutDWz8s0ka4/pX8ITKDV+Kr8ymhFlKyxAq/cdWaKEpgImIWy+Cxaic57+QOtvh n7GdtJdovHHrtM1uzLuPdMjmKoRfYqS0abaVO0xN/Hj1PiCVXLSKXTkg1YCH0ZEU4fH3 Sy/bOQiKFvKGI8VhG1W7tAjFuErlJGqvmcNCYi2PTmINySqXpIorVxqrs9WNJuqQ4hln 9EsLFSONpmzaqs518Eo3kU63tWr8L1cd9NLWMeJNqxFE2yUPxkwXC9C2j24OGXBGHj0c HQ9lhnHSaZGRXu1cEWMD/Jh61Xw60gj7HyMWqQFcKLwZzfz8lA1Rn21WpKmNnuA3wk96 uVgQ== X-Gm-Message-State: AE9vXwOFTVCKeWKiZUkXUXcCdkudVGdBZCqr8ZA3EVArarmVONzaq60pxVxqRdzz7Ur3nw== X-Received: by 10.98.149.131 with SMTP id c3mr1693753pfk.73.1472520242983; Mon, 29 Aug 2016 18:24:02 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id uc1sm52046859pac.24.2016.08.29.18.24.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Aug 2016 18:24:02 -0700 (PDT) To: Anima WG References: <47c158b3-92f4-8a36-1bc1-c5c19afdc6b3@gmail.com> <20160801085529.GT21039@cisco.com> <97815aec-a36f-8dda-6798-eb0c1c5eda17@gmail.com> <20160805083457.GH21039@cisco.com> <20160808140326.GA6295@cisco.com> <20160809063909.GZ21039@cisco.com> <9e003de0-8351-650c-dca7-50472a0570ee@gmail.com> <20160810064103.GM21039@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 30 Aug 2016 13:24:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] GRASP issue 51: Flooded objectives X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 01:24:05 -0000 Hi, I'm guessing from the quietness of the list that many people are on vacation, but for now, here is the proposed action on this point: - a change to the Flood message format that adds a TTL field and a locator field (in the same format as in a Discovery Response). Both of them can be null (which means infinity for the TTL). - add a TTL field to the Discovery Response too. This makes the Flood and Discovery Response message formats essentially identical. We'll also add a recommendation that flooded objectives should be repeated at a suitable frequency. Otherwise, there is a problem for new or sleeping nodes. Regards Brian On 12/08/2016 09:15, Brian E Carpenter wrote: > Hi WG, > > This rather long message expands on GRASP issue 51, which is summarised as: > > 51. Should flooded objectives have a time-to-live before they are > deleted from the flood cache? And should they be tagged in the > cache with their source locator? > > This has led to a complicated discussion in the signaling design time (mainly > between me and Toerless) and we would like feedback from the WG before taking > any firm decisions. > > Breaking it down into separate issues: > > 51.1 Should flooded objectives have a time-to-live before they are deleted from > the flood cache? > > Cutting a complex discussion short, it seems that we will surely have use cases > where a time-to-live is needed. It might be infinity, of course, but we might also > want to be sure that a flooded objective vanishes after 30 seconds. To do that, we > need to add a TTL field. > > Q1: Does the WG agree to add a TTL to the Flood message? > > 51.2 We do have at least one use case where more than one source floods the same > objective, and the recipient ASAs need to distinguish the results. > (That use case is when more than one Registrar or Proxy announces its availability > via a flooded objective, so that joining nodes don't need to send an insecure > Discovery message during bootstrap.) So the flood cache needs to record the > source of the flooded objective. > > 51.3 That leads to another complication. Suppose that more than one ASA in a given > node floods the same objective. > > Side issue: I (Brian) had been working on the assumption that only one ASA in > a given node can manage a given objective. "Manage" means being willing to act as > a negotiation responder, a synchronization responder, or as a source of flooding. > But in fact, although there might be a reason for that limitation in a particular > use case, GRASP as a protocol could perfectly well handle several ASAs managing > the same objective. [My prototype implementation cannot really do so, but that's > an implementation choice.] > > Return from side issue: If more than one ASA in the same node floods the same > objective, recording the source (as mentioned under 51.2) is not enough. We would > need to separate multiple instances from the same source node. There is a use > case for this too: if we want to make a soft changeover from version N to version N+1 > of a given ASA, where version N is not switched off until all current sessions > end, but all new sessions will involve version N+1. > > This will not cause any protocol changes for GRASP discovery (which already > returns a locator as a 3-tuple {IP address, protocol, port}. Therefore, > it won't cause any changes for synchronization or negotiation, which are > based on discovery results. > > But it does mean that to distinguish flooded objectives from each other, we will > need to tag them too with a 3-tuple {IP address, protocol, port}. > > Q2: Does the WG agree to add a locator 3-tuple to the Flood message? > > When considering these additions to Flood messages, which add a few bytes > of overhead, please consider that for most use cases, the frequency of > flooding would be quite low. > > Regards > Brian + signaling design team >