From nobody Sun Feb 12 13:58:56 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29C1129B69 for ; Sun, 12 Feb 2017 13:58:55 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18AEpQJa7jQR for ; Sun, 12 Feb 2017 13:58:54 -0800 (PST) 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 08F45129B65 for ; Sun, 12 Feb 2017 13:58:53 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DCDE4E033; Sun, 12 Feb 2017 17:20:09 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 970856381A; Sun, 12 Feb 2017 16:58:49 -0500 (EST) From: Michael Richardson To: Toerless Eckert In-Reply-To: <20170117172824.GB14606@faui40p.informatik.uni-erlangen.de> References: <20170117171732.GA14606@faui40p.informatik.uni-erlangen.de> <20170117172824.GB14606@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: anima-bootstrap Subject: Re: [Anima-bootstrap] Anima bootstrap: discover protocol multicast notes X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 21:58:56 -0000 --=-=-= Content-Type: text/plain Toerless Eckert wrote: > Oh, and just read mDNS RFC and found the place where it prohibits > periodic unsolicited announcements, so added that at the end. > Michael: Would be great if you > can figure out what you see in your network. Worst case we'll have > to ask Stewart... I haven't had time to do this. I wonder if Peter van der Stok can help here? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlig2pkACgkQgItw+93Q 3WUjuwgAjanTy06MmMQqx3sGPnqXpcBw8QvusFLC0io7KRbLrOV0QljRKt6vXk6n OgIDuB9WPrtdIGb2l/vpCAL6CxcGMjqJS9gmGLQrWm+zIHoUWoW0cqVDqu/BnzXa GSAZyWU5YY09Qydi7hmzcFDp3BEfmIop5xmlgf90Ds+cjcHL/EsWgu3IdgaHy1Z2 32pPccpAaahG98fzwZWVnRTTmzJSwexx/xCkS8pWhJ8rPB3BtqqEe/k/1d043RQq VXVBnxLcjYDh5nDmNi2kz3pqgX17UkHmORUMDlmrub4CyBVO8N2Rflew1PGTI9mv jaBQ0cnNfeKrn3hjPWB2Ot3TEVrGog== =WX6t -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Feb 12 14:02:53 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8975F128824 for ; Sun, 12 Feb 2017 14:02:51 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y929O2rzzgXC for ; Sun, 12 Feb 2017 14:02:50 -0800 (PST) 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 4E0D51279EB for ; Sun, 12 Feb 2017 14:02:50 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B5308E033; Sun, 12 Feb 2017 17:24:09 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 81AB76381A; Sun, 12 Feb 2017 17:02:49 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-Reply-To: References: <20170117171732.GA14606@faui40p.informatik.uni-erlangen.de> <20170117172824.GB14606@faui40p.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: anima-bootstrap@ietf.org Subject: Re: [Anima-bootstrap] Anima bootstrap: discover protocol multicast notes X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 22:02:51 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> This information is typically ignored in existing network protocol >> stacks >> and is also typically unavailable on the socket-API. This IMHO makes >> it highly beneficial to >> use a very lightweight protocol (like the subset of GRASP dedicate to >> this) that can specifically >> be implemented to do this security check. > Presumably you have to use a raw socket. I don't see any other way to get the > destination address out of the packet. With recvmsg(), you can can as for IPV6_RECVPKTINFO in the auxiliary messages in IPV6_PKTINFO. You get the destination IPv6 address as well as the ifindex. (ifindex is pretty essential if you are receiving multicast messages) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlig24kACgkQgItw+93Q 3WWcWQf+IM1wO5cIIDz+qSti4SF59nG7kqFeJnCVRKJljeLfGzi1YVP+RALdeCMW 3RSzJ3yqxLnnMm45hZzyfrgWsfqTsU0I6hNHC8ZD7hnS2T9DWG77Sl+BVe8yr3L6 CVv5Gqg3Se8/WiQkXJWT+tB67Sy6yE919py1x7w1LY4tBLckjjsnMz+Uuf22Ek/l tU0Xi0YckDBKOw33bU24Y1qT+pHOh10iIV+xT5bR5jN4MQSr8uUrNm5KJFizejsM SwaA7m5/lx+sQsvAmCMaI9HNdu/oYrGxhNnjnFIVa0VZht7uEVuf9apFyaEqyjba 6tRcXxZ0Kd4Og3/hnRqy/RmzTFZpGw== =6Sqp -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Feb 12 14:20:54 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3691D126BF6 for ; Sun, 12 Feb 2017 14:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 LfxWpKk_r4KZ for ; Sun, 12 Feb 2017 14:20:49 -0800 (PST) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 B4B0C128BA2 for ; Sun, 12 Feb 2017 14:20:49 -0800 (PST) Received: by mail-pg0-x243.google.com with SMTP id 75so7928444pgf.3 for ; Sun, 12 Feb 2017 14:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=kyBVQR0gzRLtrYNzQO8IfnQcaMIyY4SYXAtIfvyuDFs=; b=R60WfGganCJK2kYwVWIfKjZpHVrfE7/2o4exoFjmzzphJtQ/xUQkyX3OOjP2+9o+lL UjwsuBBjHmhFsWjEG2ICjH6qNreg0xG0iv8Q1oy5BPv4LPKHkIlq+AXvaQ6DZrfUlgaP 7HPBC8eyKeVXfeX68+G3WeXQTmFkY9JL5nvquZ6cMeEaDXk3B8/MOSOWu2QyO4vWYk0c F+dUq1PBjR7Py/rp9MMNJWxWvZmhbtmlW2ug5dkhzWyEaFyUDEkszbyyFmF54wVXS50I Sd+yYE9ATjAIVjteVnl23VcAiRsLbkmpTxeoRSW9pC8h1QrTxMSWYkN7Ft4BHVFSfOjV tydw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=kyBVQR0gzRLtrYNzQO8IfnQcaMIyY4SYXAtIfvyuDFs=; b=rLjF0b2C+wu1Yd1vq7q/pc0SX7CfuaK3vBR1xDjHi4GGEgnKPpi22aAwAZmyaSwEgz AWadS7HCB20P1/wtXNfV1JBNbNpOq0PBZQiJSJ0uKTlC25hhWcZWUwzjEEOEbD8LFF8U JmHjAAazkjAgz2eMu2s7EcCP78j/Mn1eHTDL3VLQDoY7aE4RrQfWpN3UR22cqttIywKF LSRlH38eQlStOjvQqTtDVMYHlI5cdMzOcyZzo7UUWbbg0h6FvKHaJtRQW+0yNNuHbG0R xdKOK8Tim0YnjHjg1u/3qkEXxuEtqwa6hvJ1SYFWJly8/f0Fy9WqxqdNU5qVIttxBbGn NcFA== X-Gm-Message-State: AMke39kNS6wCYFthLoXyF5COM4u8HeA+wV57mv4rpaysWRXSdhhJrhFGRTNP1l6+Gn+eUA== X-Received: by 10.84.233.136 with SMTP id l8mr25899508plk.169.1486938049036; Sun, 12 Feb 2017 14:20:49 -0800 (PST) Received: from ?IPv6:2406:e007:6e60:1:28cc:dc4c:9703:6781? ([2406:e007:6e60:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id w16sm16753719pgc.15.2017.02.12.14.20.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Feb 2017 14:20:48 -0800 (PST) To: Michael Richardson References: <20170117171732.GA14606@faui40p.informatik.uni-erlangen.de> <20170117172824.GB14606@faui40p.informatik.uni-erlangen.de> <12728.1486936969@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Mon, 13 Feb 2017 11:20:44 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <12728.1486936969@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: anima-bootstrap@ietf.org Subject: Re: [Anima-bootstrap] Anima bootstrap: discover protocol multicast notes X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 22:20:52 -0000 On 13/02/2017 11:02, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> This information is typically ignored in existing network protocol > >> stacks > >> and is also typically unavailable on the socket-API. This IMHO makes > >> it highly beneficial to > >> use a very lightweight protocol (like the subset of GRASP dedicate to > >> this) that can specifically > >> be implemented to do this security check. > > > Presumably you have to use a raw socket. I don't see any other way to get the > > destination address out of the packet. > > With recvmsg(), you can can as for IPV6_RECVPKTINFO in the auxiliary > messages in IPV6_PKTINFO. You get the destination IPv6 address as well as > the ifindex. (ifindex is pretty essential if you are receiving multicast messages) Yes, for multicast I now see that I do pick up the destination address and ifindex from recvfrom(). I haven't needed to look at that code for many months. For TCP I seem to pick it up from accept(). Brian From nobody Mon Feb 13 00:56:57 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8271293DF for ; Mon, 13 Feb 2017 00:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 pPHtGw73GkXp for ; Mon, 13 Feb 2017 00:56:54 -0800 (PST) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D363712950C for ; Mon, 13 Feb 2017 00:56:53 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:215]) by smtp-cloud6.xs4all.net with ESMTP id k8wo1u00U13if52018woKN; Mon, 13 Feb 2017 09:56:49 +0100 Received: from AMontpellier-654-1-241-185.w92-133.abo.wanadoo.fr ([92.133.12.185]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 13 Feb 2017 09:56:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 13 Feb 2017 09:56:48 +0100 From: peter van der Stok To: Michael Richardson Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <11820.1486936729@obiwan.sandelman.ca> References: <20170117171732.GA14606@faui40p.informatik.uni-erlangen.de> <20170117172824.GB14606@faui40p.informatik.uni-erlangen.de> <11820.1486936729@obiwan.sandelman.ca> Message-ID: <8a8567bb1b9993c077d84abf4bfc82f3@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Cc: anima-bootstrap , Toerless Eckert Subject: Re: [Anima-bootstrap] Anima bootstrap: discover protocol multicast notes X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 08:56:56 -0000 Hi all, We just did our own mDNS (students did years ago) and have no experience with existing code. What was the precise question? Peter Michael Richardson schreef op 2017-02-12 22:58: > Toerless Eckert wrote: > > > Oh, and just read mDNS RFC and found the place where it prohibits > > periodic unsolicited announcements, so added that at the end. > > > Michael: Would be great if you > > can figure out what you see in your network. Worst case we'll > have > > to ask Stewart... > > I haven't had time to do this. > I wonder if Peter van der Stok can help here? > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > Anima-bootstrap mailing list > Anima-bootstrap@ietf.org > https://www.ietf.org/mailman/listinfo/anima-bootstrap From nobody Mon Feb 13 08:26:28 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7972212952C; Mon, 13 Feb 2017 08:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 UQB_938jp82p; Mon, 13 Feb 2017 08:26:24 -0800 (PST) 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 6D46C129441; Mon, 13 Feb 2017 08:26:24 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2ED4A200A3; Mon, 13 Feb 2017 11:47:46 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5BB7E6381A; Mon, 13 Feb 2017 11:26:23 -0500 (EST) From: Michael Richardson To: Hannes Tschofenig In-Reply-To: <16c236b7-dd80-1e27-8de9-16f05558d38e@gmx.net> References: <16c236b7-dd80-1e27-8de9-16f05558d38e@gmx.net> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: anima-bootstrap , saag Subject: Re: [Anima-bootstrap] [saag] BOFs about IoT firmware update and TEE configuration X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 16:26:26 -0000 Hannes Tschofenig wrote: > ** =E2=80=9CFirmware Update Description (FUD)=E2=80=9D > Last year we had a workshop organized by the IAB on firmware updates = for > IoT devices (see https://www.iab.org/activities/workshops/iotsu/) whe= re > we talked about various challenges and gaps. > As a follow-up to the workshop we would like to initiate some > standardization activity in this area. > The mailing list can be found at > https://www.ietf.org/mailman/listinfo/fud It's a terrible TLA. Too good not to keep. > ** =E2=80=9CA Protocol for Dynamic Trusted Execution Environment Enab= lement (TEEP)=E2=80=9D > This BOF is about an application layer security protocol that allows = to > configure security credentials and software running on a Trusted > Execution Environment (TEE). Today, TEEs are, for example, found home > routers, set-top boxes, smart phones, tablets, wearables, etc. > Unfortunately, there have been mostly proprietary protocols used in t= his > environment. > With this BOF we are making an attempt to standardize such a protocol= . A > strawman proposal of such a protocol has been published with > https://tools.ietf.org/html/draft-pei-opentrustprotocol-03. > The mailing list can be found at: > https://www.ietf.org/mailman/listinfo/teep okay. We (ANIMA bootstrap DT) need BOF time to talk about what we are doing, and = how we leverage TPMs. This is additional existing work. -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Tue Feb 14 10:13:14 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0AB1296DC for ; Tue, 14 Feb 2017 10:13:13 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIG0CxvPIGFq for ; Tue, 14 Feb 2017 10:13:11 -0800 (PST) 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 96F601296DE for ; Tue, 14 Feb 2017 10:13:11 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F3E07200A3; Tue, 14 Feb 2017 13:34:33 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5855C6381A; Tue, 14 Feb 2017 13:13:07 -0500 (EST) From: Michael Richardson To: anima-bootstrap In-Reply-To: <8a8567bb1b9993c077d84abf4bfc82f3@xs4all.nl> References: <20170117171732.GA14606@faui40p.informatik.uni-erlangen.de> <20170117172824.GB14606@faui40p.informatik.uni-erlangen.de> <11820.1486936729@obiwan.sandelman.ca> <8a8567bb1b9993c077d84abf4bfc82f3@xs4all.nl> 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: Toerless Eckert , consultancy@vanderstok.org Subject: [Anima-bootstrap] M_FLOOD and mDNS (was Re: Anima bootstrap: discover protocol multicast notes) X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: anima-bootstrap@ietf.org List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 18:13:13 -0000 --=-=-= Content-Type: text/plain peter van der Stok wrote: > We just did our own mDNS (students did years ago) and have no > experience with > existing code. > What was the precise question? It's a good question. What *IS* the question :-) We have had the discussion about use of GRASP M_FLOOD vs mDNS for discovery of the Join Proxy by the pledge. We have had some indirect feedback ("heresay") from implementers to the effect thta the M_FLOOD stuff "is IETF ivory tower nonsense, and we should stop inventing new vanity protocols." (paraphrased, and unattributed. Sorry Brian: not my words, and I'm relaying them third or fourth-hand, and I sure wish that said people would communicate directly, but I think corporate reporting structures get in the way of some of that) There are some esthetic reasons to prefer use of M_FLOOD. This has to do with ANIMA being a self-contained system. There is also a claim that mDNS is already present in many small devices. RFC6763 even says that some ethernet chips can autonomously answer mDNS queries when the device in question is in low-power mode! But there are some real technical claims about why mDNS does not suit: The specific claim is that we can't do unsolicited announcements using mDNS. https://tools.ietf.org/html/rfc6762#section-8, section 8.2 says: A Multicast DNS responder MUST NOT send announcements in the absence of information that its network connectivity may have changed in some relevant way. In particular, a Multicast DNS responder MUST NOT send regular periodic announcements as a matter of course. The rfc6763 DNS-SD process makes it pretty clear that discovery involves a query and a reply, and that responses may be multicast such that they are easily cached. 6762 says a lot about TTL and how often things are cached. I myself do not quite understand the entire interaction. I observe that on networks I am part of that, my mDNS daemon (avahi), always has a list of seldom (even never!) used services in it's cache. For instance: knothole-[~](2.1.5) mcr 10002 %avahi-browse -vat | wc -l 174 knothole-[~](2.1.5) mcr 10003 %avahi-browse -vat | grep -i Mumble + credil IPv6 lapeche Mumble Server local + credil IPv4 lapeche Mumble Server local I'm sure that NOBODY has ever asked the network if there was a Mumble server around. Clearly, when it first started, it had a reason to announce itself, but that value should have a TTL that after the several hundred days of uptime for the "lapeche" machine must have expired. So I'm unclear how reconcile what I read in the specifications ("MUST NOT send regular priodic announcements") with what I see in practice. It might be that in the end we don't care about the anonimity of the pledge. If the pledge can ask the network about Join Proxy, then there is nothing to stop us from using mDNS here. On the other hand, M_FLOOD is as certainly useable, and is rather simple. I had very little problem implementing it myself. I also think that every Join Proxy is also an ACP node, and so it will want to M_FLOOD about it's ACPness, and so I see little downside here. I do not have horse in this race: I just don't want to be ignored by developers... who granted, have not come to this conversation. (I hear lots of anti-IETF rhetoric from Linux kernel developers, most of whom have never posted any question to an IETF list, ever!) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlijSLIACgkQgItw+93Q 3WWDnAf/ZcKh3bZhOe+lBYOLZ9KRbLgBOd96tTR3xTdG0ALenLAYAehhBqaGMWaa N7biCL/dCeBYVQCpkF/+iowWCH74GGmL8ZuV7/oKts1nwWkM7ccMc+q2lHl8S1aM 4sJf0gKp3sxhlQv48OJNGh5oo7WgMZhjFRHiSRp8O1pdFVvOXcJ5H1bZz02zqxTh pdZ5uUBq3wNf7pp2sQFm6p8LQ7rkLNuh1xSmspbagVJ0GzUlzXAszqjgTNteTu6K MD0Zt2NAziFzp9PsTvDfjMoCydRP/DJdtktle0sQ2OMBA1xP0xXXZzAB93SVRc2L Ja3lc4ZMy3x/tWAQtFJLVR+WJP3Qww== =pzOf -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 14 11:40:37 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1E8129717 for ; Tue, 14 Feb 2017 11:40:35 -0800 (PST) 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 gHLhcI2uxKIL for ; Tue, 14 Feb 2017 11:40:33 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 08257129420 for ; Tue, 14 Feb 2017 11:40:33 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id k200so20245243itb.1 for ; Tue, 14 Feb 2017 11:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Oc9BPaM/s4EpRs+VzdUdj9HX6g0rQlRJoJbXtQdikx4=; b=Dx4MMGbFHJKV1eBfjOpSAJu9gvEHBPHAVGVvcDKxfLKUzPsceK7L33+sHfSRt3tSGn gVf4uoHrL6wspO2hQVfTDq/YuB3US0QyhNlkQJlXnazw2+uyuXOxEghwb600b9XiNbJE IVN4gDKViFUIGeliyq3XZ/N1LbNmdvkcttSiYL9twySDSVbo3l93q776kCRrKs1rl5D0 Opr3E3je15gFZ5/pgktCPY+VVCZeYCDu/KWQL5f2z70TH3ir15mViMStFPkO0A0rZCzY zRdCgzDzbxMhjcjix3OS9YNtmRW6jdx+36HPvOR+bq2W2i1noVZ7GdVvSJCgd++aVEOJ vtKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=Oc9BPaM/s4EpRs+VzdUdj9HX6g0rQlRJoJbXtQdikx4=; b=AB7a6eaToYu9Hp5pgaDpxc8Mew0TChp5cePYSmOgLN8JLwleRzrIeH/egG3Er3qB8v lf/9jnViS5zDrvtej+7Whfa6/IhyABhDGSekJKG5SPTefbFE97AWI4eR9hpUgAAe1v+8 ZNMTbPWyedoJ6I5W2PdX2TwC3frTYUHMryzf0D5GMjtmXzueioPNzEAIzwHKmIJ1IcHz G9jT1BXqvTt+TCMkzeFXu7p64o8t5p7GE+6w9QMGWK8bhTqa3hCsETWs6P5imGTkd3a2 dF0PfSMjVcpHzKUz6YkhSsZSLEbETEOeDfs6zecpFjxpjWqgH6bH/QSbI7M5kPO9g0OA TuJQ== X-Gm-Message-State: AMke39lfaQDJpYaDO0m/TcHx2BOUHKOxSIim/GdhXfDHJk6H9FqkdEIQhrOUa/EP6cweXg== X-Received: by 10.99.97.196 with SMTP id v187mr22359329pgb.175.1487101232206; Tue, 14 Feb 2017 11:40:32 -0800 (PST) Received: from [192.168.178.21] ([118.148.78.74]) by smtp.gmail.com with ESMTPSA id t15sm2837648pgn.18.2017.02.14.11.40.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Feb 2017 11:40:31 -0800 (PST) To: anima-bootstrap@ietf.org References: <20170117171732.GA14606@faui40p.informatik.uni-erlangen.de> <20170117172824.GB14606@faui40p.informatik.uni-erlangen.de> <11820.1486936729@obiwan.sandelman.ca> <8a8567bb1b9993c077d84abf4bfc82f3@xs4all.nl> <18113.1487095987@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <9e98b251-e66f-a898-2548-962c07d3a380@gmail.com> Date: Wed, 15 Feb 2017 08:40:32 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <18113.1487095987@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Toerless Eckert , consultancy@vanderstok.org Subject: Re: [Anima-bootstrap] M_FLOOD and mDNS (was Re: Anima bootstrap: discover protocol multicast notes) X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 19:40:35 -0000 On 15/02/2017 07:13, Michael Richardson wrote: > > peter van der Stok wrote: > > We just did our own mDNS (students did years ago) and have no > > experience with > > existing code. > > What was the precise question? > > It's a good question. What *IS* the question :-) > > We have had the discussion about use of GRASP M_FLOOD vs mDNS for discovery > of the Join Proxy by the pledge. We have had some indirect feedback > ("heresay") from implementers to the effect thta the M_FLOOD stuff > "is IETF ivory tower nonsense, and we should stop inventing new vanity > protocols." > > (paraphrased, and unattributed. Sorry Brian: not my words, and I'm relaying > them third or fourth-hand, and I sure wish that said people would communicate > directly, but I think corporate reporting structures get in the way of some > of that) Can't hear them due to fingers stuck in ears :-) Seriously - why do you think I invested considerable personal time in a prototype? Because I was afraid that we were designing something unrealistic. But we're not, and I've never found a way that mDNS or DNS-SD could do what we want. > There are some esthetic reasons to prefer use of M_FLOOD. This has to do with > ANIMA being a self-contained system. > > There is also a claim that mDNS is already present in many small > devices. RFC6763 even says that some ethernet chips can autonomously answer > mDNS queries when the device in question is in low-power mode! > > But there are some real technical claims about why mDNS does not suit: > > The specific claim is that we can't do unsolicited announcements using > mDNS. https://tools.ietf.org/html/rfc6762#section-8, section 8.2 says: > > A Multicast DNS responder MUST NOT send announcements in the absence > of information that its network connectivity may have changed in some > relevant way. In particular, a Multicast DNS responder MUST NOT send > regular periodic announcements as a matter of course. > > The rfc6763 DNS-SD process makes it pretty clear that discovery involves a > query and a reply, and that responses may be multicast such that they are > easily cached. 6762 says a lot about TTL and how often things are cached. > > I myself do not quite understand the entire interaction. I observe that > on networks I am part of that, my mDNS daemon (avahi), always has a list of > seldom (even never!) used services in it's cache. Yes, the GRASP model will cache too of course, but non-relay nodes will only cache (a) what they discovered personally and (b) whatever was flooded. They will not cache the results of 3rd party discoveries. Anyway, the GRASP model doesn't just support services. Objectives aren't services, although they could represent services. And once again: outside the ACP, there is no need to force GRASP into every pledge. I would expect COAP or mDNS to be the way a non-autonomic pledge finds its nearest proxy. > > For instance: > knothole-[~](2.1.5) mcr 10002 %avahi-browse -vat | wc -l > 174 > > knothole-[~](2.1.5) mcr 10003 %avahi-browse -vat | grep -i Mumble > + credil IPv6 lapeche Mumble Server local > + credil IPv4 lapeche Mumble Server local > > I'm sure that NOBODY has ever asked the network if there was a Mumble > server around. Clearly, when it first started, it had a reason to announce > itself, but that value should have a TTL that after the several hundred days > of uptime for the "lapeche" machine must have expired. So I'm unclear how > reconcile what I read in the specifications ("MUST NOT send regular priodic > announcements") with what I see in practice. > > > It might be that in the end we don't care about the anonimity of the pledge. > If the pledge can ask the network about Join Proxy, then there is nothing > to stop us from using mDNS here. > > On the other hand, M_FLOOD is as certainly useable, and is rather simple. > I had very little problem implementing it myself. Got any code I could run (on Linux)? At least I could check if my GRASP can receive those floods correctly. No need to wait for Chicago. > I also think that every > Join Proxy is also an ACP node, and so it will want to M_FLOOD about it's > ACPness, and so I see little downside here. > > I do not have horse in this race: I just don't want to be ignored by > developers... who granted, have not come to this conversation. Running code is the best answer to that. > (I hear lots of anti-IETF rhetoric from Linux kernel developers, most of whom > have never posted any question to an IETF list, ever!) Want to hear some anti-Linux-kernel-developer rhetoric? :-) But actually, do we care? We don't need anything new in the kernel to make GRASP/ACP work, I don't think. And do we need anything for BRSKI? Brian From nobody Tue Feb 14 14:32:11 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A4A129956 for ; Tue, 14 Feb 2017 14:32:09 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKIUsBozudhU for ; Tue, 14 Feb 2017 14:32:08 -0800 (PST) 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 BB52812995C for ; Tue, 14 Feb 2017 14:32:07 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7AD72200A3; Tue, 14 Feb 2017 17:53:33 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 550626381A; Tue, 14 Feb 2017 17:32:06 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <9e98b251-e66f-a898-2548-962c07d3a380@gmail.com> References: <20170117171732.GA14606@faui40p.informatik.uni-erlangen.de> <20170117172824.GB14606@faui40p.informatik.uni-erlangen.de> <11820.1486936729@obiwan.sandelman.ca> <8a8567bb1b9993c077d84abf4bfc82f3@xs4all.nl> <18113.1487095987@obiwan.sandelman.ca> <9e98b251-e66f-a898-2548-962c07d3a380@gmail.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-bootstrap@ietf.org, Toerless Eckert , consultancy@vanderstok.org Subject: Re: [Anima-bootstrap] M_FLOOD and mDNS (was Re: Anima bootstrap: discover protocol multicast notes) X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 22:32:10 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> On the other hand, M_FLOOD is as certainly useable, and is rather >> simple. I had very little problem implementing it myself. > Got any code I could run (on Linux)? At least I could check if my GRASP > can receive those floods correctly. No need to wait for Chicago. Actually, I lied. I have M_DISCOVERY/M_RESPONSE code in C and Ruby, but it's supposed to be replaced with M_FLOOD. I will point to it as soon as possible. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlijhWYACgkQgItw+93Q 3WWAuAf+IQRgTuusrqgC3Ob6plQnBDe666dmUUwpWoDBYueyn0JXDQ9QLKgdM+Hx VN8rYfC+uiQ77qWp5oEmphIJInwKiWwD1PpUwFoZshdHzOZa5XIL2aX5gU/1p5h1 1x8QFXNI+2xTSkZmk7gUV1PjGIeMmHlE9cJYdvXc6jXKHcb8tAM64ULVMU7+v2kB P4y9clb4KLEZY3esgTa7zJrvaJXv42ExFkcV2KsaibFL87y615jhiE7IhxAb8V93 R4/cByRp6TNcWd95DC6kSYmsWiNB88jRH5EkbbImgWrVhQSfzkRW+DEvSQaEiX4P Qy3dsdKLqKE+L/AhxlaVXEyEkKBBLA== =od1A -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 15 01:06:24 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A1A1294CD for ; Wed, 15 Feb 2017 01:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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, URIBL_BLOCKED=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 6TtxKHzGbPMI for ; Wed, 15 Feb 2017 01:06:20 -0800 (PST) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D347128B38 for ; Wed, 15 Feb 2017 01:06:17 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:215]) by smtp-cloud2.xs4all.net with ESMTP id kx671u00K13if5201x68sd; Wed, 15 Feb 2017 10:06:13 +0100 Received: from AMontpellier-654-1-69-96.w90-0.abo.wanadoo.fr ([90.0.44.96]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 15 Feb 2017 10:06:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 15 Feb 2017 10:06:07 +0100 From: peter van der Stok To: anima-bootstrap@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <18113.1487095987@obiwan.sandelman.ca> References: <20170117171732.GA14606@faui40p.informatik.uni-erlangen.de> <20170117172824.GB14606@faui40p.informatik.uni-erlangen.de> <11820.1486936729@obiwan.sandelman.ca> <8a8567bb1b9993c077d84abf4bfc82f3@xs4all.nl> <18113.1487095987@obiwan.sandelman.ca> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Cc: Michael Richardson , Toerless Eckert , consultancy@vanderstok.org Subject: Re: [Anima-bootstrap] M_FLOOD and mDNS (was Re: Anima bootstrap: discover protocol multicast notes) X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 09:06:22 -0000 Hi Michael, I saw Brian's response. Just a four additional remarks by me, just to show my point of view. See below. Michael Richardson schreef op 2017-02-14 19:13: > peter van der Stok wrote: > > We just did our own mDNS (students did years ago) and have no > > experience with > > existing code. > > What was the precise question? > > It's a good question. What *IS* the question :-) > > We have had the discussion about use of GRASP M_FLOOD vs mDNS for > discovery > of the Join Proxy by the pledge. We have had some indirect feedback > ("heresay") from implementers to the effect thta the M_FLOOD stuff > "is IETF ivory tower nonsense, and we should stop inventing new vanity > protocols." > > (paraphrased, and unattributed. Sorry Brian: not my words, and I'm > relaying > them third or fourth-hand, and I sure wish that said people would > communicate > directly, but I think corporate reporting structures get in the way of > some > of that) > > There are some esthetic reasons to prefer use of M_FLOOD. This has to > do with > ANIMA being a self-contained system. > > There is also a claim that mDNS is already present in many small > devices. RFC6763 even says that some ethernet chips can autonomously > answer > mDNS queries when the device in question is in low-power mode! As said before, discovery is a "popular" subject with everybody coming up with its preferred solution. I can imagine that within the anima context specific discovery functions are wanted or omitted;I have no opinion. However, the bootstrapping process is an interesting one and deserves attention outside anima. For those other operational environments, different discovery functions may be used. I like to point out mDNS due to its long-standing existence. If bootstrapping is taken over by other SDOs, I expect them to often choose something different from GRASP or mDNS. (fact of life). > > But there are some real technical claims about why mDNS does not suit: > > The specific claim is that we can't do unsolicited announcements using > mDNS. https://tools.ietf.org/html/rfc6762#section-8, section 8.2 says: > > A Multicast DNS responder MUST NOT send announcements in the absence > of information that its network connectivity may have changed in > some > relevant way. In particular, a Multicast DNS responder MUST NOT > send > regular periodic announcements as a matter of course. The beginning of section 8 says: " Whenever a Multicast DNS responder starts up, wakes up from sleep, receives an indication of a network interface "Link Change" event, or has any other reason to believe that its network connectivity may have changed in some relevant way, it MUST perform the two startup steps below: Probing (Section 8.1) and Announcing (Section 8.3). " Much of the text of rfc6762 is about suppressing superfluous traffic. The method relies on repetitive querying and reactive responding, with a response at responder re-activation (see above). There is a lot of operational experience here, and deserves attention. > > The rfc6763 DNS-SD process makes it pretty clear that discovery > involves a > query and a reply, and that responses may be multicast such that they > are > easily cached. 6762 says a lot about TTL and how often things are > cached. > > I myself do not quite understand the entire interaction. I observe > that > on networks I am part of that, my mDNS daemon (avahi), always has a > list of > seldom (even never!) used services in it's cache. > > For instance: > knothole-[~](2.1.5) mcr 10002 %avahi-browse -vat | wc -l > 174 > > knothole-[~](2.1.5) mcr 10003 %avahi-browse -vat | grep -i Mumble > + credil IPv6 lapeche Mumble Server local > + credil IPv4 lapeche Mumble Server local > > I'm sure that NOBODY has ever asked the network if there was a Mumble > server around. Clearly, when it first started, it had a reason to > announce > itself, but that value should have a TTL that after the several hundred > days > of uptime for the "lapeche" machine must have expired. So I'm unclear > how > reconcile what I read in the specifications ("MUST NOT send regular > priodic > announcements") with what I see in practice. > > > It might be that in the end we don't care about the anonimity of the > pledge. Did we? IMO, almost impossible in an unsecured bootstrapping network. Once keys are distributed, pledge looses it identity and starts afresh (I reckoned) > If the pledge can ask the network about Join Proxy, then there is > nothing > to stop us from using mDNS here. Or anything else dependent on the operational environment of the SDO using the bootstrapping protocol. > > On the other hand, M_FLOOD is as certainly useable, and is rather > simple. > I had very little problem implementing it myself. I also think that > every > Join Proxy is also an ACP node, and so it will want to M_FLOOD about > it's > ACPness, and so I see little downside here. > > I do not have horse in this race: I just don't want to be ignored by > developers... who granted, have not come to this conversation. > > (I hear lots of anti-IETF rhetoric from Linux kernel developers, most > of whom > have never posted any question to an IETF list, ever!) > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > Anima-bootstrap mailing list > Anima-bootstrap@ietf.org > https://www.ietf.org/mailman/listinfo/anima-bootstrap From nobody Wed Feb 15 08:04:44 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9BD126579 for ; Wed, 15 Feb 2017 08:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 T9flireS_OZd for ; Wed, 15 Feb 2017 08:04:41 -0800 (PST) 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 A59F61294B9 for ; Wed, 15 Feb 2017 07:59:35 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 46F46E1D4; Wed, 15 Feb 2017 11:21:04 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 964506381A; Wed, 15 Feb 2017 10:59:34 -0500 (EST) From: Michael Richardson To: consultancy@vanderstok.org In-Reply-To: References: <20170117171732.GA14606@faui40p.informatik.uni-erlangen.de> <20170117172824.GB14606@faui40p.informatik.uni-erlangen.de> <11820.1486936729@obiwan.sandelman.ca> <8a8567bb1b9993c077d84abf4bfc82f3@xs4all.nl> <18113.1487095987@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: anima-bootstrap@ietf.org, Toerless Eckert Subject: Re: [Anima-bootstrap] M_FLOOD and mDNS (was Re: Anima bootstrap: discover protocol multicast notes) X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 16:04:42 -0000 --=-=-= Content-Type: text/plain peter van der Stok wrote: > discovery functions may be used. I like to point out mDNS due to its > long-standing existence. okay. I also prefer not to re-invent everything. > The beginning of section 8 says: " Whenever a Multicast DNS > responder starts up, wakes up from sleep, receives an indication of a > network interface "Link Change" event, or has any other reason to > believe that its network connectivity may have changed in some > relevant way, it MUST perform the two startup steps below: Probing > (Section 8.1) and Announcing (Section 8.3). " Much of the text of Yes, that's the case on the first interval. Once it's none that, it's not supposed to be proactively announce itself again, from what I understand. It's a service, so it doesn't to defend it's name. > rfc6762 is about suppressing superfluous traffic. The method relies > on repetitive querying and reactive responding, with a response at > responder re-activation (see above). There is a lot of operational > experience here, and deserves attention. Okay, but would this be a valid implementation: unsigned char stuff[]={ 0x01,0x02, /* encoded DNS-SD reply */ while(true) { sleep(60); sendmsg(stuff, multicast-address, port-5353); } ? >> It might be that in the end we don't care about the anonimity of the >> pledge. > Did we? IMO, almost impossible in an unsecured bootstrapping > network. Once keys are distributed, pledge looses it identity and > starts afresh (I reckoned) Okay, *DO YOU* care about anonimity of the pledge? Do *YOU* care if the pledge must solicit a Join Proxy by multicasting a query? >> If the pledge can ask the network about Join Proxy, then there is >> nothing to stop us from using mDNS here. > Or anything else dependent on the operational environment of > the SDO using the bootstrapping protocol. Agreed. What would you like to chose here? Tell us your opinion. Don't be shy. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlikeuYACgkQgItw+93Q 3WUeNwf6A+3+m1UlDNaX5O4mzwDeTfb/frTCMYwknmL5WHGQtJuh5ReNXfvD8u6a 4maEcZgGW5lScNaWBRnhYhRasxqKDG8XKgPWIPPZKjeTxCKdsuj0PnrneVOfpuJm n+44xgc4Mt8sxKvCmHmqs0PvDXxrPYqhO1cjKqtsFNV1xF1lQGEI3h2ybljogMLT 5nm6XF1R4bR4B9mepgHnAsSP+jEH/8sVkPTxbpPTabhCGP1z0Iy1onleWLgPHcr+ mbCAlrVjQKGKX2G3dLAUIch8Sjovwc98LUMLMLuUggc1pKRgkL2tJTlyIDMtOUqE BGN7mbQHiDeCKfnXDEecpPIp0kQSMw== =dNh1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 15 16:57:03 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF39129C22 for ; Wed, 15 Feb 2017 16:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 oPWVkxw42ps1 for ; Wed, 15 Feb 2017 16:57:01 -0800 (PST) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::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 E6ABF129C1E for ; Wed, 15 Feb 2017 16:57:00 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id t188so1012629pgt.2 for ; Wed, 15 Feb 2017 16:57:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=DzniEHXywrLa7iBmdijy7n45O3XjwMZJihbm396n5mQ=; b=Z7oTwwTptJeW7nt+4lvcCpax/yfe8C6ZjP29L0/NDVx8YKEUofHGefYa+dWGj9ohOL Qrt/b8xVV1/jWWZKadIhS3Gj0tvw3NBxf1ChkTZNp4c99GLwnw68rhzIcxhqUyOdqTD9 RiRYQKE4w0AJL/Oqs9M9+HKfUMA9oaWziHg6ATsePytzN6Kdt3Oj6xzQULhj5jAu8ocY pylB3uIbJ7RA8e7ACR7IcN8X+dWo5tI4jvAxyY9zVHBA0WsruNELVnHWdftdpVLSWuM3 9LYPYIySkjfOlp/2pOKqT9Rc3F+BzgNDsfscarEaEsm06Cnyj0YkYdo1KAUKM8U9xXek J8Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=DzniEHXywrLa7iBmdijy7n45O3XjwMZJihbm396n5mQ=; b=aWsz8gift9KPCkfduiVZ3a1N5H1pdgTrTnJLkZKLvSz6Yjp6dIa3xj1rtEd8XyFVrU G0P77FrIO9f37SEai6JkYhHcp1XGQnbOpfBe8AJ56EnWTXNcLHcavzdkQ8P1QqJbIzAf K/5fBQY2WIWKUmW5SNf2oFTz9FQTQmFCYCs23PGwM/bw0FyuoLgj6LRdOoIXqZ9bfPDI OESc7anLZnLJ8Trs8/rXuM8RH+yAld3A3o96VxOPgxn8G0dooYak40B1InIU4fchM/1c ZJfkX0kgt7iemmyQW5cqAhVWQILYOFF9J7CouDjdjcTT72oVwa0J0K/4MaiaFuWGICRi wNEQ== X-Gm-Message-State: AMke39lEzegd6VGdTtX84EcDNtijDdWFgRoMiP7CwI+jCaaXTwbFL2+T1WLJGL8v2p5prg== X-Received: by 10.84.195.164 with SMTP id j33mr47524330pld.171.1487206620503; Wed, 15 Feb 2017 16:57:00 -0800 (PST) Received: from [192.168.178.21] ([118.148.112.221]) by smtp.gmail.com with ESMTPSA id i21sm9542625pfi.94.2017.02.15.16.56.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 16:56:59 -0800 (PST) To: Michael Richardson , consultancy@vanderstok.org References: <20170117171732.GA14606@faui40p.informatik.uni-erlangen.de> <20170117172824.GB14606@faui40p.informatik.uni-erlangen.de> <11820.1486936729@obiwan.sandelman.ca> <8a8567bb1b9993c077d84abf4bfc82f3@xs4all.nl> <18113.1487095987@obiwan.sandelman.ca> <20582.1487174374@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 16 Feb 2017 13:57:02 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20582.1487174374@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: anima-bootstrap@ietf.org, Toerless Eckert Subject: Re: [Anima-bootstrap] M_FLOOD and mDNS (was Re: Anima bootstrap: discover protocol multicast notes) X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 00:57:02 -0000 On 16/02/2017 04:59, Michael Richardson wrote: > > peter van der Stok wrote: > > discovery functions may be used. I like to point out mDNS due to its > > long-standing existence. > > okay. I also prefer not to re-invent everything. To repeat myself: we have always expected that non-autonomic pledges would *not* use GRASP to discover their join assistant. A join assistant would support multiple discovery methods if necessary. Nothing prevents a tiny subset of GRASP running in a non-autonomic pledge, just for the purpose of receiving M_FLOODs. But we have no particular reason to push for that. Brian > > > The beginning of section 8 says: " Whenever a Multicast DNS > > responder starts up, wakes up from sleep, receives an indication of a > > network interface "Link Change" event, or has any other reason to > > believe that its network connectivity may have changed in some > > relevant way, it MUST perform the two startup steps below: Probing > > (Section 8.1) and Announcing (Section 8.3). " Much of the text of > > Yes, that's the case on the first interval. Once it's none that, it's not > supposed to be proactively announce itself again, from what I understand. > It's a service, so it doesn't to defend it's name. > > > rfc6762 is about suppressing superfluous traffic. The method relies > > on repetitive querying and reactive responding, with a response at > > responder re-activation (see above). There is a lot of operational > > experience here, and deserves attention. > > Okay, but would this be a valid implementation: > unsigned char stuff[]={ 0x01,0x02, /* encoded DNS-SD reply */ > while(true) { > sleep(60); > sendmsg(stuff, multicast-address, port-5353); > } > > ? > > >> It might be that in the end we don't care about the anonimity of the > >> pledge. > > > Did we? IMO, almost impossible in an unsecured bootstrapping > > network. Once keys are distributed, pledge looses it identity and > > starts afresh (I reckoned) > > Okay, *DO YOU* care about anonimity of the pledge? > Do *YOU* care if the pledge must solicit a Join Proxy by multicasting a query? > > >> If the pledge can ask the network about Join Proxy, then there is > >> nothing to stop us from using mDNS here. > > > Or anything else dependent on the operational environment of > > the SDO using the bootstrapping protocol. > > Agreed. > What would you like to chose here? Tell us your opinion. > Don't be shy. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima-bootstrap mailing list > Anima-bootstrap@ietf.org > https://www.ietf.org/mailman/listinfo/anima-bootstrap > From nobody Thu Feb 16 00:36:24 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC171299CE for ; Thu, 16 Feb 2017 00:36:24 -0800 (PST) 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 ICAfcDCH-8gN for ; Thu, 16 Feb 2017 00:36:22 -0800 (PST) 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 6182A129474 for ; Thu, 16 Feb 2017 00:36:22 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.195]) by smtp-cloud2.xs4all.net with ESMTP id lLcK1u00F4CYHle01LcKjE; Thu, 16 Feb 2017 09:36:20 +0100 Received: from AMontpellier-654-1-69-96.w90-0.abo.wanadoo.fr ([90.0.44.96]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 16 Feb 2017 09:36:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 16 Feb 2017 09:36:19 +0100 From: peter van der Stok To: Brian E Carpenter Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: <20170117171732.GA14606@faui40p.informatik.uni-erlangen.de> <20170117172824.GB14606@faui40p.informatik.uni-erlangen.de> <11820.1486936729@obiwan.sandelman.ca> <8a8567bb1b9993c077d84abf4bfc82f3@xs4all.nl> <18113.1487095987@obiwan.sandelman.ca> <20582.1487174374@obiwan.sandelman.ca> Message-ID: <3f534be2aaf394503614ecde7fbec0bb@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Cc: Michael Richardson , anima-bootstrap@ietf.org, Toerless Eckert , consultancy@vanderstok.org Subject: Re: [Anima-bootstrap] M_FLOOD and mDNS (was Re: Anima bootstrap: discover protocol multicast notes) X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 08:36:24 -0000 Brian E Carpenter schreef op 2017-02-16 01:57: > On 16/02/2017 04:59, Michael Richardson wrote: >> >> peter van der Stok wrote: >> > discovery functions may be used. I like to point out mDNS due >> to its >> > long-standing existence. >> >> okay. I also prefer not to re-invent everything. > > To repeat myself: we have always expected that non-autonomic pledges > would *not* use GRASP to discover their join assistant. A join > assistant > would support multiple discovery methods if necessary. GREAT, I had not understood that that is the consensus; and of course I agree. My be put text like that in the intro of keyinfra? Peter > > Nothing prevents a tiny subset of GRASP running in a non-autonomic > pledge, just for the purpose of receiving M_FLOODs. But we have no > particular reason to push for that. > > Brian From nobody Thu Feb 16 00:49:46 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB441294A9 for ; Thu, 16 Feb 2017 00:49:45 -0800 (PST) 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 GjO5dpmfJq3Y for ; Thu, 16 Feb 2017 00:49:44 -0800 (PST) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8F3129538 for ; Thu, 16 Feb 2017 00:49:44 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.195]) by smtp-cloud2.xs4all.net with ESMTP id lLpi1u0084CYHle01LpipC; Thu, 16 Feb 2017 09:49:42 +0100 Received: from AMontpellier-654-1-69-96.w90-0.abo.wanadoo.fr ([90.0.44.96]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 16 Feb 2017 09:49:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 16 Feb 2017 09:49:42 +0100 From: peter van der Stok To: Michael Richardson Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <20582.1487174374@obiwan.sandelman.ca> References: <20170117171732.GA14606@faui40p.informatik.uni-erlangen.de> <20170117172824.GB14606@faui40p.informatik.uni-erlangen.de> <11820.1486936729@obiwan.sandelman.ca> <8a8567bb1b9993c077d84abf4bfc82f3@xs4all.nl> <18113.1487095987@obiwan.sandelman.ca> <20582.1487174374@obiwan.sandelman.ca> Message-ID: <77ef9d9a0fe928ce0d857de188fc991b@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Cc: anima-bootstrap@ietf.org, Toerless Eckert , consultancy@vanderstok.org Subject: Re: [Anima-bootstrap] M_FLOOD and mDNS (was Re: Anima bootstrap: discover protocol multicast notes) X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 08:49:45 -0000 > > > The beginning of section 8 says: " Whenever a Multicast > DNS > > responder starts up, wakes up from sleep, receives an indication > of a > > network interface "Link Change" event, or has any other reason to > > believe that its network connectivity may have changed in some > > relevant way, it MUST perform the two startup steps below: > Probing > > (Section 8.1) and Announcing (Section 8.3). " Much of the text > of > > Yes, that's the case on the first interval. Once it's none that, it's > not > supposed to be proactively announce itself again, from what I > understand. > It's a service, so it doesn't to defend it's name. > > > rfc6762 is about suppressing superfluous traffic. The method > relies > > on repetitive querying and reactive responding, with a response > at > > responder re-activation (see above). There is a lot of > operational > > experience here, and deserves attention. > > Okay, but would this be a valid implementation: > unsigned char stuff[]={ 0x01,0x02, /* encoded DNS-SD reply */ > while(true) { > sleep(60); > sendmsg(stuff, multicast-address, port-5353); > } > This looks like a caricature of the mDNS text regarding the sleep. I don't think the text is intended for lots of sleepy sensors. From an inter-operability point of view it looks OK. One can argue about the load generated on the network. > ? > > >> It might be that in the end we don't care about the anonimity of > the > >> pledge. > > > Did we? IMO, almost impossible in an unsecured > bootstrapping > > network. Once keys are distributed, pledge looses it identity > and > > starts afresh (I reckoned) > > Okay, *DO YOU* care about anonimity of the pledge? > Do *YOU* care if the pledge must solicit a Join Proxy by multicasting a > query? *I* don't. preferably link-local though. > > >> If the pledge can ask the network about Join Proxy, then there > is > >> nothing to stop us from using mDNS here. > > > Or anything else dependent on the operational environment > of > > the SDO using the bootstrapping protocol. > > Agreed. > What would you like to chose here? Tell us your opinion. personally I would use CoAP discovery; we talk about CoAP here. And specify a join-proxy resource-type in the coap registry. > Don't be shy. Try to be bold. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- From nobody Thu Feb 16 06:29:16 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B272129600 for ; Thu, 16 Feb 2017 06:29:15 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjnHCF16zOSW for ; Thu, 16 Feb 2017 06:29:13 -0800 (PST) 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 A36571294D7 for ; Thu, 16 Feb 2017 06:29:13 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 58C4F2009E; Thu, 16 Feb 2017 09:50:44 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 62C6E636BB; Thu, 16 Feb 2017 09:29:11 -0500 (EST) From: Michael Richardson To: consultancy@vanderstok.org In-Reply-To: <77ef9d9a0fe928ce0d857de188fc991b@xs4all.nl> References: <20170117171732.GA14606@faui40p.informatik.uni-erlangen.de> <20170117172824.GB14606@faui40p.informatik.uni-erlangen.de> <11820.1486936729@obiwan.sandelman.ca> <8a8567bb1b9993c077d84abf4bfc82f3@xs4all.nl> <18113.1487095987@obiwan.sandelman.ca> <20582.1487174374@obiwan.sandelman.ca> <77ef9d9a0fe928ce0d857de188fc991b@xs4all.nl> 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 Date: Thu, 16 Feb 2017 09:29:11 -0500 Message-ID: <26993.1487255351@obiwan.sandelman.ca> Archived-At: Cc: anima-bootstrap@ietf.org, Toerless Eckert Subject: Re: [Anima-bootstrap] M_FLOOD and mDNS (was Re: Anima bootstrap: discover protocol multicast notes) X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:29:15 -0000 peter van der Stok wrote: >> Okay, *DO YOU* care about anonimity of the pledge? Do *YOU* care if >> the pledge must solicit a Join Proxy by multicasting a query? > *I* don't. preferably link-local though. okay. >> Agreed. What would you like to chose here? Tell us your opinion. > personally I would use CoAP discovery; we talk about CoAP here. And > specify a join-proxy resource-type in the coap registry. I'm not sure what is CoAP discovery... tell me about it! And we are talking about non-802.15.4 (like) networks, because I think 15.4 networks can be handled differently. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Thu Feb 16 07:14:55 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B328E129ADC for ; Thu, 16 Feb 2017 07:14:54 -0800 (PST) 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 Yklif-9nmotP for ; Thu, 16 Feb 2017 07:14:52 -0800 (PST) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FA4D129509 for ; Thu, 16 Feb 2017 07:14:46 -0800 (PST) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:214]) by smtp-cloud2.xs4all.net with ESMTP id lTEk1u00E0F6qFb01TEkwn; Thu, 16 Feb 2017 16:14:44 +0100 Received: from AMontpellier-654-1-69-96.w90-0.abo.wanadoo.fr ([90.0.44.96]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 16 Feb 2017 16:14:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 16 Feb 2017 16:14:44 +0100 From: peter van der Stok To: Michael Richardson Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <26993.1487255351@obiwan.sandelman.ca> References: <20170117171732.GA14606@faui40p.informatik.uni-erlangen.de> <20170117172824.GB14606@faui40p.informatik.uni-erlangen.de> <11820.1486936729@obiwan.sandelman.ca> <8a8567bb1b9993c077d84abf4bfc82f3@xs4all.nl> <18113.1487095987@obiwan.sandelman.ca> <20582.1487174374@obiwan.sandelman.ca> <77ef9d9a0fe928ce0d857de188fc991b@xs4all.nl> <26993.1487255351@obiwan.sandelman.ca> Message-ID: <9341e5c2d9ecb3decf70fb68da0f6f50@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Cc: anima-bootstrap@ietf.org, Toerless Eckert , consultancy@vanderstok.org Subject: Re: [Anima-bootstrap] M_FLOOD and mDNS (was Re: Anima bootstrap: discover protocol multicast notes) X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:14:54 -0000 > > > personally I would use CoAP discovery; we talk about CoAP here. > And > > specify a join-proxy resource-type in the coap registry. > > I'm not sure what is CoAP discovery... tell me about it! > > And we are talking about non-802.15.4 (like) networks, because I think > 15.4 > networks can be handled differently. Below the text to appear in the est-coaps draft. I hope it is clear; otherwise I can send text from the resource directory draft where the subject is more exhaustively treated. _________________________________________________________________ The presence and location of (path to) the EST-coaps resources are discovered by multicasting a GET request to "/.well-known/core" including a resource type (RT) parameter with the value "core.est" [RFC6690]. Upon success, the return payload will contain the root resource of the EST resources. It is up to the implementation to choose its root resource, but it is recommended that the value "/est" is used, where possible. The example below shows the discovery of the presence and location of management data. REQ: GET /.well-known/core?rt=core.est RES: 2.05 Content ; rt="core.est" _____________________________________________________________ cheerio, Peter From nobody Thu Feb 16 11:09:44 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC2B12941A for ; Thu, 16 Feb 2017 11:09:43 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 2cM-oK1QGzfI for ; Thu, 16 Feb 2017 11:09:42 -0800 (PST) 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 8A3BA12955E for ; Thu, 16 Feb 2017 11:02:08 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DFFFB2009E; Thu, 16 Feb 2017 14:23:40 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4133A636BB; Thu, 16 Feb 2017 14:02:07 -0500 (EST) From: Michael Richardson To: consultancy@vanderstok.org In-Reply-To: <9341e5c2d9ecb3decf70fb68da0f6f50@xs4all.nl> References: <20170117171732.GA14606@faui40p.informatik.uni-erlangen.de> <20170117172824.GB14606@faui40p.informatik.uni-erlangen.de> <11820.1486936729@obiwan.sandelman.ca> <8a8567bb1b9993c077d84abf4bfc82f3@xs4all.nl> <18113.1487095987@obiwan.sandelman.ca> <20582.1487174374@obiwan.sandelman.ca> <77ef9d9a0fe928ce0d857de188fc991b@xs4all.nl> <26993.1487255351@obiwan.sandelman.ca> <9341e5c2d9ecb3decf70fb68da0f6f50@xs4all.nl> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: anima-bootstrap@ietf.org, Toerless Eckert Subject: Re: [Anima-bootstrap] M_FLOOD and mDNS (was Re: Anima bootstrap: discover protocol multicast notes) X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 19:09:43 -0000 --=-=-= Content-Type: text/plain peter van der Stok wrote: >> I'm not sure what is CoAP discovery... tell me about it! >> >> And we are talking about non-802.15.4 (like) networks, because I think >> 15.4 networks can be handled differently. > Below the text to appear in the est-coaps draft. I hope it is clear; > otherwise I can send text from the resource directory draft where the > subject is more exhaustively treated. > _________________________________________________________________ The > presence and location of (path to) the EST-coaps resources are > discovered by multicasting a GET request to "/.well-known/core" > including a resource type (RT) parameter with the value "core.est" Ah, I see. > REQ: GET /.well-known/core?rt=core.est > RES: 2.05 Content ; rt="core.est" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlil9y4ACgkQgItw+93Q 3WWKogf9EVU0g8e/AYxSvxjbvv5MnuipZudX4HNFHIQno9ySxkjFRT1cKW5nY23o hdep75XZ1WFJa4GPiWQbwYzpkZUNOlXPG4s+ncxKMRDP98nxl63J69tP1W8ovjvU KtBO5tOpzsZH+mFlV3gPcPGb6neJLdxTcj50+fmq64ojmUbdYoDERXlH6y+y4gbv w7PDf1p68RDqjJH+rWC4mVhyuqbscLdflQX/NFhzrchT2JZ6E3S44FMUcT+5DH6Q x0BCebOzn4C5gY3JN7wCagoNT12UILSx1fVbb929FJJlBzXQ1KNkBzW9mV3N0zbk HzYxXSurnJRtwwEAQc4Ys/BDc8yVIA== =ALCd -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 21 07:50:11 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423F0129498 for ; Tue, 21 Feb 2017 07:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOfoU5FRJIpn for ; Tue, 21 Feb 2017 07:50:08 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D79129507 for ; Tue, 21 Feb 2017 07:50:08 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0379158C4AE; Tue, 21 Feb 2017 16:50:02 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id D24ACB0B7E9; Tue, 21 Feb 2017 16:50:02 +0100 (CET) Date: Tue, 21 Feb 2017 16:50:02 +0100 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20170221155002.GA8168@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: anima-bootstrap Subject: [Anima-bootstrap] Brian: GRASP parameter for registrar discovery by proxy X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 15:50:10 -0000 Hi Brian In the anima bootstrap meeting we tried to figure out the necessary GRASP message elements for discovery of registrars by proxies. And make it extensible. If you check: http://etherpad.tools.ietf.org:9000/p/anima-boostrapping?useMonospaceFont=true 578 - 608 We may have a bunch of different possible proxy behaviors: - TCP circuit proxy in conjunction with HTTPs - UDP proxy in conjunction with CoAP - IPinIP proxy in conjunction with either HTTPs or CoAP MichaelR's text was currently suggesting to indicate in the GRASP message what the registrar supports via the locators: locator1 = [O_IPv6_LOCATOR, fe80::1234, 6, ] locator2 = [O_IPv6_LOCATOR, fe80::1234, 17, ] locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] The first line would indicate TCP circuit proxy, the second UDP proxy, the third one IPinIP proxy. I am quite uncomfortable to indicate the desired proxy behavior purely via the IP protocol field in a locator (6, 17, 41). It already is IMHO underspecified, eg: unclear why the UDP proxy would (only) support CoAP, and what actually the IPinIP stack supports (CoAP, HTTPs, ...). So, how/where would we most easily indicate the stack in the GRASP response ? For example: locator1 = [O_IPv6_LOCATOR, fe80::1234, 6, , tcp-circuit] locator2 = [O_IPv6_LOCATOR, fe80::1234, 17, , coap-udp] locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil, tcp-ip-in-ip] locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil, coap-ip-in-ip] Thanks! Toerless From nobody Tue Feb 21 11:45:20 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443661294D0 for ; Tue, 21 Feb 2017 11:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 nLJBpLqU00Mr for ; Tue, 21 Feb 2017 11:45:17 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::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 9D8D3129CA3 for ; Tue, 21 Feb 2017 11:44:49 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id z128so2859672pgb.0 for ; Tue, 21 Feb 2017 11:44:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ARIXWSK4d+qgGUiVbCn8laQHSPaqih0BGfpSzGFsz64=; b=XhP3HvPXd347jzqBZgL2GGgO8nGAcMV35/NFFNtwBWymEn6gS/uw61OdO6fGE15JrA taw/H/DWUcaMow5o4X6Fkb5O01MvU8Tav0z65+OtER1mruiJsfEZGhGOBmFrG7WjeIhl l5X8sG1U1AbkNw5AOiPZouVDuBjUpI3SmCR5GPeuHFzbMmWWpGoZHNPMPYrrSpTsF+d4 Dz+VBw5NJ3xpXZFV1CBHb5u4g4x0RHwgzvhmd8+reKoeqhTehNwvZA34VRww70fEl/bD heCjDJSPSkOmiFHtDhwIIMYNieSzN/Nv1XOnVuM6OjtwKILnHYlO77xFSfzYkTHydLM4 obFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=ARIXWSK4d+qgGUiVbCn8laQHSPaqih0BGfpSzGFsz64=; b=QSpjAoD1wzQVrqo6x13rnb5sgHWVj22T0VvGkippnfKNV2hZ1WMhEFANVQgUd0oT7P iPpzkV6cp62v1mjhqauH+MBZoFaTlvjPDsMQfm2EMGdZUZdgqE89CosTv9RzJRLN+0Dd RQ02ApKCAeTO/v6ZNerEDcAMpwrLCDC/2ntDmxz/ICxZOaU+yyolWrxHldAkBBEGL+Xt P25Cz/qsGFJ9v9mZE0tgcwgzSPpJgbZmvImGxBIEH9Ysfh/jwHWMREqR4mS4/zMSTlEn HPGmWvM7olz909fUaOX0qJIjhiTpBa4QoNQiXkwZHVHFbUAxQxvZRBdNHhHH2J/NvMwY 3acw== X-Gm-Message-State: AMke39mIR7MhSy6FZvD1pikJ0Z5veMr888i9mT+H+chxxEZyHFfNOzc/8aWaNK19mVUzbw== X-Received: by 10.99.109.4 with SMTP id i4mr2571821pgc.11.1487706288937; Tue, 21 Feb 2017 11:44:48 -0800 (PST) Received: from ?IPv6:2406:e007:474b:1:28cc:dc4c:9703:6781? ([2406:e007:474b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id w16sm42727834pgc.15.2017.02.21.11.44.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Feb 2017 11:44:48 -0800 (PST) To: Toerless Eckert References: <20170221155002.GA8168@faui40p.informatik.uni-erlangen.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6b414f54-4164-5c9d-390e-30d21f786cca@gmail.com> Date: Wed, 22 Feb 2017 08:44:49 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170221155002.GA8168@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: anima-bootstrap Subject: Re: [Anima-bootstrap] Brian: GRASP parameter for registrar discovery by proxy X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 19:45:19 -0000 Hi Toerless, First of all, did you look at draft-carpenter-anima-ani-objectives-01 and https://www.cs.auckland.ac.nz/~brian/graspy/brski/ ? I am not defending the details in those but they do indicate what's possible with GRASP, and how I think this could be solved. More below: On 22/02/2017 04:50, Toerless Eckert wrote: > Hi Brian > > In the anima bootstrap meeting we tried to figure out the necessary > GRASP message elements for discovery of registrars by proxies. And make > it extensible. > > If you check: > > http://etherpad.tools.ietf.org:9000/p/anima-boostrapping?useMonospaceFont=true > 578 - 608 That seems to go back to using discover/response. Wrong answer, IMHO; flooding is simpler: fewer messages and richer semantics. I'm going to assume that below. > We may have a bunch of different possible proxy behaviors: > > - TCP circuit proxy in conjunction with HTTPs > - UDP proxy in conjunction with CoAP > - IPinIP proxy in conjunction with either HTTPs or CoAP Sure. In the above, these are what I call the "method" amd they would be defined by a text string name, which makes it easy to add new ones. They could be anything; in my examples I used "BRSKI-TLS" and "BRSKI-COAP" but "tcp-circuit" etc would work fine too. Whatever you want. > MichaelR's text was currently suggesting to indicate in the GRASP message > what the registrar supports via the locators: > > locator1 = [O_IPv6_LOCATOR, fe80::1234, 6, ] > locator2 = [O_IPv6_LOCATOR, fe80::1234, 17, ] > locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] > > The first line would indicate TCP circuit proxy, the second UDP proxy, > the third one IPinIP proxy. > > I am quite uncomfortable to indicate the desired proxy behavior > purely via the IP protocol field in a locator (6, 17, 41). It already > is IMHO underspecified, eg: unclear why the UDP proxy would (only) support > CoAP, and what actually the IPinIP stack supports (CoAP, HTTPs, ...). Correct. It's insufficient because it cannot separate the upper layer cases. (Also, using link-local examples is an oversight, surely: this should be an ACP address, e.g. fdab:dead:beef::1234, I think.) > So, how/where would we most easily indicate the stack in the GRASP > response ? For example: > > locator1 = [O_IPv6_LOCATOR, fe80::1234, 6, , tcp-circuit] > locator2 = [O_IPv6_LOCATOR, fe80::1234, 17, , coap-udp] > locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil, tcp-ip-in-ip] > locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil, coap-ip-in-ip] No, that would be a protocol change by adding an extra field to the locator syntax. However, this is already covered by a feature of the Flood message which we added a while back. Each item in a flood message is optionally associated with its own locator: flood-message = [M_FLOOD, session-id, initiator, ttl, +[objective, (locator-option / [])]] so we'd send several copies of the objective, each with its own "method" and locator. So for example we'd flood the objective ["AN_join_registrar", F_NEG, 6, ["tcp-circuit"]] with locator [O_IPv6_LOCATOR, fdab:dead:beef::1234, 6, 443] and an objective ["AN_join_registrar", F_NEG, 6, ["coap-udp"]] with the locator [O_IPv6_LOCATOR, fdab:dead:beef::1234, 17, 5683] The could be sent all in one Flood message, or in separate ones, possible from different sources if there were actually two registrars, Truly, if you read the draft and eyeball the Python, you can see how it works. If you really don't want to use flooding, it gets more tricky. Discovery alone won't do the trick in a simple way. I know how to do it but it will involve more messages. Regards Brian > > Thanks! > Toerless > From nobody Wed Feb 22 00:46:01 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AE2129690 for ; Wed, 22 Feb 2017 00:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 5Acx1f_UpJa2 for ; Wed, 22 Feb 2017 00:45:58 -0800 (PST) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0222A1293DF for ; Wed, 22 Feb 2017 00:45:57 -0800 (PST) Received: from webmail.xs4all.nl ([194.109.20.206]) by smtp-cloud6.xs4all.net with ESMTP id nklv1u0094SmhUa01klvTj; Wed, 22 Feb 2017 09:45:56 +0100 Received: from AMontpellier-654-1-111-93.w90-0.abo.wanadoo.fr ([90.0.86.93]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 22 Feb 2017 09:45:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 22 Feb 2017 09:45:55 +0100 From: peter van der Stok To: Anima-bootstrap Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <101549d80da6710ad7427e9ae20dc0ab@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail Archived-At: Subject: [Anima-bootstrap] est over coaps X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 08:46:00 -0000 Hi anima bootstrap, In the minutes I saw that there were some questions bout the est over coaps draft. Some updates: The two est-coap drafts are merged, and the result will be published to ACE before the chicago cut-off. Indeed the est over coaps draft goes beyond est; and includes BRSKI functions. We expect short packets, and therefore shorten the URI path names and use coaps://example.com/est/EST-coaps; see the table below +------------------+------------------+-----------+ | BRSKI | EST | EST-coaps | +------------------+------------------+-----------+ | | /cacerts | /crts | | | /simpleenroll | /sen | | | /simplereenroll | /sren | | | /csrattrs | /att | | | /serverkeygen | /skg | | /requestvoucher | | /rv | | /voucherstatus | | /vs | | /enrollstatus | | /es | +------------------+------------------+-----------+ I must say that the turnover on BRSKI URI path names is quite high, and the table may not be up to date. Questions and remarks are welcome. Hope this helps, Peter -- Peter van der Stok tel NL: +31(0)492474673 F: +33(0)966015248 From nobody Thu Feb 23 06:35:13 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3941B129871 for ; Thu, 23 Feb 2017 06:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Girvx_8guEv4 for ; Thu, 23 Feb 2017 06:35:11 -0800 (PST) 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 41C231296CF for ; Thu, 23 Feb 2017 06:35:11 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 70CAAE1E1; Thu, 23 Feb 2017 09:57:07 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5CC6F6381A; Thu, 23 Feb 2017 09:35:10 -0500 (EST) From: Michael Richardson To: consultancy@vanderstok.org In-Reply-To: <101549d80da6710ad7427e9ae20dc0ab@xs4all.nl> References: <101549d80da6710ad7427e9ae20dc0ab@xs4all.nl> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Anima-bootstrap Subject: Re: [Anima-bootstrap] est over coaps X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 14:35:12 -0000 --=-=-= Content-Type: text/plain peter van der Stok wrote: > In the minutes I saw that there were some questions bout the est over > coaps draft. Some updates: The two est-coap drafts are merged, and the > result will be published to ACE before the chicago cut-off. Indeed the wonderful to hear, I look forward to reading them. > I must say that the turnover on BRSKI URI path names is quite high, and > the table may not be up to date. Questions and remarks are welcome. Sorry, if we make further changes, we will communicate them directly to you. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAliu8x0ACgkQgItw+93Q 3WXuXQf+Nwcn+MnMYgKJ8IxdBI1LR5veMW2FH1kiWfagLD24E7B/W7Dt/2Qu5cKo k6EEt8QOmOlYS8XfWOfVGiTziLYvSGMJAxqYEITzpGSA8hv0QYwBr1Ug2MuquB7b yWGn4jC0fMSh8QbnNiyhSNYTvmxXb3FsHe2mTVutj9rWwds469GFBOvcKiSLLMhb aTy3JHhZ81xvKZNr/xUiZ+9tivKV8dkfzyltR7N0EdCMQy6iC9YV6mxcmm5jYmT6 cVSEGLIhrRoWhjOUU1nU450fS3Y2mfDfD9t3R6lbvExS4Bzqgjna/lEajiVYyKjq 2Yiqf3BcZJ3POTKJ39BQvf6EC2S36g== =Ibjt -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 23 08:08:08 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18AE1299EB for ; Thu, 23 Feb 2017 08:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 PCv5JPjjcpmZ for ; Thu, 23 Feb 2017 08:08:05 -0800 (PST) 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 568D41299E1 for ; Thu, 23 Feb 2017 08:08:05 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BD305E1E3; Thu, 23 Feb 2017 11:29:59 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6EA096381A; Thu, 23 Feb 2017 11:08:02 -0500 (EST) From: Michael Richardson To: anima-bootstrap , Brian E Carpenter In-Reply-To: <6b414f54-4164-5c9d-390e-30d21f786cca@gmail.com> References: <20170221155002.GA8168@faui40p.informatik.uni-erlangen.de> <6b414f54-4164-5c9d-390e-30d21f786cca@gmail.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: Toerless Eckert Subject: Re: [Anima-bootstrap] Brian: GRASP parameter for registrar discovery by proxy X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 16:08:07 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > That seems to go back to using discover/response. Wrong answer, IMHO; > flooding is simpler: fewer messages and richer semantics. I'm going to > assume that below. What if the Registrar needs to be aware of the Join Proxy (prior to it making use of it), and may need to do some (local) configuration or load balancing in the decision to provide service to that proxy. This seems to be a clear case where discovery ought to be used. > (Also, using link-local examples is an oversight, surely: this should > be an ACP address, e.g. fdab:dead:beef::1234, I think.) Yes, exactly. It should be an ACP address. > The could be sent all in one Flood message, or in separate ones, > possible from different sources if there were actually two registrars, It seems like Flood responses and Responses ought to be interchangeable. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlivCOIACgkQgItw+93Q 3WUQGQf/S5jVofYCBCpywgAyl+tagFQOt625tE/7HDHH1CIiGgK6moVKu2fXL+Bi tOYGjO9HYCbHmjUtprv0xlZ2tbpQRZ7JLlaU0V7CLADkvlM6vL2b98PFYegHIipd i99TaZV4X3maevwslu+wY2LftDUEvzSGEfSdHJdoONKMF5nXTl8ccNn5VU3j8D8a umaRwJZu1DtLfN/bWQ1SDFUjYVRX+CqAuoCMiqd/RislAR9k9SeZH/W92se1jHhp IgOgjZf2l7nxlt8udUA0R9NH8eb/O6DeBUVJIitQ6e/8NNBilGWLD0+BT1wmIfFm bvpmLBbBNv4rNuBQZgMARbW6FRhkHw== =l3Wi -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 24 11:15:09 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D88B1294CF for ; Fri, 24 Feb 2017 11:15:07 -0800 (PST) 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 FiU2dvUDTWVd for ; Fri, 24 Feb 2017 11:15:06 -0800 (PST) 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 544E71294A8 for ; Fri, 24 Feb 2017 11:15:06 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id o64so419607pfb.0 for ; Fri, 24 Feb 2017 11:15:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=wqJsRAB2XLGN2JsVkr8/yImqGtl1A/VWHaqCs7HhbsU=; b=MMh2+knCHlCPXvcOClb8Bzl+O2TQQSk4NiliM6qbWnwwEtp13OLmAQNcpAvbeM2Hcy sCcfQrsiFkF01t2tXjeHNC6AhgBgOyNLMwly0XR//8IIZVzSt2Icq/5xZmvEG7FEKX4z iGSpKdA7FhRwmPwXlaoxRVHZIDmntZ5384t24MkOHQjvRq1p8Lbes7zk435P1FfZUxMf oIyy+Lt1cx3Nidzy110Fv7V6tRztJcNuDl3sIUV822puvz2DDj+jaQp96pW2g0/oAszW cxsCLHow3LBNW2IREuDLbqra3nItQyCuuVm0TdUkJktKN5by2JAG6SleTwKY6FyOSHRJ lCdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=wqJsRAB2XLGN2JsVkr8/yImqGtl1A/VWHaqCs7HhbsU=; b=GNQbz5EoYGunA/J4Kwwfag7kEUJ8Bl38R1fKU+Gu+d1BGHpMJO/PljN91W9OR+kmnv esKjJObGpFnTKeVSDc+egdtXimua1mzXSf8NT80Mf//2e1arS8GkgJoq+BWTY1qpEYKW 3NjIERPFv7LH3B4pwOsRMWbz/b9BZL/gAOEODM1D185xiB7E0PnPieOsTcFj9LsjpnHE toqB9Qum4spt1PLuHbBnSZSUXv88Boa5h6QfhBVJ0Bk6Qj6438McU3OyVKgm51L9pnjh huCkXzr6nJnYD5cAXO5Oy+OqSkoQksqHksBEwfv751US+LvYWJViN782SMvuvsXeEz9Y aJeQ== X-Gm-Message-State: AMke39lXCbAjJrRYVX05TwYQ8RXZNlnvegV2XbHIcKskdEROks0S/bKm8HM0OZy8EtWB3w== X-Received: by 10.99.107.130 with SMTP id g124mr5399575pgc.108.1487963705920; Fri, 24 Feb 2017 11:15:05 -0800 (PST) Received: from [192.168.178.21] ([118.149.99.147]) by smtp.gmail.com with ESMTPSA id f3sm16571647pga.34.2017.02.24.11.15.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2017 11:15:05 -0800 (PST) To: Michael Richardson , anima-bootstrap References: <20170221155002.GA8168@faui40p.informatik.uni-erlangen.de> <6b414f54-4164-5c9d-390e-30d21f786cca@gmail.com> <18032.1487866082@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 25 Feb 2017 08:15:14 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <18032.1487866082@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Toerless Eckert Subject: Re: [Anima-bootstrap] Brian: GRASP parameter for registrar discovery by proxy X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 19:15:07 -0000 On 24/02/2017 05:08, Michael Richardson wrote: > > Brian E Carpenter wrote: > > That seems to go back to using discover/response. Wrong answer, IMHO; > > flooding is simpler: fewer messages and richer semantics. I'm going to > > assume that below. > > What if the Registrar needs to be aware of the Join Proxy (prior to it making > use of it), and may need to do some (local) configuration or load balancing > in the decision to provide service to that proxy. > > This seems to be a clear case where discovery ought to be used. > > > (Also, using link-local examples is an oversight, surely: this should > > be an ACP address, e.g. fdab:dead:beef::1234, I think.) > > Yes, exactly. It should be an ACP address. > > > The could be sent all in one Flood message, or in separate ones, > > possible from different sources if there were actually two registrars, > > It seems like Flood responses and Responses ought to be interchangeable. They are similar. But from my prototyping, I found Flood to be a more natural semantic than Discovery/Response. Brian From nobody Fri Feb 24 11:19:09 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556451294D2 for ; Fri, 24 Feb 2017 11:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ho4pw7Vy1vV6 for ; Fri, 24 Feb 2017 11:19:07 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB7C1294D1 for ; Fri, 24 Feb 2017 11:19:07 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id z128so14879242pgb.0 for ; Fri, 24 Feb 2017 11:19:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=7QP4FHwUbtRm7qLdPdo38ov0pFnshw9p56tuq9pjuis=; b=fO77WA9XQ4xApo/MqTsvzwu2HImaTzf5hAQxleiuzE03b68hLju0JcHEzUP9c5x8zV NxR2rcgQFiqDNJLpY0AR2RH6thd4gPuyzr5NbpnglbVhKz21Cmoby/oAcJ5SOdsh5d99 fN2q91ixhKLZtffEL5uY5p5oy+3JezUWcofdhzr/M++lcl+6Co03bnRahJYsMPVh8XZV FZ4bd9g1cOqyWyZNuPolnYCpxGOHsEQC03LcPTRhIYc60+HC5E0bud+elxejqBYTv2Mu fOJZ7T3ryImBQITS6KPafSNOz4ee1HC4We+1o659rqtIMgOVxzA0bCS1nT6CKerxcVSN 4j1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=7QP4FHwUbtRm7qLdPdo38ov0pFnshw9p56tuq9pjuis=; b=KeknXEnJABt2HEpqqQfzTjxTI+kHEurUDfvXrB8EoEduLMnynGKFmvKyopYkkqfrZC 5ATTOsgfLmcf9L09sC8YoCY0HWvVJCaQmhZfJrk8JG9fCR9el47gfrl0r/PFN3+YjO4X BAanyyvDe6DljLWcspgv+TKdIt+Z+uIi515i/lnaGDsrwD1XHesY4BxxczXrET0obDoj cOJZhkmo2crkMruk5NcKtjA79e38nCkBR0JJxzk4BqUkeelVRIeij/4NNr/4OwswPX04 Y035Y+9avWnwVOCVL7HT+4UG6P3319MM4xFV8jcxvEUavXhQEW5zvYHXE+8h4GSlz+sw 2JFw== X-Gm-Message-State: AMke39k3FkynXHK+lYnX5yOpPtBWjeIC2uxIss5HlAPVw4hAfO8G9GTFmqnSoWDMtOHgYw== X-Received: by 10.99.172.2 with SMTP id v2mr5442781pge.100.1487963946719; Fri, 24 Feb 2017 11:19:06 -0800 (PST) Received: from [192.168.178.21] ([118.149.99.147]) by smtp.gmail.com with ESMTPSA id f125sm5175671pfc.4.2017.02.24.11.19.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2017 11:19:06 -0800 (PST) To: Michael Richardson , anima-bootstrap References: <20170221155002.GA8168@faui40p.informatik.uni-erlangen.de> <6b414f54-4164-5c9d-390e-30d21f786cca@gmail.com> <18032.1487866082@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 25 Feb 2017 08:19:15 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <18032.1487866082@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Toerless Eckert Subject: Re: [Anima-bootstrap] Brian: GRASP parameter for registrar discovery by proxy X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 19:19:08 -0000 Forgot something... On 24/02/2017 05:08, Michael Richardson wrote: > > Brian E Carpenter wrote: > > That seems to go back to using discover/response. Wrong answer, IMHO; > > flooding is simpler: fewer messages and richer semantics. I'm going to > > assume that below. > > What if the Registrar needs to be aware of the Join Proxy (prior to it making > use of it), and may need to do some (local) configuration or load balancing > in the decision to provide service to that proxy. That seems a bit disjoint from "proxy needs to find registrar". And it definitely sounds like a two-way conversation, which would more naturally be modelled as a negotiation. Can you change that from a "what if?" to a more specific requirement that we can model? Brian > > This seems to be a clear case where discovery ought to be used. > > > (Also, using link-local examples is an oversight, surely: this should > > be an ACP address, e.g. fdab:dead:beef::1234, I think.) > > Yes, exactly. It should be an ACP address. > > > The could be sent all in one Flood message, or in separate ones, > > possible from different sources if there were actually two registrars, > > It seems like Flood responses and Responses ought to be interchangeable. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Mon Feb 27 10:29:53 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A26912999E for ; Mon, 27 Feb 2017 10:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 GvVxvHS5adD1 for ; Mon, 27 Feb 2017 10:29:50 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B302412999D for ; Mon, 27 Feb 2017 10:29:50 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 034C358C540; Mon, 27 Feb 2017 19:29:45 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id E01D9B0B873; Mon, 27 Feb 2017 19:29:44 +0100 (CET) Date: Mon, 27 Feb 2017 19:29:44 +0100 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20170227182944.GA5096@faui40p.informatik.uni-erlangen.de> References: <20170221155002.GA8168@faui40p.informatik.uni-erlangen.de> <6b414f54-4164-5c9d-390e-30d21f786cca@gmail.com> <18032.1487866082@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Michael Richardson , anima-bootstrap Subject: Re: [Anima-bootstrap] Brian: GRASP parameter for registrar discovery by proxy X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 18:29:52 -0000 > > What if the Registrar needs to be aware of the Join Proxy (prior to it making > > use of it), and may need to do some (local) configuration or load balancing > > in the decision to provide service to that proxy. > > That seems a bit disjoint from "proxy needs to find registrar". And it definitely > sounds like a two-way conversation, which would more naturally be modelled as > a negotiation. Can you change that from a "what if?" to a more specific > requirement that we can model? +1. would like to see an exaple use-case requirement for this. If there is one, it would make discovery procedures more complex because so far we are assuming that the easiest scalable solution is for (large number of) proxies to discovery (few) registrars. Toerless > Brian > > > > > This seems to be a clear case where discovery ought to be used. > > > > > (Also, using link-local examples is an oversight, surely: this should > > > be an ACP address, e.g. fdab:dead:beef::1234, I think.) > > > > Yes, exactly. It should be an ACP address. > > > > > The could be sent all in one Flood message, or in separate ones, > > > possible from different sources if there were actually two registrars, > > > > It seems like Flood responses and Responses ought to be interchangeable. > > > > -- > > Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > > > -- --- tte@cs.fau.de From nobody Mon Feb 27 15:12:19 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CF012945C for ; Mon, 27 Feb 2017 15:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WS4PcWhZJYD for ; Mon, 27 Feb 2017 15:12:14 -0800 (PST) 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 00BD8129469 for ; Mon, 27 Feb 2017 15:12:00 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 598A4E1D5 for ; Mon, 27 Feb 2017 18:34:12 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3BB326381A for ; Mon, 27 Feb 2017 18:12:00 -0500 (EST) From: Michael Richardson To: anima-bootstrap X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima-bootstrap] agenda and details for Tuesday X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 23:12:18 -0000 --=-=-= Content-Type: text/plain etherpad: http://etherpad.tools.ietf.org:9000/p/anima-boostrapping?useMonospaceFont=true JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m00a039327e09fc09340872992b151581 Meeting number (access code): 644 519 877 Meeting password: bootstrap 1) interop planning. 20minutes max. 2) getting the -05 out the door (20 minutes max) 3) I was asked to write about IPIP encapsulation. https://github.com/anima-wg/anima-bootstrap/commit/bba6351458955862965c71199b2f8a94f90cf169 There are some provisioning issues that came up. I tried to capture some of the updates in: https://github.com/anima-wg/anima-bootstrap/commit/e049ec790a7051d54094bfca9d8921e59d7458e5 And this led me to thing that the Registrar discovery probably needs a full NEG_SYN, rather than M_FLOOD or M_DISCOVER... (BTW: There is an IASA 2.0 telecon meeting at 11am EST, as well as RTG Chair chat...) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAli0sj8ACgkQgItw+93Q 3WU7agf/eXN9AJEjihCz7Rpd/NwKXHPNPL7g9RLJehVn9qmojv+15XpxTZrCopjS Y0vyJFToFXB6hcZW2z8dHbBwW8aotLCAns53COz846i2+cuDERKz2CmZdNS5MjF+ IYat+Gx5r4BuX9WBoBbAVfgKvzbkOWitsyzNqI4Dshpk8OvRcwOJLoz+TEVuADjq ZMmwrNuLsXRhhb3ZILVs7K9eKLKChEcSKz2meOcaxs4XSe4FSiNP99SmhIJn/Bia o+ov9JdF0wZioRLU4/cCX3KMVFK30gae7bDW34ZjA7/QKE6YU28VsQEpCMZUjjvp G9rImWGbpHeGirx2mViiS1kIue34Bg== =pmoZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 27 15:37:39 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755A4129459 for ; Mon, 27 Feb 2017 15:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 n3kcbCrawM-e for ; Mon, 27 Feb 2017 15:37:37 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::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 3F3FB12941D for ; Mon, 27 Feb 2017 15:37:37 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id s67so49936455pgb.3 for ; Mon, 27 Feb 2017 15:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=3rVsOxLe4mGqECM64vb0tPq1eNB9TrmAhpZM5fm1Ebc=; b=DgJL1CFVCD55xZmdMaDS3BTo50CnIhLPvQrxLYgpQYqNmFVXJUR0ezuB32phCExBVs GF7qMy1G3oV2CIotrzLyZ3SQUC13ZR9Z3vS00bUL3BHiVtyzrWJPA1t3X3GFzISwIenc sP2LuE+rXiLRazQkf3YqBWjoWI/MfAONYE300rgjuCVdjx8sIZHhYr3uQ/p/XkzjJTwn CO7sqg75fBW5ElkooVLPHo4JH7cJzcNL5ZANG/xfFDdDkUVDTcYbUndsvpY2Y9DCWJe+ oZiEUbvuR/FxhAKsq821Gz+lTBI9+Xi2xb2Jf4KF2MX2r9HqZzLUY8cNHmfz++11Bh4w 7Ing== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=3rVsOxLe4mGqECM64vb0tPq1eNB9TrmAhpZM5fm1Ebc=; b=ZJYxCW4MGQSDdH9rUUuAVb0Ok+NhgRqgO6GpyEmk7qRhEO3iq9lD7DtW1mk/7Z9n1K wascrubq6MUtH/VGNHJlSYdKufE/eL3HZK9gFhFdo+CH3wVmitVUCo0uKeisipLOM8aK carTaPhSCJkfm1ODGUkWBjjFLbRtH2YxXiIa2TZVOFdNywOQbXI2qAo3qjP5r9aV5UxG PTxAoijNooE8WSoJFkEOZ0nxBD2FHcu9klbqQlL3YZhSUzhzg6tXsdP68jt4xpHy8o0J zAuyExfIXRNsHnzcdxaDfArb99DCKOYJVkaqBgi48Zw063ihn6ydWt8ryzUdWPlahXLN x3pg== X-Gm-Message-State: AMke39mobmHzFK+BON6R/cGU72kDDjC2QbGYxM/I5P9Tvjh5vwTdDoOiuMYoeFVkX2irkQ== X-Received: by 10.98.76.140 with SMTP id e12mr23651205pfj.82.1488238656717; Mon, 27 Feb 2017 15:37:36 -0800 (PST) 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 a2sm32605484pfc.72.2017.02.27.15.37.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Feb 2017 15:37:36 -0800 (PST) To: anima-bootstrap@ietf.org References: <26901.1488237120@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <27b00b4c-0e38-688f-35de-20b1e492e948@gmail.com> Date: Tue, 28 Feb 2017 12:37:34 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <26901.1488237120@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima-bootstrap] agenda and details for Tuesday X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 23:37:38 -0000 > And this led me to thing that the Registrar discovery probably needs a full > NEG_SYN, rather than M_FLOOD or M_DISCOVER... You could do both. Use Flood as the baseline and Negotiate or Synchronize if the baseline info is insufficient. I'm not sure if GRASP is Turing-equivalent, but I think you can probably do anything you want. Regards Brian From nobody Tue Feb 28 10:14:50 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB05C129667 for ; Tue, 28 Feb 2017 10:14:48 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hZDn2395pWU for ; Tue, 28 Feb 2017 10:14:47 -0800 (PST) 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 02AB3129664 for ; Tue, 28 Feb 2017 10:14:47 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E88EE2056F for ; Tue, 28 Feb 2017 13:36:59 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 12ABC6381A for ; Tue, 28 Feb 2017 13:14:45 -0500 (EST) From: Michael Richardson To: anima-bootstrap X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Anima-bootstrap] voucher yang X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 18:14:48 -0000 --=-=-= Content-Type: text/plain Kent, thanks for the updates to the YANG for the voucher. Some comments: leaf assertion { description "The assertion is a statement from the MASA regarding how the owner was verified. This statement enables pledges to support more detailed policy checks. Pledges MUST ensure that the assertion provided is acceptable before processing the voucher."; I think that it's more about the registrar than the pledge activity. leaf subject-hash { type binary; description Will there be an update to RFC5280 that will unlock us from SHA-1? Are all of subject-hash/cn-id/dns-id required, or is it one of the above? leaf-list device-identifier { type string; min-elements 1; description "A non-empty list of POSIX regular expressions, each identifying one or more device identifiers (e.g., serial numbers). For instance, the expression could match just a single serial number, or it might match a range of serial numbers. When processing a vouchers, pledges MUST ensure that their unique identifier matches at least one regular expression in the list. If no matching regular expression is found, the pledge MUST NOT process this voucher."; Oh, wow. I'd really rather not have a regex here! I'm more worried about the possible Turing-completeness of the regex rather than the code space issue. I think in IoT, if the device hasn't got a regex parser, then the vendor just won't issue vouchers with regex in them, so that is okay. If we have to, I guess I'd rather have a PCRE if we can find a specification for that. leaf nonce { type string; // unit64? I think it should be binary? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAli1vhQACgkQgItw+93Q 3WUXLgf/fwiuap8kp8EjXs9cbDUtDe8ZO6xys+freJxeenAh/tB//29SycdqjRgj NXif3KrfTAMls2laDiMN4Fn2McF+KyXErHwx7F1DF5WxG9F//pIRhGzHdCrZFT7V fAztqqQGSOk+hN2HcFht+046w+goUWJ7o8B7gKftNVy6zsJU520M/mTwDJwJIH2i ybWGbWSYNYoKcGs05g8yuPrzxKILMZqxDk629jFNocTeKDYbaDNewrrvPCMrP5FU lM1oucJTFa03harhD9DsLPDQISVjsIUKXd1BlSzM6ZN07IL19Hyb3pjrTEU4c1kd C4AiWnsQRiJ7I39Gg8of29bqTL7+vQ== =GmEP -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 28 10:54:01 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCA3129673 for ; Tue, 28 Feb 2017 10:54:00 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulzBrhc9Oz_i for ; Tue, 28 Feb 2017 10:53:59 -0800 (PST) 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 BB8891293D6 for ; Tue, 28 Feb 2017 10:53:58 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8F984E199; Tue, 28 Feb 2017 14:16:12 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8B7806381A; Tue, 28 Feb 2017 13:53:57 -0500 (EST) From: Michael Richardson To: "Liubing \(Leo\)" In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C2E96D65@nkgeml514-mbx.china.huawei.com> References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> <14831.1481139454@obiwan.sandelman.ca> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E940C1@nkgeml514-mbx.china.huawei.com> <0c7b995c954746b8a58ae8a3399588ba@XCH-ALN-010.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E96D65@nkgeml514-mbx.china.huawei.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-bootstrap@ietf.org" , peter van der Stok , "Panos Kampanakis \(pkampana\)" , "Kumar, Sandeep" Subject: Re: [Anima-bootstrap] CoAP mandatory? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 18:54:00 -0000 --=-=-= Content-Type: text/plain Liubing (Leo) wrote: > So I guess once the new draft is adopted, BRSKI will choose the CoAP > as mandatory, right? To followup an old email thread. It would be nice (from my point of view), to do that, but I don't think that we have consensus to do that. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAli1x0UACgkQgItw+93Q 3WW1iwf9G02ay3i8MmvBW9nNwbR+H6LvJzJrxNvs8i8ZcYZaMGeBgUBhSe53c/FV WyFoVJo5I02ZX8bQITyp8zEMFR3Hxldeabuu70BEi3rSpWZsIkVxk+kjNIP4tGmT niX6NTinSKevTshTasuTmK+Hb1z/e+Hrgb3Biyk9CE+MCMn1JCoo1OtS/eFatzQ1 I14ZZqrxM0AEDupeJPRWE8j46P/uPd48mM1GBdXF3E4QHiVXUDKlOjQPtWhX85f3 vzFF49iVPfa0Ee7ma+jd7IFIt2S0FaViLVdrDrTClzYAwXlYvlj493/yXADtO3zQ zejKL4X1YW2v8WS2SeymiqgtdmifxA== =JTlo -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 28 19:47:17 2017 Return-Path: X-Original-To: anima-bootstrap@ietfa.amsl.com Delivered-To: anima-bootstrap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CA41293F0 for ; Tue, 28 Feb 2017 19:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Uxxs8sUh5Rfy for ; Tue, 28 Feb 2017 19:47:13 -0800 (PST) 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 6B1D0129468 for ; Tue, 28 Feb 2017 19:47:13 -0800 (PST) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBX02035; Wed, 01 Mar 2017 03:47:01 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 1 Mar 2017 03:47:00 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 1 Mar 2017 11:46:55 +0800 From: "Liubing (Leo)" To: Michael Richardson Thread-Topic: [Anima-bootstrap] CoAP mandatory? Thread-Index: AQHSZm3bDBkyKdzxNEmKd2cHh6652KEwahAAgAPLTRCASl+ygIABF8qA Date: Wed, 1 Mar 2017 03:46:54 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2EA4DDB@nkgeml514-mbx.china.huawei.com> References: <6525c5f0b6e040b683ccd9c43b1c5e2f@VI1PR9003MB0237.MGDPHG.emi.philips.com> <14831.1481139454@obiwan.sandelman.ca> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E940C1@nkgeml514-mbx.china.huawei.com> <0c7b995c954746b8a58ae8a3399588ba@XCH-ALN-010.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C2E96D65@nkgeml514-mbx.china.huawei.com> <27173.1488308037@obiwan.sandelman.ca> In-Reply-To: <27173.1488308037@obiwan.sandelman.ca> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.191.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58B64435.020D, 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: 6fb0175b8f406722e4ad34b78e99510c Archived-At: Cc: "anima-bootstrap@ietf.org" , peter van der Stok , "Panos Kampanakis \(pkampana\)" , "Kumar, Sandeep" Subject: Re: [Anima-bootstrap] CoAP mandatory? X-BeenThere: anima-bootstrap@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list for the bootstrap design team of the ANIMA WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 03:47:15 -0000 Hi Michael, Thanks for your response. > -----Original Message----- > From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] > Sent: Wednesday, March 01, 2017 2:54 AM > To: Liubing (Leo) > Cc: Panos Kampanakis (pkampana); anima-bootstrap@ietf.org; peter van der > Stok; Kumar, Sandeep > Subject: Re: [Anima-bootstrap] CoAP mandatory? >=20 >=20 > Liubing (Leo) wrote: > > So I guess once the new draft is adopted, BRSKI will choose the CoA= P > > as mandatory, right? >=20 > To followup an old email thread. >=20 > It would be nice (from my point of view), to do that, but I don't think t= hat we > have consensus to do that. [Bing] I didn't quite followed the relative discussion. Is this because tha= t CoAP is seldom supported by Non-IoT devices (e.g. telecom boxes)?=20 Best regards, Bing > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20