From nobody Fri Jun 1 04:04:10 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AFA128C0A; Fri, 1 Jun 2018 04:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info 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 QIAMK5PBFmMh; Fri, 1 Jun 2018 04:04:06 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE367129C5D; Fri, 1 Jun 2018 04:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1527851042; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=1349; bh=eI0uD+gRn+bD4uk/xyqcI4pqDy4ZY2wBsAtptrcg/Fc=; b=YvXsQGffiWfV+N48a8ejrX75MOQx73wZIJycSNfDH4OmPAUx/w1U/yXHcimDnK1M usysGR9XGUI+8NcN3pEwIvIQOXllASDYv1WIZNLd99Iy2HTjEkIOOa+UE74e9TWMooi jUX4c+KYW2+FU1GmVCHjKblw8CutIthsDYFZXhTM= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1527851042164917.4880003232064; Fri, 1 Jun 2018 04:04:02 -0700 (PDT) Date: Fri, 01 Jun 2018 12:04:02 +0100 From: Denis Ovsienko To: , "Babel at IETF" Message-ID: <163bb04c573.11825f79f223857.6080690462112978176@ovsienko.info> In-Reply-To: <163b2dab1a7.b9ca30aa119717.1733400857314939856@ovsienko.info> References: <163b2dab1a7.b9ca30aa119717.1733400857314939856@ovsienko.info> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] Extension of Call for WG adoption of draft-ovsienko-babel-rfc7298bis through 2018-05-28 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 11:04:08 -0000 ---- On Wed, 30 May 2018 22:01:06 +0100 Denis Ovsienko wrote ---- > ---- On Fri, 18 May 2018 05:16:48 +0100 Donald Eastlake wrote ---- > > Hi, > > > > This is a reminder that there is an ongoing call for adopt of > > draft-ovsienko-babel-rfc7298bis. This message extends the deadline for > > responding through 28 May. Please indicate if you think this draft > > should or should not be adopted as a starting point by the BABEL WG. > > Greetings. > > It is 30 May and I would like to get a decision. I am working group member Denis Ovsienko, the author of draft-ovsienko-babel-rfc7298bis and its predecessor document RFC 7298. It is 01 June 2018 today, 2 months and 1 week since the beginning of the formal call to adopt the I-D as a Babel WG document. Both the initial call and the extension are now over, during the call period I had provided all relevant supporting information I reasonably could, and my personal understanding now is that the working group eventually had NOT indicated enough support to adopt the document. One more time I am asking the WG chairs Donald Eastlake and Russ White to complete the established procedure, that is, to state the results of this call in due formal way and to make respective updates to the IETF datatracker. -- Denis Ovsienko From nobody Fri Jun 1 07:55:16 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3784212D893; Fri, 1 Jun 2018 07:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_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 Ve0GnQGlPbk3; Fri, 1 Jun 2018 07:55:12 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 6A3F612D890; Fri, 1 Jun 2018 07:55:12 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id f1-v6so3050185ioh.6; Fri, 01 Jun 2018 07:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=Z7gNP6IxIoYIq8RR/OZWTht3xku+2bqFhU6dcayh2Vg=; b=c29ujOODw8emhSmo/On233vCAAj/zY3mv6Uy0Pe6oTTsqF7fxqi9wuJeWuHq0Brrl6 ASLs/P5DRN0VqcTyZHKlAXnb4s9a8WcRUZ7VqYHxZXSGqgpUY173oDScvywLduTOFXv2 G/WH6Z9yOY0yjuDHMtzy3YuZfpV/7avBdvWnvZhEGMdPisQ3td/DpcEr3HpOOOGcYlQA J+M2nQB/kRM7DLV2KaStHfdYuK8VR1UnHY5XSWa3L8vQKaG49LT8sgBxAeMYbgJ9nq5U 9u7ZFpKKrdgWQxmoPFw2ngIpoSReDXXCPyN1qlQ5xxdaA3A9uQoQXCDu7HeJUhoevtkI MXlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=Z7gNP6IxIoYIq8RR/OZWTht3xku+2bqFhU6dcayh2Vg=; b=NNLxk3JbiCNjjVhatAPKALjNkU9ZGIgGay4pS+Oz/fuqH9sxM/cknkOMf/GO4vzQ7b mV6ciGeaYpwWwEkE0bAJiyOyLoToytb3qhk45zbFOoMDOGfHDa4dRDC4zm2LK5XosGcB Sr4G00Y8EH4J4pQoRruKwdkju6lN4yU2ysLqRpslktv0COohHhYwZToDvLQOazRisiW7 X+T5Ug6beB5Iktttawwm4Zo5kxg9jA5LyBPKBGg60CaP48C/I3nxkTggNL72TODPKOka fM9BUwmDqHBg2tQWBiHNEdcaT/pexVH+6+39rTgPMsivFjTgPC7Yw8zFwIy4T1aYXqNo /Dhw== X-Gm-Message-State: APt69E3gwsuKxRoe+PSEyKHPd2ebIotDFte7WPiYguAWfWDhyAVw9qms Jd2YqgGl3GcaNHLjzLXgywM2zo++gft0Z9+Nt8qtfg== X-Google-Smtp-Source: ADUXVKIjo44x/j05ExrE/GtsQ2HalWZAowXjOUdHrcJLmSad8usXjyiqmi+eZVlDu/BFdslvVgF+p2Q4Wuk79lcZQJw= X-Received: by 2002:a6b:871d:: with SMTP id j29-v6mr10651433iod.14.1527864911224; Fri, 01 Jun 2018 07:55:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:a210:0:0:0:0:0 with HTTP; Fri, 1 Jun 2018 07:54:55 -0700 (PDT) From: Donald Eastlake Date: Fri, 1 Jun 2018 10:54:55 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs@ietf.org, Denis Ovsienko Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [babel] Not Adopted Re: Extension of Call for WG adoption of draft-ovsienko-babel-rfc7298bis through 2018-05-28 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 14:55:15 -0000 Hi, Due to the low number of non-author expressions of support and the presence of some opposition to adoption, there does not appear to be consensus to adopt this draft at this time. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Fri, Jun 1, 2018 at 7:04 AM, Denis Ovsienko wrote: > ---- On Wed, 30 May 2018 22:01:06 +0100 Denis Ovsienko wrote ---- > > ---- On Fri, 18 May 2018 05:16:48 +0100 Donald Eastlake wrote ---- > > > Hi, > > > > > > This is a reminder that there is an ongoing call for adopt of > > > draft-ovsienko-babel-rfc7298bis. This message extends the deadline = for > > > responding through 28 May. Please indicate if you think this draft > > > should or should not be adopted as a starting point by the BABEL WG= . > > > > Greetings. > > > > It is 30 May and I would like to get a decision. > > I am working group member Denis Ovsienko, the author of draft-ovsienko-ba= bel-rfc7298bis and its predecessor document RFC 7298. It is 01 June 2018 to= day, 2 months and 1 week since the beginning of the formal call to adopt th= e I-D as a Babel WG document. Both the initial call and the extension are n= ow over, during the call period I had provided all relevant supporting info= rmation I reasonably could, and my personal understanding now is that the w= orking group eventually had NOT indicated enough support to adopt the docum= ent. > > One more time I am asking the WG chairs Donald Eastlake and Russ White to= complete the established procedure, that is, to state the results of this = call in due formal way and to make respective updates to the IETF datatrack= er. > > -- > Denis Ovsienko > > From nobody Fri Jun 1 09:44:32 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD7812D963; Fri, 1 Jun 2018 09:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info 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 s7vADBfEseab; Fri, 1 Jun 2018 09:44:27 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30AC312D961; Fri, 1 Jun 2018 09:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1527871463; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=427; bh=pTw8R/gDtiOwFoCiNLE373uzDHtDiXws2zFczZu0t2c=; b=aUn6v4Jy2q7wlJ+HyDxq7t/F4RvZxevjCZw5tjqnB+k/Jr2PTY8JqMxLj1jwn3N9 qMkQ2mhHwSYwv7P5VkbODIizeqz0oGJNcs0O+pNEyg6bEWY9//x6EfV5d81tvKpU9ga yvm4zlOqtS2o8Uu7c1njGx6yjMR+IO4t6bGgw/Iw= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1527871463130297.2355548928715; Fri, 1 Jun 2018 09:44:23 -0700 (PDT) Date: Fri, 01 Jun 2018 17:44:23 +0100 From: Denis Ovsienko To: "Babel at IETF" , Message-ID: <163bc3c5ed9.ebce1af2309980.9104464086495721@ovsienko.info> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] Not Adopted Re: Extension of Call for WG adoption of draft-ovsienko-babel-rfc7298bis through 2018-05-28 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 16:44:31 -0000 ---- On Fri, 01 Jun 2018 15:54:55 +0100 Donald Eastlake wrote ---- > Hi, > > Due to the low number of non-author expressions of support and the > presence of some opposition to adoption, there does not appear to be > consensus to adopt this draft at this time. Thank you very much Donald. I accept that this working group has made this decision in this specific way. -- Denis Ovsienko From nobody Fri Jun 1 16:55:22 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEBA12E049; Fri, 1 Jun 2018 16:55:21 -0700 (PDT) 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, 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 E151dy0mRkP9; Fri, 1 Jun 2018 16:55:19 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D4212E048; Fri, 1 Jun 2018 16:55:18 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w51NtHGB007483; Sat, 2 Jun 2018 01:55:17 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 252F9EB22D; Sat, 2 Jun 2018 01:55:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id OvZx9OAIdpYi; Sat, 2 Jun 2018 01:55:16 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1E687EB200; Sat, 2 Jun 2018 01:55:16 +0200 (CEST) Date: Sat, 02 Jun 2018 01:55:16 +0200 Message-ID: <871sdqnjtn.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko Cc: "Babel at IETF" , In-Reply-To: <163bc3c5ed9.ebce1af2309980.9104464086495721@ovsienko.info> References: <163bc3c5ed9.ebce1af2309980.9104464086495721@ovsienko.info> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 02 Jun 2018 01:55:17 +0200 (CEST) X-Miltered: at korolev with ID 5B11DCE5.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B11DCE5.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B11DCE5.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Not Adopted Re: Extension of Call for WG adoption of draft-ovsienko-babel-rfc7298bis through 2018-05-28 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 23:55:21 -0000 > I accept that this working group has made this decision in this specific way. Denis, wee're working hard right now to define a protocol that doesn't have the vulnerabilities of the current draft, a process that you've unfortunately decided not participate in. Let us please work together on defining a better protocol, and one that gets adopeted by the working group. -- Juliusz From nobody Sat Jun 2 01:05:12 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E8D12EAF9; Sat, 2 Jun 2018 01:05:11 -0700 (PDT) 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, 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 Wumks9M4Ku_h; Sat, 2 Jun 2018 01:05:09 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1681270A0; Sat, 2 Jun 2018 01:05:08 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w52857Er011246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 2 Jun 2018 10:05:07 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w52857F2013078; Sat, 2 Jun 2018 10:05:08 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id E0AE5EB279; Sat, 2 Jun 2018 10:05:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id qyErZXyBM9I6; Sat, 2 Jun 2018 10:05:04 +0200 (CEST) Received: from mac-matthieu.lan (AAubervilliers-652-1-236-125.w86-198.abo.wanadoo.fr [86.198.55.125]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id AD097EB22E; Sat, 2 Jun 2018 10:05:02 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Matthieu Boutier X-Priority: Medium In-Reply-To: <163a3eefcb3.105e54392539813.8869059599002671510@ovsienko.info> Date: Sat, 2 Jun 2018 10:05:01 +0200 Cc: Babel at IETF , babel-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0B1F8607-E0D3-4725-A9F2-2ACF41207D57@irif.fr> References: <163a3eefcb3.105e54392539813.8869059599002671510@ovsienko.info> To: Denis Ovsienko X-Mailer: Apple Mail (2.3445.6.18) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 02 Jun 2018 10:05:07 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 02 Jun 2018 10:05:08 +0200 (CEST) X-Miltered: at korolev with ID 5B124FB3.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B124FB3.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B124FB3.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B124FB3.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B124FB3.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B124FB3.002 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] WG Last Call for draft-ietf-babel-source-specific (2018-03-26 to 2018-04-09) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2018 08:05:11 -0000 Thanks for your reading Denis, > (Here it could be helpful to provide a reference that helps the reader = get the difference right.) Done. > However, this extension is encoded using mandatory sub-TLVs, > introduced in [BABEL], and therefore is not compatible with the = older > version of the Babel Routing Protocol [RFC6126]. Consequently, this > extension MUST NOT be used with routers implementing RFC 6126, > otherwise persistent routing loops may occur. >=20 > (It looks like the right moment to stop for a moment and think. Could = anybody briefly remind why leaving the protocol version 2 in 6126-bis is = considered better than bumping it up to 3?) You're right, I will add some explicit statement saying that "6126 does not support mandatory sub-TLVs". > (Is it correct that the model in this specification treats 0/0 same as = any other source prefix, it is just the encoding convention that 0/0 is = always represented with the absence of the sub-TLV? If so, it could be = helpful to acknowledge this point in the document for clarity.) Thanks, this was not said explicitly in the protocol operation. > Please find below a patch for the XML source file with some trivial = corrections. Thanks. > - > + I think it's fine with 10, as the base protocol uses this for all its = lists. Matthieu= From nobody Mon Jun 4 05:21:22 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0F8124319 for ; Mon, 4 Jun 2018 05:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info 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 62Y2QlHFNr_S for ; Mon, 4 Jun 2018 05:21:19 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9B0126E01 for ; Mon, 4 Jun 2018 05:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1528114867; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=2001; bh=PZ6PNyAQnFZUaOhuVBN3+SlLL0PihSXkXjBdgO6aPYI=; b=NNzrWfWTzr12laqaB0bvBmfCPL9ScOtX4uUXkQ/PJek914sW0mhN9ARYMCKMKFXt ty7Xix9WYnVE7qyemqcMEvpUktEVf6E9DSRPlsXQ03y4Tzuzn4InaHP85ulzUpHTMfo bZF/u+Vf4DNJOfBkqM5g3XNokRg2Caqtj3RiKVqU= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1528114867530132.95107736082093; Mon, 4 Jun 2018 05:21:07 -0700 (PDT) Date: Mon, 04 Jun 2018 13:21:07 +0100 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <163cabe6d49.1115744068931.3357457871401802835@ovsienko.info> In-Reply-To: <0B1F8607-E0D3-4725-A9F2-2ACF41207D57@irif.fr> References: <163a3eefcb3.105e54392539813.8869059599002671510@ovsienko.info> <0B1F8607-E0D3-4725-A9F2-2ACF41207D57@irif.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] WG Last Call for draft-ietf-babel-source-specific (2018-03-26 to 2018-04-09) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 12:21:20 -0000 ---- On Sat, 02 Jun 2018 09:05:01 +0100 Matthieu Boutier wrote ---- > Thanks for your reading Denis, > > > (Here it could be helpful to provide a reference that helps the reader get the difference right.) > > Done. > > > However, this extension is encoded using mandatory sub-TLVs, > > introduced in [BABEL], and therefore is not compatible with the older > > version of the Babel Routing Protocol [RFC6126]. Consequently, this > > extension MUST NOT be used with routers implementing RFC 6126, > > otherwise persistent routing loops may occur. > > > > (It looks like the right moment to stop for a moment and think. Could anybody briefly remind why leaving the protocol version 2 in 6126-bis is considered better than bumping it up to 3?) > > You're right, I will add some explicit statement saying that "6126 does > not support mandatory sub-TLVs". Please correct me if the following interpretation is wrong. There is a deployed fleet of RFC 6126 devices and it is not going to disappear immediately. There is going to be a deployed fleet of SS-extended devices. When the two kinds randomly meet in the wild and source-specific routes start to propagate, the network can randomly break or degrade. Acknowledging the problem in a document is a good start. But ending up with a design that fails to fail safe looks wrong. If the specification does not provide an implementer with some means to detect this situation and deal with it (as trivial as a protocol version number if nothing else works), the problem will end up dumped at the end user, which is not what they reasonably expect. Do you see what I mean? [...] > > - > > + > > I think it's fine with 10, as the base protocol uses this for all its lists. The formatting issue the above change fixes is difficult to see in XML. It is much easier to see in the .txt output. -- Denis Ovsienko From nobody Mon Jun 4 06:16:22 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D4C12D962 for ; Mon, 4 Jun 2018 06:16:20 -0700 (PDT) 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, 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 OBu30P1boku5 for ; Mon, 4 Jun 2018 06:16:18 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 189CB12D95F for ; Mon, 4 Jun 2018 06:16:17 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w54DGGVW011019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Jun 2018 15:16:16 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w54DGIVU000960; Mon, 4 Jun 2018 15:16:18 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5549BEB914; Mon, 4 Jun 2018 15:16:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 2IAKEl_2l2SD; Mon, 4 Jun 2018 15:16:10 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 4AAC0EB27A; Mon, 4 Jun 2018 15:16:10 +0200 (CEST) Date: Mon, 04 Jun 2018 15:16:10 +0200 Message-ID: <87d0x6u1yd.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko Cc: "Babel at IETF" In-Reply-To: <163cabe6d49.1115744068931.3357457871401802835@ovsienko.info> References: <163a3eefcb3.105e54392539813.8869059599002671510@ovsienko.info> <0B1F8607-E0D3-4725-A9F2-2ACF41207D57@irif.fr> <163cabe6d49.1115744068931.3357457871401802835@ovsienko.info> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Mon, 04 Jun 2018 15:16:16 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 04 Jun 2018 15:16:18 +0200 (CEST) X-Miltered: at korolev with ID 5B153BA0.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B153BA2.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B153BA0.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B153BA2.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B153BA0.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B153BA2.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] WG Last Call for draft-ietf-babel-source-specific (2018-03-26 to 2018-04-09) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 13:16:21 -0000 > Please correct me if the following interpretation is wrong. There is > a deployed fleet of RFC 6126 devices and it is not going to disappear > immediately. There is going to be a deployed fleet of SS-extended > devices. When the two kinds randomly meet in the wild and > source-specific routes start to propagate, the network can randomly > break or degrade. > Acknowledging the problem in a document is a good start. But ending up > with a design that fails to fail safe looks wrong. Babel development tries, to the extent possible, to meet the needs of our users. When we decided to go with the mandatory bits (and therefore break compatibility with 6126), I spoke with a number of users of Babel, some of them in the live, some of them by e-mail. I then explained the transition plan on the babel-users mailing list, no less than three times. There were no objections. Our users are worried about a flag day, since they are unable to update all of their routers in a timely manner. However, they are not worried about an orderly transition: - the next version of babeld will not break compatibility without an explicit option; - future versions of babeld will have a per-interface flag called "rfc6126-compatible" that will cause babeld to remain compatible with deployed implementations. Of course, I have not spoken with every single user of babeld. However, I am confident that the above transition plan is the best we can do without splitting the community into "version 2" and "version 3", which at this stage would be tantamount to suicide. -- Juliusz From nobody Mon Jun 4 09:05:30 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E358E12451D; Mon, 4 Jun 2018 09:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info 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 hblC_liK0-B4; Mon, 4 Jun 2018 09:05:26 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C1FE12756F; Mon, 4 Jun 2018 09:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1528128323; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=2468; bh=pt5AJK1DFHcABb4uHcvWrU3mV4ExDVmWGhdFgVWRYuQ=; b=vLXvL5TYKrCEKWljmpGOPdGjLDB5SlmViPtdfnD8r6tsQpYDD3v5wPzsjuPyEQTn NacRaXtUhkx/56LKcalBF2nj1MggEfQj4RcqHqX6OSEVg6IHRfAiPupOOGWi/ILZ/yF MBMZMK7EQNf33x5g+uttgcZpN06aTe57m5c5E8bU= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1528128323290834.9151423060115; Mon, 4 Jun 2018 09:05:23 -0700 (PDT) Date: Mon, 04 Jun 2018 17:05:23 +0100 From: Denis Ovsienko To: "Babel at IETF" , "babel-chairs" Message-ID: <163cb8bbed9.c4c4572624473.8273863658213485114@ovsienko.info> In-Reply-To: <871sdqnjtn.wl-jch@irif.fr> References: <163bc3c5ed9.ebce1af2309980.9104464086495721@ovsienko.info> <871sdqnjtn.wl-jch@irif.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] Not Adopted Re: Extension of Call for WG adoption of draft-ovsienko-babel-rfc7298bis through 2018-05-28 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 16:05:29 -0000 ---- On Sat, 02 Jun 2018 00:55:16 +0100 Juliusz Chroboczek wrote ---- > > I accept that this working group has made this decision in this specific way. > > Denis, wee're working hard right now to define a protocol that doesn't > have the vulnerabilities of the current draft, a process that you've > unfortunately decided not participate in. > > Let us please work together on defining a better protocol, and one that > gets adopeted by the working group. Hello Juliusz. My I-D is a good enough document to be a working group item. As I had written the whole document up to the level of RFC, I would be able to make remaining editorial fixes if necessary. You may claim you do not see it, but this is straightforward. I am able to identify and admit a serious technical issue in my own work and to come up with the solution. Specifically, I have already done that. It is my pleasure to have made this contribution to the IETF by explaining both the problem and the solution on the Babel WG mailing list. The design problem you say you are going to solve has already been solved, and you perfectly know that as you were involved first person. The job is done, what else are going to add to it? Your name at the top? The process you say I do not participate in only happened because of me in the first place. I made sure to drive it as far as the working group ever wanted, and you were aware and annoyed, sorry. So, for the purposes of this project the document is good enough, the core design is good enough and I am good enough. That said, I do not own the working group, I am not going to bend IETF rules in any way I would like, and I am not going to force my voluntary contributions down everyone's throat. The working group has made its decision in this specific way and I as a member accept this decision. Do you realize exactly the same ought to apply to you too? Because you are a working group member and you are out of the way once again. Before it becomes unpleasant for you, please mind your conduct. The working group will eventually decide what would be the best way to accomplish its charter. If you want to influence this process, remember you are one of the members, no less and no more. Meanwhile, if you have excess energy nowhere to apply, do everyone a favor and make quality fixes to the points made against the 6126-bis I-D. That is your part of the project after all. -- Denis Ovsienko From nobody Mon Jun 4 11:59:08 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BCE130DCC for ; Mon, 4 Jun 2018 11:59:06 -0700 (PDT) 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, 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 oyeyXpQIUThB for ; Mon, 4 Jun 2018 11:59:03 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168E7130DC0 for ; Mon, 4 Jun 2018 11:59:02 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w54Ix0L9014835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Jun 2018 20:59:00 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w54Ix2Hw027259; Mon, 4 Jun 2018 20:59:02 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 56B28EB279; Mon, 4 Jun 2018 20:59:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Iyq_hRGI2Lxn; Mon, 4 Jun 2018 20:58:59 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 5D103EB200; Mon, 4 Jun 2018 20:58:59 +0200 (CEST) Date: Mon, 04 Jun 2018 20:58:59 +0200 Message-ID: <874liitm30.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko Cc: "Babel at IETF" In-Reply-To: <163cb8bbed9.c4c4572624473.8273863658213485114@ovsienko.info> References: <163bc3c5ed9.ebce1af2309980.9104464086495721@ovsienko.info> <871sdqnjtn.wl-jch@irif.fr> <163cb8bbed9.c4c4572624473.8273863658213485114@ovsienko.info> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Mon, 04 Jun 2018 20:59:00 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 04 Jun 2018 20:59:02 +0200 (CEST) X-Miltered: at korolev with ID 5B158BF4.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B158BF6.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B158BF4.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B158BF6.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B158BF4.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B158BF6.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Not Adopted Re: Extension of Call for WG adoption of draft-ovsienko-babel-rfc7298bis through 2018-05-28 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 18:59:06 -0000 > do everyone a favor and make quality fixes to the points made against > the 6126-bis I-D. What are you referring to? -- Juliusz From nobody Tue Jun 5 10:30:29 2018 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C09FB127333; Tue, 5 Jun 2018 10:30:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152821982171.19338.6276482977626565380@ietfa.amsl.com> Date: Tue, 05 Jun 2018 10:30:21 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-information-model-03.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 17:30:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : Babel Information Model Author : Barbara Stark Filename : draft-ietf-babel-information-model-03.txt Pages : 18 Date : 2018-06-05 Abstract: This Babel Information Model can be used to create data models under various data modeling regimes (e.g., YANG). It allows a Babel implementation (via a management protocol such as netconf) to report on its current state and may allow some limited configuration of protocol constants. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-information-model-03 https://datatracker.ietf.org/doc/html/draft-ietf-babel-information-model-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-information-model-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 5 10:36:43 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF5A1310EC for ; Tue, 5 Jun 2018 10:36:41 -0700 (PDT) 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 3c1QeO7Fbv1i for ; Tue, 5 Jun 2018 10:36:39 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78290127333 for ; Tue, 5 Jun 2018 10:36:39 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w55HZLb2018855 for ; Tue, 5 Jun 2018 13:36:39 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2jdxns8srq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 05 Jun 2018 13:36:38 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w55Hab4l010903 for ; Tue, 5 Jun 2018 13:36:37 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w55HaV6D010677 for ; Tue, 5 Jun 2018 13:36:34 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 354A840AE6C3 for ; Tue, 5 Jun 2018 17:36:31 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30488.vci.att.com (Service) with ESMTPS id 1FF9540AE6C2 for ; Tue, 5 Jun 2018 17:36:31 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.42]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0399.000; Tue, 5 Jun 2018 13:36:30 -0400 From: "STARK, BARBARA H" To: "babel@ietf.org" Thread-Topic: [babel] I-D Action: draft-ietf-babel-information-model-03.txt Thread-Index: AQHT/PLxc0q/5OxFnkiEIoPDb1w1/6RR7ReA Date: Tue, 5 Jun 2018 17:36:30 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DDD4001@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <152821982171.19338.6276482977626565380@ietfa.amsl.com> In-Reply-To: <152821982171.19338.6276482977626565380@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.234] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-05_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806050202 Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-03.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 17:36:42 -0000 Hi babelers, I've uploaded an updated draft of the info model. I'm also going to send ou= t 3 emails replying specifically to the emailed comments from Juliusz, Toke= , and David. From back in April. When I published the last draft and immedi= ately disappeared for 2 weeks vacation. Barbara > -----Original Message----- > From: babel On Behalf Of internet- > drafts@ietf.org > Sent: Tuesday, June 05, 2018 1:30 PM > To: i-d-announce@ietf.org > Cc: babel@ietf.org > Subject: [babel] I-D Action: draft-ietf-babel-information-model-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Babel routing protocol WG of the IETF. >=20 > Title : Babel Information Model > Author : Barbara Stark > Filename : draft-ietf-babel-information-model-03.txt > Pages : 18 > Date : 2018-06-05 >=20 > Abstract: > This Babel Information Model can be used to create data models under > various data modeling regimes (e.g., YANG). It allows a Babel > implementation (via a management protocol such as netconf) to report > on its current state and may allow some limited configuration of > protocol constants. >=20 >=20 > The IETF datatracker status page for this draft is: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbabel-2Dinformation- > 2Dmodel_&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3D-N7j4nn_ATZjMnjpbAzWVahCqin7aLsX- > AMNoWHtvUM&s=3DGg_bJO02Ew1UWzGZHZ_XHct4XNTM- > Wm_GXpp1MhuVhc&e=3D >=20 > There are also htmlized versions available at: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__tools.ietf.org_html_draft-2Dietf-2Dbabel-2Dinformation-2Dmodel- > 2D03&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3D-N7j4nn_ATZjMnjpbAzWVahCqin7aLsX- > AMNoWHtvUM&s=3D81HNM8_bGc6Jh_uLHXRqPnBRrjYkinMzErjL0caz1Vc&e=3D > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dbabel-2Dinformation- > 2Dmodel-2D03&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3D-N7j4nn_ATZjMnjpbAzWVahCqin7aLsX- > AMNoWHtvUM&s=3DVH7CbBMmItNrtdw-rV-yOZn1SYjyf6nS2G2jr1imazY&e=3D >=20 > A diff from the previous version is available at: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dbabel-2Dinformation- > 2Dmodel-2D03&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3D-N7j4nn_ATZjMnjpbAzWVahCqin7aLsX- > AMNoWHtvUM&s=3DdcaefEWwqR3gKFEBqDVBdE-HyUmtWJyq__Lova- > S3s4&e=3D >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_interne= t- > 2Ddrafts_&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3D-N7j4nn_ATZjMnjpbAzWVahCqin7aLsX- > AMNoWHtvUM&s=3DMd2erITlmvFsNsx87oqgx- > 7uiYNSOV6n0WzLEtNmONI&e=3D >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_babel&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4vrfog&m=3D- > N7j4nn_ATZjMnjpbAzWVahCqin7aLsX- > AMNoWHtvUM&s=3DtVaIO_ZtkLbHvVH_djwLzKP4Q4czRTUad0N40Uzo4No&e > =3D From nobody Tue Jun 5 10:37:54 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7951310EC for ; Tue, 5 Jun 2018 10:37:52 -0700 (PDT) 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 xAbFo4ry9GGi for ; Tue, 5 Jun 2018 10:37:49 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564A4127333 for ; Tue, 5 Jun 2018 10:37:49 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w55Hawch028540; Tue, 5 Jun 2018 13:37:48 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 2jdy2r80ty-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Jun 2018 13:37:48 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w55Hblb6013811; Tue, 5 Jun 2018 13:37:47 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w55HbjIa013762; Tue, 5 Jun 2018 13:37:45 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 34C7140002DC; Tue, 5 Jun 2018 17:37:45 +0000 (GMT) Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (unknown [130.8.218.150]) by zlp30486.vci.att.com (Service) with ESMTPS id 1BB3E40002D0; Tue, 5 Jun 2018 17:37:45 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.42]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0399.000; Tue, 5 Jun 2018 13:37:44 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: "babel@ietf.org" Thread-Topic: [babel] (Juliusz) I-D Action: draft-ietf-babel-information-model-02.txt Thread-Index: AdP88zNIe09i9u6LSs+4/SC78ZXP7w== Date: Tue, 5 Jun 2018 17:37:44 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DDD4012@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.234] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-05_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806050202 Archived-At: Subject: Re: [babel] (Juliusz) I-D Action: draft-ietf-babel-information-model-02.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 17:37:53 -0000 Response in-line. I've noted a couple of items with "***" where I'd appreci= ate more info. Barbara > -----Original Message----- > From: Juliusz Chroboczek >=20 > Thanks, Barbara. I haven't checked the security bits, but the rest looks= fine > to me. A few minor nits. >=20 > Due to the simplicity of the Babel protocol and the fact that it is > designed to be used in non-professionally administered environments > (such as home networks) >=20 > Please don't say that -- Babel is a general-purpose routing protocol that= is > designed to survive where other protocols die. In particular, it can sur= vive in > the hostile Home Network environment, but I'd like to avoid restricting i= t to > that case. I suggest removing the bit from "and the fact" up to the clos= ing > paranthesis. Done > babel-supported-link-types: set of values of supported link types > where the following enumeration values MUST be supported: 1 =3D > wireless, 2 =3D physical-layer ethernet, 99 =3D other >=20 > I'd prefer this to be a list of strings, with possible values "wired", "w= ireless", > "tunnel" and "other". Changed to string (and removed sentence under "int" data type that said it = was used for enumerations. But I used "ethernet" instead of "wired". I real= ly think at some point it may be useful to see if it makes sense to treat t= echnologies over coax and powerline (which are also technically "wired") di= fferent from (physical layer) ethernet. =20 > > 3.2. Definition of babel-constants-obj >=20 > I don't see a way to find out if this Babel instance is speaking IPv6, IP= v4, or > both. (Toke suggested we dump the IPv4 support, I'm half inclined to agr= ee.) Deleted [ip-address babel-mcast-group-ipv4;] > > 3.3. Definition of babel-interfaces-obj >=20 > babel-link-type: indicates the type of link; integer values >=20 > Same as above -- I'd prefer this to be a string. Same as above. =20 > babel-external-cost: external input to cost of link of this > interface (need to determine how to express this);MUST be > configurable if implemented >=20 > I suggest "if supported, this is a value that is added to the metrics of = routes > learned over this interface". There's a space missing after the semicolo= n. Done. Also added "how an implementation uses the value is up to the impleme= ntation, which means the use may not be consistent across implementations" =20 > babel-neighbors: a set of babel-neighbors objects >=20 > There's a "u" missing ;-) Comment rejected. U can't make me (because, when u is missing there's not m= uch u can do). =20 > > 3.4. Definition of babel-neighbors-obj >=20 > babel-hello-mcast-history: the multicast Hello history of whether > or not each of the 16 multicast Hello messages prior to babel- > hello-seqno was received; represented as a 16 bit (4 hex digits) > value where 1 =3D Hello received and 0 =3D Hello not received; see > draft-ietf-babel-rfc6126bis [rfc6126bis] section A.1 >=20 > You need to specify the endiannness of this bitstring. The reference > implementation puts the most recent bits at the big-endian end, and shift= s > right.=20 > On a related note, shouldn't this be a bit string of an implementation-de= fined > length? Thx. I had actually tried to figure out the endianness from the appendix te= xt, but wasn't quite sure after reading it. That's why I just referred to t= he text; I thought maybe it was just me being dense. I'm adding a statement= that the most recent received Hello is placed in the most significant bit = and previous Hello bits are shifted right; and making the string length und= efined. Since endianness is often thought of in the context of how the bits= are internally stored (as opposed to how they are visually represented to = humans), I'm avoiding that word and using "most significant bit" instead. =20 > babel-hello-seqno: expected Hello sequence number >=20 > This needs to be split into "babel-expected-ucast-hello-seqno" and "babel= - > expected-mcast-hello-seqno". OK. I used "exp" instead of "expected". I also made both mandatory but said= "if [multi|uni]cast Hello messages are not expected, or processing of [mul= ti|uni]icast messages is not enabled, this MUST be 0. I could have made the= m conditionally mandatory but thought it would be easy enough to implement = and set to 0 even if the type of casting isn't supported. Changed the histo= ry parameter descriptions to reference these new names. =20 > > 3.6. Definition of babel-routes-obj >=20 > I think there's a field missing -- the interface over which this route ha= s been > learned. Alternatively, you could put a reference to the neighbour from > which this route has been learned. Ok. Included neighbor reference. It had been in the previous iteration and = for some reason I can't quite remember was deleted. I think I got confused = because the definition was bad.=20 ***question***: It's possible for the same route to be advertised by multip= le neighbors, right? -- so is this entry the one that has been selected to = actually use (and other advertisements were discarded)? =20 > babel-route-next-hop: the next-hop address of this route; this > will be empty if this route has no next-hop address >=20 > I suggest "if this is empty, the next hop is the address of the neighbour= from > which the route has been learnt." ***opinion needed***: Hmm. If the next hop is the address of the neighbor, = then that's what should be in this parameter and it shouldn't be empty. The= purpose of "empty" (according to my notes of our discussion) was for the c= ase where this device itself is the "next hop". I'm not making changes to t= his until we discuss. =20 > babel-route-metric: the metric with which this route was > advertised by the neighbor, or maximum value (infinity) to > [...] > babel-route-announced-metric: a calculated metric for this route; > how the metric is calculated is implementation-specific; either >=20 > Have you inverted the two? > > Please add "if this is the value 65535, then this route has been retracte= d and > is temporarily unreachable (see Section 3.5.5 of [RFC6126bis])". To avoid ambiguity, I've renamed to babel-route-received-metric and babel-r= oute-calculated-metric. ***opinion need***: The current definition (for the what is now received-me= tric) says "maximum value (infinity)" will indicate retraction, which is co= nsistent with language of section 3.5.5. And calculated-metric has nothing = similar. Are you suggesting (a) received-metric should replace "maximum val= ue (infinity)" with 65535 and calculated-metric should have this statement = added, (b) received-metric should continue to use "maximum value (infinity)= " but calculated-metric should have the statement you suggest (with 65535),= or (c) would it be better for both to use "maximum value (infinity)" in su= ch a statement? I'm going with choice (c) in absence of additional advice. =20 > babel-route-feasible: a boolean flag indicating whether this route > is known to work; a route that is not feasible will never be > selected=20 > A boolean flag indicating whether this route is feasible, as defined in S= ection > 3.5.1 of [RFC6126bis]. OK. Changed. =20 > 5. Do we need a registry for the supported security mechanisms? >=20 > No. OK. Issue moved to Closed. From nobody Tue Jun 5 10:40:31 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3E913110C for ; Tue, 5 Jun 2018 10:40:29 -0700 (PDT) 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 GZ6qElJULn1q for ; Tue, 5 Jun 2018 10:40:27 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91CE1310EC for ; Tue, 5 Jun 2018 10:40:27 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w55HarpD028447; Tue, 5 Jun 2018 13:40:27 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 2jdy2r8330-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Jun 2018 13:40:26 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w55HeN7q018955; Tue, 5 Jun 2018 13:40:24 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w55HeLHX018878; Tue, 5 Jun 2018 13:40:21 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 3221D40002A4; Tue, 5 Jun 2018 17:40:21 +0000 (GMT) Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (unknown [130.8.218.152]) by zlp30488.vci.att.com (Service) with ESMTPS id 1D72D40002AE; Tue, 5 Jun 2018 17:40:21 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.42]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0399.000; Tue, 5 Jun 2018 13:40:20 -0400 From: "STARK, BARBARA H" To: =?iso-8859-1?Q?=27Toke_H=F8iland-J=F8rgensen=27?= , "babel@ietf.org" Thread-Topic: [babel] I-D Action: draft-ietf-babel-information-model-02.txt Thread-Index: AQHTzTHqUGLPde4vy02uVWpeD+EO3qPyyfnggAMgZgCAXAtYEA== Date: Tue, 5 Jun 2018 17:40:20 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DDD4027@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <152296922074.3735.16897081899496814064@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114DD686A8@GAALPA1MSGUSRBF.ITServices.sbc.com> <87y3hyam6h.fsf@toke.dk> In-Reply-To: <87y3hyam6h.fsf@toke.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.234] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-05_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806050202 Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-02.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 17:40:30 -0000 Response in-line. There are some questions interspersed. Barbara > From: Toke H=F8iland-J=F8rgensen > > babel-ucast-hello-interval: the current unicast hello interval in > > use for this interface >=20 > Shouldn't this be per-neighbour? Good question. I don't see anything in source-specific that suggests differ= ent intervals will be used for different destinations, so I don't know. Wha= t are y'all developers doing? Is it possible that y'all's code will cause d= ifferent Hello intervals to be sent to different destinations? It seems eas= ier to keep this at an interface level, and all the costs used to determine= an interval are at the interface level.=20 Also... Right now the neighbor table is only about messages received from n= eighbors and the responses to those messages. Would there be concern with a= ssuming neighbors =3D specific destinations (and using a single table for b= oth) -- is there a necessary correlation of neighbors to source-specific de= stinations? Or, if we need to express information related to specific desti= nations, should that be a distinct table? > > babel-message-log: log entries that have timestamp of a received > > Babel message and the entire received Babel message, including > > Ethernet frame and IP headers; an implementation must restrict the > > size of this log, but how and what size is > > implementation-specific >=20 > A userspace implementation doesn't necessarily have access to the Etherne= t > and IP headers. Good point. I've added the words "if possible" to the Ethernet frame and IP= headers clause. I also did this for the credentials log. It's definitely d= esirable. > > babel-neighbor-ihu-interval: current IHU interval for this > > neighbor >=20 > The IHU interval (i.e. the value put into an IHU TLV) is not necessarily > available; it is perfectly sensible to just store the expiry time. Why would the value put in the TLV not be available? I could make this opti= onal, if it may be hard to record this value when sent. By "expiry time" do= you mean the current value of the timer, or something else? What I was try= ing to get at by knowing the sent IHU TLV interval was what this babel inst= ance's expectations were as to how frequent it needed to be getting Hellos = from this neighbor. Comparing the different intervals used for different ne= ighbors on an interface can be valuable information in understanding a netw= ork, if those intervals vary. Or should they vary? I'm not sure how I would= use "expiry time" or why I should care about it? > > babel-security-supported: list of supported security mechanisms >=20 > So every security object contains the entire list of supported security > mechanisms? Until this point I was under the impression that the logic wa= s > one security object per mechanism... Hmm. That's a great suggestion. I like that idea. That solves certain thing= s that were bothering me. I'll change security to be a separate object inst= ance per mechanism. I'll need to move the list of supported security mechan= isms up to the top level object. But this will let me put an enable/disable= parameter inside the object and get rid of the strange list of enabled sec= urity mechanisms. Having credentials split up by mechanism means credential= s are maintained per mechanism instead of centrally. Since credentials for = HMAC and DTLS are so disparate I don't think there's a chance they could us= e the same credentials so maintaining per mechanism is ok. I'll make this c= hange. =20 > > 1. babel-interfaces-obj: Juliusz:"This needs further discussion, I > > fear some of these are implementation details." [In the absence > > of discussion, the current model stands. Note that all but > > link-type and the neighbors sub-object are optional; if an > > implementation does not have any of the optional elements then > > it simply doesn't have them and that's fine.] >=20 > The information currently in the draft (apart from the message log), I al= so > added as debug output in Bird, so I think it makes sense to include it. I= also > output current v4/v6 nexthop addresses used for routes announced over > each interface; may be useful to include, since the mapping from addresse= s > assigned to the interface is not always obvious, so may be useful to see = what > a particular implementation picked? How will this (per interface route next hop) be different from the route ob= ject babel-route-next-hop parameter for each announced route? I don't quite= understand. From nobody Tue Jun 5 10:42:19 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D43A127333 for ; Tue, 5 Jun 2018 10:42:17 -0700 (PDT) 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 Yss4sUy3RYiE for ; Tue, 5 Jun 2018 10:42:15 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58E013110C for ; Tue, 5 Jun 2018 10:42:14 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w55HanZq028389; Tue, 5 Jun 2018 13:41:06 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 2jdy2r83t9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Jun 2018 13:41:05 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w55Hf4ow020621; Tue, 5 Jun 2018 13:41:04 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w55Hf1IR020493; Tue, 5 Jun 2018 13:41:01 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id BEE5140002D0; Tue, 5 Jun 2018 17:41:01 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30486.vci.att.com (Service) with ESMTPS id AA6A640002A2; Tue, 5 Jun 2018 17:41:01 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.42]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0399.000; Tue, 5 Jun 2018 13:41:01 -0400 From: "STARK, BARBARA H" To: "'dschinazi@apple.com'" CC: "babel@ietf.org" Thread-Topic: [babel] (David) I-D Action: draft-ietf-babel-information-model-02.txt Thread-Index: AdP89F3pGMVybPRLSqu0le964B4aAA== Date: Tue, 5 Jun 2018 17:41:00 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DDD4038@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.61.166.234] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-05_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=657 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806050202 Archived-At: Subject: Re: [babel] (David) I-D Action: draft-ietf-babel-information-model-02.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 17:42:17 -0000 UmVzcG9uc2UgaW4tbGluZS4NCkJhcmJhcmENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBkc2NoaW5hemlAYXBwbGUuY29tIDxkc2NoaW5hemlAYXBwbGUuY29tPg0KPiAN Cj4gVHdvIG1pbm9yIGNvbW1lbnRzOg0KPiANCj4gMSkgYmFiZWwtaGVsbG8tW211XWNhc3QtaGlz dG9yeSBpcyBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwgZG9jdW1lbnRlZCBpbg0KPiBhbiBhcHBl bmRpeCwgc2hvdWxkIGl0IGJlIGV4cG9zZWQ/DQo+IElzbid0IHJ4Y29zdC90eGNvc3QvY29zdCBz dWZmaWNpZW50Pw0KDQpUaGUgc3Vic2VxdWVudCB0aHJlYWQgb24gdGhpcyBzdWdnZXN0ZWQgaXQg d2FzIG9rIHRvIGtlZXAgdGhpcyBhcyBhbiBvcHRpb25hbCBwYXJhbWV0ZXIuIFNvIEkgbGVmdCBp dC4NCiANCj4gMikgUmVnYXJkaW5nIHNlY3VyaXR5LCBzaG91bGQgaXQgYmUgcG9zc2libGUgdG8g cHVsbCB0aGUgcHJpdmF0ZSBrZXkgZnJvbSBhDQo+IHJvdXRlcj8gSXMgdGhhdCBjb21tb24gcHJh Y3RpY2U/DQoNClRoZSBzdWJzZXF1ZW50IHRocmVhZCBvbiB0aGlzIHN1Z2dlc3RlZCB0aGUgZ2Vu ZXJhbCBkZXNpZ24gb2YgdGhlIGluZm8gbW9kZWwgd2FzIG9rLiBCdXQgSSBkaWQgYWRkIGEgc3Rh dGVtZW50IHRvIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgc2VsZi1jcmVkZW50aWFsIHBhcmFtZXRl ciB0aGF0IHNhaWQgImFueSBwcml2YXRlIGtleSBjb21wb25lbnQgb2YgYSBjcmVkZW50aWFsIE1V U1QgTk9UIGJlIHJlYWRhYmxlIi4NCg== From nobody Tue Jun 5 12:27:16 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E55131144 for ; Tue, 5 Jun 2018 12:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 v_Zs1xrQuQDC for ; Tue, 5 Jun 2018 12:27:14 -0700 (PDT) Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C57613113F for ; Tue, 5 Jun 2018 12:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1528226833; x=2392140433; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eERukPS1PZ+YbP+r1DMIEt1g3WfpNu2Zg7MhRrLOlMg=; b=i5OSrUXKIlXixZp2FaExfkog7XgH4C3IAv8hEHZo/dPL41zDEHAZIr0/J96mAPul q1RtLnjpva6Fnq2aE6uLfkxvD1sRI5L7J727Vs5BZQra63HRuf1fjC4yeZxhvz3r CihOgLrZf2YiY5aUaY5jB+Y8GS0NJ679AY2spGJ+wFnn0kZRMUxOI0TWzDRM1SLY iO08cautUFIymZEV2Imryg+6vyJXNk0Za8D4KH1wq40gvmNSAOqAPEN8o3a3+Aca qqXzDMKBotAYcfyU+IaMvS+soeZMEoSJXyGISltdva9AF7I7QKKBB9t8MrDakXp4 QKoOMFRsrMQ6ced50HtrGw==; X-AuditID: 11ab0216-c7fff70000002f11-8f-5b16e4101293 Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id 44.D6.12049.014E61B5; Tue, 5 Jun 2018 12:27:13 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ma1-mmpp-sz11.apple.com (ma1-mmpp-sz11.apple.com [17.171.128.33]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0P9V006BH7DCUVG0@mr2-mtap-s03.rno.apple.com>; Tue, 05 Jun 2018 12:27:12 -0700 (PDT) Received: from [17.192.155.180] by ma1-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P9V000A67C10Q40@ma1-mmpp-sz11.apple.com>; Tue, 05 Jun 2018 12:27:12 -0700 (PDT) X-Va-A: X-Va-T-CD: 81ca60fce39c2560b6c4a7e5841f9b8f X-Va-E-CD: 9d350d132d3d404e9be533d1caf7f9f5 X-Va-R-CD: 281e1556a41c271e9cb7ffa2aa9663d6 X-Va-CD: 0 X-Va-ID: f8096ac9-fe0d-40cd-8f14-e9ce663f9452 X-V-A: X-V-T-CD: c190214d8f986553c2d21c1d439ea442 X-V-E-CD: 9d350d132d3d404e9be533d1caf7f9f5 X-V-R-CD: 281e1556a41c271e9cb7ffa2aa9663d6 X-V-CD: 0 X-V-ID: 93481e52-67ae-4912-9741-7a1f5e7585da X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-05_09:,, signatures=0 Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <2D09D61DDFA73D4C884805CC7865E6114DDD4038@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Tue, 05 Jun 2018 12:27:10 -0700 Cc: "babel@ietf.org" Message-id: References: <2D09D61DDFA73D4C884805CC7865E6114DDD4038@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUiuPlRu67gE7Fog9knuC22LOpmsZj09yej A5PHy/45jB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4emkKc8Fsjoqdx48yNzBeY+ti5OSQEDCR ODT3BHMXIxeHkMBBJolLs+4xgSR4BQQlfky+x9LFyMHBLCAvcfC8LEiYWUBL4vujVhaI+nVM Eh0TT0M53xglrr/rZoGYyi7x59cOKFtbYunXBcww9rPnPXD2o4azTBA2l8SCradZIWxdiakz G6DibBLrTyyBsrUkFs3+zgZjz964Ac5ue/KXHcLmlDj/ZSKUrSMx9dwBqJnZElvXnGYEsYUF pCW6LtxlhbBDJOY3fgB7kg1ozoE1RiBhToEYiYYXt8DKWQRUJRYtfMEG8byqxKqNK6DhYyOx ufEuWFxIIFpi1vspYPUiAuoSq6ZNh1qrJDH9+222CYxys5CCdBYiSGchBekCRuZVjMK5iZk5 upl5RkZ6iQUFOal6yfm5mxhBEb6aSWwH473XhocYBTgYlXh4V3SLRQuxJpYVV+YeYpTmYFES 5/24CygkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMeBsicUPSb8D+6ccDJTV4zSxmRrPcUh1 R/SJYy8LYk8JP1zCw2G2Z/tit4i938+sMf85dWbHHbNJx7Z6djjK8eRxzFJh6zwQ/nxiUlWm TfsPH7OzX1aEOys133v7s1rwR3HhbeGy5TruUtsluq21hfu79h107njIf3a5zey6Qu91i8/M 0EpKUmIpzkg01GIuKk4EANecE0bRAgAA Archived-At: Subject: Re: [babel] (David) I-D Action: draft-ietf-babel-information-model-02.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 19:27:16 -0000 Thanks Barbara, that works for me. David > On Jun 5, 2018, at 10:41, STARK, BARBARA H wrote: > > Response in-line. > Barbara > >> -----Original Message----- >> From: dschinazi@apple.com >> >> Two minor comments: >> >> 1) babel-hello-[mu]cast-history is an implementation detail documented in >> an appendix, should it be exposed? >> Isn't rxcost/txcost/cost sufficient? > > The subsequent thread on this suggested it was ok to keep this as an optional parameter. So I left it. > >> 2) Regarding security, should it be possible to pull the private key from a >> router? Is that common practice? > > The subsequent thread on this suggested the general design of the info model was ok. But I did add a statement to the description of the self-credential parameter that said "any private key component of a credential MUST NOT be readable". > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Tue Jun 5 14:26:34 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA9413119B for ; Tue, 5 Jun 2018 14:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 hFEmFQmqnbaE for ; Tue, 5 Jun 2018 14:26:29 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6975B130DE0 for ; Tue, 5 Jun 2018 14:26:29 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1528233985; bh=m46Jh5r3hs+g2GE7DBIOHWyT4eoOFSk6isfXp7urhEE=; h=From:To:Subject:In-Reply-To:References:Date:From; b=MXXZnlvJG2GftfoCU2wTh0Z08UyJtRKCBZKjoJirgmYMspbqz06NXiMqyBJTjeyiZ 7rQnhftL+J/eVgEabPBcI7/XsfP/ovlUqwh6tJQiEFS6a7qzs4GUpUanOPRmIfme1+ W+J/boNCxP7QQ3GPB05p9mEStK2vEnta8LVW0psllXtCzCXkNQRBKasJvBTnrBMGiC HdjHz4rLlHBw9FeSz/48rYzLfiyr6zveGtyGUMFEWQHo0mhoiFcSJpHYeTVLMjCmVG ECSiExj/oSc7L6oZ7ykAyKA2PeQKyvnoyIJguzWlnLVR2GNzL5uizK7dgXCHJ2gF7r O3Tsip0X0FtPg== To: "STARK\, BARBARA H" , "babel\@ietf.org" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DDD4027@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <152296922074.3735.16897081899496814064@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114DD686A8@GAALPA1MSGUSRBF.ITServices.sbc.com> <87y3hyam6h.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DDD4027@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Tue, 05 Jun 2018 23:26:32 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <874liggc1j.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-02.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 21:26:33 -0000 "STARK, BARBARA H" writes: > Response in-line. There are some questions interspersed. > Barbara > >> From: Toke H=C3=B8iland-J=C3=B8rgensen >> > babel-ucast-hello-interval: the current unicast hello interval in >> > use for this interface >>=20 >> Shouldn't this be per-neighbour? > > Good question. I don't see anything in source-specific that suggests > different intervals will be used for different destinations, so I > don't know. What are y'all developers doing? Is it possible that > y'all's code will cause different Hello intervals to be sent to > different destinations? Well, not presently. > It seems easier to keep this at an interface level, and all the costs > used to determine an interval are at the interface level. Sure. But there's nothing in 6126bis that mandates this. So I'm mostly thinking that maybe the information model is not the place to specify that this must be the case? > Also... Right now the neighbor table is only about messages received > from neighbors and the responses to those messages. Would there be > concern with assuming neighbors =3D specific destinations (and using a > single table for both) -- is there a necessary correlation of > neighbors to source-specific destinations? Or, if we need to express > information related to specific destinations, should that be a > distinct table? Erm, not sure I'm following here. What's a destination? And what do you mean by source-specific destination in particular? Are you talking about the extension, or the 'source' data type in 6126bis? >> > babel-message-log: log entries that have timestamp of a received >> > Babel message and the entire received Babel message, including >> > Ethernet frame and IP headers; an implementation must restrict the >> > size of this log, but how and what size is >> > implementation-specific >>=20 >> A userspace implementation doesn't necessarily have access to the Ethern= et >> and IP headers. > > Good point. I've added the words "if possible" to the Ethernet frame > and IP headers clause. I also did this for the credentials log. It's > definitely desirable. Cool. >> > babel-neighbor-ihu-interval: current IHU interval for this >> > neighbor >>=20 >> The IHU interval (i.e. the value put into an IHU TLV) is not necessarily >> available; it is perfectly sensible to just store the expiry time. > > Why would the value put in the TLV not be available? I could make this > optional, if it may be hard to record this value when sent. By "expiry > time" do you mean the current value of the timer, or something else? Currently, when an IHU packet comes in, I set a timer for when it is going to expire (say, IHU interval 10 seconds, timer set at T+10s). Now, if you ask me four seconds later what the IHU interval is, I can only tell you that I expect another IHU within the next 6 seconds; but not that the last one was sent four seconds ago. > What I was trying to get at by knowing the sent IHU TLV interval was > what this babel instance's expectations were as to how frequent it > needed to be getting Hellos from this neighbor. Comparing the > different intervals used for different neighbors on an interface can > be valuable information in understanding a network, if those intervals > vary. Or should they vary? I'm not sure how I would use "expiry time" > or why I should care about it? Well, the expiry time as explained above is an indicator that tells you something like, but not the same as, the actual advertised interval. I.e., when you display the current timers you're basically getting a random sample in the interval [0;IHU interval sent]. >> > babel-security-supported: list of supported security mechanisms >>=20 >> So every security object contains the entire list of supported security >> mechanisms? Until this point I was under the impression that the logic w= as >> one security object per mechanism... > > Hmm. That's a great suggestion. I like that idea. That solves certain > things that were bothering me. I'll change security to be a separate > object instance per mechanism. I'll need to move the list of supported > security mechanisms up to the top level object. But this will let me > put an enable/disable parameter inside the object and get rid of the > strange list of enabled security mechanisms. Having credentials split > up by mechanism means credentials are maintained per mechanism instead > of centrally. Since credentials for HMAC and DTLS are so disparate I > don't think there's a chance they could use the same credentials so > maintaining per mechanism is ok. I'll make this change. Great! >> > 1. babel-interfaces-obj: Juliusz:"This needs further discussion, I >> > fear some of these are implementation details." [In the absence >> > of discussion, the current model stands. Note that all but >> > link-type and the neighbors sub-object are optional; if an >> > implementation does not have any of the optional elements then >> > it simply doesn't have them and that's fine.] >>=20 >> The information currently in the draft (apart from the message log), I a= lso >> added as debug output in Bird, so I think it makes sense to include it. = I also >> output current v4/v6 nexthop addresses used for routes announced over >> each interface; may be useful to include, since the mapping from address= es >> assigned to the interface is not always obvious, so may be useful to see= what >> a particular implementation picked? > > How will this (per interface route next hop) be different from the > route object babel-route-next-hop parameter for each announced route? > I don't quite understand. Well it shouldn't be. But there may be configured interfaces that don't currently export any routes (due to filters, or just if the instance has just started up). In this case it may be useful to know which address is going to be used when a route shows up in the future. Also, the interface next hop value may be configurable (it is in Bird at least). -Toke From nobody Wed Jun 6 18:44:03 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177F013107A for ; Wed, 6 Jun 2018 18:44:01 -0700 (PDT) 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, 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 PfBiOszWtFJ5 for ; Wed, 6 Jun 2018 18:43:57 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5881130E16 for ; Wed, 6 Jun 2018 18:43:56 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w571hqg7031119; Thu, 7 Jun 2018 03:43:52 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id B81AFEB22D; Thu, 7 Jun 2018 03:43:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id VW73FVglncpC; Thu, 7 Jun 2018 03:43:50 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3E6F5EB200; Thu, 7 Jun 2018 03:43:50 +0200 (CEST) Date: Thu, 07 Jun 2018 03:43:50 +0200 Message-ID: <87a7s7jrqh.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: "STARK, BARBARA H" , "babel@ietf.org" In-Reply-To: <874liggc1j.fsf@toke.dk> References: <152296922074.3735.16897081899496814064@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114DD686A8@GAALPA1MSGUSRBF.ITServices.sbc.com> <87y3hyam6h.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DDD4027@GAALPA1MSGUSRBF.ITServices.sbc.com> <874liggc1j.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 07 Jun 2018 03:43:53 +0200 (CEST) X-Miltered: at korolev with ID 5B188DD8.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B188DD8.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B188DD8.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-02.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 01:44:01 -0000 >> Good question. I don't see anything in source-specific that suggests >> different intervals will be used for different destinations, Note that this has nothing to do with source-specific, which creates a new class of routes but doesn't change anything to neighbour discovery. >> so I don't know. What are y'all developers doing? Is it possible that >> y'all's code will cause different Hello intervals to be sent to >> different destinations? > Well, not presently. The protocol allows it. We don't have much experience with unicast hellos yet. >> It seems easier to keep this at an interface level, and all the costs >> used to determine an interval are at the interface level. > Sure. But there's nothing in 6126bis that mandates this. So I'm mostly > thinking that maybe the information model is not the place to specify > that this must be the case? On the other hand, it's an optional field, so an implementation that uses per-neighbour values can simply omit it. Barbara, I have no strong feelings either way, but I rather agree with Toke. >> Or, if we need to express information related to specific destinations, >> should that be a distinct table? A destination is either an interface (for a multicast packet) or a neighbour (for a unicast packet). Creating a new table for destinations does not feel right. (In my implementation, destinations are interfaces and neighbours, as outlined above, except that both structures delegate common functionality to a "struct buffered", which would correspond to your intuition of a destination. I might rename it to destination.) >>> > babel-neighbor-ihu-interval: current IHU interval for this >>> > neighbor >>> >>> The IHU interval (i.e. the value put into an IHU TLV) is not necessarily >>> available; it is perfectly sensible to just store the expiry time. > Currently, when an IHU packet comes in, I set a timer for when it is > going to expire (say, IHU interval 10 seconds, timer set at T+10s). Now, > if you ask me four seconds later what the IHU interval is, I can only > tell you that I expect another IHU within the next 6 seconds; but not > that the last one was sent four seconds ago. Same here. >>> The information currently in the draft (apart from the message log), >>> I also added as debug output in Bird, so I think it makes sense to >>> include it. I also output current v4/v6 nexthop addresses used for >>> routes announced over each interface; may be useful to include, since >>> the mapping from addresses assigned to the interface is not always >>> obvious, so may be useful to see what a particular implementation >>> picked? >> How will this (per interface route next hop) be different from the >> route object babel-route-next-hop parameter for each announced route? >> I don't quite understand. The next hop of a route is the address of the neighbour. I think that Toke is speaking about the next-hop address that will be announced to neighbours, i.e. that will appear in the neighbour's routing table. -- Juliusz From nobody Wed Jun 6 18:58:33 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1C7130E15 for ; Wed, 6 Jun 2018 18:58:28 -0700 (PDT) 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, 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 lZhaZFQrm5bc for ; Wed, 6 Jun 2018 18:58:24 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4F5130DFD for ; Wed, 6 Jun 2018 18:58:24 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w571wKMY032628; Thu, 7 Jun 2018 03:58:21 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A6EF6EB22E; Thu, 7 Jun 2018 03:58:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id lmWubKWef2Ww; Thu, 7 Jun 2018 03:58:19 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6D8A6EB22D; Thu, 7 Jun 2018 03:58:19 +0200 (CEST) Date: Thu, 07 Jun 2018 03:58:19 +0200 Message-ID: <878t7rjr2c.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "babel@ietf.org" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DDD4012@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DDD4012@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 07 Jun 2018 03:58:21 +0200 (CEST) X-Miltered: at korolev with ID 5B18913C.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B18913C.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B18913C.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] (Juliusz) I-D Action: draft-ietf-babel-information-model-02.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 01:58:29 -0000 Good work, Barbara, thanks a lot. > Changed to string (and removed sentence under "int" data type that said > it was used for enumerations. But I used "ethernet" instead of > "wired". I really think at some point it may be useful to see if it > makes sense to treat technologies over coax and powerline (which are > also technically "wired") different from (physical layer) ethernet. Ok, I'll add an alias to the configuration language of babeld. >> > 3.2. Definition of babel-constants-obj >> I don't see a way to find out if this Babel instance is speaking IPv6, >> IPv4, or both. (Toke suggested we dump the IPv4 support, I'm half >> inclined to agree.) > Deleted [ip-address babel-mcast-group-ipv4;] Suggest renaming babel-mcast-group-ipv6 to babel-mcast-group. >> babel-neighbors: a set of babel-neighbors objects >> >> There's a "u" missing ;-) > Comment rejected. U can't make me (because, when u is missing there's > not much u can do). One of the major hurdles in first year Java programming is to learn to spell "length". (And then they claim that Polish has too many consonants.) >> babel-hello-mcast-history: [...] >> You need to specify the endiannness of this bitstring. Hmm, now it's a string but you speak about most-significant bits? I'm confused. > ***question***: It's possible for the same route to be advertised by > multiple neighbors, right? No. Multiple routes to the same destination can be announced by multiple neighbours, but Babel considers them as distinct routes. See 6126bis Section 3.2.6 -- two routes are the same if they have the same triple (prefix, plen, neighbour). > -- so is this entry the one that has been selected to actually use (and > -- other advertisements were discarded)? No. Of the multiple routes to a given destination, at most one is selected. >> babel-route-next-hop: the next-hop address of this route; this >> will be empty if this route has no next-hop address >> >> I suggest "if this is empty, the next hop is the address of the >> neighbour from which the route has been learnt." > ***opinion needed***: Hmm. If the next hop is the address of the > neighbor, then that's what should be in this parameter and it shouldn't > be empty. The purpose of "empty" (according to my notes of our > discussion) was for the case where this device itself is the "next > hop". I'm not making changes to this until we discuss. You're right. Artefact of my implementation. > ***opinion need***: The current definition (for the what is now > received-metric) says "maximum value (infinity)" will indicate > retraction, which is consistent with language of section 3.5.5. And > calculated-metric has nothing similar. Are you suggesting (a) > received-metric should replace "maximum value (infinity)" with 65535 and > calculated-metric should have this statement added, (b) received-metric > should continue to use "maximum value (infinity)" but calculated-metric > should have the statement you suggest (with 65535), or (c) would it be > better for both to use "maximum value (infinity)" in such a statement? > I'm going with choice (c) in absence of additional advice. Agreed. Thanks again, -- Juliusz From nobody Thu Jun 7 07:00:39 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0560E13115C for ; Thu, 7 Jun 2018 07:00:25 -0700 (PDT) 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, 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 oOSQzcEr6HsH for ; Thu, 7 Jun 2018 07:00:21 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC60130EF7 for ; Thu, 7 Jun 2018 07:00:20 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w57E0IWn000758; Thu, 7 Jun 2018 16:00:18 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A925AEB200; Thu, 7 Jun 2018 16:00:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id w4cDTqcToejQ; Thu, 7 Jun 2018 16:00:12 +0200 (CEST) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A0B57EB22E; Thu, 7 Jun 2018 16:00:12 +0200 (CEST) Date: Thu, 07 Jun 2018 16:00:12 +0200 Message-ID: <87po12d7df.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org CC: Clara =?ISO-8859-1?Q?D=F4?= , Weronika =?ISO-8859-2?Q?Ko=B3odziejak?= User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 07 Jun 2018 16:00:18 +0200 (CEST) X-Miltered: at korolev with ID 5B193A72.008 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B193A72.008 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B193A72.008 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Questions about HMAC authentication X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 14:00:33 -0000 Dear all, Clara and Weronika (in copy of this mail) have made some progress in implementing HMAC authentication. A few comments and questions. 1. What shall we put in the pseudo-header? Our current strawman proposal is source IP destination IP Do we need to add the port numbers (which are normally constant)? Anything else? (Note on this subject that including the source IP complicates the implementation somewhat -- at the time when you're generating the HMAC, the source address is not known yet; for it to be known, you need to either use a connected socket or double-guess the kernel. It's only a problem if the interface has multiple link-local addresses, which shouldn't normally happen.) 2. Denis' definition of the HMAC TLV contains a Key ID. We don't understand what the Key ID is for, so we're omitting it for now. We'd be grateful for guidance. 3. TS/PC is 32 bits of TS and 16 bits of PC. Make it 32+32? 4. I was thinking about adding a flag to TS/PC that indicates that the TS is UTC time modulo 2^32. This avoids a replay attack when both the sender and the receiver have a reliable hardware clock, but the receiver has lost its ANM state. (Suppose that A is sending TS/PC with the UTC bit set, and B has lost its ANM state. If B has a reliable clock, it can discard any packet that is more than one minute or so in the past, which avoids a trivial replay attack.) Advice? Criticism? Objections? -- Juliusz From nobody Thu Jun 7 07:22:40 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEF3130EF1 for ; Thu, 7 Jun 2018 07:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 FZ8Gn_m4y-QE for ; Thu, 7 Jun 2018 07:22:31 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1549130EFD for ; Thu, 7 Jun 2018 07:22:30 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1528381349; bh=45qFZ5HzL/8xIwPfiqasYTDctZt2sZGk8p62k1rFWRw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=jAHfEThkn+uKevFZqoA2GqQf5kvYAieyYA8qlldZ2Z+uzyOhXZwKg9dKDpMzhTjEU 9cd3YZwSIsePToxeegn3nsbKjyl9f5mua6QLJVruNGrYxs5/DAsMqZKsZ/7+vz/Q63 o8gH32FUFhDlDOe7ifWd0raqdZjFeowVseOkxjCGtJ3Wag6Gtnqk0G87ekZKP1BKQY WdLBMzGp0HlktEMiXNKlsBgLIR3U4e/PqAx2+ycENN9qzRnKPJFbrio6AJW3Wp5ySf LXna4I7XmTBwCOFvnTcQ/1HTQTfqMnFmg+r31VV+foPjW/nFSFBJzf41kV/F6tHOmP cRgG21uo5kEaA== To: Juliusz Chroboczek , babel@ietf.org Cc: Weronika =?utf-8?Q?Ko=C5=82odziejak?= , Clara =?utf-8?Q?D=C3=B4?= In-Reply-To: <87po12d7df.wl-jch@irif.fr> References: <87po12d7df.wl-jch@irif.fr> Date: Thu, 07 Jun 2018 16:22:28 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <874lieznff.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Questions about HMAC authentication X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 14:22:36 -0000 Juliusz Chroboczek writes: > Dear all, > > Clara and Weronika (in copy of this mail) have made some progress in > implementing HMAC authentication. A few comments and questions. > > 1. What shall we put in the pseudo-header? Our current strawman proposal is > > source IP > destination IP > > Do we need to add the port numbers (which are normally constant)? > Anything else? Hmm, technically you are not following the spec if you change the port number, are you? So it would technically be acceptable to exclude those? > (Note on this subject that including the source IP complicates the > implementation somewhat -- at the time when you're generating the HMAC, > the source address is not known yet; for it to be known, you need to > either use a connected socket or double-guess the kernel. It's only > a problem if the interface has multiple link-local addresses, which > shouldn't normally happen.) Well if you don't want to guess you could conceivably add a hash for each one? > 2. Denis' definition of the HMAC TLV contains a Key ID. We don't > understand what the Key ID is for, so we're omitting it for now. We'd be > grateful for guidance. As I understood it it's an ID that you put into your configuration, and you only verify a signature if you have a key with a corresponding ID. Cuts down on hash operations for things that wouldn't match anyway. If you don't use this, what do you do with multiple keys? > 3. TS/PC is 32 bits of TS and 16 bits of PC. Make it 32+32? Not sure. Why? > 4. I was thinking about adding a flag to TS/PC that indicates that the TS > is UTC time modulo 2^32. This avoids a replay attack when both the sender > and the receiver have a reliable hardware clock, but the receiver has lost > its ANM state. > > (Suppose that A is sending TS/PC with the UTC bit set, and B has lost its > ANM state. If B has a reliable clock, it can discard any packet that is > more than one minute or so in the past, which avoids a trivial replay > attack.) > > Advice? Criticism? Objections? How do you determine if you have a reliable clock? What happens if you are wrong? This seems like an option that most people would just end up turning off because someone somewhere had problems with clock accuracy an yelled about it on the internet... -Toke From nobody Sun Jun 10 06:50:36 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A527130E6E for ; Sun, 10 Jun 2018 06:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 h05pIte3r8lL for ; Sun, 10 Jun 2018 06:50:29 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F26130F49 for ; Sun, 10 Jun 2018 06:50:29 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1528638624; bh=5nZPJftaka0VRr6rHF/0rQHJ6qvDOAP4tMmotExyKL0=; h=From:To:Subject:Date:From; b=NIJazXzzaHDMfjDUIc8PWA1IpqFo5aovh9qb3LrENiYntHwoh8DzP3+MhAzzwkRZt pGmywtCfERchW0mvmpisy/0Jilu+eXsVOcQC5ISfhxrNRNWNP+37R3IXYICx1kjfea MOxt/CJHuW9RDWcmD3ByJJqNiJS00bhu3Q1Ulr/nexvnMGvZP3SqkSJRtvdzTMXh82 t6GXBoWbVYueg+FMYsIuVq1ev/ltzwPuTWQasdUtsmhpJtA7PivnGpOXGtD1aBUsyD ZIQhFuoOuAV41kb9WC1E9r9j8YUy6akgWqC3VwEwJm01IfeqV9ewoKSMUtpfZY/LL3 529BGYGiC5j1w== To: babel@ietf.org Date: Sun, 10 Jun 2018 15:50:24 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <8736xulpi7.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [babel] What to do if we don't know the next hop? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 13:50:33 -0000 Hey everyone Section 4.6.9 of 6126bis says this about next hops: > The next-hop address for this update is taken from the last preceding > Next Hop TLV with a matching address family (IPv4 or IPv6) in the > same packet even if it was otherwise ignored due to an unknown > mandatory sub-TLV; if no such TLV exists, it is taken from the > network-layer source address of this packet. However, when carrying IPv4 prefixes over a v6 transport, no network-layer source address exists. The document doesn't explicitly say what to do about such prefixes. The obvious answer is just to drop them, but should this be spelled out? And more importantly, should there be a prohibition against *sending* such TLVs? It is, evidently, quite possible to write an implementation that will happily distribute v4 routes over IPv6 with no valid next hop if configured to run on a link with no v4 addresses configured. I know because I did just that; the Bird implementation currently will not skip over v4 routes if it can't find a next hop. I'll get this fixed in the implementation, of course, but should this also be discussed in the spec? -Toke From nobody Sun Jun 10 08:15:43 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340E9130E70 for ; Sun, 10 Jun 2018 08:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 pnAVNQl4EXXO for ; Sun, 10 Jun 2018 08:15:39 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0BEC130DFF for ; Sun, 10 Jun 2018 08:15:38 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5AFFZE2015218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 Jun 2018 17:15:36 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w5AFFaS4020189; Sun, 10 Jun 2018 17:15:36 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 43CC3EB279; Sun, 10 Jun 2018 17:15:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id zyVdmJZrzUM3; Sun, 10 Jun 2018 17:15:33 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3E4C8EB200; Sun, 10 Jun 2018 17:15:31 +0200 (CEST) Date: Sun, 10 Jun 2018 17:15:31 +0200 Message-ID: <87wov6r7u4.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: babel@ietf.org In-Reply-To: <8736xulpi7.fsf@toke.dk> References: <8736xulpi7.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sun, 10 Jun 2018 17:15:37 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 10 Jun 2018 17:15:37 +0200 (CEST) X-Miltered: at korolev with ID 5B1D4097.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B1D4098.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B1D4097.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B1D4098.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B1D4097.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B1D4098.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] What to do if we don't know the next hop? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 15:15:42 -0000 > And more importantly, should there be a prohibition against *sending* > such TLVs? That's a tricky one. In the case of BGP, RFC 5549 allows just that -- announcing an IPv4 route with an IPv6 next hop. 5549 is pretty vague, but my understnading is that the forwarding plane would do an ND lookup for the IPv6 address of the next hop, then send IPv4 packets to the MAC address thus obtained. (The intent is to avoid assigning IPv4 addresses to transit links; it's a matter of preference whether to use an IPv6 next hop or borrow an IPv4 address from another link, Cisco-style.) More generally, RFC 6126bis is deliberately vague about the forwarding plane. The intent is that the protocol announces routes, you attempt to install the routes you grok, and keep the others uninstalled. - if you have no IPv4 stack, you drop any IPv4 routes; - if you cannot deal with IPv4 routes whose next hop is not in the directly connected prefix, you drop any IPv4 routes whose next hop is not in the directly connected prefix (that's what the BSD/Mac OS X port of babeld does, and what the old Quagga port used to do); - if you cannot deal with IPv4 routes with an IPv6 next hop, you drop IPv4 routes with an IPv6 next hop; - if you cannot deal with IPv6 routes whose next hop is not a link local, you drop any IPv6 routes whose next hop is not a link local. I don't think that these cases need to be made explicit in RFC 6126bis. I'm not sure if it's useful to mention that if you failed to install a route, you MUST NOT announce it. -- Juliusz From nobody Sun Jun 10 08:18:12 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174EE130E72 for ; Sun, 10 Jun 2018 08:18:11 -0700 (PDT) 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, 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 s79at5Y_xFrX for ; Sun, 10 Jun 2018 08:18:09 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E0E130DFF for ; Sun, 10 Jun 2018 08:18:09 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5AFI8Uf015705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 10 Jun 2018 17:18:08 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w5AFI9xE020576; Sun, 10 Jun 2018 17:18:09 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id DBD0FEB8C4; Sun, 10 Jun 2018 17:18:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 53wvwYPsVYml; Sun, 10 Jun 2018 17:18:06 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D28C9EB22E; Sun, 10 Jun 2018 17:18:06 +0200 (CEST) Date: Sun, 10 Jun 2018 17:18:06 +0200 Message-ID: <87vaaqr7pt.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: babel@ietf.org In-Reply-To: <87wov6r7u4.wl-jch@irif.fr> References: <8736xulpi7.fsf@toke.dk> <87wov6r7u4.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sun, 10 Jun 2018 17:18:08 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 10 Jun 2018 17:18:09 +0200 (CEST) X-Miltered: at korolev with ID 5B1D4130.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B1D4131.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B1D4130.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B1D4131.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B1D4130.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B1D4131.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] What to do if we don't know the next hop? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 15:18:11 -0000 > That's a tricky one. In the case of BGP, RFC 5549 allows just that -- > announcing an IPv4 route with an IPv6 next hop. 5549 is pretty vague, but > my understnading is that the forwarding plane would do an ND lookup for > the IPv6 address of the next hop, then send IPv4 packets to the MAC > address thus obtained. On the other hand, perhaps it would be better to explicitly require such routes to be dropped, in order to avoid confusion. If the feature is ever required, we'll write an extension to that effect. So: (1) leave it vague; (2) explicitly MUST DROP; (3) explicitly define meaning. I'm open to (1) and (2), I'm opposed to (3). Opinions? -- Juliusz From nobody Sun Jun 10 10:50:26 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF03130EB5 for ; Sun, 10 Jun 2018 10:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 Z3WFmD2RTLos for ; Sun, 10 Jun 2018 10:50:18 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F72130EA6 for ; Sun, 10 Jun 2018 10:50:18 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1528652598; bh=pXr7y67onIlExfjIb0RpYPFUpAkXwEWhjVKdZZ5sVLs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=r7Hn06qeFk8XkFqE5t9ttEDGOU5Lgqs3efnz9wH3IFqMYvt0A/X8RST5chVCVL2OO mBz5zMpvE2t8LOCdAd0HnivFqzgkj9s4E9Wpx5hS7j4aewEtkKsQZx2aUPmhXS0g/U z5t7CKZny9QIo0DHmO+bIE0qruI7fJ/yPStZ4jSsCKpL5fzp3wE8D/g/Gl3rPS/9qN afyllzHXRlkRAT6Vf22qhfUvJmfGgHjdvifCWSQa5FjJlugtWbCzMseAnYJSdkNRv8 oC41HB34dvZcoNkerWAENexel5GeJMLSiXgtqKU8cHqxKRz76If5z1BHeddbTxi30c A6m2NAQVWDDKQ== To: Juliusz Chroboczek Cc: babel@ietf.org In-Reply-To: <87vaaqr7pt.wl-jch@irif.fr> References: <8736xulpi7.fsf@toke.dk> <87wov6r7u4.wl-jch@irif.fr> <87vaaqr7pt.wl-jch@irif.fr> Date: Sun, 10 Jun 2018 19:43:18 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87tvqak05l.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] What to do if we don't know the next hop? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 17:50:22 -0000 Juliusz Chroboczek writes: >> That's a tricky one. In the case of BGP, RFC 5549 allows just that -- >> announcing an IPv4 route with an IPv6 next hop. 5549 is pretty vague, but >> my understnading is that the forwarding plane would do an ND lookup for >> the IPv6 address of the next hop, then send IPv4 packets to the MAC >> address thus obtained. > > On the other hand, perhaps it would be better to explicitly require such > routes to be dropped, in order to avoid confusion. If the feature is ever > required, we'll write an extension to that effect. > > So: > > (1) leave it vague; > (2) explicitly MUST DROP; > (3) explicitly define meaning. > > I'm open to (1) and (2), I'm opposed to (3). Opinions? I think I'd prefer (2). I agree that we shouldn't open the can of worms that (3) implies :) -Toke From nobody Sun Jun 10 18:42:00 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700E4130DD2 for ; Sun, 10 Jun 2018 18:41:59 -0700 (PDT) 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 X6wNuGd8wcnv for ; Sun, 10 Jun 2018 18:41:58 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220A0130DD0 for ; Sun, 10 Jun 2018 18:41:58 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w5B1crBE016908; Sun, 10 Jun 2018 21:41:57 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2jhfj4g1pt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 10 Jun 2018 21:41:57 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w5B1ftvq017480; Sun, 10 Jun 2018 21:41:55 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w5B1fpPX017448; Sun, 10 Jun 2018 21:41:51 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 869A140002B4; Mon, 11 Jun 2018 01:41:51 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30486.vci.att.com (Service) with ESMTPS id 7460540002A3; Mon, 11 Jun 2018 01:41:51 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.78]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0399.000; Sun, 10 Jun 2018 21:41:50 -0400 From: "STARK, BARBARA H" To: =?iso-8859-1?Q?=27Toke_H=F8iland-J=F8rgensen=27?= , "Juliusz Chroboczek" CC: "babel@ietf.org" Thread-Topic: [babel] What to do if we don't know the next hop? Thread-Index: AQHUAMIJ4R5KQzM60U+RLxUgyiAOmqRZ3UiAgAAAuACAACiSAIAAQVvA Date: Mon, 11 Jun 2018 01:41:50 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DDE191F@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8736xulpi7.fsf@toke.dk> <87wov6r7u4.wl-jch@irif.fr> <87vaaqr7pt.wl-jch@irif.fr> <87tvqak05l.fsf@toke.dk> In-Reply-To: <87tvqak05l.fsf@toke.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.219.137] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-11_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=5 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=5 clxscore=1015 lowpriorityscore=0 mlxscore=5 impostorscore=0 mlxlogscore=130 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806110018 Archived-At: Subject: Re: [babel] What to do if we don't know the next hop? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 01:42:00 -0000 > >> That's a tricky one. In the case of BGP, RFC 5549 allows just that > >> -- announcing an IPv4 route with an IPv6 next hop. 5549 is pretty > >> vague, but my understnading is that the forwarding plane would do an > >> ND lookup for the IPv6 address of the next hop, then send IPv4 > >> packets to the MAC address thus obtained. > > > > On the other hand, perhaps it would be better to explicitly require > > such routes to be dropped, in order to avoid confusion. If the > > feature is ever required, we'll write an extension to that effect. > > > > So: > > > > (1) leave it vague; > > (2) explicitly MUST DROP; > > (3) explicitly define meaning. > > > > I'm open to (1) and (2), I'm opposed to (3). Opinions? >=20 > I think I'd prefer (2). I agree that we shouldn't open the can of worms t= hat (3) > implies :) I like the simplicity and consistent behavior of (2).=20 Barbara From nobody Mon Jun 11 08:39:17 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF75E130DCA for ; Mon, 11 Jun 2018 08:39:15 -0700 (PDT) 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] 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 nPfdwbgVFSyJ for ; Mon, 11 Jun 2018 08:39:13 -0700 (PDT) Received: from mail.crfreenet.org (varda.crfreenet.org [81.92.145.160]) by ietfa.amsl.com (Postfix) with ESMTP id DDC8212D949 for ; Mon, 11 Jun 2018 08:39:12 -0700 (PDT) Received: from feanor (feanor-poda.crfreenet.org [164.215.121.182]) by mail.crfreenet.org (Postfix) with ESMTP id 24D9A5FB98; Mon, 11 Jun 2018 17:39:11 +0200 (CEST) Date: Mon, 11 Jun 2018 17:39:10 +0200 From: Ondrej Zajicek To: Juliusz Chroboczek Cc: Toke =?iso-8859-1?Q?H=F8iland-J=F8rgensen?= , babel@ietf.org Message-ID: <20180611153910.tjuuawwguxt5x4ru@feanor.crfreenet.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [babel] What to do if we don't know the next hop? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 15:39:16 -0000 >> That's a tricky one. In the case of BGP, RFC 5549 allows just that -- >> announcing an IPv4 route with an IPv6 next hop. 5549 is pretty vague, but >> my understnading is that the forwarding plane would do an ND lookup for >> the IPv6 address of the next hop, then send IPv4 packets to the MAC >> address thus obtained. > > On the other hand, perhaps it would be better to explicitly require such > routes to be dropped, in order to avoid confusion. If the feature is ever > required, we'll write an extension to that effect. > > So: > > (1) leave it vague; > (2) explicitly MUST DROP; > (3) explicitly define meaning. > > I'm open to (1) and (2), I'm opposed to (3). Opinions? Hi I am generally in favor of RFC_5549-like behavior, so i would prefer this: 1) Loose the description in 4.4.9 Next hop such that the default next hop is the source address for address families where such address is applicable (instead of 'matching'). 2) Explicitly MUST DROP silently for cases where there is no default next hop (i.e. source address not applicable and no matching next hop TLV). [*] 3) Sending such updates is allowed. What means by 'address is applicable' depends on whether platform supports RFC_5549-style routes. Note that only the receiver ability to use RFC_5549-style routes is relevant (as route announcer is able to receive the packet regarless of how receiver resolved the MAC address), so there is no need to signalize the ability. And the situation is analogous to whether receiver support next hops is not in the directly connected prefix. Although it is true that for full RFC_5549-like support it would be necessary to define a new TLV or a next hop sub-TLV to be able to send explicit next hops of different address families, in most cases (esp. when third-party next hops are discouraged) the above behavior would be enough. [*] Or perhaps the receiver could keep such routes and do not use and propagate them, but it definitely should not handle such updates with packet parse error. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From nobody Mon Jun 11 12:40:52 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD35130EBF for ; Mon, 11 Jun 2018 12:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 NMRaihYeM2hP for ; Mon, 11 Jun 2018 12:40:48 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284D2130EBC for ; Mon, 11 Jun 2018 12:40:48 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1528746037; bh=4ItF3b1wHMU4KrA5pzf8/o0f63RVPNKfSK+bVdstvBg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=BsNM2ahI9ox4TpHS7XSP8oewaJ1yMDoD3zTu5loElQ3509kuIcz1CYX4XGWPCO5BG Vu7UEMw5mgEgGnvTnOa0jNkSOVQKCnLBHd1+Ij9F5eevhLOA0isVErvSy5FtYXzNcD eVIfWzBuLPFUI8yFaY8wQayq5wP1CaCMldJOE0f6jmfGBRPeRSKyfqTIqE/N7mljfz 09J70lPwdcdlvjEvdYEQrUf1Jv64pYD6/FzPjdkNqC8kxP5gwQ56dgJ2Dv3oOHspdL nxf3kkDHmQV39/Jg8gyeLxsrE49l+3/mMObDd9u2CWR5IinOjOmOeuHl2FCiE+zsYp eI+pva/dwnRdQ== To: Ondrej Zajicek , Juliusz Chroboczek Cc: babel@ietf.org In-Reply-To: <20180611153910.tjuuawwguxt5x4ru@feanor.crfreenet.org> References: <20180611153910.tjuuawwguxt5x4ru@feanor.crfreenet.org> Date: Mon, 11 Jun 2018 21:40:34 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87zi01i025.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] What to do if we don't know the next hop? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 19:40:51 -0000 Ondrej Zajicek writes: >>> That's a tricky one. In the case of BGP, RFC 5549 allows just that -- >>> announcing an IPv4 route with an IPv6 next hop. 5549 is pretty vague, but >>> my understnading is that the forwarding plane would do an ND lookup for >>> the IPv6 address of the next hop, then send IPv4 packets to the MAC >>> address thus obtained. >> >> On the other hand, perhaps it would be better to explicitly require such >> routes to be dropped, in order to avoid confusion. If the feature is ever >> required, we'll write an extension to that effect. >> >> So: >> >> (1) leave it vague; >> (2) explicitly MUST DROP; >> (3) explicitly define meaning. >> >> I'm open to (1) and (2), I'm opposed to (3). Opinions? > > Hi > > I am generally in favor of RFC_5549-like behavior, so i would prefer > this: > > 1) Loose the description in 4.4.9 Next hop such that the default next hop > is the source address for address families where such address is > applicable (instead of 'matching'). > > 2) Explicitly MUST DROP silently for cases where there is no default next > hop (i.e. source address not applicable and no matching next hop TLV). [*] > > 3) Sending such updates is allowed. > > > What means by 'address is applicable' depends on whether platform > supports RFC_5549-style routes. Note that only the receiver ability to > use RFC_5549-style routes is relevant (as route announcer is able to > receive the packet regarless of how receiver resolved the MAC address), > so there is no need to signalize the ability. And the situation > is analogous to whether receiver support next hops is not in the > directly connected prefix. Bit of a side note, but does Bird currently support his on Linux? And if so, how does it interface with the kernel routing table? > Although it is true that for full RFC_5549-like support it would be > necessary to define a new TLV or a next hop sub-TLV to be able to send > explicit next hops of different address families, in most cases (esp. > when third-party next hops are discouraged) the above behavior would > be enough. > > [*] Or perhaps the receiver could keep such routes and do not use and > propagate them, but it definitely should not handle such updates with > packet parse error. Oohh... only just realised that it is returning a parse error for the whole packet and not just ignoring the TLV. Oops. Can I trouble you to change that to return _IGNORE instead, or do you want me to send a patch? :) -Toke From nobody Mon Jun 11 12:48:06 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685A0130EC8 for ; Mon, 11 Jun 2018 12:48:04 -0700 (PDT) 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] 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 ObZAsMs9E90m for ; Mon, 11 Jun 2018 12:48:02 -0700 (PDT) Received: from mail.crfreenet.org (varda.crfreenet.org [81.92.145.160]) by ietfa.amsl.com (Postfix) with ESMTP id 168D0130EC3 for ; Mon, 11 Jun 2018 12:48:01 -0700 (PDT) Received: from feanor (feanor-poda.crfreenet.org [164.215.121.182]) by mail.crfreenet.org (Postfix) with ESMTP id 47B735FBB6; Mon, 11 Jun 2018 21:48:01 +0200 (CEST) Date: Mon, 11 Jun 2018 21:48:01 +0200 From: Ondrej Zajicek To: Toke =?iso-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: Juliusz Chroboczek , babel@ietf.org Message-ID: <20180611194801.4kjecvannfpuqmr5@feanor.crfreenet.org> References: <20180611153910.tjuuawwguxt5x4ru@feanor.crfreenet.org> <87zi01i025.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <87zi01i025.fsf@toke.dk> X-Operating-System: Debian GNU/Linux User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [babel] What to do if we don't know the next hop? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 19:48:05 -0000 On Mon, Jun 11, 2018 at 09:40:34PM +0200, Toke H=F8iland-J=F8rgensen wrote: > > What means by 'address is applicable' depends on whether platform > > supports RFC_5549-style routes. Note that only the receiver ability to > > use RFC_5549-style routes is relevant (as route announcer is able to > > receive the packet regarless of how receiver resolved the MAC address), > > so there is no need to signalize the ability. And the situation > > is analogous to whether receiver support next hops is not in the > > directly connected prefix. >=20 > Bit of a side note, but does Bird currently support his on Linux? And if > so, how does it interface with the kernel routing table? Bird supports that for BGP, but cannot export such routes to kernel routing table because AFAIK Linux kernel does not support it yet. > > Although it is true that for full RFC_5549-like support it would be > > necessary to define a new TLV or a next hop sub-TLV to be able to send > > explicit next hops of different address families, in most cases (esp. > > when third-party next hops are discouraged) the above behavior would > > be enough. > > > > [*] Or perhaps the receiver could keep such routes and do not use and > > propagate them, but it definitely should not handle such updates with > > packet parse error. >=20 > Oohh... only just realised that it is returning a parse error for the > whole packet and not just ignoring the TLV. Oops. Can I trouble you to > change that to return _IGNORE instead, or do you want me to send a > patch? :) I will fix that. --=20 Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." From nobody Mon Jun 11 12:49:45 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3AC130ECB for ; Mon, 11 Jun 2018 12:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 5sez8YGYThPb for ; Mon, 11 Jun 2018 12:49:37 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89351310A6 for ; Mon, 11 Jun 2018 12:49:36 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1528746575; bh=zvPNsVsCg59AFBspMseZn+cRhyswQeOXbcRNrQEv13g=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=VbZ+tYUZQVJZ18BkF8VCs5vg7aJssnaRy/XxZwNy+7v9f1zWm1+U4FAjnv+9oEpzB 9x3yk5O9WZx0Qr+GNJR3o3AmUhXezEOJkQXMiZgNmhh4+V2CcAgmyNiFQhnR15ikw2 Cx26tpjqNiys+7BI4JP57lCZ7pZRXPNAhe/6MrJvqmh+UouANlZJYIVKLRf3+wTcoY JAEkoGiobENrq0tYS+oF+pZICefW43BomKe1i8Sd4Cbu57+UPSCR5lfAuVA4m/FLJ7 xraB6UMbcnAjiGS6umK9DAS8YzqRng1YUtGr7UCKPEuWl9jd5xKsEJ88CPHRqXIyv0 eEcCMuT1HPJnA== To: Ondrej Zajicek Cc: Juliusz Chroboczek , babel@ietf.org In-Reply-To: <20180611194801.4kjecvannfpuqmr5@feanor.crfreenet.org> References: <20180611153910.tjuuawwguxt5x4ru@feanor.crfreenet.org> <87zi01i025.fsf@toke.dk> <20180611194801.4kjecvannfpuqmr5@feanor.crfreenet.org> Date: Mon, 11 Jun 2018 21:49:31 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87r2ldhzn8.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] What to do if we don't know the next hop? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 19:49:43 -0000 Ondrej Zajicek writes: > On Mon, Jun 11, 2018 at 09:40:34PM +0200, Toke H=C3=B8iland-J=C3=B8rgense= n wrote: >> > What means by 'address is applicable' depends on whether platform >> > supports RFC_5549-style routes. Note that only the receiver ability to >> > use RFC_5549-style routes is relevant (as route announcer is able to >> > receive the packet regarless of how receiver resolved the MAC address), >> > so there is no need to signalize the ability. And the situation >> > is analogous to whether receiver support next hops is not in the >> > directly connected prefix. >>=20 >> Bit of a side note, but does Bird currently support his on Linux? And if >> so, how does it interface with the kernel routing table? > > Bird supports that for BGP, but cannot export such routes to kernel > routing table because AFAIK Linux kernel does not support it yet. Right, didn't think so. Hmm, something to get the kernel people to fix at some point I guess :) >> > Although it is true that for full RFC_5549-like support it would be >> > necessary to define a new TLV or a next hop sub-TLV to be able to send >> > explicit next hops of different address families, in most cases (esp. >> > when third-party next hops are discouraged) the above behavior would >> > be enough. >> > >> > [*] Or perhaps the receiver could keep such routes and do not use and >> > propagate them, but it definitely should not handle such updates with >> > packet parse error. >>=20 >> Oohh... only just realised that it is returning a parse error for the >> whole packet and not just ignoring the TLV. Oops. Can I trouble you to >> change that to return _IGNORE instead, or do you want me to send a >> patch? :) > > I will fix that. Great, thanks! -Toke From nobody Mon Jun 11 13:51:51 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C243130DBE for ; Mon, 11 Jun 2018 13:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 xOQzzpBWXyUF for ; Mon, 11 Jun 2018 13:51:44 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA3D1130E7E for ; Mon, 11 Jun 2018 13:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1528750304; x=2392663904; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=D2JxRORAFDm5WC/vUgFq4CkkCPOP9ZQPBQEFiIv59cQ=; b=O5VDw0+tUUJ9I+TaS3WMrd6ZlFQxpIpNsSQEJ44oK7466fH3lrnOgkztOzok8fkh sEM47dixciqO6NyPcEEoCnYZd9wtIFwF06xEUA+4jHr5JLgrAt5HjeeXafYZnec0 G6mTEpWMK5Irf7HyvHbkUm63E0cTlS10Mq0S2a+pm4AH495bdK1GCERHlI7XCOd+ pjTEkIOGUYxSgB4B9dKTH7ftl0wREEV5h2ZE1L7vvJjXveU/1XkRftjP+4Qr0Sr3 nLPVMiCys6z3Ew6778w4gKLcliBgdL6j9GaMb2GBbgNG/QI0YN6EgYfbW6FnWWRY R5uLTjJ4/GUfYHUCnUWxLA==; X-AuditID: 11973e13-62dff7000000242c-60-5b1ee0e0212c Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 92.C0.09260.0E0EE1B5; Mon, 11 Jun 2018 13:51:44 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0PA600758FA41XH0@ma1-mtap-s02.corp.apple.com>; Mon, 11 Jun 2018 13:51:44 -0700 (PDT) Received: from [17.192.155.180] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0PA600L2NFA5U770@nwk-mmpp-sz09.apple.com>; Mon, 11 Jun 2018 13:51:42 -0700 (PDT) X-Va-A: X-Va-T-CD: 81ca60fce39c2560b6c4a7e5841f9b8f X-Va-E-CD: 10fc20244544dd69772084957a3a5b6c X-Va-R-CD: 991fb4a7045f1666e5f4378fd8518dc1 X-Va-CD: 0 X-Va-ID: 4a36d2b0-e807-43b0-a51d-bf0372068f0e X-V-A: X-V-T-CD: c190214d8f986553c2d21c1d439ea442 X-V-E-CD: 10fc20244544dd69772084957a3a5b6c X-V-R-CD: 991fb4a7045f1666e5f4378fd8518dc1 X-V-CD: 0 X-V-ID: fc9399d0-8d1c-4328-8856-c50f11ead205 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-11_10:,, signatures=0 Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <2D09D61DDFA73D4C884805CC7865E6114DDE191F@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Mon, 11 Jun 2018 13:51:40 -0700 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Juliusz Chroboczek , "babel@ietf.org" Message-id: References: <8736xulpi7.fsf@toke.dk> <87wov6r7u4.wl-jch@irif.fr> <87vaaqr7pt.wl-jch@irif.fr> <87tvqak05l.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DDE191F@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEIsWRmVeSWpSXmKPExsUiqOHDpvvggVy0wc8fGhZbFnWzWEz6+5PR Yn7rMjaLre9XsDuweLzsn8PosWTJTyaPxVveMnpsOXSRLYAlissmJTUnsyy1SN8ugSujcfcB xoKNLBWz7i5mbWDczNzFyMkhIWAicW3mX9YuRi4OIYF9TBKXz51mB0nwCghK/Jh8j6WLkYOD WUBe4uB5WZAws4CWxPdHrSwQ9RuYJJ5efcUE4XxjlLhx/D4rxFR2iT+/drBA2NoSS78uYIax 36xZxwpjL9/7kwnC5pJYsPU0VFxX4tj6C1C9bBLrTyyBqtGSWDT7OxvIQSD2nKs8MOF/q75B lXBKnP8ykR3C1pGY8noT1MhsifNbFrKB2MIC0hJdF+6yQth2Ehu3TWUHGckGNOfAGiOQMKdA jMSylVPAylkEVCVud7wGe5FZoI1RYuGFJWyQ8LGR2DvrF9Tvxxkllk78wwiSEBFQl1g1bTrU YiWJ6d9vs01glJuFFKazEGE6CylMFzAyr2IUyk3MzNHNzDPVSywoyEnVS87P3cQISgTT7YR3 MJ5eZXWIUYCDUYmHd0O1XLQQa2JZcWXuIUZpDhYlcV6rK0AhgfTEktTs1NSC1KL4otKc1OJD jEwcnFINjBWffSz4K4XOTI76pi5tfq7ItGNLekiusOQbG9mddzqsPyas6dw9W8ajUoOvffEb iePbuoRXz1T49dM3jUn2yTHWxg3GAXZifFeii3btKvvlNeHmwr7Tb6/HWsaz3Vjx70K1fvzX aQe8BNeeWC72XcBVc2/i4v4PHHo3j2pcWM360XWR3b4JDkosxRmJhlrMRcWJACJjZOPlAgAA Archived-At: Subject: Re: [babel] What to do if we don't know the next hop? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 20:51:48 -0000 >>> (1) leave it vague; >>> (2) explicitly MUST DROP; >>> (3) explicitly define meaning. >>> >>> I'm open to (1) and (2), I'm opposed to (3). Opinions? >> >> I think I'd prefer (2). I agree that we shouldn't open the can of worms that (3) >> implies :) > > I like the simplicity and consistent behavior of (2). > Barbara I agree. "MUST DROP" reduces confusion now and allows us to safely define an extension later when the need arises. I'd also add "MUST NOT SEND" as well, to be overturned by the hypothetical future extension. David From nobody Mon Jun 11 17:33:27 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D10130E99 for ; Mon, 11 Jun 2018 17:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 Tng-7bt1zn3k for ; Mon, 11 Jun 2018 17:33:18 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB052130E7D for ; Mon, 11 Jun 2018 17:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1528763598; x=2392677198; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bf8ldmOdPMRZfACPitmdkSnqN+UAHj5qEoz9q1wQDvc=; b=CAiTvl7k3IyOxhdeI6VTg5gBqzUf4XoCEEw93C5cgRasYahBJyIKU24h6WH2d9jJ dT1NAFxko67k6tuqAMmKB/9NhSti2E+UPgCFa0vy2+XPIPnXinySej3FbXO2rpcf ZCayPapiPzw27xjGIAAMoBSnmZn3UTbJf1aMuDYkAVXVMH0zTkOKMfri4MhpTG05 NYV9TOFHodexMjxeyDRE9/XyRZx5iCrnmLGSctF/ICsW6XWVOkst2VKapTYhQjo+ B7KBnq0pL4wo9kzdMbEWooctTA/18ooPjRLSiRV7JTU06wVHs0NzFp+CxyD4omOb Uz8NZVlXWC7WE6+Ap/yn/w==; Received: from relay3.asia.apple.com (relay-server.asia.apple.com [17.82.200.17]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id C0.CC.15050.DC41F1B5; Mon, 11 Jun 2018 17:33:18 -0700 (PDT) X-AuditID: 11973e11-f0d049e000003aca-e2-5b1f14cd0d3f Received: from echium.asia.apple.com ( [17.84.80.65]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay3.asia.apple.com (Apple Singapore relay) with SMTP id 77.83.27265.DC41F1B5; Tue, 12 Jun 2018 08:33:17 +0800 (MYT) Received: from [17.192.155.180] by echium.asia.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0PA600LXDPILP310@echium.asia.apple.com>; Tue, 12 Jun 2018 08:33:16 +0800 (SGT) Sender: dschinazi@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: David Schinazi In-reply-to: <874lieznff.fsf@toke.dk> Date: Mon, 11 Jun 2018 17:33:14 -0700 Cc: Juliusz Chroboczek , babel@ietf.org, =?utf-8?B?Q2xhcmEgRMO0?= , =?utf-8?Q?Weronika_Ko=C5=82odziejak?= Content-transfer-encoding: quoted-printable Message-id: References: <87po12d7df.wl-jch@irif.fr> <874lieznff.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUiGHRCUPeciHy0waq1ChZbFnWzWGy4vI7Z Yn7rMjaLre9XsFt8+HSH1YHVY+esu+weS5b8ZPJYvOUto8eWQxfZPF5Nf8gewBrFZZOSmpNZ llqkb5fAlXH97jzGgveSFW+2bGdvYFws0sXIySEhYCLR+7WTuYuRi0NIYBeTROveVWxdjBxg iVt/IiDi85kkpj1qZYVwPjFKHD57mgmkW1hAWqLrwl1WkAZmAXWJKVNyQcK8QL23r/1ghyix kOjf3sECUsImoCVxYI0RSJhTQFVi7udLLCA2C5B94OQqdpDxzAKbGSVWTt7CBpJgFtCWePLu AivETBuJTdtnMIPMERJwkHjz0gwkLCJgL9H49QILxC9KEtO/32YDmSMhsIdNouP4G/YJjMKz EK6bheS6WUg2LGBkXsUolJuYmaObmWekl1hQkJOql5yfu4kRFBPT7QR3MB5fZXWIUYCDUYmH N6JSLlqINbGsuDL3EKM0B4uSOG/uF6CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxscHiwTM U2XffVCS3rfO9sf3hMWMbae+7QjsaK1wXTZR/rv7+is1r15vZbq2ZJvv3ph4fttmoTcq5QxP 4/a4ysqr8i0/ccVpb46fUp9ga+2ThCn6pk9LlaslnRMC7eUmRSZpP0uQXcLSbpQwje15j8Fi FsZP4levXEm9aTW3Uvz7lNdb3Gc5KrEUZyQaajEXFScCANlWetxqAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUiGBLgqHtWRD7aYMlCLosti7pZLDZcXsds Mb91GZvF1vcr2C0+fLrD6sDqsXPWXXaPJUt+Mnks3vKW0WPLoYtsHq+mP2QPYI3isklJzcks Sy3St0vgyrh+dx5jwXvJijdbtrM3MC4W6WLk4JAQMJG49Seii5GLQ0hgPpPEtEetrBDOJ0aJ w2dPM3UxcnIIC0hLdF24ywrSwCygLjFlSi5ImBeo9/a1H+wQJRYS/ds7WEBK2AS0JA6sMQIJ cwqoSsz9fIkFxGYBsg+cXMUOMp5ZYDOjxMrJW9hAEswC2hJP3l1ghZhpI7Fp+wxmkDlCAg4S b16agYRFBOwlGr9eAJsjIaAkMf37bbYJjAKzEA6aheSgWUiGLmBkXsUoWpSak1hprJdYnJmo l1hQkJOql5yfu4kRFMxBJwR3MH6YaniIUYCDUYmHl49HPlqINbGsuDL3EKMEB7OSCK/1f7lo Id6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwWWbVRQgLpiSWp2ampBalFMFkmDk6pBkbbG3s/3/3a tMJJZd6yqUdN6kOr57Mt2HXtx49rx/rUK7UXBnxcrJwt+Wbm+WlX8jPPedRF7xaRZQyuChWp +qjw2kmbj//g05qvXTURkY4SJk8nXuaepXO70DZoivF/n3liUTs+fzyrltypxShdGdQoV7VE oWNPxN3ovRaH9UziShYbTIybYqTEUpyRaKjFXFScCADfCMcmYgIAAA== Archived-At: Subject: Re: [babel] Questions about HMAC authentication X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 00:33:23 -0000 > On Jun 7, 2018, at 07:22, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Juliusz Chroboczek writes: >=20 >> Dear all, >>=20 >> Clara and Weronika (in copy of this mail) have made some progress in >> implementing HMAC authentication. A few comments and questions. Awesome! >> 1. What shall we put in the pseudo-header? Our current strawman = proposal is >>=20 >> source IP >> destination IP >>=20 >> Do we need to add the port numbers (which are normally constant)? >> Anything else? >=20 > Hmm, technically you are not following the spec if you change the port > number, are you? So it would technically be acceptable to exclude = those? Agree that we don't need them now, but it gives us the option for easier = future extensibility. >> (Note on this subject that including the source IP complicates the >> implementation somewhat -- at the time when you're generating the = HMAC, >> the source address is not known yet; for it to be known, you need to >> either use a connected socket or double-guess the kernel. It's only >> a problem if the interface has multiple link-local addresses, which >> shouldn't normally happen.) >=20 > Well if you don't want to guess you could conceivably add a hash for > each one? I dislike this option, allowing multiple hashes reduces the security as = attackers could send many hashes to increase their odds of collision. >> 2. Denis' definition of the HMAC TLV contains a Key ID. We don't >> understand what the Key ID is for, so we're omitting it for now. = We'd be >> grateful for guidance. >=20 > As I understood it it's an ID that you put into your configuration, = and > you only verify a signature if you have a key with a corresponding ID. > Cuts down on hash operations for things that wouldn't match anyway. If > you don't use this, what do you do with multiple keys? Yes, my understanding is that having an identifier is much more = efficient if you have many keys configured, and reduces the impact of DoS attacks. >> 3. TS/PC is 32 bits of TS and 16 bits of PC. Make it 32+32? >=20 > Not sure. Why? >=20 >> 4. I was thinking about adding a flag to TS/PC that indicates that = the TS >> is UTC time modulo 2^32. This avoids a replay attack when both the = sender >> and the receiver have a reliable hardware clock, but the receiver has = lost >> its ANM state. >>=20 >> (Suppose that A is sending TS/PC with the UTC bit set, and B has lost = its >> ANM state. If B has a reliable clock, it can discard any packet that = is >> more than one minute or so in the past, which avoids a trivial replay >> attack.) >>=20 >> Advice? Criticism? Objections? >=20 > How do you determine if you have a reliable clock? What happens if you > are wrong? This seems like an option that most people would just end = up > turning off because someone somewhere had problems with clock accuracy > an yelled about it on the internet... I also think hoping for a *reliable* clock is optimistic and opens up a = whole range of failure patterns when the clocks drift apart. I think the correct fix to that attack is to only accept updates from a = neighbor once you've confirmed that they've ACKed a recent Hello seqno of yours. David= From nobody Tue Jun 12 00:39:58 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8037130E08 for ; Tue, 12 Jun 2018 00:39:54 -0700 (PDT) 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 zePLDY4wXLOg for ; Tue, 12 Jun 2018 00:39:51 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CF212F1A2 for ; Tue, 12 Jun 2018 00:39:51 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5C7ZG5U043046 for ; Tue, 12 Jun 2018 03:39:50 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 2jj65ckdmm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 12 Jun 2018 03:39:50 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w5C7dnkv029594 for ; Tue, 12 Jun 2018 03:39:49 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w5C7dlbv029546 for ; Tue, 12 Jun 2018 03:39:48 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id BCB5C40002DD for ; Tue, 12 Jun 2018 07:39:47 +0000 (GMT) Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (unknown [130.8.218.150]) by zlp30487.vci.att.com (Service) with ESMTPS id 9FD9D40002DB for ; Tue, 12 Jun 2018 07:39:47 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.78]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0399.000; Tue, 12 Jun 2018 03:39:47 -0400 From: "STARK, BARBARA H" To: "babel@ietf.org" Thread-Topic: Babel YANG deliverable Thread-Index: AdQB89PwrnOJZclrSnekzkUjBmvbvg== Date: Tue, 12 Jun 2018 07:39:46 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DDE71DC@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.244.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-12_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=619 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806120089 Archived-At: Subject: [babel] Babel YANG deliverable X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 07:39:55 -0000 I think we need to have a list discussion about this Babel YANG deliverable= . It is clear that none of the people directly engaged in this WG have the ex= pertise or competency to create a Babel YANG model. We also have no desire = or intent to acquire this expertise. The learning curve is steep and time-c= onsuming.=20 The requirement to create a Babel YANG model is purely about creating the m= odel for the sake of having the model. There exists no user community deman= d for this model, at this time. There exists a user community who does want Babel. There is a homenet (unma= naged network) use case which has rfc6126bis as a dependency. There is inte= rest from other users with networks that do not require management through = a management protocol, or who are using other non-IETF solutions. There is = some interest from at least one employee of an ISP (me) who has committed t= o creating the information model and a BBF TR-181 data model (for use with = BBF TR-069 and TR-369). Lack of publication of rfc6126bis is standing in th= e way of these use cases being fully realized. [Side note: Because of these= use cases, netconf and YANG MUST NOT be mandatory to implement, even if th= e YANG model is created.] However, the lack of a YANG model is being used as an excuse to prevent pub= lication of rfc6126bis -- even though none of the user communities actively= interested in Babel care anything about YANG or netconf. The Babel user co= mmunity is being held hostage by YANG advocates. So we're at an impasse. I see the following as possible ways forward, and provide an assessment of = their feasibility and outcomes. 1. Kill the rfc6126bis effort now. Very feasible. Outcome: All work on Babe= l leaves IETF and either dies or goes elsewhere. 2. Put rfc6126bis on hold until a YANG model happens. This is the default "= do nothing" choice. Obviously, very feasible. Outcome: Since the YANG model= shows no sign of happening, it is highly likely we would lose the interest= of the draft authors, and it would be effectively the same as killing the = draft. If we're going to kill the draft, then I prefer the decision be a co= nscious one (see option 1).=20 3. One of the people currently engaged in Babel puts in the time and effort= to learn YANG and create a model. Highly unlikely. Outcome: Extensive dela= y (due to learning curve and bad attitude), which is likely to devolve into= option 2. 4. Someone who is competent in YANG volunteers to quickly create the YANG m= odel. Feasibility is unknown, but no-one has stepped forward, yet. Outcome:= If done quickly, it might be successful; otherwise, it will devolve into o= ption 2. 5. The draft is sent on for IESG review without there being a YANG model. T= his can be with** or without a management section that explains the current= lack of a YANG model. Feasible (depends on chair willingness). Outcome: Su= ccess is uncertain since we've been told there is a policy that says routin= g protocols must have a YANG model just for the sake of having a YANG model= ? Not sure what the policy really is, since I can't find where it's stated. Option 2 is default (do nothing, and kill the draft by lack of action). Opt= ion 3 should be tossed -- it's not going to happen. Options 1, 4, or 5 are = up to the chairs. [The WG participants know of no-one for option 4.] Donald, Russ, -- it's in your hands. Do we consciously kill it, do you find= someone ASAP to do the YANG model, do you move it forward and fight the fi= ght, or do we do nothing and allow it to die?=20 My preference would be to fight the fight -- send the draft up for review. = This "there shall be a YANG model" policy (it would be great to get a point= er to this policy so we can read it and determine who approved this policy = and any other details of this policy) is inappropriate and untenable for Ba= bel.=20 Barbara ** Possible Management section text: Babel may be used in a variety of scenarios. As one of these scenarios is t= he unmanaged home network case, no management capability will be required i= n order to be compliant with this specification. A Babel implementation pro= file for the home network use case is defined in [homenet-babel-profile]. Where there is interest in defining other Babel usages, specifying an imple= mentation profile for those usages is recommended. Such a profile would nee= d to identify any needed management capabilities and protocols, and would n= eed to ensure that data models necessary for interoperability exist. The in= formation model [babel-information-model] has been defined as a basis for c= reating interoperable data models for various management interfaces and pro= tocols (e.g., YANG, a graphical user interface, Broadband Forum TR-069 or T= R-369). From nobody Tue Jun 12 03:55:17 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B906130EE0 for ; Tue, 12 Jun 2018 03:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 Uh501fyrok6d for ; Tue, 12 Jun 2018 03:55:09 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA427130EB5 for ; Tue, 12 Jun 2018 03:55:05 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1528800902; bh=+gi7Xd4qmxiSxrLO4PiWNynDXCk3j3dggga5E3ESxKw=; h=From:To:Subject:In-Reply-To:References:Date:From; b=PmokSHAgpzQbNNAB1I4Oo/aOZbGQgATe4MXgKYs/sOUAntz+ejelTAmsqPAvz1RyZ Thj9HAu6EeuGPxMGJ+CRZQQFrfOla1Cxpr2vDFxiBaT0dQt+Xrx22que37LtMAbqW/ qRLh5aWhFQuyKisssbKcNcdokK/i12TbmlnFek1tHAS1iVi7dmZ6YQhPkmWIJ+J4hh QRecM0FJto0f3W56AUHcINJWbhBn65/rU/2f83qIiOdUMlApXgrgenRD6MBrt18W/0 PQ6fmsqfQP/vbNzKTLxxPYc9wXNfUU8NDr7cpHHtCecrNclySRQSBcKSpomwYmXCBP Jt4BWJ/uo9o4g== To: "STARK\, BARBARA H" , "babel\@ietf.org" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DDE71DC@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DDE71DC@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Tue, 12 Jun 2018 12:55:01 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87d0wwjmuy.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Babel YANG deliverable X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 10:55:15 -0000 "STARK, BARBARA H" writes: > I think we need to have a list discussion about this Babel YANG deliverable. > It is clear that none of the people directly engaged in this WG have the expertise or competency to create a Babel YANG model. We also have no desire or intent to acquire this expertise. The learning curve is steep and time-consuming. > The requirement to create a Babel YANG model is purely about creating the model for the sake of having the model. There exists no user community demand for this model, at this time. > There exists a user community who does want Babel. There is a homenet (unmanaged network) use case which has rfc6126bis as a dependency. There is interest from other users with networks that do not require management through a management protocol, or who are using other non-IETF solutions. There is some interest from at least one employee of an ISP (me) who has committed to creating the information model and a BBF TR-181 data model (for use with BBF TR-069 and TR-369). Lack of publication of rfc6126bis is standing in the way of these use cases being fully realized. [Side note: Because of these use cases, netconf and YANG MUST NOT be mandatory to implement, even if the YANG model is created.] > > However, the lack of a YANG model is being used as an excuse to prevent publication of rfc6126bis -- even though none of the user communities actively interested in Babel care anything about YANG or netconf. The Babel user community is being held hostage by YANG advocates. > So we're at an impasse. > > I see the following as possible ways forward, and provide an assessment of their feasibility and outcomes. > 1. Kill the rfc6126bis effort now. Very feasible. Outcome: All work on Babel leaves IETF and either dies or goes elsewhere. > 2. Put rfc6126bis on hold until a YANG model happens. This is the default "do nothing" choice. Obviously, very feasible. Outcome: Since the YANG model shows no sign of happening, it is highly likely we would lose the interest of the draft authors, and it would be effectively the same as killing the draft. If we're going to kill the draft, then I prefer the decision be a conscious one (see option 1). > 3. One of the people currently engaged in Babel puts in the time and effort to learn YANG and create a model. Highly unlikely. Outcome: Extensive delay (due to learning curve and bad attitude), which is likely to devolve into option 2. > 4. Someone who is competent in YANG volunteers to quickly create the YANG model. Feasibility is unknown, but no-one has stepped forward, yet. Outcome: If done quickly, it might be successful; otherwise, it will devolve into option 2. > 5. The draft is sent on for IESG review without there being a YANG model. This can be with** or without a management section that explains the current lack of a YANG model. Feasible (depends on chair willingness). Outcome: Success is uncertain since we've been told there is a policy that says routing protocols must have a YANG model just for the sake of having a YANG model? Not sure what the policy really is, since I can't find where it's stated. > > Option 2 is default (do nothing, and kill the draft by lack of action). Option 3 should be tossed -- it's not going to happen. Options 1, 4, or 5 are up to the chairs. [The WG participants know of no-one for option 4.] > Donald, Russ, -- it's in your hands. Do we consciously kill it, do you find someone ASAP to do the YANG model, do you move it forward and fight the fight, or do we do nothing and allow it to die? > > My preference would be to fight the fight -- send the draft up for review. This "there shall be a YANG model" policy (it would be great to get a pointer to this policy so we can read it and determine who approved this policy and any other details of this policy) is inappropriate and untenable for Babel. I agree with your assessment, and would prefer option 4 (if feasible) or 5. I think it would be a shame if the IETF bureaucracy ends up choking Babel :/ -Toke From nobody Tue Jun 12 05:42:48 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2BC130E27 for ; Tue, 12 Jun 2018 05:42:45 -0700 (PDT) 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, 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 pleSpMWKQqer for ; Tue, 12 Jun 2018 05:42:42 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C403130DC0 for ; Tue, 12 Jun 2018 05:42:42 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5CCgbVB019211; Tue, 12 Jun 2018 14:42:37 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 51C18EB200; Tue, 12 Jun 2018 14:42:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id KWzrsJfmOMFp; Tue, 12 Jun 2018 14:42:36 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A7A66EB22D; Tue, 12 Jun 2018 14:42:33 +0200 (CEST) Date: Tue, 12 Jun 2018 14:42:33 +0200 Message-ID: <87lgbkgoqu.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "babel@ietf.org" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DDE71DC@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DDE71DC@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 12 Jun 2018 14:42:37 +0200 (CEST) X-Miltered: at korolev with ID 5B1FBFBD.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B1FBFBD.003 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B1FBFBD.003 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Babel YANG deliverable X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 12:42:46 -0000 > My preference would be to fight the fight -- send the draft up for > review. This "there shall be a YANG model" policy (it would be great to > get a pointer to this policy so we can read it and determine who approved > this policy and any other details of this policy) is inappropriate and > untenable for Babel. I fully agree. -- Juliusz From nobody Tue Jun 12 06:01:53 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF48C130E98 for ; Tue, 12 Jun 2018 06:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYhDK28xJEmQ for ; Tue, 12 Jun 2018 06:01:46 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on070f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::70f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99BAA130E71 for ; Tue, 12 Jun 2018 06:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ziega2pLcdrhepew5CLYtZGkG8XuTduuDYFacLjRZf0=; b=I93ztNXCp10wMQHl2YxiHk77an4V3Vby78uiKzyXptOlb0YkLmLowgNju+DcB0cbA6J0ZUvvuewzCN49pVIZncamDXeehiZe3YVgoTW5GI4TGuFoprSwkQEYsoT33CBb6cCyEfJ4+bibPHmAtZotTVFAsKLYj8fdA/vYvmekDzQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com; Received: from [135.244.204.1] (135.245.212.1) by DB6PR0701MB2502.eurprd07.prod.outlook.com (2603:10a6:4:62::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.6; Tue, 12 Jun 2018 13:01:43 +0000 To: babel@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6114DDE71DC@GAALPA1MSGUSRBF.ITServices.sbc.com> <87lgbkgoqu.wl-jch@irif.fr> From: Martin Vigoureux Message-ID: Date: Tue, 12 Jun 2018 15:01:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <87lgbkgoqu.wl-jch@irif.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Originating-IP: [135.245.212.1] X-ClientProxiedBy: PR0P264CA0027.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1::15) To DB6PR0701MB2502.eurprd07.prod.outlook.com (2603:10a6:4:62::14) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7193020); SRVR:DB6PR0701MB2502; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2502; 3:4u0+QzT5MgDjtCnRFraDC6dyRypzXXCqorRtinvVnzcWdCoPJ1CDNanr9t+pGFayiD9/H0s+xWw4MzNj9euyUvjGapJbXHhRUVG8tHCAU8bO0MOoYDiALNnlmr5cvlpONJEcECae5T0NMNx7AP3bHtPLiOSVErI8GNqYVcrHTlCSKOP6GqQSQbaYNjhJJK1Dv9GrzIbQqyzL6OHRkcJTIcEfEx+WtM90fX7pN7k0QXcQWp9CKjj+mwXSR1YPSAT6; 25:t9vznzfwFKi4uL0Jq93g/EgftNFbv1BNw4VhrXSaNlem3/8JbiI9zOAitYb/1/lwAfbmCZ+tr750EXlzfEmofv3FEhYj9NlSAmjrcToVsFnj9QhzRwa2q2Pbo9ZJJeiUliecnlgH5uJtcFyr5/rEcaWRF+6UJ9YdHAvgC6C7HEaQgLpoOG4sb2BH6oR24DI1/Nhw1FNeEQBtWtjHVSvgkv4ht+iN6d9/jDxiZpa5PIsiVTtdModNKb7joieNNhsXwUHzKTyWiCYCz1TRdYRGB15cV0EcxnMpa5ZNMF6V0C3dq7EDwov0frdppJgnwDfN6uXGTyAmgaZ5407JBpR+ZQ==; 31:h9QVcs5dgGX3Q6BzTjobeDSENYfV3rel37QrV/jLlFejnugZCNbyblDdgm7cGuP2GCuPW6+tPy/frEtl7dHtLtyrrciI9IHsBNQJnTgJy04Kubd+3w/zAk/VVEIhWAFJJAxfwVLshRBZkpWkThuuEV5k+tHWnMA8yGjK6NYxdxuqSNR7azo0g4PWplBixrnmspRh5tJD3g3fZfq/wZypdbkRXVhd/PqSzfb0VtqR2i0= X-MS-TrafficTypeDiagnostic: DB6PR0701MB2502: X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2502; 20:j2S5DS6TXgtAUFXwyDTi8lnQP5Yan1AOIbwUUn0JwcpyUilyu/gDxOMH0FRgSZDpTtGuktddK3PxHcsX/43YVf4cvTPMa95J8rKNxE36oMPVfyfBTdR02jO57/OXfdWaiLwVLcNoP6F3CEHSv9IWciXaGbR32D7lQ2fwIV9CKjGTEQRXEr1edCBd/WVt0aZortJCQexKupwr6roH6I2q6o2CXxdctpYrh38WYx3TskzKLmdr7ixZRBWZ/B6n18aF3YzmwClbX/lsOMFAp4csV1B11UrcPEj4y1OcMlMeB5J5cHUNn9jSO9eXVOCxkuwFagLP3KDkmOD9NxCvjZaJmD+cD+84ccPn9diYx8h5l9X7pxaHqSU5ZXpGXbwQcS5FT1jpZ/LrqbqDhOiQvMKDHQ1EFk7sguixS6c2Ip0vCsIP3m3fyjWtTUDthMatpJPHL8tZJPJa9NcEjiecH+U89VlK8iP/+ToqnQ/BMQYecbmW+2Bm9v8pxUipsLhRSZ4+; 4:vRetyaZ3mheBl4TcAGS+FmIkcndNw1FjMFTqKpoTg2PrEQ4vSj0mpf5VFWTQbu6RBnoXXJNkmZ8DqVJoPmszSjMzH+PuP59WJ1el0m/zRfsBPLHYrI74Tnz4sdydipZQnApyF6QZY1p26+zsiWMJoRZ/NjNtuGtKBZM6s0CIp1qIX3sP+SXZ0kS8nQKDyPMJqhtsllaJIZ/DOfYXH0zrz/De7HzbRZ/0I7SOSN9yMdZFwTa5OU5j3uiDQdndx6Rc0MGDgYKdVLrzZVJPms8ezQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231254)(11241501184)(806099)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:DB6PR0701MB2502; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2502; X-Forefront-PRVS: 07013D7479 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(366004)(39380400002)(39860400002)(396003)(346002)(376002)(199004)(189003)(47776003)(105586002)(6916009)(6666003)(6246003)(2870700001)(36756003)(229853002)(2906002)(86362001)(53936002)(49976009)(186003)(65826007)(26005)(106356001)(31696002)(68736007)(6486002)(76176011)(2486003)(23676004)(52116002)(52146003)(5660300001)(6306002)(966005)(386003)(16526019)(31686004)(65806001)(65956001)(66066001)(3846002)(6116002)(64126003)(67846002)(486006)(44832011)(97736004)(476003)(2361001)(2616005)(956004)(11346002)(446003)(305945005)(7736002)(8676002)(8936002)(81156014)(81166006)(50466002)(58126008)(316002)(16576012)(3260700006)(25786009)(478600001)(2351001)(78286006); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2502; H:[135.244.204.1]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3MDFNQjI1MDI7MjM6S0xXWHFnUkI5YklVd3JYRDA3V0k1Ulhv?= =?utf-8?B?OG5wUTlmRGhmMGQ3a3d3akNmdjNtYjZWMXBvbHJ2a2loY2dId2ZjKzkyMVVS?= =?utf-8?B?V1VHNWNhNjNHUHQ5ZGpyVFMyZUx4VG96bjdwZEdjOGNNeXE0L1Q1SEJRYWtl?= =?utf-8?B?YUxYR01MaGtoV2RLc2ZMTFVRYTdPelpoNmxad1JadWpISFJyOEtlOERxZVBH?= =?utf-8?B?V0Y3VURDNlFGVVdydE1XclRmcnU0WVI2TUo5dFp1U0FJMnl6QVZFZGx5RGEy?= =?utf-8?B?M1JqWVJSUXdZZUZYa1F3VzBML29Tdm5iVnN4c0tpcE8xYXVUYlRsTktLNnhR?= =?utf-8?B?M0tUS2tYK0JnUWNtT1VQQ0tqWUZFT3pycUN6S0IySTdzNnZsV3JrWFhNbDFs?= =?utf-8?B?WTlSMktLY3BBWnBLOEFRelRRNURJWUg3ZGxGemlTTSt2MmRvYUNkeElYb01a?= =?utf-8?B?RG1xOXQ5VzRoMWVOTHpwcHZaY3ovZnVMeWp6S3dnaTBuQ2dBM3c1bUI0b0Q4?= =?utf-8?B?azc1R2xWQVBVcnJwKzhIWFNpUzR4NmxVV3V0UjBWb2d1Z0J0Z1pha09Yak8x?= =?utf-8?B?azZ4MUhzUXp6Z1dqQzBOSzhWcUlaNkZxbm54Nm9kdENtTG5lVWczYlVQNDZP?= =?utf-8?B?VSt4bG01UVNJc0ZoeE1odU9pK3BzR0libGJwZUE4VW03akI1bXFjV3M5MHQw?= =?utf-8?B?SUdNSDBQK3QxczJXODBJU001eEk2dTN4KzhBc3lJaVFFNEp3YVlQT3M5SS9u?= =?utf-8?B?ODVBb0lLejJBcnZKOEhlU0F0dWtOTVE2Z2IrY0habGN6UkMxbERqQ3l1Nk1a?= =?utf-8?B?SDNibGxjY2JHVVFZalJQbjg5Y0R0RmFrd1JweDU2UituOGJyRkorbHJwRkZU?= =?utf-8?B?NVFOTXlKemUvSi9hMTRwcENVTTFTZjlhRFk5Tk90L1B6ZFVZMytEYXA2emYv?= =?utf-8?B?dlVDWDdkWm4vTWcveldWVXZxZkNCM0RIY0M4UUdXYUVtaktUWE1JbWFGQ1lL?= =?utf-8?B?cEtmWUpqUnlGajJFMTVjdHN0UjN1anQzS29wdVVzK1VabGdVWEZqR001MitY?= =?utf-8?B?OTg1WUhWcDVZdW1RSHV5VlQ3Q3dpbitwK2VhcnZBWnh2dE5PS25IWWJVMlU1?= =?utf-8?B?aUx3ai90VXp4NjVzR2lOZGVldkEyS0lNbDQ5KythKzJVSFdRc1NtQzBqdklI?= =?utf-8?B?VjlCSU9qdFpXK0lWVDlqSVBTOGZzRXlrTm1LQzNLTk5GM05mU2tFdFFGTFVK?= =?utf-8?B?S1QwSVNlYjRZZElpYlh4R00wQVFDTVBsWFhDZWtPeDE1UVVGTWlXdjlZcUtR?= =?utf-8?B?djZwdnBzT3BBWTA2YlJsQStpZ0UvSkNtWE1pbktwV3BwT1k4ZG1hemtURktq?= =?utf-8?B?MS9uZDViS3owVGdDb3VPeUZ3clF5WlEyQytHdEQ0dS9PckZBMUt3YldteE84?= =?utf-8?B?RU84Q1pGbVNERzNjU3F4YVFjYk9lQjR0RDQ4YS9CWkNUMWpITmlZNFU2ekov?= =?utf-8?B?enJ2aFNCc2NGNGtRV0RVcm9aUmhVVEk3V1lIN1BRMzJBWmxybFdESzZaMHhG?= =?utf-8?B?bmhmTE40c2tNQm1GYlgrY1M2VlN5WFFDUVppTDRsWkZ0VU5pY21SallUZHF2?= =?utf-8?B?QWdpTkQ4SHFJRWNMRXNFbzUrS3IxVVFXV0RSZkdzR3ZGZjRUbnU2T1VHSWMx?= =?utf-8?B?SWtiWk0xai9WZC9ScFRienRzNXJjb25YTEVLalk0eGRmczZONEZ1UlBJZEQz?= =?utf-8?B?dldOQ2h4MFBRQ1JvY0p1YVYwejFJSmVINlBzMllTM1lDU3JuWWorb2pBWWh6?= =?utf-8?B?R1hWQ2dYaEdOWHBWSzZGN242MDhKR3VCMVAzYmp1NktaTmNrckpZbzYrWGRE?= =?utf-8?B?VGxSa0gwa09UVUY0N2MxMDA3RWNJUGtyckF0WVlJV3RSekp0VmRoUmRmNS8v?= =?utf-8?B?RW9LU0RJeE82a0hMUkRDeE9RQ004b2FWRlhIWjArR2ZqcUNXNlRrSDVUaFlt?= =?utf-8?B?SEVDNGRDdkRTT1YzK3ozRWdrVzN3eUVKUi9OQzNqRCtjbVBFSUJIa0d1R2Ez?= =?utf-8?Q?nlGnXtYP0L07Vk1nwm83JEcaG4H?= X-Microsoft-Antispam-Message-Info: XSdhtQVd0VxR4TgXBv28q346RAu52hIBEj783oGhHP6YqOlLs+F3L0/ojW3SKrBbF1WT/4IBGDCaPzPSmgktaAjDNuT9AgqKjC+nEFd3OYzP9C309WLqz7KBgQ5C5/vSLQfDg/f7lHoHlqA9g32cxu3q4avaY4KBW3bVVY7041PV1WNrhIFh+dipZZphZsyFrijuhcOPw7SMVkzQDhCIwULqx/K+p0cRWfImyM4VwV7zDwHKJ7iJ2gwLgITJPwni X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2502; 6:AOufTe8Vlr6XrpUbNsoR7JkKZkyYAqDrkPssfk15FTvsa1a5Z09hpRP6qSKP/f4W1bcEnCfO2uByBpzln26OxpoiBgip5HJNckkCMG2zLRhw0kE8VXbG4RM6fkqseBXVffKT6ms1gw6gQt+hQiJZZpIZnOShw/m2pX8UMwEFB6qtXD+64y4r7YiGac2dcKuf2ZOJNCDqVBTdx3mXHkHw2K770PlO9H8gNpHVam4B9H8rngiD/Jh+7LE2vD8DqXxvf78azXOE/6ylb1YcMwNkld4i/dw/NUtgengWNmOhnoBxpMX36k+DtjePEkbJLa+g5QbXitpO5rXazj6ufn+ZAvG8a3BWnEyOG1qG7V58/wtdgo0f6L41/1nKWEizG+G2MT7r2EV2ETjYAVL6Bh7yXE1ctCOeZexsP9P8Yu5MENkWd2dCRqdwmxA3EJjU4cCv8JQixyjeXRLKgcIEZTpVng==; 5:A9Sh5j31QkazZGtFaoEZ7mTI8qpK0kVbhVOJJ2IKWSjRZ1j0HTz1vcyA2ComBLqw+HMRIhYbwZIq2ME7CdAH+WxFKaUg67JOmuJxCQJah6oCYzbOSHrh0XWld39cYIPs/8ATCd5xq1kkN22l3bZKc0vdPOFIxypisxgjAmEPADs=; 24:K4UT5FGjtN/EXhfUCkTbOCF3jownYKoWugK6+PjQwmFOp9bmHEyQxy/q6Z/wPUFhROVrDFJguQJeko8kK8V19gSbbWycl9q476H+9Sbm7iU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2502; 7:KGqc0/9fZP9SRQwuZpd6aK2JFqJHBd2qTV+jioY3j2yp/WkdNGZFqMigUjQmvtcvlXnmoXxR9/4axXKqvvLgLzTPCNKSZ+WikttQIAv2sZEX03Pv0Qrp8WpbhFTLtLKC34BCurCZc5Wa0843hq90WATu7Xh1xPFpvjl5+yMCyGPie5SvCjy+DHq3gecEAr2pYfCWtaw7niMwHtf2vxQriNbKIAIaDxy9djyXWbthPzXTnpff6wy3klBR9IyrDeom X-MS-Office365-Filtering-Correlation-Id: f467e43f-da5a-4242-144f-08d5d064a551 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2018 13:01:43.0393 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f467e43f-da5a-4242-144f-08d5d064a551 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2502 Archived-At: Subject: Re: [babel] Babel YANG deliverable X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 13:01:50 -0000 Hello WG, there is no "policy". There is a WG charter which says: To be consistent with the ongoing effort to use YANG data modules in the Routing Area, a Babel YANG data model to support management of home gateway routers is required as part of moving Babel to Proposed Standard. regards, martin Le 2018-06-12 à 14:42, Juliusz Chroboczek a écrit : >> My preference would be to fight the fight -- send the draft up for >> review. This "there shall be a YANG model" policy (it would be great to >> get a pointer to this policy so we can read it and determine who approved >> this policy and any other details of this policy) is inappropriate and >> untenable for Babel. > > I fully agree. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > From nobody Tue Jun 12 06:12:06 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E92130E83 for ; Tue, 12 Jun 2018 06:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_Tn7RuEC-Tn for ; Tue, 12 Jun 2018 06:11:59 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 38751130E30 for ; Tue, 12 Jun 2018 06:11:59 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id s26-v6so27960678ioj.4 for ; Tue, 12 Jun 2018 06:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8YS2U7ypYkDR9rhQvinUZhAnkn2hCJ5VM4b8g2m2Kp4=; b=cHHBuK9RFL5o/hnRTiA3Sqa+NwKvjYHWB0zPSlpCZy+SXmF/iiNzuGIsnJB7xVU+2o D7FdIyYhpd/sQ8Y4AwfjrbxYKQV30MQ3Uas/qFQHGxOFiVLbXMp0rzrN+jzEDiGGNG1h ygevq1HL7pJE1x/TLeAbnAgumdlMhiE5c70hdLB/1hgVbE0pYTMLr9rc1NQv6R+6x6FM 1YB1Xclmfz9lV44+uNUrWIOBpcxFDKVrCh93zKO/1gZGkhRnV+tsSsKgOKwD7PkkasUY Mr5sDsHzLEJC8ae3muSv9XSoky+oqOkkcy46q9Kkg8QDI3EO4KTLm3rniHfLDO7u5YtO a7cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8YS2U7ypYkDR9rhQvinUZhAnkn2hCJ5VM4b8g2m2Kp4=; b=sB4BWXFFWnsxoocaQLujQI3Y9DQNeKJa5RGZt8vxWipUsq0KPan0VItIe8Tz6uKJX5 sNaBNl5tueXatvV+KlTuUPQQINsYZ+AQeS3C7upatF10q9Ge16YtOrRJU7eNVfrBXHRq pzGye/HOuN6/aqXbh2hEfjG1Iiaqd7s2AF1eZ7iL2OsFKTg9Rf2ht/jeUxqYZcZ3aVK7 +aTV4R9e/4oiLxkRA280R91jiNiUaCWs1tWuyDi+J4GYNO1nP2k6qLsTBfpfBJVTNGtt JrQdWoxqPvVeY1B2AU7MFzFFEIkn1iKPgMM7KZrTS/qYk4ZveXjNYL3Gtns4PxkQwl/9 KWSA== X-Gm-Message-State: APt69E3yMiZfdS7U+ugjAyLH32TD5+5Kdjjdlaov+tbZfGrI0zcw7Va4 UgZ/yJx9fN8GScDtuwQeJLEeL9YO72AYhruKmi8jag0W X-Google-Smtp-Source: ADUXVKIdE1m1m4TETVa1h/cqZ8CxekzSCIH9vIwnPsPgQVLlBEyad5qLj3AIhEeN+u2LFRVGawQ12aAht/UBwB15Blk= X-Received: by 2002:a6b:c6c9:: with SMTP id w192-v6mr335522iof.131.1528809118442; Tue, 12 Jun 2018 06:11:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bf84:0:0:0:0:0 with HTTP; Tue, 12 Jun 2018 06:11:42 -0700 (PDT) In-Reply-To: <87d0wwjmuy.fsf@toke.dk> References: <2D09D61DDFA73D4C884805CC7865E6114DDE71DC@GAALPA1MSGUSRBF.ITServices.sbc.com> <87d0wwjmuy.fsf@toke.dk> From: Donald Eastlake Date: Tue, 12 Jun 2018 09:11:42 -0400 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: "STARK, BARBARA H" , "babel@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Babel YANG deliverable X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 13:12:02 -0000 Hi Barbara and Toke, On Tue, Jun 12, 2018 at 6:55 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > "STARK, BARBARA H" writes: > >> I think we need to have a list discussion about this Babel YANG delivera= ble. >> It is clear that none of the people directly engaged in this WG have the= expertise or competency to create a Babel YANG model. We also have no desi= re or intent to acquire this expertise. The learning curve is steep and tim= e-consuming. >> The requirement to create a Babel YANG model is purely about creating th= e model for the sake of having the model. There exists no user community de= mand for this model, at this time. I do not view the requirement in the Babel Charter for a YANG model the same way you do. Although no analogy is exact, let me give a quick analogy to security. Time and again, protocols have come to the IETF with advocates who insist the security isn't needed, that the protocol will only be used in limited environments, that the protocol will never be used across the general Internet, that there is no community demand for the protocol to be securable, etc. And those advocate have almost always been proven wrong -- in many cases resulting in painful and sometimes not entirely successful attempts to retrofit security. So, there is an actual general IETF process requirement for Security Considerations sections in standards track documents. An analogy to management is not exact, management is easier to retrofit, Operational Considerations is not a general IETF process required section in standard track documents, etc. Nevertheless, I think that management oriented people would view with suspicion the claim that Babel will never need to be manageable, that there will never be a case where a management station that is, say, monitoring information inside a variety of protocols on a network would also like to monitor Babel. So, there is a requirement for a YANG model in the Babel Charter but, as long as there is clear progress towards that, it is not clear that its completion needs to be a blocking consideration for rfc6126bis. >> There exists a user community who does want Babel. There is a homenet (u= nmanaged network) use case which has rfc6126bis as a dependency. There is i= nterest from other users with networks that do not require management throu= gh a management protocol, or who are using other non-IETF solutions. There = is some interest from at least one employee of an ISP (me) who has committe= d to creating the information model and a BBF TR-181 data model (for use wi= th BBF TR-069 and TR-369). Lack of publication of rfc6126bis is standing in= the way of these use cases being fully realized. [Side note: Because of th= ese use cases, netconf and YANG MUST NOT be mandatory to implement, even if= the YANG model is created.] >> >> However, the lack of a YANG model is being used as an excuse to prevent = publication of rfc6126bis -- even though none of the user communities activ= ely interested in Babel care anything about YANG or netconf. The Babel user= community is being held hostage by YANG advocates. >> So we're at an impasse. >> >> I see the following as possible ways forward, and provide an assessment = of their feasibility and outcomes. >> 1. Kill the rfc6126bis effort now. Very feasible. Outcome: All work on B= abel leaves IETF and either dies or goes elsewhere. >> 2. Put rfc6126bis on hold until a YANG model happens. This is the defaul= t "do nothing" choice. Obviously, very feasible. Outcome: Since the YANG mo= del shows no sign of happening, it is highly likely we would lose the inter= est of the draft authors, and it would be effectively the same as killing t= he draft. If we're going to kill the draft, then I prefer the decision be a= conscious one (see option 1). >> 3. One of the people currently engaged in Babel puts in the time and eff= ort to learn YANG and create a model. Highly unlikely. Outcome: Extensive d= elay (due to learning curve and bad attitude), which is likely to devolve i= nto option 2. >> 4. Someone who is competent in YANG volunteers to quickly create the YAN= G model. Feasibility is unknown, but no-one has stepped forward, yet. Outco= me: If done quickly, it might be successful; otherwise, it will devolve int= o option 2. I will send a message to the Operations Area Directors and Directorate seeking a volunteer to work on a YANG model. I probably should have done this earlier. >> 5. The draft is sent on for IESG review without there being a YANG model= . This can be with** or without a management section that explains the curr= ent lack of a YANG model. Feasible (depends on chair willingness). Outcome:= Success is uncertain since we've been told there is a policy that says rou= ting protocols must have a YANG model just for the sake of having a YANG mo= del? Not sure what the policy really is, since I can't find where it's stat= ed. The Chairs can request publication based on WG consensus but it is then up to our Area Director to review the document and, if he so chooses, initiate the IETF Last Call and put it on the IESG agenda. >> Option 2 is default (do nothing, and kill the draft by lack of action). = Option 3 should be tossed -- it's not going to happen. Options 1, 4, or 5 a= re up to the chairs. [The WG participants know of no-one for option 4.] >> Donald, Russ, -- it's in your hands. Do we consciously kill it, do you f= ind someone ASAP to do the YANG model, do you move it forward and fight the= fight, or do we do nothing and allow it to die? >> >> My preference would be to fight the fight -- send the draft up for revie= w. This "there shall be a YANG model" policy (it would be great to get a po= inter to this policy so we can read it and determine who approved this poli= cy and any other details of this policy) is inappropriate and untenable for= Babel. I did ask our AD and he indicated that he would be extremely reluctant to forward the draft to the IESG, due to the requirement in the Babel Charter for a YANG model, unless such a model had been at least started. > I agree with your assessment, and would prefer option 4 (if feasible) or > 5. I think it would be a shame if the IETF bureaucracy ends up choking > Babel :/ Thanks, Donald PS: The Babel Charter is here https://datatracker.ietf.org/wg/babel/about/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > -Toke From nobody Tue Jun 12 07:20:29 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E20E130F29 for ; Tue, 12 Jun 2018 07:20:27 -0700 (PDT) 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 kOWD3lc_glAJ for ; Tue, 12 Jun 2018 07:20:23 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C692130E3D for ; Tue, 12 Jun 2018 07:20:23 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w5CEGqd6017020; Tue, 12 Jun 2018 10:20:22 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2jjetmb196-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Jun 2018 10:20:21 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w5CEKKsH025052; Tue, 12 Jun 2018 10:20:21 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w5CEKEFF024761; Tue, 12 Jun 2018 10:20:15 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 7553340002DA; Tue, 12 Jun 2018 14:20:14 +0000 (GMT) Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (unknown [130.8.218.152]) by zlp30483.vci.att.com (Service) with ESMTPS id 62FD9400069B; Tue, 12 Jun 2018 14:20:14 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.78]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0399.000; Tue, 12 Jun 2018 10:20:13 -0400 From: "STARK, BARBARA H" To: Martin Vigoureux CC: "babel@ietf.org" Thread-Topic: [babel] Babel YANG deliverable Thread-Index: AdQB89PwrnOJZclrSnekzkUjBmvbvgAeIhuAAACqxYD//9LlMA== Date: Tue, 12 Jun 2018 14:20:13 +0000 Message-ID: <579233F1-7794-49E7-B05F-43A95CCACC45@att.com> References: <2D09D61DDFA73D4C884805CC7865E6114DDE71DC@GAALPA1MSGUSRBF.ITServices.sbc.com> <87lgbkgoqu.wl-jch@irif.fr>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-12_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=800 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806120162 Archived-At: Subject: Re: [babel] Babel YANG deliverable X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 14:20:28 -0000 Hi Martin, > On Jun 12, 2018, at 10:02 PM, Martin Vigoureux wrote: >=20 > Hello WG, >=20 > there is no "policy". There is a WG charter which says: >=20 > To be consistent with the ongoing effort to use YANG data modules in the > Routing Area, a Babel YANG data model to support management of home > gateway routers is required as part of moving Babel to Proposed > Standard. >=20 > regards, > martin There appears to be considerable variation across IETF as to what is done a= bout charter items where no-one steps up to do do them. Other cases I=92ve = seen, the AD has simply acknowledged drafts do not write themselves. A char= ter item that no-one volunteers to write is one that will not be written. T= his is the only case I=92ve seen where a standalone draft is held hostage u= nless other chartered items are done.=20 Are you volunteering to create the Babel yang model? That would be great, i= f you are. Hopefully you=92re not demanding that others do work you find so= unimportant that you aren=92t willing to spend your own time on it.=20 Barbara=20 >=20 > Le 2018-06-12 =E0 14:42, Juliusz Chroboczek a =E9crit : >>> My preference would be to fight the fight -- send the draft up for >>> review. This "there shall be a YANG model" policy (it would be great to >>> get a pointer to this policy so we can read it and determine who approv= ed >>> this policy and any other details of this policy) is inappropriate and >>> untenable for Babel. >> I fully agree. >> -- Juliusz >> _______________________________________________ >> babel mailing list >> babel@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_babel&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8= Tq4vrfog&m=3DKUl39WBERUssMBc4NgENSyN8yJFmYTlXPKHyiR76N8E&s=3D4kbvBR_jYRCAjB= MnjFcr8fZD0RMBfKNmvx0CM9Dcvq8&e=3D >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_babel&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8T= q4vrfog&m=3DKUl39WBERUssMBc4NgENSyN8yJFmYTlXPKHyiR76N8E&s=3D4kbvBR_jYRCAjBM= njFcr8fZD0RMBfKNmvx0CM9Dcvq8&e=3D From nobody Tue Jun 12 10:32:02 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1DD130F78 for ; Tue, 12 Jun 2018 10:31:59 -0700 (PDT) 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, 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 yg71eICkThdk for ; Tue, 12 Jun 2018 10:31:56 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D16130F7E for ; Tue, 12 Jun 2018 10:31:53 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5CHVqqq029050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Jun 2018 19:31:52 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w5CHVq2S009973; Tue, 12 Jun 2018 19:31:53 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 0020EEB22E; Tue, 12 Jun 2018 19:31:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id dBCfbWTz7x3C; Tue, 12 Jun 2018 19:31:49 +0200 (CEST) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1A990EB279; Tue, 12 Jun 2018 19:31:46 +0200 (CEST) Date: Tue, 12 Jun 2018 19:31:46 +0200 Message-ID: <87h8m752t9.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org CC: Denis Ovsienko User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 12 Jun 2018 19:31:52 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 12 Jun 2018 19:31:53 +0200 (CEST) X-Miltered: at korolev with ID 5B200388.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B200388.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B200388.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B200388.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B200388.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B200388.002 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: [babel] A few observations about HMAC authentication X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 17:32:00 -0000 Clara and Weronika have made good progress today -- we've got roughly the functionality of 7298 (modulo some minor bugs) plus the pseudo-header. 1. Original Babel is fairly robust against packet reordering. This is no longer the case with HMAC authentication, where any reordered packets will be dropped due to TS/PC mis-ordering. 2. We don't understand why TS/PC are two integers. As far as the protocol is concerned, TS/PC is just a 48-bit string ordered lexicographically. Have we missed something? 3. I'm still not convinced we want a keyID. Please convince me either way. We'll keep youse updated, -- Juliusz From nobody Tue Jun 12 10:40:39 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC9A130F73 for ; Tue, 12 Jun 2018 10:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kapsi.fi 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 jHnGjnO1jW8Y for ; Tue, 12 Jun 2018 10:40:33 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (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 D65FF130F8E for ; Tue, 12 Jun 2018 10:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=/bqTn/1dHbWWm91m/0PkUVy5/Odt9gRHfm9ev/5F3E0=; b=g7E5x2ogJ7iDs8I5LFPA4jm2gNOO9dMWaexcDuuep45BKbogTnsNGWMDl7yMshHk4zP06obIw8wKYkkvSPJT7c6PWtx+cs+S21N+uLpuerySoUQBSXZeu/12SGwUAX3KtGNS6eiCh/d2C9hQQkvE/Fubx9uNWrhkuKhVui6jxh7WBCtKA+Hnb/Q8rNos1G03UUjSXDjpvdkZMyp1NvupWbzUk4mvC5/GFz8DJ4mOZ0rVJXwJVduFakIsdrv7h72BjtFkuOLeqo+m1HyjcaUtZMG0Qj+GiNVoJow87wXz4aJlJnqxCfz/frFf9MYE4yx9h0jbk9pBRCZajThAKROY8w==; Received: from 91-155-69-32.elisa-laajakaista.fi ([91.155.69.32] helo=poro.lan) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fSnHS-0006dy-2H; Tue, 12 Jun 2018 20:40:30 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Markus Stenberg In-Reply-To: <87h8m752t9.wl-jch@irif.fr> Date: Tue, 12 Jun 2018 20:40:29 +0300 Cc: babel@ietf.org, Denis Ovsienko Content-Transfer-Encoding: quoted-printable Message-Id: <9FA87AFB-3DE6-48E8-AC26-3683176F15A4@iki.fi> References: <87h8m752t9.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.6.18) X-SA-Exim-Connect-IP: 91.155.69.32 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] A few observations about HMAC authentication X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 17:40:38 -0000 On 12 Jun 2018, at 20.31, Juliusz Chroboczek wrote: > Clara and Weronika have made good progress today -- we've got roughly = the > functionality of 7298 (modulo some minor bugs) plus the pseudo-header. >=20 > 1. Original Babel is fairly robust against packet reordering. This is = no > longer the case with HMAC authentication, where any reordered = packets > will be dropped due to TS/PC mis-ordering. Considering there is no guarantee of packet ordering in general, you = would really want something more like IPsec replay window (i.o.w. most = recent N remembered as bits =E2=80=99seen this, not that=E2=80=99) than = just plain increasing order-or-die.=20 That said, I am not sure how much of reordering would you get on = link-local anyway, the reordering is more of an issue on longer routes. > 2. We don't understand why TS/PC are two integers. As far as the = protocol > is concerned, TS/PC is just a 48-bit string ordered = lexicographically. > Have we missed something? >=20 > 3. I'm still not convinced we want a keyID. Please convince me either = way. Well, it is tradeoff between 2 options: - flag day update of network configuration which isn=E2=80=99t really an = option (I know for a fact that key rotation is required in A LOT of = places these days as a matter of course) - attempting =E2=80=98few=E2=80=99 keys to see if hash matches one of = them=20 The procedure is basically 1. one key rules! 2. gradually roll out configurations with both =E2=80=98the one key=E2=80=99= and new key accepted while all send old one, then 3. update all configurations just to send new one, and 4. yet once more update configurations to get rid of old one. during [2/3] you would have to essentially accept both keys to avoid = flag day. There are arguably also other configurations, where you have overlapping = domains with some parts of it using different keys, but I am not going = to tinfoil hat land here; the above is a scenario I have seen in action = =E2=80=98enough=E2=80=99. Anyway, from my point of view, just one hash + no key id is fine, if we = don=E2=80=99t try to make the hash actually hard to brute force. If we = do that, then trying two keys might be prohibitively expensive but then = again, it would be too easy to DoS too. Cheers, -Markus= From nobody Tue Jun 12 11:07:04 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386D4130F9C for ; Tue, 12 Jun 2018 11:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 s4Ha_DwYWIBe for ; Tue, 12 Jun 2018 11:06:55 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75BB7130E79 for ; Tue, 12 Jun 2018 11:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1528826814; x=2392740414; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TUO9Jiz4kIgCrhK6Kh9a9C9NTAGpCnS3P+vWAly/Oro=; b=0lYySQRD9ov7/xgos///o1MfKQmUAZortNeDrCDXSKbxgyQTjz56+n8xMO4VoRFL L9nzIADE1tSneylzGg9Du8Rohj35OoCeRU8+I2wEzAojBC2Pkz4zf6kyGlBMN+7W MNJnk3Affd3c7lj/Dh8LCdQdjM3DGlpOYZuSDle0yAa4rJKOhMq+pUGvXWZgc2kU hRAcew20SmmMRnka20u2kdXdrYygC9OUGaXBmIY8aG6FTCP9b37JKZqAGCUrRrQW ojgU8cdfI3CWJpMm4q9mWmvQdggRpxfyeybvr3c6787ODo47xDc/eV06z9wUhbPX /bDzLxTvL+BVFnX4Ikz+RQ==; X-AuditID: 11973e16-6f1ff7000000740c-82-5b200bbec4f5 Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 39.60.29708.EBB002B5; Tue, 12 Jun 2018 11:06:54 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0PA8001PM2BI0080@mr2-mtap-s02.rno.apple.com>; Tue, 12 Jun 2018 11:06:54 -0700 (PDT) Received: from [17.234.6.103] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0PA800DPE2BHLU20@nwk-mmpp-sz12.apple.com>; Tue, 12 Jun 2018 11:06:54 -0700 (PDT) X-Va-A: X-Va-T-CD: 97ae2fa26a9cff59ec260ac59bd7fd5d X-Va-E-CD: fdaf2856c9c41a3a75a031fea9ffca07 X-Va-R-CD: ed536e1bb4a88cc8366416d7c28beef5 X-Va-CD: 0 X-Va-ID: 35d801c3-069e-49d1-b3a4-71b6e12711f1 X-V-A: X-V-T-CD: c5dbda1f82e1bbea6259c0421d21e87a X-V-E-CD: fdaf2856c9c41a3a75a031fea9ffca07 X-V-R-CD: ed536e1bb4a88cc8366416d7c28beef5 X-V-CD: 0 X-V-ID: 573d753f-53e3-43ed-973f-e95c637ca007 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-12_11:,, signatures=0 Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <9FA87AFB-3DE6-48E8-AC26-3683176F15A4@iki.fi> Date: Tue, 12 Jun 2018 11:06:52 -0700 Cc: Juliusz Chroboczek , Denis Ovsienko , babel@ietf.org Content-transfer-encoding: quoted-printable Message-id: References: <87h8m752t9.wl-jch@irif.fr> <9FA87AFB-3DE6-48E8-AC26-3683176F15A4@iki.fi> To: Markus Stenberg X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUiuPlRm+4+boVog+YtUhZbFnWzWFz5c57d Yn7rMjaLvXNXsDiweCxZ8pPJ4/DXhSwei7e8ZfQ43NDPEsASxWWTkpqTWZZapG+XwJVx/fRG poLJ0hXLWncwNjAeEe1i5OCQEDCRuL6oqIuRi0NI4ACTxK3Oq4xdjJwcvAKCEj8m32MBqWEW UJeYMiUXomY9k8Tsjd+YIZwvjBIrHv8Ba5AQYJf482sHC4StLXH4WwMjjN007S5c/FTLEzYI m0tiwdbTrBBH6ErsWKcNEWaTWH9iCROErSWxfvUPVhj7WOs7Zhj7d/t0qJGcEue/TGSHsHUk /h9fBjU+W2Lx6cdgvcIC0hJdF+6CrRIWcJRY/dAWxGQDGnNgjRGIySlgJfH2qCZIMYuAqsSG k61gQ5gF4iV29z5nhbC1JZ68uwA2hFfARmLy2xqQsJBAuMThyc/B9osA7b/w6SDUvUoS07/f ZpvAKDcLKThnIYJzFpKhCxiZVzEK5SZm5uhm5pnrJRYU5KTqJefnbmIERf90O7EdjA9XWR1i FOBgVOLhtbgiHy3EmlhWXJl7iFGag0VJnPe1OlBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD Y4BNzUO9g8tElfonLfU7dsRd2spC3fgw43mL/GYlPpu56zk5r1ltTtQryliZ+ubdh8D9s2d/ t1hjJTs197e+X1vqR853gRVBlQtnskie2+ymV/Yx9u7bxkLZ5Y/WFM127xHKa5NQ6yj3+b2/ 8mPvRH3OlXLivlM5c27an2tQPdQjMrF9oUudEktxRqKhFnNRcSIATWE3c98CAAA= Archived-At: Subject: Re: [babel] A few observations about HMAC authentication X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 18:07:02 -0000 > On Jun 12, 2018, at 10:40, Markus Stenberg = wrote: >=20 > On 12 Jun 2018, at 20.31, Juliusz Chroboczek wrote: >> Clara and Weronika have made good progress today -- we've got roughly = the >> functionality of 7298 (modulo some minor bugs) plus the = pseudo-header. >>=20 >> 1. Original Babel is fairly robust against packet reordering. This = is no >> longer the case with HMAC authentication, where any reordered = packets >> will be dropped due to TS/PC mis-ordering. >=20 > Considering there is no guarantee of packet ordering in general, you = would really want something more like IPsec replay window (i.o.w. most = recent N remembered as bits =E2=80=99seen this, not that=E2=80=99) than = just plain increasing order-or-die.=20 >=20 > That said, I am not sure how much of reordering would you get on = link-local anyway, the reordering is more of an issue on longer routes. Has the Babel community observed reordering of Babel packets? Is this on = local networks or overlays only? If reordering does happen, I agree with the replay window solution. >> 2. We don't understand why TS/PC are two integers. As far as the = protocol >> is concerned, TS/PC is just a 48-bit string ordered = lexicographically. >> Have we missed something? I'm equally confused, I'm assuming having the standard only define one = string ordered lexicographically would be easier to implement - and = therefore safer. >> 3. I'm still not convinced we want a keyID. Please convince me = either way. >=20 > Well, it is tradeoff between 2 options: >=20 > - flag day update of network configuration which isn=E2=80=99t really = an option (I know for a fact that key rotation is required in A LOT of = places these days as a matter of course) >=20 > - attempting =E2=80=98few=E2=80=99 keys to see if hash matches one of = them=20 >=20 > The procedure is basically >=20 > 1. one key rules! > 2. gradually roll out configurations with both =E2=80=98the one key=E2=80= =99 and new key accepted while all send old one, then > 3. update all configurations just to send new one, and > 4. yet once more update configurations to get rid of old one. >=20 > during [2/3] you would have to essentially accept both keys to avoid = flag day. >=20 > There are arguably also other configurations, where you have = overlapping domains with some parts of it using different keys, but I am = not going to tinfoil hat land here; the above is a scenario I have seen = in action =E2=80=98enough=E2=80=99. I think the tradeoff is 1) with keyID - bad: you have to send two bytes of keyID per hash - good: you only need to try one key when receiving a hash: O(1) 2) without keyID - bad: you have to try as many hashes as keys you know: O(n), = that opens up DoS - good: you save two bytes for each hash sent over the wire I'd prefer to spend the two bytes to minimize CPU utilization and DoS = risk. > Anyway, from my point of view, just one hash + no key id is fine, if = we don=E2=80=99t try to make the hash actually hard to brute force. If = we do that, then trying two keys might be prohibitively expensive but = then again, it would be too easy to DoS too. Unless I'm missing something, having a reasonable hash function = (SHA2-256) and a large-enough key (256bits) is enough to prevent = brute-forcing without the need to perform multiple rounds of hashing. David= From nobody Tue Jun 12 13:34:53 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31783130E8F for ; Tue, 12 Jun 2018 13:34:51 -0700 (PDT) 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, 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 4LiLNw-x_U-4 for ; Tue, 12 Jun 2018 13:34:46 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4B63130E12 for ; Tue, 12 Jun 2018 13:34:45 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5CKYeQV022176; Tue, 12 Jun 2018 22:34:40 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9C6BFEB200; Tue, 12 Jun 2018 22:34:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id RjEg33HSoENO; Tue, 12 Jun 2018 22:34:39 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 53DC7EB22E; Tue, 12 Jun 2018 22:34:34 +0200 (CEST) Date: Tue, 12 Jun 2018 22:34:34 +0200 Message-ID: <87vaansq05.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Markus Stenberg , Denis Ovsienko , babel@ietf.org In-Reply-To: References: <87h8m752t9.wl-jch@irif.fr> <9FA87AFB-3DE6-48E8-AC26-3683176F15A4@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 12 Jun 2018 22:34:41 +0200 (CEST) X-Miltered: at korolev with ID 5B202E60.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B202E60.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B202E60.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] A few observations about HMAC authentication X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 20:34:52 -0000 >>> 1. Original Babel is fairly robust against packet reordering. This is no >>> longer the case with HMAC authentication, where any reordered packets >>> will be dropped due to TS/PC mis-ordering. >> That said, I am not sure how much of reordering would you get on >> link-local anyway, the reordering is more of an issue on longer routes. Agreed. I think we're going to implement with no reordering allowed, but the spec should be flexible enough to allow a reordering window. I'll be grateful for help with this. >>> 3. I'm still not convinced we want a keyID. Please convince me either way. >> >> Well, it is tradeoff between 2 options: >> >> - flag day update of network configuration which isn’t really an option >> (I know for a fact that key rotation is required in A LOT of places >> these days as a matter of course) I think there's consensus that we want to support key rotation -- carrying multiple HMACs for a single packet will be allowed in either case. The question is whether the HMACs are decorated with a Key ID -- in Denis' draft, there's an explicit Key ID, so you only check the HMACs that correspond to keys you already know. In our implementation, there's no Key ID, so you have to check all HMACs before you decide whether any match. > I think the tradeoff is > 1) with keyID > - bad: you have to send two bytes of keyID per hash > - good: you only need to try one key when receiving a hash: O(1) The main issue is one of manageability. With no Key ID, before doing key rotation, you just deploy the new key -- nothing to worry about except the hash function and the key. With a Key ID, you need to find an unused Key ID and ensure you deploy with the same Key ID to all routers. > - bad: you have to try as many hashes as keys you know: O(n), that > opens up DoS I don't see that. The "n" in O(n) is the number of keys you already know (normally just 1 or 2), so it's not controlled by the attacker. The procedure is simply: - compute HMAC(packet, key) for all keys known to you; - compare the result with each of the HMAC TLVs in the received packet. It can be optimised somewhat with a Key ID, but not much, unless you've got dozens of keys deployed simultaneously. -- Juliusz From nobody Wed Jun 13 02:03:24 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BE1130E14 for ; Wed, 13 Jun 2018 02:03:20 -0700 (PDT) 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 axX34KAVW38n for ; Wed, 13 Jun 2018 02:03:16 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87182130E05 for ; Wed, 13 Jun 2018 02:03:16 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w5D8tUFV029697; Wed, 13 Jun 2018 05:03:15 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 2jjsjbdftb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Jun 2018 05:03:14 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w5D93Ews014056; Wed, 13 Jun 2018 05:03:14 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w5D93BOx014008; Wed, 13 Jun 2018 05:03:11 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 833B34000348; Wed, 13 Jun 2018 09:03:11 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30484.vci.att.com (Service) with ESMTPS id 63A704000340; Wed, 13 Jun 2018 09:03:11 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.78]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0399.000; Wed, 13 Jun 2018 05:03:10 -0400 From: "STARK, BARBARA H" To: "'Donald Eastlake'" , =?utf-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= CC: "babel@ietf.org" Thread-Topic: [babel] Babel YANG deliverable Thread-Index: AdQB89PwrnOJZclrSnekzkUjBmvbvgAaYK+AAATGCwAAFU4iEA== Date: Wed, 13 Jun 2018 09:03:09 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DDEA127@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DDE71DC@GAALPA1MSGUSRBF.ITServices.sbc.com> <87d0wwjmuy.fsf@toke.dk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.242.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-13_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806130101 Archived-At: Subject: Re: [babel] Babel YANG deliverable X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 09:03:21 -0000 SGkgRG9uYWxkLA0KUmVzcG9uc2UgaW5saW5lLg0KQmFyYmFyYQ0KLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiA+PiBJIHRoaW5rIHdlIG5lZWQgdG8gaGF2ZSBhIGxpc3QgZGlzY3Vzc2lvbiBhYm91dCB0 aGlzIEJhYmVsIFlBTkcNCj4gZGVsaXZlcmFibGUuDQo+ID4+IEl0IGlzIGNsZWFyIHRoYXQgbm9u ZSBvZiB0aGUgcGVvcGxlIGRpcmVjdGx5IGVuZ2FnZWQgaW4gdGhpcyBXRyBoYXZlIHRoZQ0KPiBl eHBlcnRpc2Ugb3IgY29tcGV0ZW5jeSB0byBjcmVhdGUgYSBCYWJlbCBZQU5HIG1vZGVsLiBXZSBh bHNvIGhhdmUgbm8NCj4gZGVzaXJlIG9yIGludGVudCB0byBhY3F1aXJlIHRoaXMgZXhwZXJ0aXNl LiBUaGUgbGVhcm5pbmcgY3VydmUgaXMgc3RlZXAgYW5kDQo+IHRpbWUtY29uc3VtaW5nLg0KPiA+ PiBUaGUgcmVxdWlyZW1lbnQgdG8gY3JlYXRlIGEgQmFiZWwgWUFORyBtb2RlbCBpcyBwdXJlbHkg YWJvdXQgY3JlYXRpbmcNCj4gdGhlIG1vZGVsIGZvciB0aGUgc2FrZSBvZiBoYXZpbmcgdGhlIG1v ZGVsLiBUaGVyZSBleGlzdHMgbm8gdXNlciBjb21tdW5pdHkNCj4gZGVtYW5kIGZvciB0aGlzIG1v ZGVsLCBhdCB0aGlzIHRpbWUuDQo+IA0KPiBJIGRvIG5vdCB2aWV3IHRoZSByZXF1aXJlbWVudCBp biB0aGUgQmFiZWwgQ2hhcnRlciBmb3IgYSBZQU5HIG1vZGVsIHRoZQ0KPiBzYW1lIHdheSB5b3Ug ZG8uDQo+ICAgICAgQWx0aG91Z2ggbm8gYW5hbG9neSBpcyBleGFjdCwgbGV0IG1lIGdpdmUgYSBx dWljayBhbmFsb2d5IHRvIHNlY3VyaXR5LiBUaW1lDQo+IGFuZCBhZ2FpbiwgcHJvdG9jb2xzIGhh dmUgY29tZSB0byB0aGUgSUVURiB3aXRoIGFkdm9jYXRlcyB3aG8gaW5zaXN0IHRoZQ0KPiBzZWN1 cml0eSBpc24ndCBuZWVkZWQsIHRoYXQgdGhlIHByb3RvY29sIHdpbGwgb25seSBiZSB1c2VkIGlu IGxpbWl0ZWQNCj4gZW52aXJvbm1lbnRzLCB0aGF0IHRoZSBwcm90b2NvbCB3aWxsIG5ldmVyIGJl IHVzZWQgYWNyb3NzIHRoZSBnZW5lcmFsDQo+IEludGVybmV0LCB0aGF0IHRoZXJlIGlzIG5vIGNv bW11bml0eSBkZW1hbmQgZm9yIHRoZSBwcm90b2NvbCB0byBiZQ0KPiBzZWN1cmFibGUsIGV0Yy4g QW5kIHRob3NlIGFkdm9jYXRlIGhhdmUgYWxtb3N0IGFsd2F5cyBiZWVuIHByb3ZlbiB3cm9uZyAt DQo+IC0gaW4gbWFueSBjYXNlcyByZXN1bHRpbmcgaW4gcGFpbmZ1bCBhbmQgc29tZXRpbWVzIG5v dCBlbnRpcmVseSBzdWNjZXNzZnVsDQo+IGF0dGVtcHRzIHRvIHJldHJvZml0IHNlY3VyaXR5LiBT bywgdGhlcmUgaXMgYW4gYWN0dWFsIGdlbmVyYWwgSUVURiBwcm9jZXNzDQo+IHJlcXVpcmVtZW50 IGZvciBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9ucyBpbiBzdGFuZGFyZHMgdHJhY2sN Cj4gZG9jdW1lbnRzLg0KPiAgICAgIEFuIGFuYWxvZ3kgdG8gbWFuYWdlbWVudCBpcyBub3QgZXhh Y3QsIG1hbmFnZW1lbnQgaXMgZWFzaWVyIHRvIHJldHJvZml0LA0KPiBPcGVyYXRpb25hbCBDb25z aWRlcmF0aW9ucyBpcyBub3QgYSBnZW5lcmFsIElFVEYgcHJvY2VzcyByZXF1aXJlZCBzZWN0aW9u IGluDQo+IHN0YW5kYXJkIHRyYWNrIGRvY3VtZW50cywgZXRjLiBOZXZlcnRoZWxlc3MsIEkgdGhp bmsgdGhhdCBtYW5hZ2VtZW50DQo+IG9yaWVudGVkIHBlb3BsZSB3b3VsZCB2aWV3IHdpdGggc3Vz cGljaW9uIHRoZSBjbGFpbSB0aGF0IEJhYmVsIHdpbGwgbmV2ZXINCj4gbmVlZCB0byBiZSBtYW5h Z2VhYmxlLCB0aGF0IHRoZXJlIHdpbGwgbmV2ZXIgYmUgYSBjYXNlIHdoZXJlIGENCj4gbWFuYWdl bWVudCBzdGF0aW9uIHRoYXQgaXMsIHNheSwgbW9uaXRvcmluZyBpbmZvcm1hdGlvbiBpbnNpZGUg YSB2YXJpZXR5IG9mDQo+IHByb3RvY29scyBvbiBhIG5ldHdvcmsgd291bGQgYWxzbyBsaWtlIHRv IG1vbml0b3IgQmFiZWwuIA0KDQpKdXN0IHRvIGJlIGNsZWFyLCBJIG5ldmVyIHN1Z2dlc3RlZCB0 aGF0IEJhYmVsIHdpbGwgbmV2ZXIgbmVlZCB0byBiZSBtYW5hZ2VhYmxlLiBJJ20gcHV0dGluZyBy ZWFsIGVmZm9ydCBpbnRvIGJhYmVsLWluZm9ybWF0aW9uLW1vZGVsIGJlY2F1c2UgSSBkbyBzZWUg dGhlIG5lZWQgZm9yIG1hbmFnZWFiaWxpdHkgaW4gc29tZSB1c2FnZXMuIFRoZSBwb2ludHMgSSd2 ZSBtYWRlIGFyZToNCiAtIHRoZXJlIG11c3QgYmUgbm8gbWFuZGF0b3J5LXRvLWltcGxlbWVudCBt YW5hZ2VtZW50IHByb3RvY29sIHNvIGxpZ2h0d2VpZ2h0IGltcGxlbWVudGF0aW9ucyBjYW4gZXhp c3QgZm9yIHVubWFuYWdlZCBlbnZpcm9ubWVudHMgKGFuZCwgYWxzbywgbWFuYWdlbWVudCBpbnRl cmZhY2VzIGFyZSBhIG1ham9yIHNvdXJjZSBvZiBzZWN1cml0eSB2dWxuZXJhYmlsaXRpZXM7IG1h bmFnZW1lbnQgaW50ZXJmYWNlcyB0aGF0IGFyZW4ndCBwcmVzZW50IGhhdmUgbm8gdnVsbmVyYWJp bGl0aWVzIGFuZCBjYW4ndCBiZSB1c2VkIHRvIGNvbXByb21pc2UgYSBkZXZpY2UpDQogLSBiYWJl bC1pbmZvcm1hdGlvbi1tb2RlbCBpcyBwcm9ncmVzc2luZw0KIC0gSSdsbCBiZSBjcmVhdGluZyBh IFRSLTE4MSBkYXRhIG1vZGVsLCBzbyBCYWJlbCBjYW4gYmUgbWFuYWdlZCB0aHJvdWdoIFRSLTA2 OS9UUi0zNjk7IHRoaXMgaXMgdGhlIG1hbmFnZW1lbnQgcHJvdG9jb2wgSSdtIGludGVyZXN0ZWQg aW4gdXNpbmcgYmVjYXVzZSBteSBlbXBsb3llciBjdXJyZW50bHkgdXNlcyBpdCB0byBtYW5hZ2Vk IG1pbGxpb25zIG9mIFdpLUZpIENFIHJvdXRlcnMgYW5kIGhhcyBubyBwbGFucyBvZiBtb3Zpbmcg dG8gbmV0Y29uZiBvciByZXN0Y29uZiBmb3IgQ0Ugcm91dGVyIG1hbmFnZW1lbnQNCiAtIEkgaGF2 ZSBubyBpbnRlbnRpb24gb2YgbGVhcm5pbmcgWUFORywgYW5kIG5vIG90aGVyIHJlZ3VsYXIgV0cg cGFydGljaXBhbnQgYXBwZWFycyBpbnRlcmVzdGVkIGluIGxlYXJuaW5nIFlBTkcgZWl0aGVyOyBZ QU5HIGlzbid0IGVhc3kgLS0gaXQgdGFrZXMgdGltZSB0byBsZWFybiBhbmQgbW9yZSB0aW1lIHRv IGxlYXJuIHdlbGw7IHNvIHRoZSBhdXRob3JzIG9mIGFsbCB0aGUgYmFiZWwgV0cgZHJhZnRzIGFy ZSBub3QgaW4gYSBwb3NpdGlvbiB0byBwcm9taXNlIGEgWUFORyBtb2RlbA0KIC0gYXMgYW4gYWRk aXRpb25hbCBub3RlIChyZXNwb25kaW5nIHRvIHlvdXIgc2VudGVuY2UgYWJvdXQgbW9uaXRvcmlu ZyksIEkgdGhpbmsgTmV0SlNPTiAobmV0anNvbi5vcmcpIHdvdWxkIGJlIGEgbXVjaCBiZXR0ZXIg YXBwcm9hY2ggZm9yIHRoZSB0eXBlIG9mIG1vbml0b3JpbmcgeW91IGRlc2NyaWJlOyBpdCB3b3Vs ZCBiZSBwcmV0dHkgZWFzeSB0byBjcmVhdGUgYSBOZXRKU09OIGV4dGVuc2lvbiBmb3IgQmFiZWwg KGdpdmVuIHRoZSBpbmZvcm1hdGlvbiBtb2RlbCkNCg0KVGhlIGxhbmd1YWdlIHJlcXVpcmluZyBh IFlBTkcgbW9kZWwgd2FzIHBsYWNlZCBpbiB0aGUgY2hhcnRlciBiZWNhdXNlIEJlbm9pdCBpbnNp c3RlZCBvbiBpdCBhbmQgc2FpZCBCYWJlbCB3aWxsIG5vdCBiZSBtYWRlIGludG8gYW4gSUVURiBQ cm9wb3NlZCBTdGFuZGFyZCB3aXRob3V0IGEgWUFORyBtb2RlbCoqLiBJdCB3YXMgbm90IHNvbWV0 aGluZyB0aGUgV0cgd2FudGVkLCBidXQgaXMgc29tZXRoaW5nIHRoYXQgd2FzIGZvcmNlZCBvbiB1 cy4gQXBwYXJlbnRseSB0aGlzIHJlcXVpcmVtZW50IHdpbGwgcmVuZGVyIG1lYW5pbmdsZXNzIGFs bCB0aGUgd29yayBkb25lIG9uIEJhYmVsIHVubGVzcyBzb21lb25lIGNhbiBiZSBmb3VuZCB0byBk byBhIFlBTkcgbW9kZWwuIFllYXJzIG9mIHdvcmsgYW5kIGVmZm9ydCBpcyBkZXBlbmRpbmcgb24g dGhlIGtpbmRuZXNzIG9mIHN0cmFuZ2VycyB0byBwcm9kdWNlIHNvbWV0aGluZyB0aGF0IGlzIGJl aW5nIHJlcXVpcmVkIGZvciBubyBvdGhlciByZWFzb24gdGhhbiBzb21lIHBlb3BsZSBub3QgaW52 b2x2ZWQgd2l0aCBCYWJlbCBoYWQgYSBkZXNpcmUgKGFuZCB0aGUgcG93ZXIpIHRvIHJlcXVpcmUg aXQuIA0KKipodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2JhYmVsL2N1cnJl bnQvbXNnMDAzNzguaHRtbA0KDQo+IFNvLCB0aGVyZSBpcyBhDQo+IHJlcXVpcmVtZW50IGZvciBh IFlBTkcgbW9kZWwgaW4gdGhlIEJhYmVsIENoYXJ0ZXIgYnV0LCBhcyBsb25nIGFzIHRoZXJlIGlz DQo+IGNsZWFyIHByb2dyZXNzIHRvd2FyZHMgdGhhdCwgaXQgaXMgbm90IGNsZWFyIHRoYXQgaXRz IGNvbXBsZXRpb24gbmVlZHMgdG8gYmUgYQ0KPiBibG9ja2luZyBjb25zaWRlcmF0aW9uIGZvciBy ZmM2MTI2YmlzLg0KDQpUaGF0J3Mgc29tZXdoYXQgZ29vZCBuZXdzLiBCdXQgdGhlIFdHIHBhcnRp Y2lwYW50cyBhcmUgcG93ZXJsZXNzIHRvIG1ha2UgdGhpcyBoYXBwZW4gLS0gc2hvcnQgb2YgZXhw ZW5kaW5nIG1hc3NpdmUgZWZmb3J0IHRvIGxlYXJuIFlBTkcgYW5kIHByb2R1Y2UgdGhlIERNIG91 cnNlbHZlcyAtLSB3aGljaCBpcyBhbiB1bnJlYWxpc3RpYyBleHBlY3RhdGlvbiBpbiBvcmRlciB0 byBjcmVhdGUgc29tZXRoaW5nIHRoYXQgaXMganVzdCBhIGNoZWNrLXRoZS1ib3ggcmVxdWlyZW1l bnQgd2l0aCBubyB1c2VyIGNvbW11bml0eSBleHByZXNzaW5nIGludGVyZXN0IG9yIGRlbWFuZC4N Cg0KPiA+PiBUaGVyZSBleGlzdHMgYSB1c2VyIGNvbW11bml0eSB3aG8gZG9lcyB3YW50IEJhYmVs LiBUaGVyZSBpcyBhIGhvbWVuZXQNCj4gPj4gKHVubWFuYWdlZCBuZXR3b3JrKSB1c2UgY2FzZSB3 aGljaCBoYXMgcmZjNjEyNmJpcyBhcyBhIGRlcGVuZGVuY3kuDQo+ID4+IFRoZXJlIGlzIGludGVy ZXN0IGZyb20gb3RoZXIgdXNlcnMgd2l0aCBuZXR3b3JrcyB0aGF0IGRvIG5vdCByZXF1aXJlDQo+ ID4+IG1hbmFnZW1lbnQgdGhyb3VnaCBhIG1hbmFnZW1lbnQgcHJvdG9jb2wsIG9yIHdobyBhcmUg dXNpbmcgb3RoZXINCj4gPj4gbm9uLUlFVEYgc29sdXRpb25zLiBUaGVyZSBpcyBzb21lIGludGVy ZXN0IGZyb20gYXQgbGVhc3Qgb25lIGVtcGxveWVlDQo+ID4+IG9mIGFuIElTUCAobWUpIHdobyBo YXMgY29tbWl0dGVkIHRvIGNyZWF0aW5nIHRoZSBpbmZvcm1hdGlvbiBtb2RlbA0KPiA+PiBhbmQg YSBCQkYgVFItMTgxIGRhdGEgbW9kZWwgKGZvciB1c2Ugd2l0aCBCQkYgVFItMDY5IGFuZCBUUi0z NjkpLg0KPiA+PiBMYWNrIG9mIHB1YmxpY2F0aW9uIG9mIHJmYzYxMjZiaXMgaXMgc3RhbmRpbmcg aW4gdGhlIHdheSBvZiB0aGVzZSB1c2UNCj4gPj4gY2FzZXMgYmVpbmcgZnVsbHkgcmVhbGl6ZWQu IFtTaWRlIG5vdGU6IEJlY2F1c2Ugb2YgdGhlc2UgdXNlIGNhc2VzLA0KPiA+PiBuZXRjb25mIGFu ZCBZQU5HIE1VU1QgTk9UIGJlIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQsIGV2ZW4gaWYgdGhlDQo+ IFlBTkcNCj4gPj4gbW9kZWwgaXMgY3JlYXRlZC5dDQo+ID4+DQo+ID4+IEhvd2V2ZXIsIHRoZSBs YWNrIG9mIGEgWUFORyBtb2RlbCBpcyBiZWluZyB1c2VkIGFzIGFuIGV4Y3VzZSB0byBwcmV2ZW50 DQo+IHB1YmxpY2F0aW9uIG9mIHJmYzYxMjZiaXMgLS0gZXZlbiB0aG91Z2ggbm9uZSBvZiB0aGUg dXNlciBjb21tdW5pdGllcw0KPiBhY3RpdmVseSBpbnRlcmVzdGVkIGluIEJhYmVsIGNhcmUgYW55 dGhpbmcgYWJvdXQgWUFORyBvciBuZXRjb25mLiBUaGUgQmFiZWwNCj4gdXNlciBjb21tdW5pdHkg aXMgYmVpbmcgaGVsZCBob3N0YWdlIGJ5IFlBTkcgYWR2b2NhdGVzLg0KPiA+PiBTbyB3ZSdyZSBh dCBhbiBpbXBhc3NlLg0KPiA+Pg0KPiA+PiBJIHNlZSB0aGUgZm9sbG93aW5nIGFzIHBvc3NpYmxl IHdheXMgZm9yd2FyZCwgYW5kIHByb3ZpZGUgYW4gYXNzZXNzbWVudA0KPiBvZiB0aGVpciBmZWFz aWJpbGl0eSBhbmQgb3V0Y29tZXMuDQo+ID4+IDEuIEtpbGwgdGhlIHJmYzYxMjZiaXMgZWZmb3J0 IG5vdy4gVmVyeSBmZWFzaWJsZS4gT3V0Y29tZTogQWxsIHdvcmsgb24gQmFiZWwNCj4gbGVhdmVz IElFVEYgYW5kIGVpdGhlciBkaWVzIG9yIGdvZXMgZWxzZXdoZXJlLg0KPiA+PiAyLiBQdXQgcmZj NjEyNmJpcyBvbiBob2xkIHVudGlsIGEgWUFORyBtb2RlbCBoYXBwZW5zLiBUaGlzIGlzIHRoZSBk ZWZhdWx0DQo+ICJkbyBub3RoaW5nIiBjaG9pY2UuIE9idmlvdXNseSwgdmVyeSBmZWFzaWJsZS4g T3V0Y29tZTogU2luY2UgdGhlIFlBTkcNCj4gbW9kZWwgc2hvd3Mgbm8gc2lnbiBvZiBoYXBwZW5p bmcsIGl0IGlzIGhpZ2hseSBsaWtlbHkgd2Ugd291bGQgbG9zZSB0aGUNCj4gaW50ZXJlc3Qgb2Yg dGhlIGRyYWZ0IGF1dGhvcnMsIGFuZCBpdCB3b3VsZCBiZSBlZmZlY3RpdmVseSB0aGUgc2FtZSBh cyBraWxsaW5nDQo+IHRoZSBkcmFmdC4gSWYgd2UncmUgZ29pbmcgdG8ga2lsbCB0aGUgZHJhZnQs IHRoZW4gSSBwcmVmZXIgdGhlIGRlY2lzaW9uIGJlIGENCj4gY29uc2Npb3VzIG9uZSAoc2VlIG9w dGlvbiAxKS4NCj4gPj4gMy4gT25lIG9mIHRoZSBwZW9wbGUgY3VycmVudGx5IGVuZ2FnZWQgaW4g QmFiZWwgcHV0cyBpbiB0aGUgdGltZSBhbmQNCj4gZWZmb3J0IHRvIGxlYXJuIFlBTkcgYW5kIGNy ZWF0ZSBhIG1vZGVsLiBIaWdobHkgdW5saWtlbHkuIE91dGNvbWU6IEV4dGVuc2l2ZQ0KPiBkZWxh eSAoZHVlIHRvIGxlYXJuaW5nIGN1cnZlIGFuZCBiYWQgYXR0aXR1ZGUpLCB3aGljaCBpcyBsaWtl bHkgdG8gZGV2b2x2ZSBpbnRvDQo+IG9wdGlvbiAyLg0KPiA+PiA0LiBTb21lb25lIHdobyBpcyBj b21wZXRlbnQgaW4gWUFORyB2b2x1bnRlZXJzIHRvIHF1aWNrbHkgY3JlYXRlIHRoZQ0KPiBZQU5H IG1vZGVsLiBGZWFzaWJpbGl0eSBpcyB1bmtub3duLCBidXQgbm8tb25lIGhhcyBzdGVwcGVkIGZv cndhcmQsIHlldC4NCj4gT3V0Y29tZTogSWYgZG9uZSBxdWlja2x5LCBpdCBtaWdodCBiZSBzdWNj ZXNzZnVsOyBvdGhlcndpc2UsIGl0IHdpbGwgZGV2b2x2ZQ0KPiBpbnRvIG9wdGlvbiAyLg0KPiAN Cj4gSSB3aWxsIHNlbmQgYSBtZXNzYWdlIHRvIHRoZSBPcGVyYXRpb25zIEFyZWEgRGlyZWN0b3Jz IGFuZCBEaXJlY3RvcmF0ZQ0KPiBzZWVraW5nIGEgdm9sdW50ZWVyIHRvIHdvcmsgb24gYSBZQU5H IG1vZGVsLiBJIHByb2JhYmx5IHNob3VsZCBoYXZlIGRvbmUNCj4gdGhpcyBlYXJsaWVyLg0KDQpU aGFuayB5b3UuIEkgc2luY2VyZWx5IGhvcGUgeW91IGZpbmQgc29tZW9uZS4gUGxlYXNlIGxldCB0 aGVtIGtub3cgd2UndmUgYWxyZWFkeSBpZGVudGlmaWVkIHRoZSBkYXRhIGVsZW1lbnRzIGFuZCBy ZWFsbHkganVzdCBuZWVkIHNvbWVvbmUgd2hvIGtub3dzIFlBTkcgbW9kZWxpbmcuIElkZW50aWZ5 aW5nIGRhdGEgZWxlbWVudHMgY2FuIGJlIGRpZmZpY3VsdCBmb3Igc29tZW9uZSB3aG8ga25vd3Mg bm90aGluZyBvZiB0aGUgdGhpbmcgYmVpbmcgbW9kZWxlZCAtLSBqdXN0IGxpa2UgY3JlYXRpbmcg YSBZQU5HIG1vZGVsIGlzIGRpZmZpY3VsdCBmb3IgdGhvc2Ugbm90IHZlcnNlZCBpbiBZQU5HLiBU aGVzZSBhcmUgZGlzdGluY3QgY29tcGV0ZW5jaWVzLg0KIA0KPiA+PiA1LiBUaGUgZHJhZnQgaXMg c2VudCBvbiBmb3IgSUVTRyByZXZpZXcgd2l0aG91dCB0aGVyZSBiZWluZyBhIFlBTkcgbW9kZWwu DQo+IFRoaXMgY2FuIGJlIHdpdGgqKiBvciB3aXRob3V0IGEgbWFuYWdlbWVudCBzZWN0aW9uIHRo YXQgZXhwbGFpbnMgdGhlDQo+IGN1cnJlbnQgbGFjayBvZiBhIFlBTkcgbW9kZWwuIEZlYXNpYmxl IChkZXBlbmRzIG9uIGNoYWlyIHdpbGxpbmduZXNzKS4NCj4gT3V0Y29tZTogU3VjY2VzcyBpcyB1 bmNlcnRhaW4gc2luY2Ugd2UndmUgYmVlbiB0b2xkIHRoZXJlIGlzIGEgcG9saWN5IHRoYXQNCj4g c2F5cyByb3V0aW5nIHByb3RvY29scyBtdXN0IGhhdmUgYSBZQU5HIG1vZGVsIGp1c3QgZm9yIHRo ZSBzYWtlIG9mIGhhdmluZyBhDQo+IFlBTkcgbW9kZWw/IE5vdCBzdXJlIHdoYXQgdGhlIHBvbGlj eSByZWFsbHkgaXMsIHNpbmNlIEkgY2FuJ3QgZmluZCB3aGVyZSBpdCdzDQo+IHN0YXRlZC4NCj4g DQo+IFRoZSBDaGFpcnMgY2FuIHJlcXVlc3QgcHVibGljYXRpb24gYmFzZWQgb24gV0cgY29uc2Vu c3VzIGJ1dCBpdCBpcyB0aGVuIHVwDQo+IHRvIG91ciBBcmVhIERpcmVjdG9yIHRvIHJldmlldyB0 aGUgZG9jdW1lbnQgYW5kLCBpZiBoZSBzbyBjaG9vc2VzLCBpbml0aWF0ZQ0KPiB0aGUgSUVURiBM YXN0IENhbGwgYW5kIHB1dCBpdCBvbiB0aGUgSUVTRyBhZ2VuZGEuDQo+IA0KPiA+PiBPcHRpb24g MiBpcyBkZWZhdWx0IChkbyBub3RoaW5nLCBhbmQga2lsbCB0aGUgZHJhZnQgYnkgbGFjayBvZg0K PiA+PiBhY3Rpb24pLiBPcHRpb24gMyBzaG91bGQgYmUgdG9zc2VkIC0tIGl0J3Mgbm90IGdvaW5n IHRvIGhhcHBlbi4gT3B0aW9ucyAxLCA0LA0KPiBvciA1IGFyZSB1cCB0byB0aGUgY2hhaXJzLiBb VGhlIFdHIHBhcnRpY2lwYW50cyBrbm93IG9mIG5vLW9uZSBmb3Igb3B0aW9uIDQuXQ0KPiBEb25h bGQsIFJ1c3MsIC0tIGl0J3MgaW4geW91ciBoYW5kcy4gRG8gd2UgY29uc2Npb3VzbHkga2lsbCBp dCwgZG8geW91IGZpbmQNCj4gc29tZW9uZSBBU0FQIHRvIGRvIHRoZSBZQU5HIG1vZGVsLCBkbyB5 b3UgbW92ZSBpdCBmb3J3YXJkIGFuZCBmaWdodCB0aGUNCj4gZmlnaHQsIG9yIGRvIHdlIGRvIG5v dGhpbmcgYW5kIGFsbG93IGl0IHRvIGRpZT8NCj4gPj4NCj4gPj4gTXkgcHJlZmVyZW5jZSB3b3Vs ZCBiZSB0byBmaWdodCB0aGUgZmlnaHQgLS0gc2VuZCB0aGUgZHJhZnQgdXAgZm9yIHJldmlldy4N Cj4gVGhpcyAidGhlcmUgc2hhbGwgYmUgYSBZQU5HIG1vZGVsIiBwb2xpY3kgKGl0IHdvdWxkIGJl IGdyZWF0IHRvIGdldCBhIHBvaW50ZXINCj4gdG8gdGhpcyBwb2xpY3kgc28gd2UgY2FuIHJlYWQg aXQgYW5kIGRldGVybWluZSB3aG8gYXBwcm92ZWQgdGhpcyBwb2xpY3kgYW5kDQo+IGFueSBvdGhl ciBkZXRhaWxzIG9mIHRoaXMgcG9saWN5KSBpcyBpbmFwcHJvcHJpYXRlIGFuZCB1bnRlbmFibGUg Zm9yIEJhYmVsLg0KPiANCj4gSSBkaWQgYXNrIG91ciBBRCBhbmQgaGUgaW5kaWNhdGVkIHRoYXQg aGUgd291bGQgYmUgZXh0cmVtZWx5IHJlbHVjdGFudCB0bw0KPiBmb3J3YXJkIHRoZSBkcmFmdCB0 byB0aGUgSUVTRywgZHVlIHRvIHRoZSByZXF1aXJlbWVudCBpbiB0aGUgQmFiZWwgQ2hhcnRlcg0K PiBmb3IgYSBZQU5HIG1vZGVsLCB1bmxlc3Mgc3VjaCBhIG1vZGVsIGhhZCBiZWVuIGF0IGxlYXN0 IHN0YXJ0ZWQuDQo+IA0KPiA+IEkgYWdyZWUgd2l0aCB5b3VyIGFzc2Vzc21lbnQsIGFuZCB3b3Vs ZCBwcmVmZXIgb3B0aW9uIDQgKGlmIGZlYXNpYmxlKQ0KPiA+IG9yIDUuIEkgdGhpbmsgaXQgd291 bGQgYmUgYSBzaGFtZSBpZiB0aGUgSUVURiBidXJlYXVjcmFjeSBlbmRzIHVwDQo+ID4gY2hva2lu ZyBCYWJlbCA6Lw0KDQpUaGFua3MgRG9uYWxkLiBJIGhvcGUgc28sIHRvby4NCiANCj4gVGhhbmtz LA0KPiBEb25hbGQNCj4gDQo+IFBTOiBUaGUgQmFiZWwgQ2hhcnRlciBpcyBoZXJlDQo+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvYmFiZWwvYWJvdXQNCj4gPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KPiAgRG9uYWxkIEUuIEVhc3RsYWtlIDNyZCAgICsxLTUwOC0zMzMt MjI3MCAoY2VsbCkNCj4gIDE1NSBCZWF2ZXIgU3RyZWV0LCBNaWxmb3JkLCBNQSAwMTc1NyBVU0Eg IGQzZTNlM0BnbWFpbC5jb20NCg== From nobody Wed Jun 13 02:15:56 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6578E131072 for ; Wed, 13 Jun 2018 02:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=kapsi.fi 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 goj9AzAxp7rf for ; Wed, 13 Jun 2018 02:15:42 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (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 57B76131070 for ; Wed, 13 Jun 2018 02:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=BKr48mIbHTO0OGV2zC+NUzFfMZOUHbFwEb8mE16WFms=; b=n2+2yiZlGsl6wonwXM1chkhesHWFrBclrfLgQ8STQivT/S+JnuvFJkGo8ymtdruE7HkGH/RG0qG6PcaZddsrpAT2y908G4MHQhXHS+sdr/qxEn5ppnvibSMj+OQ8p94amlmlX58lfpCPXIq3HCbwIWXozHIDU4/CP1BMkFknuk1vMkY2jj0myFC3rqaPA7SgNn3Gexpz78JuIYfu0kfYQhe9NAxVh1WMjemkk+7LeerP9Bk+ZZdw47S5ebCNOybhqlx83Mftc3WNnf3MdshNnLT4gcBmN++n6pNK8qTFxFWF+k/zAg5QKyc7GDM3MiDnTG/SplTxl3cZAwxBefa7pg==; Received: from [194.100.69.221] (helo=[172.20.21.43]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fT1sN-0006pg-IH; Wed, 13 Jun 2018 12:15:35 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Markus Stenberg In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DDEA127@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Wed, 13 Jun 2018 12:15:34 +0300 Cc: Donald Eastlake , =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , "babel@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9DDBA806-FD26-4FB7-BCA8-0AF5F0507C81@iki.fi> References: <2D09D61DDFA73D4C884805CC7865E6114DDE71DC@GAALPA1MSGUSRBF.ITServices.sbc.com> <87d0wwjmuy.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DDEA127@GAALPA1MSGUSRBF.ITServices.sbc.com> To: BARBARA H STARK X-Mailer: Apple Mail (2.3445.8.2) X-SA-Exim-Connect-IP: 194.100.69.221 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] Babel YANG deliverable X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 09:15:53 -0000 On 13 Jun 2018, at 12.03, STARK, BARBARA H wrote: >> So, there is a >> requirement for a YANG model in the Babel Charter but, as long as = there is >> clear progress towards that, it is not clear that its completion = needs to be a >> blocking consideration for rfc6126bis. > That's somewhat good news. But the WG participants are powerless to = make this happen =E2=80=94 short of expending massive effort to learn = YANG and produce the DM ourselves -- which is an unrealistic expectation = in order to create something that is just a check-the-box requirement = with no user community expressing interest or demand. I would like to get rid of the charter item. That said, if we cannot get rid of it it, I can write (lousy first = draft) YANG model if it really helps once the management model doc is = considered ready. I have done some MIBs and PIBs in the past so writing = YANG model sounds like novel challenge, although not super interesting = one (nor relevant in the Babel context) so I would prefer not to. Cheers, -Markus From nobody Thu Jun 14 14:25:36 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB97F130E3B for ; Thu, 14 Jun 2018 14:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 vrZFKNYv-KYh for ; Thu, 14 Jun 2018 14:25:32 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033E912D949 for ; Thu, 14 Jun 2018 14:25:32 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id t6-v6so8693087iob.10 for ; Thu, 14 Jun 2018 14:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=plTV1lQAO/C392m4pT8woWs3JL8YFM5bg30F/Wy/Zik=; b=tFjCiMC3xghrJ/nRxr7zB8TPcL9gnw4zs8euTsGauEwfalTpofxHxOs7Hk/eF3rJz7 NvURPI+lRaIzCvwx6FYPwXoXuKJGbb5g7fiCRFCmUr+gSIatuNxxUajvjclRlqtBsouv LcZEEJCqbn5xK7N8XRyN2CpwTnOLy/RpgducSgzZT6g8QwyoRFiRv+DrkZoc86Zp+R4T IxwglRBl3eRkYKFbRZx0fEQna1G0RPrQoRy+4uiYa36ZKc69NJCmXHWic0pXo39nGEt0 vP9XnUj+Y5l54+bhd2z39/ga/zedivR3rADDAhBXqpQIjCewCf+EzHzgc55TA2AFsYxp YqXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=plTV1lQAO/C392m4pT8woWs3JL8YFM5bg30F/Wy/Zik=; b=EFltEJczfTOR+6tyAqiynihfmH14nJiM8JplEnrg4fO6BsIZTXLYZHP2TJnTJKDnwh hO+jAdAVbODSAw0yO1n5dXMTg5/5lhGQxmzRAmpJAiza3Tcbijv4wq4b0eXA/Uo3sGwl TGgHnLXj61SDDBWrQBESaN4SMY4vP+KwKho8d+ZFQelHZ3e5mjy8nff6MZGAf6pFbNqK GzGTmIPOXHhHJCHTKK9ky6F66hqC8477+tc2cOgrqrySjl+Lx9DaoVS0ZX6xSzuawVza DZBAuWZpYB0wGsfRwsZwYgWs6J7cA3LMJbo37nRZLMWSRe8oSvop+oXN/1VHDiHW90EN KcWQ== X-Gm-Message-State: APt69E3AgaSHPL8VpxU0g+TNeUZqfE55+GzzLbWvgqYcPCXTlM1ZOC7O BRGnaZddZNGUS8P0RPsVKaHu9IUkfRCdidSl0KQ= X-Google-Smtp-Source: ADUXVKK/7msyk2TWGVcsD+lAxZEfIV+c3/VIxGOfBegZ7uvzzOH4LHnOzM9/a72garNoOiyLVKF/nxQdxpkEAVJXbqs= X-Received: by 2002:a6b:c6c9:: with SMTP id w192-v6mr3824576iof.131.1529011531303; Thu, 14 Jun 2018 14:25:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bf84:0:0:0:0:0 with HTTP; Thu, 14 Jun 2018 14:25:15 -0700 (PDT) In-Reply-To: <9DDBA806-FD26-4FB7-BCA8-0AF5F0507C81@iki.fi> References: <2D09D61DDFA73D4C884805CC7865E6114DDE71DC@GAALPA1MSGUSRBF.ITServices.sbc.com> <87d0wwjmuy.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DDEA127@GAALPA1MSGUSRBF.ITServices.sbc.com> <9DDBA806-FD26-4FB7-BCA8-0AF5F0507C81@iki.fi> From: Donald Eastlake Date: Thu, 14 Jun 2018 17:25:15 -0400 Message-ID: To: Markus Stenberg Cc: BARBARA H STARK , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , "babel@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Babel YANG deliverable X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 21:25:34 -0000 Hi Markus, On Wed, Jun 13, 2018 at 5:15 AM, Markus Stenberg w= rote: > On 13 Jun 2018, at 12.03, STARK, BARBARA H wrote: >>> So, there is a >>> requirement for a YANG model in the Babel Charter but, as long as there= is >>> clear progress towards that, it is not clear that its completion needs = to be a >>> blocking consideration for rfc6126bis. >> That's somewhat good news. But the WG participants are powerless to make= this happen =E2=80=94 short of expending massive effort to learn YANG and = produce the DM ourselves -- which is an unrealistic expectation in order to= create something that is just a check-the-box requirement with no user com= munity expressing interest or demand. > > I would like to get rid of the charter item. Charters can certainly be changed but it requires approval of the IESG. > That said, if we cannot get rid of it it, I can write (lousy first draft)= YANG model if it really helps once the management model doc is considered = ready. I have done some MIBs and PIBs in the past so writing YANG model sou= nds like novel challenge, although not super interesting one (nor relevant = in the Babel context) so I would prefer not to. Thanks for the offer. That may turn out to be very useful. Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Cheers, > > -Markus > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Fri Jun 15 14:15:41 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612DC130E64 for ; Fri, 15 Jun 2018 14:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylBIsJs-p6dP for ; Fri, 15 Jun 2018 14:15:37 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 68535126CB6 for ; Fri, 15 Jun 2018 14:15:37 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id a195-v6so4559712itd.3 for ; Fri, 15 Jun 2018 14:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=VXdYkKDEauTbN0DlKab01KU0BrA93wG4J0Zh8ZHK2yE=; b=Jo17v1pKIFjQVRejG6zKMQTu1C9QrHUEz48yTmfI1lOrBanyywPDxROlZ5GF0cugkz tARpGwv4T8FQT25OrCJpak9kXvSiUYEReRuT65QQSlzQ/Oi/Jg4CdsGA0mxbJGtjaOm+ gVV5H/f+gm9kFdGpGzLzQVwf0bSq/2ciLlBIDT9JuYP2IY9TI3/PZYngsR1Uk7xhKePZ 6jqg/q+dq5R2M1x6nJVhdCpd2UV1PM5CdbqjeAdBwWJd06zppkaLXrFDkJNc7c7E5/O+ +ZBLNTZ3959TiC8sQwc0TGReRtiAQzm+UhdgDbNWecrmC1rt0IDu7qquh+K04b85XBUC 1tXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=VXdYkKDEauTbN0DlKab01KU0BrA93wG4J0Zh8ZHK2yE=; b=IG1zTqq4qJ86tUT0VB/Hp9f7nHDdYK6nnF66hP+JqrRjqwtyajOyOVxSvUpgPjBS55 UX7siDT4VFLJcAgRopcCPtlElvMlgEtf8Z8J12vledL0CWkroafFHwulXCgM8Iwv//GJ W6YTyvJAnh4Zn7TGIJto4RLfFUP/z5v2PCidGRZLZVMGHznyz+FKUH5JgfMADZWt8nvR rhXQ9qX/CIDyw65Xvi3qEviXi5O+06PRCY0h/Uxg0qH19yBdSV2dhsSPFxJ5BF+uVO7r Fk7lkN+dhh1wAUEebt4grM7LLpDwQkXhTjRLGE0JxYdKy6aWBIpmwQIl4X1K7ToW+bG7 MIUw== X-Gm-Message-State: APt69E3JCZHLLs2OGHhQi544k2aikFnlew3Y4YoAnEHknxeSsmV3DRGM GkOODhJoQ4/kGP1FanV251JzD2ValMEhAxINAm4= X-Google-Smtp-Source: ADUXVKIIZJj12Ey+mKyL3M2maj6u2RuPB55xVTjqLq+6loyCxVeXBvU5U69/V0uq0pG5EUZrD7R1gtzXSC7iqtGLJQs= X-Received: by 2002:a24:284a:: with SMTP id h71-v6mr2643517ith.105.1529097336517; Fri, 15 Jun 2018 14:15:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bf84:0:0:0:0:0 with HTTP; Fri, 15 Jun 2018 14:15:21 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DDEA127@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DDE71DC@GAALPA1MSGUSRBF.ITServices.sbc.com> <87d0wwjmuy.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DDEA127@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Donald Eastlake Date: Fri, 15 Jun 2018 17:15:21 -0400 Message-ID: To: "STARK, BARBARA H" Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , "babel@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Babel YANG deliverable X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 21:15:40 -0000 Hi Barbara, On Wed, Jun 13, 2018 at 5:03 AM, STARK, BARBARA H wrote: > Hi Donald, > Response inline. > Barbara > ------------------- >> >> I think we need to have a list discussion about this Babel YANG >> deliverable. >> >> It is clear that none of the people directly engaged in this WG have = the >> expertise or competency to create a Babel YANG model. We also have no >> desire or intent to acquire this expertise. The learning curve is steep = and >> time-consuming. >> >> The requirement to create a Babel YANG model is purely about creating >> the model for the sake of having the model. There exists no user communi= ty >> demand for this model, at this time. >> >> I do not view the requirement in the Babel Charter for a YANG model the >> same way you do. >> Although no analogy is exact, let me give a quick analogy to securi= ty. Time >> and again, protocols have come to the IETF with advocates who insist the >> security isn't needed, that the protocol will only be used in limited >> environments, that the protocol will never be used across the general >> Internet, that there is no community demand for the protocol to be >> securable, etc. And those advocate have almost always been proven wrong = - >> - in many cases resulting in painful and sometimes not entirely successf= ul >> attempts to retrofit security. So, there is an actual general IETF proce= ss >> requirement for Security Considerations sections in standards track >> documents. >> An analogy to management is not exact, management is easier to retr= ofit, >> Operational Considerations is not a general IETF process required sectio= n in >> standard track documents, etc. Nevertheless, I think that management >> oriented people would view with suspicion the claim that Babel will neve= r >> need to be manageable, that there will never be a case where a >> management station that is, say, monitoring information inside a variety= of >> protocols on a network would also like to monitor Babel. > > Just to be clear, I never suggested that Babel will never need to be mana= geable. I'm putting real effort into babel-information-model because I do s= ee the need for manageability in some usages. The points I've made are: My apologies if, in attempting to simplify my argument, I implies you were saying the Babel will never need management. > - there must be no mandatory-to-implement management protocol so lightwe= ight implementations can exist for unmanaged environments (and, also, manag= ement interfaces are a major source of security vulnerabilities; management= interfaces that aren't present have no vulnerabilities and can't be used t= o compromise a device) > - babel-information-model is progressing > - I'll be creating a TR-181 data model, so Babel can be managed through = TR-069/TR-369; this is the management protocol I'm interested in using beca= use my employer currently uses it to managed millions of Wi-Fi CE routers a= nd has no plans of moving to netconf or restconf for CE router management That is all good. > - I have no intention of learning YANG, and no other regular WG particip= ant appears interested in learning YANG either; YANG isn't easy -- it takes= time to learn and more time to learn well; so the authors of all the babel= WG drafts are not in a position to promise a YANG model > - as an additional note (responding to your sentence about monitoring), = I think NetJSON (netjson.org) would be a much better approach for the type = of monitoring you describe; it would be pretty easy to create a NetJSON ext= ension for Babel (given the information model) > > The language requiring a YANG model was placed in the charter because Ben= oit insisted on it and said Babel will not be made into an IETF Proposed St= andard without a YANG model**. It was not something the WG wanted, but is s= omething that was forced on us. Apparently this requirement will render mea= ningless all the work done on Babel unless someone can be found to do a YAN= G model. Years of work and effort is depending on the kindness of strangers= to produce something that is being required for no other reason than some = people not involved with Babel had a desire (and the power) to require it. > **https://www.ietf.org/mail-archive/web/babel/current/msg00378.html Well, we will see what happen on the Charter requirements front. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >> So, there is a >> requirement for a YANG model in the Babel Charter but, as long as there = is >> clear progress towards that, it is not clear that its completion needs t= o be a >> blocking consideration for rfc6126bis. > > That's somewhat good news. But the WG participants are powerless to make = this happen -- short of expending massive effort to learn YANG and produce = the DM ourselves -- which is an unrealistic expectation in order to create = something that is just a check-the-box requirement with no user community e= xpressing interest or demand. > >> >> There exists a user community who does want Babel. There is a homenet >> >> (unmanaged network) use case which has rfc6126bis as a dependency. >> >> There is interest from other users with networks that do not require >> >> management through a management protocol, or who are using other >> >> non-IETF solutions. There is some interest from at least one employee >> >> of an ISP (me) who has committed to creating the information model >> >> and a BBF TR-181 data model (for use with BBF TR-069 and TR-369). >> >> Lack of publication of rfc6126bis is standing in the way of these use >> >> cases being fully realized. [Side note: Because of these use cases, >> >> netconf and YANG MUST NOT be mandatory to implement, even if the >> YANG >> >> model is created.] >> >> >> >> However, the lack of a YANG model is being used as an excuse to preve= nt >> publication of rfc6126bis -- even though none of the user communities >> actively interested in Babel care anything about YANG or netconf. The Ba= bel >> user community is being held hostage by YANG advocates. >> >> So we're at an impasse. >> >> >> >> I see the following as possible ways forward, and provide an assessme= nt >> of their feasibility and outcomes. >> >> 1. Kill the rfc6126bis effort now. Very feasible. Outcome: All work o= n Babel >> leaves IETF and either dies or goes elsewhere. >> >> 2. Put rfc6126bis on hold until a YANG model happens. This is the def= ault >> "do nothing" choice. Obviously, very feasible. Outcome: Since the YANG >> model shows no sign of happening, it is highly likely we would lose the >> interest of the draft authors, and it would be effectively the same as k= illing >> the draft. If we're going to kill the draft, then I prefer the decision = be a >> conscious one (see option 1). >> >> 3. One of the people currently engaged in Babel puts in the time and >> effort to learn YANG and create a model. Highly unlikely. Outcome: Exten= sive >> delay (due to learning curve and bad attitude), which is likely to devol= ve into >> option 2. >> >> 4. Someone who is competent in YANG volunteers to quickly create the >> YANG model. Feasibility is unknown, but no-one has stepped forward, yet. >> Outcome: If done quickly, it might be successful; otherwise, it will dev= olve >> into option 2. >> >> I will send a message to the Operations Area Directors and Directorate >> seeking a volunteer to work on a YANG model. I probably should have done >> this earlier. > > Thank you. I sincerely hope you find someone. Please let them know we've = already identified the data elements and really just need someone who knows= YANG modeling. Identifying data elements can be difficult for someone who = knows nothing of the thing being modeled -- just like creating a YANG model= is difficult for those not versed in YANG. These are distinct competencies= . > >> >> 5. The draft is sent on for IESG review without there being a YANG mo= del. >> This can be with** or without a management section that explains the >> current lack of a YANG model. Feasible (depends on chair willingness). >> Outcome: Success is uncertain since we've been told there is a policy th= at >> says routing protocols must have a YANG model just for the sake of havin= g a >> YANG model? Not sure what the policy really is, since I can't find where= it's >> stated. >> >> The Chairs can request publication based on WG consensus but it is then = up >> to our Area Director to review the document and, if he so chooses, initi= ate >> the IETF Last Call and put it on the IESG agenda. >> >> >> Option 2 is default (do nothing, and kill the draft by lack of >> >> action). Option 3 should be tossed -- it's not going to happen. Optio= ns 1, 4, >> or 5 are up to the chairs. [The WG participants know of no-one for optio= n 4.] >> Donald, Russ, -- it's in your hands. Do we consciously kill it, do you f= ind >> someone ASAP to do the YANG model, do you move it forward and fight the >> fight, or do we do nothing and allow it to die? >> >> >> >> My preference would be to fight the fight -- send the draft up for re= view. >> This "there shall be a YANG model" policy (it would be great to get a po= inter >> to this policy so we can read it and determine who approved this policy = and >> any other details of this policy) is inappropriate and untenable for Bab= el. >> >> I did ask our AD and he indicated that he would be extremely reluctant t= o >> forward the draft to the IESG, due to the requirement in the Babel Chart= er >> for a YANG model, unless such a model had been at least started. >> >> > I agree with your assessment, and would prefer option 4 (if feasible) >> > or 5. I think it would be a shame if the IETF bureaucracy ends up >> > choking Babel :/ > > Thanks Donald. I hope so, too. > >> Thanks, >> Donald >> >> PS: The Babel Charter is here >> https://datatracker.ietf.org/wg/babel/about >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Sat Jun 16 11:51:32 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2690C130E42 for ; Sat, 16 Jun 2018 11:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info 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 g-r5D_ehzvie for ; Sat, 16 Jun 2018 11:51:28 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB26B124D68 for ; Sat, 16 Jun 2018 11:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1529175082; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=7404; bh=chZEWKRzPgfKo14RDom3pHIWs09E1Pl+/JCZN+Gz7g8=; b=C9U4fDrpx55P4g76CF+LKApqX3kQEpB+Yx2dTqw3UHREuuoPiukTcLr2OGdPSjGq ajCB7U5fhDIx7QIAvsZWQF4j4z0tMNvnNfd48/WdCG6OIiRuwXjL8pei3szSyXZ5f0R Mef05PoAXxus7kvKb49fvp9XadU8pi2kyU7QmdBU= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1529175082519278.4310734284901; Sat, 16 Jun 2018 11:51:22 -0700 (PDT) Date: Sat, 16 Jun 2018 19:51:22 +0100 From: Denis Ovsienko To: "babel@ietf.org" Message-ID: <16409f00615.f82ea2ab297633.5710771128171724883@ovsienko.info> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DDE71DC@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DDE71DC@GAALPA1MSGUSRBF.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] Babel YANG deliverable X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2018 18:51:30 -0000 Thank you for raising this point Barbara. This matter is very important for this working group, I have been thinking along those lines for a while and would like to add something in addition to what has already been discussed on this thread so far. It seems to me, it concerns all other WG members too. ---- On Tue, 12 Jun 2018 08:39:46 +0100 STARK, BARBARA H wrote ---- > I think we need to have a list discussion about this Babel YANG deliverable. > It is clear that none of the people directly engaged in this WG have the expertise or competency to create a Babel YANG model. We also have no desire or intent to acquire this expertise. The learning curve is steep and time-consuming. > The requirement to create a Babel YANG model is purely about creating the model for the sake of having the model. There exists no user community demand for this model, at this time. > There exists a user community who does want Babel. There is a homenet (unmanaged network) use case which has rfc6126bis as a dependency. There is interest from other users with networks that do not require management through a management protocol, or who are using other non-IETF solutions. There is some interest from at least one employee of an ISP (me) who has committed to creating the information model and a BBF TR-181 data model (for use with BBF TR-069 and TR-369). Lack of publication of rfc6126bis is standing in the way of these use cases being fully realized. [Side note: Because of these use cases, netconf and YANG MUST NOT be mandatory to implement, even if the YANG model is created.] > > However, the lack of a YANG model is being used as an excuse to prevent publication of rfc6126bis -- even though none of the user communities actively interested in Babel care anything about YANG or netconf. The Babel user community is being held hostage by YANG advocates. > So we're at an impasse. I agree there is a problem, but to make my point clear let me state it in a different way. Today is June 2018 and the milestones for the WG are the same as at the WG formation in June 2016: Aug 2017 IESG Submission of Babel Applicability draft (Informational) Jul 2017 IESG Submission of Babel Management draft (Proposed Standard) Jul 2017 IESG Submission of RFC6126bis and potentially companion security mechanisms draft (Proposed Standard) Oct 2016 WG adoption of Babel Management (Info Model & YANG Model) draft Jul 2016 WG adoption of RFC6126bis Jul 2016 WG adoption of Babel Applicability draft draft-chroboczek-babel-applicability YANG has been both in the charter (no YANG == no Proposed Standard) and in the milestones from the very beginning. Same as security. Same as Standards Track quality level 6126bis. All of which are at various stages of incompleteness (to be clear, 6126bis still has some of the issues I had raised in December 2016). To make it here we (the working group) had accepted the charter and the milestones, then spent the whole time initially allocated for the work, missed all of the 2017 milestones and took one more year of overtime to prove we are not delivering anytime soon. Hence the current situation is not an accident, we have thoroughly painted ourselves into a corner and it would be wrong to put the blame elsewhere (YANG costs and demand for it, bureaucracy, evil managers etc). This is how I see the real problem, YANG is just its proper detail. > I see the following as possible ways forward, and provide an assessment of their feasibility and outcomes. > 1. Kill the rfc6126bis effort now. Very feasible. Outcome: All work on Babel leaves IETF and either dies or goes elsewhere. > 2. Put rfc6126bis on hold until a YANG model happens. This is the default "do nothing" choice. Obviously, very feasible. Outcome: Since the YANG model shows no sign of happening, it is highly likely we would lose the interest of the draft authors, and it would be effectively the same as killing the draft. If we're going to kill the draft, then I prefer the decision be a conscious one (see option 1). > 3. One of the people currently engaged in Babel puts in the time and effort to learn YANG and create a model. Highly unlikely. Outcome: Extensive delay (due to learning curve and bad attitude), which is likely to devolve into option 2. > 4. Someone who is competent in YANG volunteers to quickly create the YANG model. Feasibility is unknown, but no-one has stepped forward, yet. Outcome: If done quickly, it might be successful; otherwise, it will devolve into option 2. > 5. The draft is sent on for IESG review without there being a YANG model. This can be with** or without a management section that explains the current lack of a YANG model. Feasible (depends on chair willingness). Outcome: Success is uncertain since we've been told there is a policy that says routing protocols must have a YANG model just for the sake of having a YANG model? Not sure what the policy really is, since I can't find where it's stated. > > Option 2 is default (do nothing, and kill the draft by lack of action). Option 3 should be tossed -- it's not going to happen. Options 1, 4, or 5 are up to the chairs. [The WG participants know of no-one for option 4.] > Donald, Russ, -- it's in your hands. Do we consciously kill it, do you find someone ASAP to do the YANG model, do you move it forward and fight the fight, or do we do nothing and allow it to die? > > My preference would be to fight the fight -- send the draft up for review. This "there shall be a YANG model" policy (it would be great to get a pointer to this policy so we can read it and determine who approved this policy and any other details of this policy) is inappropriate and untenable for Babel. > Spelling those options is a good step towards a resolution -- among other things it reminds people the project default is a failure, not a success. Let's try to look one more step ahead. Even if we make it around the YANG requirement for now, how are we going to make it around the security requirement? Just rush the documents no matter what? It would smell and shooting it down would be right. We need to clarify the details of where we are, and then we need to make the right decision (to avoid riding a dead horse or discarding good work). Let me build on top of your plan and propose the following, which also covers the YANG aspect: Step 1. Study the charter and write down all meaningful work items. Step 2. Place a call in the working group asking people to confirm their presence, availability and which work items they are willing to work on and how exactly (discuss, write, proof-read, find issues, fix issues, implement) and how many working hours per week they can contribute. Step 3. If the working group fails to confirm its existence, conclude it without deliverables. Step 4. If the working group exists but does not have the resource to implement the charter in the first place, conclude it without deliverables. Step 5. Confirm new realistic dates for the milestones with the people that are willing to work on respective items. Step 6. Admit the current default to IESG and ask to extend the credit line by adjusting the milestones. If declined, conclude w/o deliverables. Step 7. (if all good so far) Resume the work as planned and demand status updates every week. Does it look any better? -- Denis Ovsienko From nobody Sun Jun 17 07:56:58 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893A9130E18; Sun, 17 Jun 2018 07:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id progubgiFYqX; Sun, 17 Jun 2018 07:56:55 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DCD5130E15; Sun, 17 Jun 2018 07:56:55 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id u4-v6so8709333itg.0; Sun, 17 Jun 2018 07:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=wuNuG0+KoxfjMaPqn0MMKOXIh0s4yFgZw6Kl6l7hnjI=; b=oqUD74EveJRt/xwwdsSCYREw0d6GJoquGGFv12eentkgK//U/LLG1GpFaZ4KBZh0E0 GIEDjp3oPF76Uma060WbWIwBxsRaaH39hUwAYDB9zeSyQVgfsXD3BMZwXA91kRnW7lhM 0ITZCCRJTLPED4NQ60Iw/jvJAOC7FBpj03AuU1Z2f7gKTTLBeyTjN+toN50b83wai2Hq UhhckHv8v8RWIhwAVIp92oyaL4OMeP/tO48eG+Q7pzx8ERDH4TLoGtKFcQiwX+QND+Q1 wQ8puxOQnaNg9G2682Id9N2XtLUFDFoBGLY6Pv7tJzrSjIx58Y1xChjx23YVicPyxlWh GE4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=wuNuG0+KoxfjMaPqn0MMKOXIh0s4yFgZw6Kl6l7hnjI=; b=AT/lDRPBi30T1pj4QDMEZYoxUAhGJtvcjXqRSzFJrOsejgworTR/tW8fcansnkozAO xG3oYtX02u0WrH9p4uB8XGC0+et6HmDU1ZDBzNeQKUgKg6RlozYTjIj/+16UfYNMJtdi Q+McA0NXRo/XLsIqyYjYYaA+2pCUZS39Rjh7OHh+qNZWZ8Wn98c7ZhS2UOu9UgGInQPA RcPS15GiAPIWwWs9oVdCjzb98TvzUrwA8EP+AGMbsLCAQ9wykKEvDfEtXJ9ax/Z2wYwn 1kh2YnLhRda+d8a5fSoKuFlqi49nuFlYmSr3lMX7f2zSOrJSi2r+SYu3kIXWMYX2ZhMJ zUbg== X-Gm-Message-State: APt69E01vuMImqnfYchUg+hmTCdVubMW3JDMQ6oLUC/xVnKw+PsDbZHp 2OjhmHY9ZHz6CwO/Ij6KGJacyME0S0c+cgwT2Uw6WQ== X-Google-Smtp-Source: ADUXVKJUlHc3h+7+j3UfYr9SArFQheDA6DgRlgH8Ba8gm1cbOjkoNCLUgo3B9VG90EWcLz434Dr5xbw5ctgH3at2rko= X-Received: by 2002:a24:49c2:: with SMTP id e63-v6mr6729112itd.59.1529247414582; Sun, 17 Jun 2018 07:56:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bf84:0:0:0:0:0 with HTTP; Sun, 17 Jun 2018 07:56:39 -0700 (PDT) From: Donald Eastlake Date: Sun, 17 Jun 2018 10:56:39 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 14:56:57 -0000 Hi, Based on the recent discussion on the mailing list, we are asking for comments in favor or opposed to the following change in the Babel WG Charter to remove the specification of a YANG model as a gating factor in moving the Babel protocol to standards track. You can also suggest further changes but to maximize the chances of getting a change approved it might be best to minimize the changes. OLD: - Address manageability of Babel by producing a Babel informational model to help provide guidance and derive the data models. To be consistent with the ongoing effort to use YANG data modules in the Routing Area, a Babel YANG data model to support management of home gateway routers is required as part of moving Babel to Proposed Standard. This information model is useful as a common source of information for the case where the Customer-Premise Equipment (CPE) is managed by the Service Provider (SP) with the Broadband Forum TR-069 protocol and its associated data model. NEW: - Address manageability of Babel by producing a Babel informational model to help provide guidance and derive the data models. This information model is useful as a common source of information for the case where the Customer-Premise Equipment (CPE) is managed by the Service Provider (SP) with the Broadband Forum TR-069 protocol and its associated data model. To be consistent with the ongoing effort to use YANG data modules in the Routing Area, a Babel YANG data model should be specified to support management of Babel routers. The full current Babel WG Charter is at https://datatracker.ietf.org/doc/charter-ietf-babel/ Thanks, Donald and Russ From nobody Sun Jun 17 08:09:06 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3966130E15; Sun, 17 Jun 2018 08:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 8zwW8cili-F0; Sun, 17 Jun 2018 08:09:02 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93288130E0D; Sun, 17 Jun 2018 08:09:02 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1529248140; bh=M6RN7cnEkdFfdruFWJ5KX/5ND8lF98YY94o27a/lftg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=XjdBDMRMmd8MQDkSG4K4PY01xzfqTFlVwzhraNt7k2HQiYQatwRehYfYurFuqU57m hlXYpQipa6Lk5IMlV+1XF5hnOK+NOtlGmjBzn0/8Jwky2GnGyWzNCRFR5wMqZoVg4T G6Yt72c4yKMZJpcwLuPOIzmOoKgG04ul+nw9og7DtL/uTO4+7uf/zTyeG6Iv3OA3IL dz+O5olpysCaeoYRaa6K+5TyJpQFg6DNSDEpefyRocQDHurGr7y+C8wPZIFrNMdS4m q/uQB9nxCjNE5b4RXdz3DMkxDEg6gRx+LxXyhdiRxXLMo0vKBwQykq3uHM4CpjtpPu xBb4Qn4HBbf0g== To: Donald Eastlake , Babel at IETF Cc: babel-chairs@ietf.org In-Reply-To: References: Date: Sun, 17 Jun 2018 17:09:00 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87h8m1v4ab.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 15:09:06 -0000 Donald Eastlake writes: > Hi, > > Based on the recent discussion on the mailing list, we are asking for > comments in favor or opposed to the following change in the Babel WG > Charter to remove the specification of a YANG model as a gating factor > in moving the Babel protocol to standards track. I'm in favour of adopting this change. -Toke From nobody Sun Jun 17 12:21:12 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31372130E37; Sun, 17 Jun 2018 12:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info 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 Fd2jj_iiNpYD; Sun, 17 Jun 2018 12:21:08 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78103127148; Sun, 17 Jun 2018 12:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1529263265; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=2930; bh=xMGblmtu+eQvCNbFGgDYw6a6vL+/HZSENMjjvvMR0ec=; b=HtHewgEH3zMYwUosa4VxnSnEP0YTrYxGxN6GT/5KEifYN/WgYTBvXergMqh0iaoc aqxiyZpGoTmfEIkSVbIlVJjo0UWa889/ElHEZlTar0SwJNrQXOKpv+Hwpa6Y5NV+vYE 4GX2eQVHbntDsmxx4WM9uU5qe4GPWLANv9UTqb6c= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1529263265344732.5319574343349; Sun, 17 Jun 2018 12:21:05 -0700 (PDT) Date: Sun, 17 Jun 2018 20:21:05 +0100 From: Denis Ovsienko To: "Babel at IETF" , Message-ID: <1640f31963d.e3da2ad4319526.4149190004246054001@ovsienko.info> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 19:21:11 -0000 ---- On Sun, 17 Jun 2018 15:56:39 +0100 Donald Eastlake wrote ---- > Hi, > > Based on the recent discussion on the mailing list, we are asking for > comments in favor or opposed to the following change in the Babel WG > Charter to remove the specification of a YANG model as a gating factor > in moving the Babel protocol to standards track. You can also suggest > further changes but to maximize the chances of getting a change > approved it might be best to minimize the changes. > > OLD: > - Address manageability of Babel by producing a Babel informational > model to help provide guidance and derive the data models. To be > consistent with the ongoing effort to use YANG data modules in the > Routing Area, a Babel YANG data model to support management of home > gateway routers is required as part of moving Babel to Proposed > Standard. This information model is useful as a common source of > information for the case where the Customer-Premise Equipment (CPE) is > managed by the Service Provider (SP) with the Broadband Forum TR-069 > protocol and its associated data model. > > NEW: > - Address manageability of Babel by producing a Babel informational > model to help provide guidance and derive the data models. This > information model is useful as a common source of information for the > case where the Customer-Premise Equipment (CPE) is managed by the > Service Provider (SP) with the Broadband Forum TR-069 protocol and its > associated data model. To be consistent with the ongoing effort to use > YANG data modules in the Routing Area, a Babel YANG data model should > be specified to support management of Babel routers. > > The full current Babel WG Charter is at > https://datatracker.ietf.org/doc/charter-ietf-babel/ Hello all. I oppose the proposed change for the following reasons. First, the fault is not in the charter. As my previous message to the list discusses, it looks like we (the working group as a whole) have neglected some meaningful parts of our charter: "Particular emphasis will be placed on work needed for a Proposed Standard routing protocol, such as ensuring manageability and strong security." We have achieved exactly the opposite so far, and it would be fair to fix first what is actually broken (specific suggestions are in that message). Second, de-rating of the requirements level should mean de-rating of the publication category. If the working group explicitly finds itself unable to produce a quality YANG deliverable in time, it could _potentially_ (if the charter allowed it) capture its core (6126bis + whatever security) deliverables as IETF Experimental publications, take a break and retain the motivation to have YANG eventually done and aim for Proposed Standard. But neither the current charter nor the proposed change take this into account. -- Denis Ovsienko From nobody Sun Jun 17 17:03:28 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21420130E59; Sun, 17 Jun 2018 17:03:26 -0700 (PDT) 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 IQkR4VK912LA; Sun, 17 Jun 2018 17:03:24 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B377F130E27; Sun, 17 Jun 2018 17:03:24 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w5HNtFFv038069; Sun, 17 Jun 2018 20:03:21 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 2jnvns3xxf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 17 Jun 2018 20:03:21 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w5I03LSx027819; Sun, 17 Jun 2018 20:03:21 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w5I03G2O027772; Sun, 17 Jun 2018 20:03:16 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id DF50D40002BC; Mon, 18 Jun 2018 00:03:16 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30487.vci.att.com (Service) with ESMTPS id CEAF740006BF; Mon, 18 Jun 2018 00:03:16 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.207]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0399.000; Sun, 17 Jun 2018 20:03:16 -0400 From: "STARK, BARBARA H" To: =?iso-8859-1?Q?=27Toke_H=F8iland-J=F8rgensen=27?= , "Donald Eastlake" , Babel at IETF CC: "babel-chairs@ietf.org" Thread-Topic: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) Thread-Index: AQHUBkt12/LBOw+XEUKOBuJ6c+cUq6Rk0LQAgABSDRA= Date: Mon, 18 Jun 2018 00:03:16 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DDFD26D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <87h8m1v4ab.fsf@toke.dk> In-Reply-To: <87h8m1v4ab.fsf@toke.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.248.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-17_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=681 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806170294 Archived-At: Subject: Re: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 00:03:26 -0000 > > Based on the recent discussion on the mailing list, we are asking for > > comments in favor or opposed to the following change in the Babel WG > > Charter to remove the specification of a YANG model as a gating factor > > in moving the Babel protocol to standards track. >=20 > I'm in favour of adopting this change. >=20 > -Toke +1 Barbara From nobody Sun Jun 17 17:20:27 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DEE130E70; Sun, 17 Jun 2018 17:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 jcgxkP7ZH57w; Sun, 17 Jun 2018 17:20:24 -0700 (PDT) Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (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 2E9C2130E59; Sun, 17 Jun 2018 17:20:24 -0700 (PDT) Received: by mail-qt0-x242.google.com with SMTP id x34-v6so13783611qtk.5; Sun, 17 Jun 2018 17:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1d8G4k4+8ZLQ2xN2kmiOjzt63WVv1yj+YPNSKAxdAdQ=; b=cUyRcWkUzxo+gXsHTUwjKgsG+/GwZIMAfv5QQwc8ll2noRYjOs8Mk+laAlexBp1rks 7Mh64ymHIS179cGzHPW/t3VpzYB/ivYUCRYG0k7dkh1CipOXpdn75+K5Dqdzd4fhhPKs ffBumO5y1ExPb/dSDwP3HHoRDN06BKOpt6ZvGibwtTIOZgoG1IVJ489ywnT8S2AAS4kf nMgI+xVhoOgCQfPsPF3ndHLGHHaeHaGiUzyCjPQB03cPMh1o/arz7BPIhEQJ4uZ6Rw+o aewGToZN5JPts0ZyP+EA6Lws/GbDIYXT24io/XJGNaDuRMOmXnal1z1ZaTv6gkeKlCxo bmwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1d8G4k4+8ZLQ2xN2kmiOjzt63WVv1yj+YPNSKAxdAdQ=; b=tYo5IEb2RyW5ccmDdMkyeS37B0KJG8mO11UtcpgAEtR+ehMeYoySSQdnHIGEGu14lg 466R2GU4BAap1pu9lZMBtK7MPUV1Mq7Xzjjq2qj6mk0wMgs6Sv1J2dSR6iC6YSNkD8zA BPcGo44vAyL94U9cU3ivWE7jcB+tAdWhQ4lVsEKtEmC/hf43h7JX+gmAs/J+88Mcs5Ox 1vl/tvlNHpUgidu5S5BZN3vpeWSPkg9rrqGHncJ1SEzlAfI6aYcIww1qJr10MZyVfYWq lwdkTPtH7ZXy+bNtE0SZtM3rGpx9AHY/4wbHl5lTQ6Y9aBopMEdRBb4y4XiyJDb8IVxX 4NwQ== X-Gm-Message-State: APt69E3X3LaO4Vp3kpD58h+YhBBO5wQSzK9GsvJOHCZGIc4qbOhFbnn9 5LjL+6EICqQW+PF2Y/EW5CstMjE1WzihSVs2X9U= X-Google-Smtp-Source: ADUXVKJDta7Ybfds0wonT5NmtS0AYoN3Gsuaa8N0KVb/dNnXE9lQ8zGj/tuqcn5nawC+7gUnO90iDnxij1eqRLiFeZg= X-Received: by 2002:ac8:33cf:: with SMTP id d15-v6mr9584942qtb.261.1529281223284; Sun, 17 Jun 2018 17:20:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:24f0:0:0:0:0:0 with HTTP; Sun, 17 Jun 2018 17:20:22 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DDFD26D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <87h8m1v4ab.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DDFD26D@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Dave Taht Date: Sun, 17 Jun 2018 17:20:22 -0700 Message-ID: To: "STARK, BARBARA H" Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Donald Eastlake , Babel at IETF , "babel-chairs@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 00:20:26 -0000 On Sun, Jun 17, 2018 at 5:03 PM, STARK, BARBARA H wrote: >> > Based on the recent discussion on the mailing list, we are asking for >> > comments in favor or opposed to the following change in the Babel WG >> > Charter to remove the specification of a YANG model as a gating factor >> > in moving the Babel protocol to standards track. >> >> I'm in favour of adopting this change. >> >> -Toke > > +1 Barbara +1 Dave > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619 From nobody Sun Jun 17 17:28:30 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712A1130E7F; Sun, 17 Jun 2018 17:28:29 -0700 (PDT) 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, 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 yeOxzuno04eH; Sun, 17 Jun 2018 17:28:27 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1800D130E74; Sun, 17 Jun 2018 17:28:26 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5I0SPDc022490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Jun 2018 02:28:25 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w5I0SQHD024600; Mon, 18 Jun 2018 02:28:26 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C3EA4EB22D; Mon, 18 Jun 2018 02:28:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 2JYWZHGnF6VH; Mon, 18 Jun 2018 02:28:22 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id AF354EB200; Mon, 18 Jun 2018 02:28:22 +0200 (CEST) Date: Mon, 18 Jun 2018 02:28:22 +0200 Message-ID: <87sh5lx7ix.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake Cc: Babel at IETF , babel-chairs@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Mon, 18 Jun 2018 02:28:25 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 18 Jun 2018 02:28:26 +0200 (CEST) X-Miltered: at korolev with ID 5B26FCA9.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B26FCAA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B26FCA9.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B26FCAA.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B26FCA9.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B26FCAA.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 00:28:30 -0000 Cool. Support, and thanks. -- Juliusz From nobody Sun Jun 17 21:15:34 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B853C1292F1 for ; Sun, 17 Jun 2018 21:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UuhzU4XDgV0 for ; Sun, 17 Jun 2018 21:15:31 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 6EA59124D68 for ; Sun, 17 Jun 2018 21:15:31 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id u4-v6so10137642itg.0 for ; Sun, 17 Jun 2018 21:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ZB7GhgGcEdcWOgHMVMY/5hM8IlXw3nbWjHDpsmeRAVc=; b=NGAPfCSIMGo4H1c7g0TebijhwWhONpfouJKURsLmn/JAIGWLIYy6wZuyU30s86Afpt XTSyJJxKfC1z2FcpcD8dsBfAoHX878/YM6yvX2v6X7mCLIEViJfqjbn9h/E3FVFC8uhe wRSigfgSsfiNicBOSG5GlKEIJrfC0AzQpt+mt3fY/1LfF1DZrL9lmszOQRgu7S+weG8a GNN530cOCEyTLHa9sATQaHkcfGtTNOmJueP9g2v3B7z8DW+UdI68KWRv6QfeQI6kriSI 8wnTKbs0q1YwzSmiu6HFLmQ/fsiM24IvKsWk3cwHjiky0uvJFfm412xrTy37fGVOd4bK FLBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ZB7GhgGcEdcWOgHMVMY/5hM8IlXw3nbWjHDpsmeRAVc=; b=t6z8h9mj5uxQP6V3T2nsCjMsz00EBjQsx4bppyIEW55pqlClL5jnLCLiiFaLxZuL4H TeawH6LPkl6Vz3ADr3s2ZE6vQT9dYJ87ZePSNVuceYdCdEjoh+ZVCt90vgX5wPqgkP06 Lj6NZ84D4efCUsGtSvJShTCM01WC4AzjOWFCy65A3kXYM8a65dthKB8XaMYIwnXI4a29 8VG7NO9gTGLFlzpOUbM7WeGIDPJoBO1iIDkFLjjjjxdoukx7g3PW+BJkNeqeX48eFkqJ 6XLJOIgx5XJJJhV7GzStsKaD40+YlK+kWUzC5NEL+1/5NSEOP07UJwqDfOmk2cF22e6J XDBw== X-Gm-Message-State: APt69E0GUED04Z9DVxy5zgA8gxDngU/Vbqk8CO16B9bPz6bBfbhDzCgs FjXgqo3kR2eGluhqpyC1jgCmHXP5PIMqIgAH4XGyQA== X-Google-Smtp-Source: ADUXVKIajtM3w3SkoUIyRSWBGHXgMOsebUGOehaGWx6Mu6+rXNYaWp9gdHfbj0DzgpFK03pOC9E7DbE9FNTGobvdFRE= X-Received: by 2002:a24:d651:: with SMTP id o78-v6mr8149795itg.94.1529295330556; Sun, 17 Jun 2018 21:15:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bf84:0:0:0:0:0 with HTTP; Sun, 17 Jun 2018 21:15:15 -0700 (PDT) From: Donald Eastlake Date: Mon, 18 Jun 2018 00:15:15 -0400 Message-ID: To: Babel at IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [babel] Tentative Babel WG meeting slot for Montreal IETF meeting X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 04:15:33 -0000 Hi, A Babel WG meeting has been tentatively scheduled for Tuesday morning July 17 at the July IETF meeting in Montreal, Canada. This may change but we currently seem to be scheduled for more time than I asked for, presumably because a longer slot was available and no shorter slots were: 09:30 to 12:00. It is not a problem if we end early. Anyone who wants to present should send a request to this list or to babel-chairs@ietf.org. I'll send out another call for presentation as the meeting gets closer. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Mon Jun 18 07:28:12 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE10130DE1; Mon, 18 Jun 2018 07:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biDy2B1zUgrA; Mon, 18 Jun 2018 07:28:07 -0700 (PDT) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 8C90E126DBF; Mon, 18 Jun 2018 07:28:07 -0700 (PDT) Received: by mail-io0-x242.google.com with SMTP id u4-v6so17005899iof.2; Mon, 18 Jun 2018 07:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xWlYxiq6rZmOtZXimVhS8wjtrg0He76iN3jphts7afA=; b=R+AaUfBvU45/yr6yOZbCEeX/6aNWxwR6cl+uYBHI1W2M+VvPpsvQv4kEMn+j73m+8o Lyaf2D3BDtyFkJPNycf29Q224f/78QWAN+IztRoV8mMqyP1h+N+p4+PEMVPOfVvwaA08 o0JkokNtC2xsOpJqBCDFkQnEcJO7yfwhM/1/avTTje0BaqRWDyCvY0qQKDJTHByYABW7 N1x8NRDw/8x0U104ipzssoc+aeFWOCXZTMSSUcqJmkJpgj3WWB8mXecSRv+tFnGcavUO vENqetf/inQaTrWZKzdkmvXjXsdSWPe7yAzWqaMJTGAVVBYc+F1YwBsu5QplZ7Wf7+8S zgLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xWlYxiq6rZmOtZXimVhS8wjtrg0He76iN3jphts7afA=; b=Ux+f450S/hRgdgKdjZdiCFvhXL8rcF9NzuF9g87Brpk2wpZRtL+lkfNYHiVLoxva8P d0I0c3XWBUpCXUanAOm7FA46gJAkRimvFe8l9XyZf/Xv2BgcosS6OGGXMLQY1bIpdpWS KssLtXMBm6QtRav9oe8mmx2Lid096UdtxbdW3Z6oFk+2a4bhEDXnvMfbL0bBUa0LkXM0 /7CQNdQRGizgnsE/lO4jzQXuMErAtML7Wc48GhdTXqRzHnIMJyaFAy2SL2pebE3AtERX +vM8rbKwTNG3u78IKB2cq7nhb+U0hdjDpXCg/vfcJsczoxYUX40LFny+FXh8G1x93F1A HE9g== X-Gm-Message-State: APt69E2BKyHx+Jk9P3OvefufJzYpt4uVkIQ5hZX2pqeOX0Rwft7E1Qns vB5FlDMNuBqcF7lz9saAR6dHKQHDsPoqo/h84qaRG9cq X-Google-Smtp-Source: ADUXVKLWhV8G6bXarZ1hOz1hl5F6ujKSzBJnSWRS2XBsMRbKLM7jnh7oZ11wE93/w6vBLAljdq+z4OIgcGcXGtgAPkk= X-Received: by 2002:a6b:c6c9:: with SMTP id w192-v6mr9951035iof.131.1529332086829; Mon, 18 Jun 2018 07:28:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bf84:0:0:0:0:0 with HTTP; Mon, 18 Jun 2018 07:27:51 -0700 (PDT) In-Reply-To: <1640f31963d.e3da2ad4319526.4149190004246054001@ovsienko.info> References: <1640f31963d.e3da2ad4319526.4149190004246054001@ovsienko.info> From: Donald Eastlake Date: Mon, 18 Jun 2018 10:27:51 -0400 Message-ID: To: Denis Ovsienko Cc: Babel at IETF , babel-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 14:28:10 -0000 Hi Denis, Thanks for your comments. On Sun, Jun 17, 2018 at 3:21 PM, Denis Ovsienko wrote= : > > ... > > Hello all. > > I oppose the proposed change for the following reasons. > > First, the fault is not in the charter. As my previous message to the lis= t discusses, it looks like we (the working group as a whole) have neglected= some meaningful parts of our charter: "Particular emphasis will be placed = on work needed for a Proposed Standard routing protocol, such as ensuring m= anageability and strong security." We have achieved exactly the opposite so= far, and it would be fair to fix first what is actually broken (specific s= uggestions are in that message). This Charter change is about process and gating, not about ultimate goals. There is substantial work on manageability in the Information Model and we do have a volunteer to do a preliminary YANG model. The problem is the interlock in the current Charter between the YANG model and the base protocol getting to Proposed Standard status and the normative dependency on Babel in the HOMENT WG. > Second, de-rating of the requirements level should mean de-rating of the = publication category. If the working group explicitly finds itself unable t= o produce a quality YANG deliverable in time, it could _potentially_ (if th= e charter allowed it) capture its core (6126bis + whatever security) delive= rables as IETF Experimental publications, take a break and retain the motiv= ation to have YANG eventually done and aim for Proposed Standard. But neith= er the current charter nor the proposed change take this into account. The entire thrust of this WG effort is to move Babel to the Standards Track and any change from that would be a major change for which I have not seen any support except your message. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > -- > Denis Ovsienko From nobody Mon Jun 18 09:29:17 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A77130DFA for ; Mon, 18 Jun 2018 09:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 oWFranDQm-Fe for ; Mon, 18 Jun 2018 09:29:10 -0700 (PDT) Received: from mail-in23.apple.com (mail-out23.apple.com [17.171.2.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE4F130DFD for ; Mon, 18 Jun 2018 09:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1529339346; x=2393252946; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jfPVgV6dYXt6gnHS+uYyaz9WcJVPjxddaFjNhV2+pE0=; b=BYwmxi3HNVnFMAt1UrYXn957uHckfSq+zTObxkxO7zdEDS7li8RXetvMXtwaS1up ka/gFiXFT3Q/2OcUWt67oANSdVvgKS5k2T+xksMrYdkIPlthPIRVh4omo5oSTBN0 AaAaNVOMUIrgbjjsQLTpz/YnkYqg+Co9qn9SG5FD0PZngy651ihYB83xD9lbjWuz rjSkKAtslopT8zH3kSzb0Fiv8AT7nQiQPD8Szijo2UGHu4xnYuER6QO3Y6UhuC9a C0knccf4uCeVPROcResn+18hb5VW15YZdvu11CO+3pe1Ivsr86CmLYyx/veQEP9D AZ/gGX0sGifm1Xtu+urvFg==; X-AuditID: 11ab0217-d27ff70000003e90-2b-5b27ddd2f7d7 Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in23.apple.com (Apple Secure Mail Relay) with SMTP id C8.0A.16016.2DDD72B5; Mon, 18 Jun 2018 09:29:06 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0PAJ000ZI1SH32I0@ma1-mtap-s02.corp.apple.com>; Mon, 18 Jun 2018 09:29:06 -0700 (PDT) Received: from [17.234.1.1] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0PAJ00BDK1SBHA00@nwk-mmpp-sz10.apple.com>; Mon, 18 Jun 2018 09:29:05 -0700 (PDT) X-Va-A: X-Va-T-CD: e37ecdf785950a8d40541851ee1b14bc X-Va-E-CD: d13d00c8cf1ba73837c3f1bb295a0524 X-Va-R-CD: 77a636e2d5b55756bec8d24b36c75e1f X-Va-CD: 0 X-Va-ID: b5cbd761-f277-4dea-9378-bad89fed2a01 X-V-A: X-V-T-CD: d81cd4791f884a0e9a3107282831bbdb X-V-E-CD: d13d00c8cf1ba73837c3f1bb295a0524 X-V-R-CD: 77a636e2d5b55756bec8d24b36c75e1f X-V-CD: 0 X-V-ID: 77cf0c2f-be85-4d4a-bfbf-b03c2dca5828 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-18_06:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp17.corp.apple.com-10000_instance1 Sender: dschinazi@apple.com From: David Schinazi In-reply-to: Date: Mon, 18 Jun 2018 09:28:57 -0700 Cc: Babel at IETF , babel-chairs@ietf.org Message-id: <33158E4B-D84F-4A60-8641-3E7C9118E44A@apple.com> References: To: Donald Eastlake X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsUiqOHDpnvprnq0weyNfBane2+xWGxZ1M1i cXC7pgOzx85Zd9k9liz5yRTAFMVlk5Kak1mWWqRvl8CV0d/xg6XgO3/FppWbWBsYX/B0MXJy SAiYSGzb8Zqli5GLQ0hgP5PEglftrCAJXgFBiR+T7wElODiYBeQlDp6XBQkzC2hJfH/UClW/ kUli/8l5TBDOJ0aJlVsms0JMZZf482sHWLOEgLbEytuyEGFtibMNR5hh7H/XrzFB2FwSC7ae hmrVlfi4og/KZpNYf2IJVI2WxNv9IL0cYPa6VaYw4YVNG9kgbE6J818mskPYOhJnXtxggbCz Ja6ufAFVEyzxcEIbI4gtLCAt0XXhLiuEHSnx9MVFJpDxbEAzD6wxAglzApWv+v0WbAyLgKrE 2W0/WSDBYClxcPkSaEjZSDz/8IsNpFVIIEDi/sESkLCIgJrE6+ULoC5Qkpj+/TbbBEb5WUhh OwsRtrOQwnYBI/MqRuHcxMwc3cw8I2O9xIKCnFS95PzcTYyg2F/NJL6D8fNrw0OMAhyMSjy8 GuvVo4VYE8uKK3MPMUpzsCiJ837YJRYtJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdGucs3M iqMMdR8U55UsqgsR+b6wS+AuX+dEic3fJpl5GUWoWefpvL6dtMf04YpVWZmvXj5JPaoT3/B1 g61oaKUf7yf9JJVTxrv8pizaKtWwpJdRWqH8mspbP5l579i37VGSmtDhkJ918l1A37aoqkvF 6x6dkzkdrzy5yI3vQ0HBiiumz3pCviuxFGckGmoxFxUnAgBKhuSd3gIAAA== Archived-At: Subject: Re: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 16:29:13 -0000 Thanks Donald and Russ! I support this change. David Schinazi > On Jun 17, 2018, at 07:56, Donald Eastlake wrote: > > Hi, > > Based on the recent discussion on the mailing list, we are asking for > comments in favor or opposed to the following change in the Babel WG > Charter to remove the specification of a YANG model as a gating factor > in moving the Babel protocol to standards track. You can also suggest > further changes but to maximize the chances of getting a change > approved it might be best to minimize the changes. > > OLD: > - Address manageability of Babel by producing a Babel informational > model to help provide guidance and derive the data models. To be > consistent with the ongoing effort to use YANG data modules in the > Routing Area, a Babel YANG data model to support management of home > gateway routers is required as part of moving Babel to Proposed > Standard. This information model is useful as a common source of > information for the case where the Customer-Premise Equipment (CPE) is > managed by the Service Provider (SP) with the Broadband Forum TR-069 > protocol and its associated data model. > > NEW: > - Address manageability of Babel by producing a Babel informational > model to help provide guidance and derive the data models. This > information model is useful as a common source of information for the > case where the Customer-Premise Equipment (CPE) is managed by the > Service Provider (SP) with the Broadband Forum TR-069 protocol and its > associated data model. To be consistent with the ongoing effort to use > YANG data modules in the Routing Area, a Babel YANG data model should > be specified to support management of Babel routers. > > The full current Babel WG Charter is at > https://datatracker.ietf.org/doc/charter-ietf-babel/ > > Thanks, > Donald and Russ > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Mon Jun 18 10:00:15 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354E5130EC7; Mon, 18 Jun 2018 10:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=kapsi.fi 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 s5jgzntXbmUv; Mon, 18 Jun 2018 10:00:00 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (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 A4BEA130EE2; Mon, 18 Jun 2018 09:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=o2qx2r2WOR3LbhuxdP/5Zob6kwdhJIm+A3NLMrnnZtM=; b=rqAgO8gCJxRs4JpapAQM4yFpTrVIUDAEar/vsHUwMVcoT6Zo2WBXmS9ztOsMOv9esqYbwLH9dCLkzi4jbUreX91rNqxnTqmhkCQCIHMArUS3ayfvsBAzDf+nZdNBk3OfHtDkCtC91c8rr0l3haK49R75cN7hpUZIaUwnXwDuZEtfW3+ZyA3jigFRKjzb3LF2yY3YMlxI65EJsq+jeLNCTb/v6bsgmGb0Y3cOCnzxlDhqgkiVec0fTaNi7kQAt5FYBZJDmCb0rPW95Tycy0IPLG1AD2I4txQwxu+wmxSXB64OD0iGM+SqooIcBVWK9KfAj+/+Y4/e0Yb0A2G21YaOQQ==; Received: from 91-155-69-32.elisa-laajakaista.fi ([91.155.69.32] helo=poro.lan) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fUxVS-00083K-NF; Mon, 18 Jun 2018 19:59:54 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Markus Stenberg In-Reply-To: Date: Mon, 18 Jun 2018 19:59:53 +0300 Cc: Babel at IETF , babel-chairs@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <9C9F173A-4E5D-4C23-A995-DB433C2DB913@iki.fi> References: To: Donald Eastlake X-Mailer: Apple Mail (2.3445.8.2) X-SA-Exim-Connect-IP: 91.155.69.32 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 17:00:14 -0000 Looks good to me as well; +1 -Markus From nobody Mon Jun 18 14:03:18 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B68127148 for ; Mon, 18 Jun 2018 14:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 xqwQz14TqHZq for ; Mon, 18 Jun 2018 14:03:13 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 23E6A130E39 for ; Mon, 18 Jun 2018 14:03:13 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id y8-v6so8774146pfm.10 for ; Mon, 18 Jun 2018 14:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0VlGypq6+481fKEssbpO8+wr7pngpvimOUwTQOHtBEU=; b=Oxg5KjmEgheK6lUeY+kM4SZu+I8etMkxjWljcg5Iy8sFz1c2Yn86mtFw8als4cOfVx nlUCoWaGilVDqvZ/e9qUbaYC9rl3uqV/Qa0SB92okVJNMNa8OCHPlk8t19qHovRPgq0Y jBbTjQ2+kGt5gi7ZvvAyuUrcwv0POkkdCBBgYpTK+8L8Uz0TXfurLqQEG6OilYe5rtRU TgTVDdc+NpYWdAZEPf/TZTVEbnRq3Yvc7z9mo+ww/AyycMJdnyA5QOGLW+uCoFcYdFBj CH0RNKJ1PjgO1t87r1GZksx7/rwxpWBwYmaVBDj9SAsFJ7XWPak0TIVA/ERHN2qdqeap awug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0VlGypq6+481fKEssbpO8+wr7pngpvimOUwTQOHtBEU=; b=Ho077T3HMGifSK7vlpBq4SkB+aQaNkT9igefKgOWV+EqB9DlIXVId2s4AGyAzYOBve Wn9+BapK5bY7fW7t/8YVgiIKqBs2M269fswPdGT0XkQ6W3IbCUXzwxMv39y3zE6Mxhma 8RiNey9KBZZC3Vl97z16dFgYl1w/j8vWPqDdmpVpstMF6NH8gqWUAKwHehx+eYaeWMik MHZYe7P+semT7cq2QtKdKeapT5jhpUqqcJvnrPplOajNyerPxEdH+tN9+iU0UTVto/Yp yYBgu0ApZh7WIZa3rIb+LqWkqKsYSD8jHGfzlcEPPAvJ/+BWOXYfpaOVE5hkG8DBFgxy GT7A== X-Gm-Message-State: APt69E371m9PHaYD2RCKGNKDntilIlmjtr1BKdKqOgM0RSsnQvJUSHVk fRC6/wYOyUPxjkRtV6YVTyGmooZ/qsIuGSMnvvEAyQ== X-Google-Smtp-Source: ADUXVKKLKJf9izlkiLjtx+5DPw4G/VQ8868q9U1zSxmkLIusu3n2aEqDLbbkwpctFnwJO5fJ0lugYN7KACJ7zYt3IhI= X-Received: by 2002:a65:56c1:: with SMTP id w1-v6mr12526445pgs.227.1529355792274; Mon, 18 Jun 2018 14:03:12 -0700 (PDT) MIME-Version: 1.0 References: <9C9F173A-4E5D-4C23-A995-DB433C2DB913@iki.fi> In-Reply-To: <9C9F173A-4E5D-4C23-A995-DB433C2DB913@iki.fi> From: Gabriel Kerneis Date: Mon, 18 Jun 2018 23:03:01 +0200 Message-ID: To: Markus Stenberg Cc: Donald Eastlake , babel-chairs@ietf.org, Babel at IETF Content-Type: multipart/alternative; boundary="000000000000bc759b056ef0e495" Archived-At: Subject: Re: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 21:03:16 -0000 --000000000000bc759b056ef0e495 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Looks like the best way forward to unlock the situation. Approved. Gabriel Le lun. 18 juin 2018 =C3=A0 19:00, Markus Stenberg = a =C3=A9crit : > Looks good to me as well; +1 > > -Markus > > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --000000000000bc759b056ef0e495 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Looks like the best way forward to unlock the situation. = Approved.

Gabriel

Le lun. 18 juin 2018 =C3= =A0 19:00, Markus Stenberg <ma= rkus.stenberg@iki.fi> a =C3=A9crit=C2=A0:
Looks good to me as well; +1

-Markus


_______________________________________________
babel mailing list
babe= l@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--000000000000bc759b056ef0e495-- From nobody Mon Jun 18 23:50:59 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFED130DC8; Mon, 18 Jun 2018 23:50:57 -0700 (PDT) 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, 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 L-7sK6KiqSnH; Mon, 18 Jun 2018 23:50:54 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B88D112E039; Mon, 18 Jun 2018 23:50:53 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5J6oo81000773; Tue, 19 Jun 2018 08:50:50 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3F87CEB914; Tue, 19 Jun 2018 08:50:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 5m2ZryyLaV1T; Tue, 19 Jun 2018 08:50:49 +0200 (CEST) Received: from [192.168.255.172] (host.52.92.23.62.rev.coltfrance.com [62.23.92.52]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9922FEB913; Tue, 19 Jun 2018 08:50:46 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Matthieu Boutier In-Reply-To: Date: Tue, 19 Jun 2018 07:15:49 +0200 Cc: Babel at IETF , babel-chairs@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: To: Donald Eastlake X-Mailer: Apple Mail (2.3445.8.2) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 19 Jun 2018 08:50:50 +0200 (CEST) X-Miltered: at korolev with ID 5B28A7CA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B28A7CA.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B28A7CA.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 06:50:58 -0000 > remove the specification of a YANG model as a gating factor I also support this change. Thanks Donald. Matthieu From nobody Wed Jun 20 08:32:03 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071E313103B; Wed, 20 Jun 2018 08:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info 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 lXS9GP2rhRJr; Wed, 20 Jun 2018 08:32:00 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17AD3130F99; Wed, 20 Jun 2018 08:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1529508711; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=4619; bh=qHHQ2GrSacm6kKGcGKODs8PqtChsTsRg1VdE4Nyixtw=; b=sY44zRtr3ZXXzWCFEI0m6zoeCkjaiw/k7UF2FzipXToXIUqPRV6YcCSGAOlYly5N 8CeexoVYp3mMZK6fq7vVr3HXfVNBHM5TH5v25jCzGe9PYv7W8Ddc33aIbanuCoCkZ2U D7CjNTeg12G/U1lIt/Mg0Qo+DHicu8jdQebLKENA= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 152950871103484.39162965485798; Wed, 20 Jun 2018 08:31:51 -0700 (PDT) Date: Wed, 20 Jun 2018 16:31:51 +0100 From: Denis Ovsienko To: , "Babel at IETF" Message-ID: <1641dd2ca78.c00b97523761.4967171539240276911@ovsienko.info> In-Reply-To: References: <1640f31963d.e3da2ad4319526.4149190004246054001@ovsienko.info> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 15:32:03 -0000 Thank you for your comments Donald, please see my questions and comments below. ---- On Mon, 18 Jun 2018 15:27:51 +0100 Donald Eastlake wrote ---- > Hi Denis, > > Thanks for your comments. > > On Sun, Jun 17, 2018 at 3:21 PM, Denis Ovsienko wrote: > > > ... > > > > Hello all. > > > > I oppose the proposed change for the following reasons. > > > > First, the fault is not in the charter. As my previous message to the list discusses, it looks like we (the working group as a whole) have neglected some meaningful parts of our charter: "Particular emphasis will be placed on work needed for a Proposed Standard routing protocol, such as ensuring manageability and strong security." We have achieved exactly the opposite so far, and it would be fair to fix first what is actually broken (specific suggestions are in that message). > > This Charter change is about process and gating, not about ultimate > goals. There is substantial work on manageability in the Information > Model and we do have a volunteer to do a preliminary YANG model. The > problem is the interlock in the current Charter between the YANG model > and the base protocol getting to Proposed Standard status and the > normative dependency on Babel in the HOMENT WG. I am sorry, but the only way I can read the above is it begins saying it is not about ultimate goals, and then says Proposed Standard is an ultimate goal and justifies bending the rules. Can you see it from this point of view? The _intentional_ dependency on YANG has been in the charter for 2 years, but only now it suddenly became a "problem", do you agree it looks strange enough to deserve a proper explanation? > > Second, de-rating of the requirements level should mean de-rating of the publication category. If the working group explicitly finds itself unable to produce a quality YANG deliverable in time, it could _potentially_ (if the charter allowed it) capture its core (6126bis + whatever security) deliverables as IETF Experimental publications, take a break and retain the motivation to have YANG eventually done and aim for Proposed Standard. But neither the current charter nor the proposed change take this into account. > > The entire thrust of this WG effort is to move Babel to the Standards > Track and any change from that would be a major change for which I > have not seen any support except your message. Standards Track work indeed has been the IETF's expectation of this working group. This was a reasonable initial expectation based on the way the pre-IETF work was presented at the IETF. That said, if the actual in-IETF results were as good as expected, there would not be this call and this discussion in the first place, do you agree? I agree the proportional de-rating would be a major change to the charter. However, just writing deliverables off with no consequences would be a major change too, and in addition to that it would be difficult to distinguish from just gaming the Standards Track process. Does one of the evils look significantly less than the other? I agree 8 people on the list have voted to support the charter change so far, and I am the only one who has objected so far. Notwithstanding the fact, I believe this working group does not yet have valid grounds to declare consensus on this call and to ask to change the charter. The matter is, your message that starts this call asks for _comments_. This is indeed a valid way to start a consensus process, and it is not a warrant to reduce it to a voting. To emphasize the difference, let me quote this: "We reject kings, presidents and voting. We believe in rough consensus and running code." One of the reasons I decided to join the IETF in 2016 was I knew what this saying is intended to mean -- long before that I had read RFC 7282 (On Consensus and Humming in the IETF). The document explains in detail why opposing a majority of _votes_ with a reasoned _objection_ in a call for _consensus_ is a normal IETF approach and it should not be questioned or dismissed. Specifically, it tells why the situation with this call is _not_ a consensus (and what could be done to try to achieve it). To sum my position up, the right thing to do would be either to leave the charter intact or to ask for proportional de-rating on both sides of the deal like suggested, in either case the working group should keep to the intended IETF methods of work. I am willing to address any comments regarding my input to this consensus call. Thank you. -- Denis Ovsienko From nobody Wed Jun 20 08:44:00 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07391310E0; Wed, 20 Jun 2018 08:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 VDT5-oJaQYs1; Wed, 20 Jun 2018 08:43:44 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0DD12F1AC; Wed, 20 Jun 2018 08:43:43 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1529509422; bh=C82Uskhdxc7r2Lp8SmzoMuxMLEGm4Rk2WMIEUWNfJeU=; h=From:To:Subject:In-Reply-To:References:Date:From; b=S0+rX5yNBd9bVWlUDFBfg+IMyV4WB4XIv5DBfrmhkbPrGJCbTf6uH/XSQIbE9jsCv LtsOuX5YtZmdb66wu6uCQkZnwz5tWrwrJHEZni73IWTWK9BZcMfMrPZicsm38O4rl8 OWVEDQpdptyxbHKyKptIKz78Dtd12WPLRupfgSqUl/k5vUla/D+HKWPqdajBXr6FY9 7pfQbrN4z1s7Og3DWd+wfFT2HldI6Wqx/KPhXPF1zLgtMxgH5/h9vdSrA20ycM3Fta w1uieWoTElZ9bncCeGAN/RdqVW0s8PYFP/FV6qFtVAxbOeqx9/LD0Gy2oO0Rha+0w2 nGzktfIhSor/g== To: Denis Ovsienko , babel-chairs@ietf.org, Babel at IETF In-Reply-To: <1641dd2ca78.c00b97523761.4967171539240276911@ovsienko.info> References: <1640f31963d.e3da2ad4319526.4149190004246054001@ovsienko.info> <1641dd2ca78.c00b97523761.4967171539240276911@ovsienko.info> Date: Wed, 20 Jun 2018 17:43:42 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87k1qtsbtd.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 15:43:51 -0000 Denis Ovsienko writes: > One of the reasons I decided to join the IETF in 2016 was I knew what > this saying is intended to mean -- long before that I had read RFC > 7282 (On Consensus and Humming in the IETF). The document explains in > detail why opposing a majority of _votes_ with a reasoned _objection_ > in a call for _consensus_ is a normal IETF approach and it should not > be questioned or dismissed. Your argument seems to be that no change to the charter is allowed except one that degrades everything to something less than standards track. While this is certainly an objection, I fail to see how it is anything resembling "reasoned". -Toke From nobody Wed Jun 20 10:03:27 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379BA130DEF; Wed, 20 Jun 2018 10:03:21 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 OvSCMpwbncbI; Wed, 20 Jun 2018 10:03:19 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF87130F56; Wed, 20 Jun 2018 10:03:18 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E728A21903; Wed, 20 Jun 2018 13:03:17 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 20 Jun 2018 13:03:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=mqRxhI bmn/6rNaCjfIVSzCFupRcgmRKdum665qWDqYM=; b=rezUabZIjcf0OX1ZDAYTbN Bl+/9UvDuExSM8uLuFnvNqHb1fl0ppTFBBIoWbN5u2oSwuYT7LB4NcBsQYmtUgM+ LfHxcBqRPfORf7pJCSnS3ayAEmZ/sE+LC4IukSn9DwEywstmdflYCjTAdXm6Hiuc EVa+2dJ/Kxt3bN6DW99kXj9V5iAdxLloJevNAcQJAHgjowK0BY8fiba+NIwh0dQY gwNS5ETPBtBcyWPsRDV8Vjeiq1+IodREFsek/8s54SwpnM8/6vamQIwTXCvLapkj 84A7/dNzsqVXOo/2/+cMyMPLOeBrh1J+WTC4IhzZeG9wVsy/cF7SUSfK8NsNuHIQ == X-ME-Proxy: X-ME-Sender: Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net [162.229.180.77]) by mail.messagingengine.com (Postfix) with ESMTPA id 8A516E403B; Wed, 20 Jun 2018 13:03:17 -0400 (EDT) From: "Russ White" To: "'Denis Ovsienko'" , , "'Babel at IETF'" References: <1640f31963d.e3da2ad4319526.4149190004246054001@ovsienko.info> <1641dd2ca78.c00b97523761.4967171539240276911@ovsienko.info> In-Reply-To: <1641dd2ca78.c00b97523761.4967171539240276911@ovsienko.info> Date: Wed, 20 Jun 2018 13:03:18 -0400 Message-ID: <062e01d408b8$968cc6c0$c3a65440$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG8ZNnxzdN5etKQKH1Amkkkp/PJoQJWkeKqAewXEJ0CYhrxX6Rjf/bQ Content-Language: en-us Archived-At: Subject: Re: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 17:03:22 -0000 > I am sorry, but the only way I can read the above is it begins saying = it is not > about ultimate goals, and then says Proposed Standard is an ultimate = goal > and justifies bending the rules. Can you see it from this point of = view? While proposed standard remains the ultimate goal, the path to reach = that goal may need to shift over time to account for present realities. = IMHO, a YANG model will be built for BABEL, but _requiring_ it "right = now" has become a road block.=20 There is an explanation for this, but it's not something the chairs, = AD's, etc. feel the need to discuss publicly. It is better to focus on = what we can focus on, and reshape the process towards the ultimate goal, = than to allow the work to stall entirely.=20 =F0=9F=98=8A Russ From nobody Wed Jun 20 12:56:48 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2E51294D0; Wed, 20 Jun 2018 12:56:45 -0700 (PDT) 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, 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 Ftb2kxf6Xqii; Wed, 20 Jun 2018 12:56:43 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6B9130E0D; Wed, 20 Jun 2018 12:56:42 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5KJtwM4015381; Wed, 20 Jun 2018 21:55:58 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id D31C0EB200; Wed, 20 Jun 2018 21:56:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id EahL6ER8IK_o; Wed, 20 Jun 2018 21:56:38 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3A471EB22E; Wed, 20 Jun 2018 21:56:36 +0200 (CEST) Date: Wed, 20 Jun 2018 21:56:36 +0200 Message-ID: <8736xhp6yz.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko Cc: , "Babel at IETF" In-Reply-To: <1641dd2ca78.c00b97523761.4967171539240276911@ovsienko.info> References: <1640f31963d.e3da2ad4319526.4149190004246054001@ovsienko.info> <1641dd2ca78.c00b97523761.4967171539240276911@ovsienko.info> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 20 Jun 2018 21:55:58 +0200 (CEST) X-Miltered: at korolev with ID 5B2AB14E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B2AB14E.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B2AB14E.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 19:56:46 -0000 > I agree 8 people on the list have voted to support the charter change so > far, and I am the only one who has objected so far. Notwithstanding the > fact, I believe this working group does not yet have valid grounds to > declare consensus on this call and to ask to change the charter. We haven't achieved unanimity. Consensus doesn't require unanimity. Eight major contributors to the Babel protocol, including all of the known active implementers, have expressed support for the change. One lone contributor has expressed opposition, with no technical arguments to support his position. > opposing a majority of _votes_ with a reasoned _objection_ in a call for > _consensus_ is a normal IETF approach and it should not be questioned or > dismissed. I have read your mail from 17 June very carefully, and my understanding is that your objection basically amounts to "any change to the charter is unacceptable". I do not personally believe that this is the kind of serious technical objection that would suffice to break consensus on its own. -- Juliusz From nobody Wed Jun 20 15:19:26 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC88130E2F; Wed, 20 Jun 2018 15:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info 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 g81QwZk0vNga; Wed, 20 Jun 2018 15:19:21 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDEB1277BB; Wed, 20 Jun 2018 15:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1529533158; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=1249; bh=DCee7Ks7EFrijs+aJvz5hiQxIrjF1GXRdp9c+n1EXTw=; b=d2/yOrtzMoX896GQhaZhiurCidtARBiG12B0a/BaMgXp6OI4kti30rbG/g9uGx/6 3HO+49VZIj1lRw+WpeE7UkRGDXz9nF3giFSdv6FwbD5T53XQmZno0ZU652qE26Fa0z0 Cl4UALgBFjvv0b88N5wfp4KdCQqks5SOWTADbO0I= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1529533158732608.9232695987432; Wed, 20 Jun 2018 15:19:18 -0700 (PDT) Date: Wed, 20 Jun 2018 23:19:18 +0100 From: Denis Ovsienko To: , "Babel at IETF" Message-ID: <1641f47d54b.d0ab42ee57408.3780955439064399322@ovsienko.info> In-Reply-To: <87k1qtsbtd.fsf@toke.dk> References: <1640f31963d.e3da2ad4319526.4149190004246054001@ovsienko.info> <1641dd2ca78.c00b97523761.4967171539240276911@ovsienko.info> <87k1qtsbtd.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 22:19:24 -0000 ---- On Wed, 20 Jun 2018 16:43:42 +0100 Toke H=C3=B8iland-J=C3=B8rgensen <= toke@toke.dk> wrote ----=20 > Denis Ovsienko writes:=20 > =20 > > One of the reasons I decided to join the IETF in 2016 was I knew what= =20 > > this saying is intended to mean -- long before that I had read RFC=20 > > 7282 (On Consensus and Humming in the IETF). The document explains in= =20 > > detail why opposing a majority of _votes_ with a reasoned _objection_= =20 > > in a call for _consensus_ is a normal IETF approach and it should not= =20 > > be questioned or dismissed.=20 > =20 > Your argument seems to be that no change to the charter is allowed=20 > except one that degrades everything to something less than standards=20 > track. While this is certainly an objection, I fail to see how it is=20 > anything resembling "reasoned".=20 Hello Toke. What you are describing is my conclusion, and how I come to that conclusion= I took care to explain in a few recent messages to the list. Of course thi= s is not apparent from the only paragraph you have quoted above, but still. You are welcome to provide a better example of reasoning in support of your= position. --=20 Denis Ovsienko From nobody Wed Jun 20 15:31:58 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D54B130E37; Wed, 20 Jun 2018 15:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info 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 66cZz3jNIIgE; Wed, 20 Jun 2018 15:31:54 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BCB51277BB; Wed, 20 Jun 2018 15:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1529533908; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=1138; bh=6otV3hAtVJNSNKVXdjXUobhUUPV36A3tp+OqGFkbJDg=; b=S2p6X/2sN1On1NFNEsNeZf+xVTFlwJzzXUrBN4RJincYw0sBlKQoxmQNN8feB58g R6m4b5kKlfmi/XKGSL9vMQx2pGHTTwKv29AtWBPhl2nb3FIN973kKoWs63ZvqOxVX3b cHkV0tcEAlWACWihehiOds9spGoFjICCTxdVupWI= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1529533908768941.6996290592559; Wed, 20 Jun 2018 15:31:48 -0700 (PDT) Date: Wed, 20 Jun 2018 23:31:48 +0100 From: Denis Ovsienko To: , "'Babel at IETF'" Message-ID: <1641f53471f.d11eeabd58789.2761076467382817367@ovsienko.info> In-Reply-To: <062e01d408b8$968cc6c0$c3a65440$@riw.us> References: <1640f31963d.e3da2ad4319526.4149190004246054001@ovsienko.info> <1641dd2ca78.c00b97523761.4967171539240276911@ovsienko.info> <062e01d408b8$968cc6c0$c3a65440$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 22:31:57 -0000 ---- On Wed, 20 Jun 2018 18:03:18 +0100 Russ White wrote ---= -=20 >=20 > > I am sorry, but the only way I can read the above is it begins saying = it is not > > about ultimate goals, and then says Proposed Standard is an ultimate g= oal > > and justifies bending the rules. Can you see it from this point of vie= w? >=20 > While proposed standard remains the ultimate goal, the path to reach tha= t goal may need to shift over time to account for present realities. IMHO, = a YANG model will be built for BABEL, but _requiring_ it "right now" has be= come a road block.=20 >=20 > There is an explanation for this, but it's not something the chairs, AD'= s, etc. feel the need to discuss publicly. It is better to focus on what we= can focus on, and reshape the process towards the ultimate goal, than to a= llow the work to stall entirely.=20 >=20 > =F0=9F=98=8A Thank you for the comment Russ, but to me it does not make a complete sense= yet. Wherever the change initiates, if it comes to a WG consensus call at = some stage, it should be treated as such. --=20 Denis Ovsienko From nobody Fri Jun 22 14:18:40 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DC7130EF1 for ; Fri, 22 Jun 2018 14:18:38 -0700 (PDT) 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, 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 kftEno7dCEQq for ; Fri, 22 Jun 2018 14:18:35 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE70D130EEB for ; Fri, 22 Jun 2018 14:18:34 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5MLHn81030311; Fri, 22 Jun 2018 23:17:49 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 040EFEB22D; Fri, 22 Jun 2018 23:18:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 9_ppnPcYagXt; Fri, 22 Jun 2018 23:18:29 +0200 (CEST) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A704BEB200; Fri, 22 Jun 2018 23:18:26 +0200 (CEST) Date: Fri, 22 Jun 2018 23:18:25 +0200 Message-ID: <878t76a5b2.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org, babel-users@lists.alioth.debian.org CC: Weronika =?ISO-8859-2?Q?Ko=B3odziejak?= , Clara =?ISO-8859-1?Q?D=F4?= User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 22 Jun 2018 23:17:49 +0200 (CEST) X-Miltered: at korolev with ID 5B2D677D.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B2D677D.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B2D677D.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [babel] ANNOUNCE: hmac authentication for Babel, first prototype X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 21:18:39 -0000 Dear all, Clara Dô et Weronika Ko³odziejak (in copy of this mail) have just pushed their work on HMAC authentication for babeld to Github: https://github.com/wkolod/babeld branch hmac It's a very early prototype, and has received almost no testing. To use, checkout and compile the hmac branch, and say in your config file: key id key1 type sha1 value deadbeefdeadbeefdeadbeefdeadbeefdeadbeef interface wlan0 hmac key1 The following features are planned but not implemented yet: - multiple keys on a single interface; - key rotation; - restart with loss of state in the absence of a hardware clock. There's a minor bug that we plan to fix next week: - all keys known to babeld are accepted, not just the keys assigned to a given interface. We also need to carefully check the error-handling behaviour, especially for TLV truncation. The protocol ============ The protocol is closely based on the work of Denis Ovsienko (RFC 7298, draft-ovsienko-babel-rfc7298bis-00. The main differences are as follows: (1) rather than inserting the source address into the HMAC TLV before hashing, we use a pseudo-header consisting of the source and destination addresses (suggested by David Schinazi, to whom thanks); (2) the HMAC TLV does not carry an explicit key-ID; instead, we test the received HMAC against all provisioned keys (just one in the normal case, just two during key rotation); (3) the HMAC TLV carries a single opaque field "TS/PC" of size 6 octets; it is not structured into TS and PC, since the distinction is not necessary; (4) the HMAC TLV lives in the packet trailer, which makes it clear what is covered by the HMAC and what isn't; (5) replay protection is slightly different, to avoid the flaw described in my posting of 10 May 2018 to babel@ietf. A neighbour is considered authentic if we received a fresh TS/PC echo from it in the last 30 seconds. Details are likely to change (I think we'll make that 4 * IHU interval). We're pretty sure of ourselves for points 1, 2, and 3. Point 4 is open for discussion -- it makes implementation simpler, but complicates the description of the protocol. Point 5 is likely to change. We are open to suggestions about how to achieve restart with loss of state. Be aware that the internship officially ends by the end of the month, so earlier comments will be even more welcome than later ones. The code ======== A quick guide to the code: - keys live in struct interface and struct buffered; all known keys are in the key table, which is reference counted; - the packet trailer is checked in check_hmac, which is called early in parse_packet; if the HMAC check fails, the packet is dropped straight away, with no further parsing; - a first pass is made over the packet to check for TS/PC and update neighbour authenticity; this is preparse_tspc, called from parse_packet; if the neighbour is not fresh, the packet is dropped straight away; - the packet is then parsed as usual. All together, some 850 lines of code, 730 not counting the configuration parser. Makefile | 10 +- anm.c | 81 +++++++++++++++ anm.h | 31 ++++++ babeld.c | 5 +- configuration.c | 121 ++++++++++++++++++++++- configuration.h | 4 + hmac.c | 300 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ hmac.h | 36 +++++++ interface.c | 12 ++- interface.h | 10 ++ message.c | 178 ++++++++++++++++++++++++++++++--- message.h | 10 +- neighbour.c | 5 + neighbour.h | 1 + net.c | 40 +++++++- net.h | 3 +- util.c | 32 ++++++ util.h | 2 + 18 files changed, 851 insertions(+), 30 deletions(-) Enjoy, -- Juliusz From nobody Tue Jun 26 04:29:05 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA42130FEB for ; Tue, 26 Jun 2018 04:29:04 -0700 (PDT) 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, 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 yDlrNG9DBGA8 for ; Tue, 26 Jun 2018 04:29:02 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FDCD130FE2 for ; Tue, 26 Jun 2018 04:29:02 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5QBSIsa028307; Tue, 26 Jun 2018 13:28:18 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 22F89EB27A; Tue, 26 Jun 2018 13:29:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 4hSRHj0cAPaA; Tue, 26 Jun 2018 13:28:59 +0200 (CEST) Received: from pirx.irif.fr (eduroam-prg-hf-1-6-220.net.univ-paris-diderot.fr [172.28.6.220]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1B90FEB200; Tue, 26 Jun 2018 13:28:59 +0200 (CEST) Date: Tue, 26 Jun 2018 13:28:58 +0200 Message-ID: <87in65rdl1.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org CC: Denis Ovsienko , Clara =?ISO-8859-1?Q?D=F4?= , Weronika =?ISO-8859-2?Q?Ko=B3odziejak?= User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 26 Jun 2018 13:28:18 +0200 (CEST) X-Miltered: at korolev with ID 5B322352.004 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B322352.004 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B322352.004 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [babel] HMAC authentication: remove TS/PC echo, use a cryptographic handshake X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 11:29:05 -0000 Dear all, Clara, Weronika and myself have been thinking about the HMAC protocol, and we're considering replacing the TS/PC echo mechanism with a cryptographic handshake. We need the list's opinion. In RFC 7298, every packet contains a strictly increasing 48-bit integer known as the TS/PC. A packet is rejected if its TS/PC is absent or not strictly larger than the TS/PC previously sent by that node. Back at Berlin, Denis showed us that this mechanism is vulnerable to replay. In 7298bis, this mechanism is augmented with the TS/PC Echo mechanism (my term). The TS/PC Echo is a sub-TLV of IHU, and MUST be sent with every IHU; it contains an echo the latest TS/PC received from the node the IHU it is destined to. A packet is rejected if it contains an applicable IHU whose TS/PC Echo is absent or not fresh enough (but not if it contains no applicable IHU). This mechanism was shown to be vulnerable to replay in my posting of 10 May. What we've currently implemented is a slight variation of the mechanism in rfc6126bis: a packet is rejected unless we have received a valid TS/PC echo from the sender recently enough (within 8 IHU intervals). This would appear to not be vulnerable to replay under reasonable conditions (either at least one node has retained its state, or TS/PC is strictly increasing), and is easy enough to implement. However, it has one major flaw: if a node resets its TS/PC (it loses its state), it is unreachable for up to one ANMTimeout, which can be on the order of hours. We propose to drop the TS/PC Echo mechanism and use a cryptographic handshake instead. When a node A receives a packet from a node B, it consults its ANM table for the right TS/PC, just like in RFC 7298. If there is no ANM entry, or if the received TS/PC is invalid, it sends a challenge with a 64-bit cryptographic nonce; B replies with a challenge reply, which contains an echo of the cryptographic nonce. If the reply is valid, A overrides its ANM entry with the TS/PC value from the packet containing the challenge reply. We're thinking of encoding the challenge as a sub-TLV of the Ack Request and Reply TLVs, but that's open to discussion. Advantages: - there's no need to wait for ANMTimeout, just a challenge exchange; - the receiver can expire its ANM entry at any time, at the cost of issuing a new challenge (packet loss can be avoided by issuing the challenge slightly before the ANM entry expires); - we avoid bloating IHUs with TS/PC echos, which makes it possible to use a larger TS/PC (e.g. to make it unpredictable by inserting randomness in the low-order bits). Disadvantages: - slightly more complicated implementation, since the challenge is stateful; - occasional packet loss while a challenge is in progress. I rather like it, so we're probably going to start the implementation. Please object now rather than later. -- Juliusz From nobody Tue Jun 26 09:24:55 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE64B1310DF for ; Tue, 26 Jun 2018 09:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kapsi.fi 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 T2ZLeQquhhs2 for ; Tue, 26 Jun 2018 09:24:46 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (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 D0C181310D5 for ; Tue, 26 Jun 2018 09:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=H1Z95QVcRAJWl4DXtsn12fjqe4E8b6ASPzXiCe14NVE=; b=U/D5DF6K8+kuf7BLfQLb1G8g9cCW5SxcwktkLQ4MgDQA2ZBiTojMFxw0MbYn61cFILZTnHkjy7LH4vG8bcKotDPMDoq3esJUclAzdLCLENBWllQNxs0Fw0IAlJ4+P+URv+BWr9Q2u6raRN38p89XDVB+FzkY+6Gp0bwMRDNJxjmAi0VQLBp6YKYvURVuGg3jzJVydY0Y5hjaVezc7QjP2U39amZCKchxiM2fq2m4x/3KlbxiLv614KN+qmkfHRg0dy9YOe6rJZ1djKjzyXYXZi6ymNHwi21hKfVflXmTuPJajQrE3N1BRUOs+Sr0/fLBjK2kcRH/WRtmWDsU5XFoXA==; Received: from 91-155-69-32.elisa-laajakaista.fi ([91.155.69.32] helo=poro.lan) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fXqll-0006dp-3y; Tue, 26 Jun 2018 19:24:41 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Markus Stenberg In-Reply-To: <87in65rdl1.wl-jch@irif.fr> Date: Tue, 26 Jun 2018 19:24:40 +0300 Cc: babel@ietf.org, =?utf-8?B?Q2xhcmEgRMO0?= , =?utf-8?Q?Weronika_Ko=C5=82odziejak?= , Denis Ovsienko Content-Transfer-Encoding: quoted-printable Message-Id: <7D5ACD36-0D7B-4F7C-AC09-43370DFBD0BC@iki.fi> References: <87in65rdl1.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.8.2) X-SA-Exim-Connect-IP: 91.155.69.32 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] HMAC authentication: remove TS/PC echo, use a cryptographic handshake X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 16:24:54 -0000 Disclaimer: Currently mildly sick :-)=20 On 26 Jun 2018, at 14.28, Juliusz Chroboczek wrote: > We propose to drop the TS/PC Echo mechanism and use a cryptographic > handshake instead. When a node A receives a packet from a node B, it > consults its ANM table for the right TS/PC, just like in RFC 7298. If > there is no ANM entry, or if the received TS/PC is invalid, it sends > a challenge with a 64-bit cryptographic nonce; B replies with a = challenge > reply, which contains an echo of the cryptographic nonce. If the = reply > is valid, A overrides its ANM entry with the TS/PC value from the = packet > containing the challenge reply. Seems like an elegant solution. > We're thinking of encoding the challenge as a sub-TLV of the Ack = Request > and Reply TLVs, but that=E2=80=99s open to discussion. Not sure if I am that keen of that, but I would have to think bit more = to comment on it more. > Advantages: >=20 > - there's no need to wait for ANMTimeout, just a challenge exchange; > - the receiver can expire its ANM entry at any time, at the cost of > issuing a new challenge (packet loss can be avoided by issuing the > challenge slightly before the ANM entry expires); > - we avoid bloating IHUs with TS/PC echos, which makes it possible to = use > a larger TS/PC (e.g. to make it unpredictable by inserting = randomness > in the low-order bits). Given the presence of a challenge-response mechanism, I am not sure you = really need larger space. Quite the opposite really due to requiring the = handshake to create the initial ANM entry.=20 Of course, you can stick the nonce in to start/end of =E2=80=99new = TS/PC=E2=80=99 but I would probably rather not transmit it in every = packet on the wire but only in e.g. initial challenge-response step and = after that assume it to be part of the ANM table entry. e.g. -> who are you? nonce=3DX <- I am Y! [nonce .]mynonce . hash-with-key(nonce,mynonce) .. <- stuff . counter . hash-with-key(mynonce . counter . pseudoheader . = stuff) counter on the wire could just be e.g. 16 bits, and mynonce arbitrarily = large (but probably e.g. 64 bits with reasonable randomness would be = enough). > Disadvantages: >=20 > - slightly more complicated implementation, since the challenge is = stateful; > - occasional packet loss while a challenge is in progress. >=20 > I rather like it, so we're probably going to start the implementation. > Please object now rather than later. Bit of a strawman proposal but in general I like the idea, usually it is = muuch easier to stick in challenge-response to prevent replay attacks = than do it fully passively when there is no time/nvram available. Cheers, -Markus= From nobody Tue Jun 26 09:40:01 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D2113109A; Tue, 26 Jun 2018 09:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHrtFYAs1aDK; Tue, 26 Jun 2018 09:39:56 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 CD7DF131068; Tue, 26 Jun 2018 09:39:56 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id q4-v6so16576956iob.2; Tue, 26 Jun 2018 09:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=5EvmORqD6vtGXWNV/QtAoE2OLLBnzv3JiBlWxtvhF1g=; b=RC/e/XSh8+tgPxA65RyeoHaIDkFEtSQyVyyMkpfU9IC2H+lY+0wyGKk0d2Lh98doBG XXh00iN+AYzJI9MVzGiMW1TvtO+iR/USzehOByE8hLWH6wAFg9WeOQ7lguOVnQV6/PNb ugFC4pTHi6yN28TlRkyZj6QK96UcV8zIkKVZZrunsjM8+QZFdIHjqNr9Czfd3Yf5vclw Fgm3+qD1/MtQekZ5zmLkQ1U7e+opn7GrTNSgEOj4QxacQ9pxF/EALjkfB1ZU9qL6CA+v M+wxh7f3u3j6IJkHzEH9rwGMiTa0QJZKtvCSLMtKsYmPgkyPnWxZCOOVre29Spb+cwLQ UneQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=5EvmORqD6vtGXWNV/QtAoE2OLLBnzv3JiBlWxtvhF1g=; b=NsZxFEE24vzfpNgskkRAjZcMw0PL9zGbjvhwF7r/A8GuLzqgs+0BJSTw61PMf13t+B 7YsgB45HMNeWxQud8Zc3V3vAU7/sznQHd0t0kcUvPLljfKPU2oBsRXsyyWzYfcNLvRcy whGxMRjIdDVBD2pihRLrS4BIOa+BIVmntEowb0TxMSSWGk1ofIDqEwNpBOgiw3nuJi6p r1bN5QIp3UI7Y3Y/QkERvLh7P4mM+TaILN4EwWgmRgueZXXSLViqEIw3oFHHswfdQDTS egld3aQm1+zZeK64N7P0JYVwJZxu9VMM0ouGnE4YAR6j5uq5hVCn3ECWxb2JGy1qHOMd bFEg== X-Gm-Message-State: APt69E3E87NnY2Iv9f0+FAthwb9RlZG2r/9qF8cu1af9WAp4j5aVXgIo DGp4ee8+033W3C9y9u7BHMCmOb84SvMalCq0ZRv5Vw== X-Google-Smtp-Source: AAOMgpe2m2YrrsPt5YHQO4dJZeid3S1G8/TRNySyo6yXa+CybUR1oTmKZ/mMiNkHlu3IRYGytfdgJVJObz/Y9EhIKEc= X-Received: by 2002:a6b:ed11:: with SMTP id n17-v6mr1928200iog.132.1530031196021; Tue, 26 Jun 2018 09:39:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bf84:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 09:39:40 -0700 (PDT) From: Donald Eastlake Date: Tue, 26 Jun 2018 12:39:40 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000ef29fe056f8e2502" Archived-At: Subject: [babel] Consensus Determined for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 16:39:59 -0000 --000000000000ef29fe056f8e2502 Content-Type: text/plain; charset="UTF-8" Hi, Based on the responses that have been received and on the prior discussion on the mailing list, the Babel Charter Update below is determined to have WG consensus. Thanks, Donald and Russ ---------- Forwarded message ---------- From: Donald Eastlake Date: Sun, Jun 17, 2018 at 10:56 AM Subject: Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) To: Babel at IETF Cc: babel-chairs@ietf.org Hi, Based on the recent discussion on the mailing list, we are asking for comments in favor or opposed to the following change in the Babel WG Charter to remove the specification of a YANG model as a gating factor in moving the Babel protocol to standards track. You can also suggest further changes but to maximize the chances of getting a change approved it might be best to minimize the changes. OLD: - Address manageability of Babel by producing a Babel informational model to help provide guidance and derive the data models. To be consistent with the ongoing effort to use YANG data modules in the Routing Area, a Babel YANG data model to support management of home gateway routers is required as part of moving Babel to Proposed Standard. This information model is useful as a common source of information for the case where the Customer-Premise Equipment (CPE) is managed by the Service Provider (SP) with the Broadband Forum TR-069 protocol and its associated data model. NEW: - Address manageability of Babel by producing a Babel informational model to help provide guidance and derive the data models. This information model is useful as a common source of information for the case where the Customer-Premise Equipment (CPE) is managed by the Service Provider (SP) with the Broadband Forum TR-069 protocol and its associated data model. To be consistent with the ongoing effort to use YANG data modules in the Routing Area, a Babel YANG data model should be specified to support management of Babel routers. The full current Babel WG Charter is at https://datatracker.ietf.org/doc/charter-ietf-babel/ Thanks, Donald and Russ --000000000000ef29fe056f8e2502 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Based on the responses that have be= en received and on the prior discussion on the mailing list, the Babel Char= ter Update below is determined to have WG consensus.

Thanks,
Donald and Russ

---------- Forwarded message ----------
F= rom: Donald Eastlake &l= t;d3e3e3@gmail.com>
Date: Sun, Jun 17, 2018 at 10:56 AM
Subject: Consensus C= all for Babel Charter Update (2018-06-17 to 2018-06-25)
To: Babel at IET= F <babel@ietf.org>
Cc: bab= el-chairs@ietf.org


Hi,

Based on the recent discussion on the mailing list, we are asking for
comments in favor or opposed to the following change in the Babel WG
Charter to remove the specification of a YANG model as a gating factor
in moving the Babel protocol to standards track. You can also suggest
further changes but to maximize the chances of getting a change
approved it might be best to minimize the changes.

OLD:
- Address manageability of Babel by producing a Babel informational
model to help provide guidance and derive the data models. To be
consistent with the ongoing effort to use YANG data modules in the
Routing Area, a Babel YANG data model to support management of home
gateway routers is required as part of moving Babel to Proposed
Standard. This information model is useful as a common source of
information for the case where the Customer-Premise Equipment (CPE) is
managed by the Service Provider (SP) with the Broadband Forum TR-069
protocol and its associated data model.

NEW:
- Address manageability of Babel by producing a Babel informational
model to help provide guidance and derive the data models. This
information model is useful as a common source of information for the
case where the Customer-Premise Equipment (CPE) is managed by the
Service Provider (SP) with the Broadband Forum TR-069 protocol and its
associated data model. To be consistent with the ongoing effort to use
YANG data modules in the Routing Area, a Babel YANG data model should
be specified to support management of Babel routers.

The full current Babel WG Charter is at
https://datatracker.ietf.org/doc/charter-ie= tf-babel/

Thanks,
Donald and Russ

--000000000000ef29fe056f8e2502-- From nobody Tue Jun 26 09:49:02 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4531F130EBF for ; Tue, 26 Jun 2018 09:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrlUCXa6DIjo for ; Tue, 26 Jun 2018 09:48:58 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 B4905130E20 for ; Tue, 26 Jun 2018 09:48:58 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id l19-v6so16595952ioj.5 for ; Tue, 26 Jun 2018 09:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xjld3WnMeslOHSe7LT/LXVbN0aIle3VM5Ek7opCTKks=; b=E1b4wIkCcAqpz8LfkYvWJ9EbYZ+2bWLtYNZWaR0nB7ehn6uIbBNq5llwuWCnZ27DYd LJjyvKYkkB7wGcosR4PWt/EkcuOwDj0z7A3mqIh9qvnfJ3WpijNG2B9/gE1kMYCP4IS1 cmzMpeJpzXNkrNXEHXMero/7cJXj74yt4MWWHTRC/ylS5YztQR8sOggm8UTG73WJUetM mTRZnGcIttzr/GUzROLhXdMsuHfe3Y3EKquSs+FjpaghgNiWRJVtr8364NlbVkjCBbVx zHsCD2x9lRXS3btkLaIpSb7TugCmd8R2WYmC3toFfUkhuj2GHk6TVk+L+gAu3hay+NBo NSnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xjld3WnMeslOHSe7LT/LXVbN0aIle3VM5Ek7opCTKks=; b=fhgRbwrn4UMP5B31f1Ml3xx+Dbh8aEuLwX6FXIq40yYDenub2edYd9BEjOqs5M9UFk cFeo36TMqjbA22jy6bed0hgF7NCxArJWR57d/QLNo23mnlqtobRM63AjVaU6IJTpTO2v puQeHkL5i6aLr8/Cm0D3pyHS94XNqo++y+S+XW1+DVeS//gGcgEnxPZHPcmhGwiP9DB8 T4tKHQFKJybh10g+FVlSUpETipFjmNV23h+9/GiW8xMPYl1JOAu1KMl7WDvb9wD2u62r MPQmiJkbe2MT4oI1vYEB7lqu9ZxoYx42Fz2QQ7fijLxoTmHcosHkuPyPktBJEfdp39Nc HBCA== X-Gm-Message-State: APt69E3sOwKULskMoaIUFvW7qmVL+AjOHMgy9/5+t03PBdfLy/v5aQbP Wu5qmeHQcw0csepfqXd45u/xvpiJ/eeZ+Fg7VJqUCQ== X-Google-Smtp-Source: AAOMgpdYRWOqW/5ljovZiCf6RT2+4H1s1mQmVffBqa3PvoxBhWXNj0oMJ5sW2ZSNb1NwqrtaNFqX23ASN6BxkgKvXdE= X-Received: by 2002:a6b:ed11:: with SMTP id n17-v6mr1952910iog.132.1530031737867; Tue, 26 Jun 2018 09:48:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bf84:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 09:48:42 -0700 (PDT) From: Donald Eastlake Date: Tue, 26 Jun 2018 12:48:42 -0400 Message-ID: To: Babel at IETF Content-Type: multipart/alternative; boundary="0000000000003b15f0056f8e46d3" Archived-At: Subject: [babel] Consensus Determined for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 16:49:00 -0000 --0000000000003b15f0056f8e46d3 Content-Type: text/plain; charset="UTF-8" Hi, Based on the responses that have been received and on the prior discussion on the mailing list, the Babel Charter Update below is determined to have WG consensus. Thanks, Donald and Russ ---------- Forwarded message ---------- From: Donald Eastlake Date: Sun, Jun 17, 2018 at 10:56 AM Subject: Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) To: Babel at IETF Cc: babel-chairs@ietf.org Hi, Based on the recent discussion on the mailing list, we are asking for comments in favor or opposed to the following change in the Babel WG Charter to remove the specification of a YANG model as a gating factor in moving the Babel protocol to standards track. You can also suggest further changes but to maximize the chances of getting a change approved it might be best to minimize the changes. OLD: - Address manageability of Babel by producing a Babel informational model to help provide guidance and derive the data models. To be consistent with the ongoing effort to use YANG data modules in the Routing Area, a Babel YANG data model to support management of home gateway routers is required as part of moving Babel to Proposed Standard. This information model is useful as a common source of information for the case where the Customer-Premise Equipment (CPE) is managed by the Service Provider (SP) with the Broadband Forum TR-069 protocol and its associated data model. NEW: - Address manageability of Babel by producing a Babel informational model to help provide guidance and derive the data models. This information model is useful as a common source of information for the case where the Customer-Premise Equipment (CPE) is managed by the Service Provider (SP) with the Broadband Forum TR-069 protocol and its associated data model. To be consistent with the ongoing effort to use YANG data modules in the Routing Area, a Babel YANG data model should be specified to support management of Babel routers. The full current Babel WG Charter is at https://datatracker.ietf.org/doc/charter-ietf-babel/ Thanks, Donald and Russ --0000000000003b15f0056f8e46d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Based on the responses that have be= en received and on the prior discussion on the mailing list, the Babel Char= ter Update below is determined to have WG consensus.

Thanks,
Donald and Russ

---------- Forwarded message ----------
F= rom: Donald Eastlake &l= t;d3e3e3@gmail.com>
Da= te: Sun, Jun 17, 2018 at 10:56 AM
Subject: Consensus Call for Babel Char= ter Update (2018-06-17 to 2018-06-25)
To: Babel at IETF <babel@ietf.org>
Cc: babel-chairs@ietf.org


Hi,

Based on the recent discussion on the mailing list, we are asking for
comments in favor or opposed to the following change in the Babel WG
Charter to remove the specification of a YANG model as a gating factor
in moving the Babel protocol to standards track. You can also suggest
further changes but to maximize the chances of getting a change
approved it might be best to minimize the changes.

OLD:
- Address manageability of Babel by producing a Babel informational
model to help provide guidance and derive the data models. To be
consistent with the ongoing effort to use YANG data modules in the
Routing Area, a Babel YANG data model to support management of home
gateway routers is required as part of moving Babel to Proposed
Standard. This information model is useful as a common source of
information for the case where the Customer-Premise Equipment (CPE) is
managed by the Service Provider (SP) with the Broadband Forum TR-069
protocol and its associated data model.

NEW:
- Address manageability of Babel by producing a Babel informational
model to help provide guidance and derive the data models. This
information model is useful as a common source of information for the
case where the Customer-Premise Equipment (CPE) is managed by the
Service Provider (SP) with the Broadband Forum TR-069 protocol and its
associated data model. To be consistent with the ongoing effort to use
YANG data modules in the Routing Area, a Babel YANG data model should
be specified to support management of Babel routers.

The full current Babel WG Charter is at
https://datatracker.ietf.org/doc/charter-ie= tf-babel/

Thanks,
Donald and Russ

--0000000000003b15f0056f8e46d3-- From nobody Tue Jun 26 11:32:33 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9B31310CA for ; Tue, 26 Jun 2018 11:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 VdUllZSRwUhE for ; Tue, 26 Jun 2018 11:32:28 -0700 (PDT) Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E9F130E20 for ; Tue, 26 Jun 2018 11:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530037947; x=2393951547; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Y9dhPLXTfm2FyTM02NPlJ3umuAwQo8scIdCQhgIQCTU=; b=mGZs/ZQHMxuD/akmJCjxCfCyqIh8PcVY4U449Fy9/aOCyxYIyC2lKXN+MLcYN9RQ Ng/2e4PbVzsFP31tfyQrZ9HKO/0cUDc8EGkq+nZIn5Hc/ak2evpo4Sqp7oYakVPQ vfqSU46aTXocZjXvAGY6ccUfZa+BJeQ6YpwzCsUabaL6upS1Wc2Wu9ETGNjsI21D EgUGl0KqOGlcE8yrOfrIFmx2jZ9JicYBCgDwM/6woN7Q/o614W23otOXFDEbPz9r Gm+PMxZZd+ll8KgDn9/9o4GXRYg+lw5hNVVzrAne7e+Vc6o+Je/CCpJkE+2Bk5+b bA70UWBxnQVgRUk9Te3zbg==; Received: from relay2.euro.apple.com (relay2.euro.apple.com [17.66.55.12]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id 8C.B1.19483.AB6823B5; Tue, 26 Jun 2018 11:32:27 -0700 (PDT) X-AuditID: 11ab0219-557ff70000004c1b-7d-5b3286b9bfdb Received: from crk-mmpp-sz03.euro.apple.com ( [17.66.12.165]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id 64.19.00572.9B6823B5; Tue, 26 Jun 2018 19:32:25 +0100 (BST) Received: from [17.192.155.180] by crk-mmpp-sz03.euro.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PAY00NE90TW1130@crk-mmpp-sz03.euro.apple.com>; Tue, 26 Jun 2018 19:32:25 +0100 (IST) Sender: dschinazi@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: David Schinazi In-reply-to: <7D5ACD36-0D7B-4F7C-AC09-43370DFBD0BC@iki.fi> Date: Tue, 26 Jun 2018 11:32:19 -0700 Cc: Juliusz Chroboczek , =?utf-8?Q?Weronika_Ko=C5=82odziejak?= , =?utf-8?B?Q2xhcmEgRMO0?= , babel@ietf.org, Denis Ovsienko Content-transfer-encoding: quoted-printable Message-id: References: <87in65rdl1.wl-jch@irif.fr> <7D5ACD36-0D7B-4F7C-AC09-43370DFBD0BC@iki.fi> To: Markus Stenberg X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUi6GTOo7u7zSjaoK1H0WLLom4Wiw2X1zFb zLn1ncVifusyNou9c1ewWHz4dIfVgc1j56y77B5Llvxk8jj8dSGLx+Itbxk9VpzcyObxavpD 9gC2KC6blNSczLLUIn27BK6M5x/YC+4YVHw6c4a5gfGnWhcjB4eEgInE79f2XYxcHEICW5gk lt2azdrFyAkWf7bnDhtEYgWTROORh+wQTgOTRM+eP2BVwgLSEl0X7rKCTGIWUJeYMiUXJMwr YCyxfvNCqJIYib0Hf7KDlLAJaEkcWGMEEuYUsJK4emEfM4jNIqAqsX3qNCaQ8cwCtxklTrxd DtbLLKAt8eTdBVaImTYSnf/fsoHYQgLhEjMbvrOD2CICOhIXPh2EOlpRon/NIbCjJQROsEm0 Xn/OPIFReBbCebOQnDcLyYoFjMyrGIVzEzNzdDPzjEz1EgsKclL1kvNzNzGCImU1k+QOxq+v DQ8xCnAwKvHw3rA3ihZiTSwrrsw9xCjNwaIkzvtxl1i0kEB6YklqdmpqQWpRfFFpTmrxIUYm Dk6pBsbb7z26cibfcXRs3sHSclLvv42zWGfWwbunVa/ceHVg7htZMcHlx0t7qnxmlV+4cWam GfurLRFe3H5C1ad+rFhlK6fx5b26i2yG0OsXc0J9F57nvxqVFdyUcrRgsewi77lt55ZvNn95 ISsz18w9J/zW2cnnjxWwxDbsnqC13FvJb9WTOBeZbV+VWIozEg21mIuKEwG8bCZ6dQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUi6MSzVHdnm1G0wa3NMhZbFnWzWGy4vI7Z Ys6t7ywW81uXsVnsnbuCxeLDpzusDmweO2fdZfdYsuQnk8fhrwtZPBZvecvoseLkRjaPV9Mf sgewRXHZpKTmZJalFunbJXBlPP/AXnDHoOLTmTPMDYw/1boYOTkkBEwknu25w9bFyMUhJLCC SaLxyEN2CKeBSaJnzx9WkCphAWmJrgt3gWwODmYBdYkpU3JBwrwCxhLrNy+EKomR2HvwJztI CZuAlsSBNUYgYU4BK4mrF/Yxg9gsAqoS26dOYwIZzyxwm1HixNvlYL3MAtoST95dYIWYaSPR +f8tG4gtJBAuMbPhOzuILSKgI3Hh00FWiKMVJfrXHGKbwCgwC+GiWUgumoVk6gJG5lWMokWp OYmVRnqppUX5eokFBTmpesn5uZsYwSFuzrOD8dVBw0OMAhyMSjy8KQ1G0UKsiWXFlbmHGCU4 mJVEeI+9NYwW4k1JrKxKLcqPLyrNSS0+xCjNwaIkzjtZiTlaSCA9sSQ1OzW1ILUIJsvEwSnV wLjbdkWTdWnCu6YP3N/m7E0RY/A1nW140/zb6r135pdNWnB4zWutkuuvolIeyIh4HFW051u9 rS1m1c5WywM73rgopAg8jgngPGU067f+/uMlF6/r/5n8e6vhtSsFXBoLllzRFWPM5VqUbeGx WPjjgZJA7uzj1w+lTfn/JSv5pNbLA9cN8lKn7KtRYinOSDTUYi4qTgQAKnsiu20CAAA= Archived-At: Subject: Re: [babel] HMAC authentication: remove TS/PC echo, use a cryptographic handshake X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 18:32:31 -0000 TLDR: I really like this idea, but here be dragons. The security property we need here is to ensure the freshness of the = peer's counter. And that requires MACing the nonce and counter together. Markus' solution, if I'm understanding it correctly, is vulnerable to a = MITM that swaps out the counter in the "I am Y" message because the = counter is not hashed. The Paris proposal solves this problem, because the nonce in the Ack is = in the payload with the counter, ensuring that they're MACed together. It's also critical to not accept a peer's counter until a handshake has = been performed, because otherwise a node that just rebooted would be vulnerable to old replayed packets. But that does mean we have a = bootstrapping problem when two routers first discover each other, since they'll both distrust the other's counter and both send the challenge = AckRequests with nonces - but the current design says we must drop AckRequests that aren't properly MACed, so we never resolve this. We = could allow accepting AckRequests with untrusted counters but still need to verify the hashes because an attacker here could intercept these = messages and replace the counters on the fly. So now we need some code = that specifically recognizes these AckRequests and verifies them differently. = This isn't horrible but in reduces the elegance a bit. That said this = issue is also present with 7298bis, so don't take this as against your = proposal in any way. Just something to think about. Maybe the easiest = solution is to have a new TLV for this that's allowed to be handled when counters = haven't been verified yet. And that new TLV would need to only be = allowed over unicast while we're at it. Another caveat is denial of service, since anyone can cause you to = generate a nonce and request echo, ideally we would want to recommend a way to generate them statelessly, similar to TCP SYN cookies (not sure = if possible here), or ensure that nonces only be generated if the = original packet triggering them was properly MACed, just with an untrusted = counter. Another minor point I'll add about nonces: the recommended security = practice is to use nonces at least half the number of bits of the hash function used, so if we use SHA2-256, that would be 128bits. The spec = should just allow the requester to set an arbitrary nonce length as a TLV or sub-TLV whose length can be 0-255, and the peer should just echo = that entire nonce TLV without stopping to think about the length. Also, once you've successfully challenged a peer, I don't think you need = to expire that or challenge them again as long as packets are increasing and in the replay window. But that requires having a counter space large = enough to accommodate a reasonable replay window. But 32bits might suffice. All that said, I still think this would be easier to implement than = TS/PC echo because you just need to keep track of a nonce and whether = the peer completed the challenge. But I'll have to actually implement to = confirm that... David > On Jun 26, 2018, at 09:24, Markus Stenberg = wrote: >=20 > Disclaimer: Currently mildly sick :-)=20 >=20 > On 26 Jun 2018, at 14.28, Juliusz Chroboczek wrote: >> We propose to drop the TS/PC Echo mechanism and use a cryptographic >> handshake instead. When a node A receives a packet from a node B, it >> consults its ANM table for the right TS/PC, just like in RFC 7298. = If >> there is no ANM entry, or if the received TS/PC is invalid, it sends >> a challenge with a 64-bit cryptographic nonce; B replies with a = challenge >> reply, which contains an echo of the cryptographic nonce. If the = reply >> is valid, A overrides its ANM entry with the TS/PC value from the = packet >> containing the challenge reply. >=20 > Seems like an elegant solution. >=20 >> We're thinking of encoding the challenge as a sub-TLV of the Ack = Request >> and Reply TLVs, but that=E2=80=99s open to discussion. >=20 > Not sure if I am that keen of that, but I would have to think bit more = to comment on it more. >=20 >> Advantages: >>=20 >> - there's no need to wait for ANMTimeout, just a challenge exchange; >> - the receiver can expire its ANM entry at any time, at the cost of >> issuing a new challenge (packet loss can be avoided by issuing the >> challenge slightly before the ANM entry expires); >> - we avoid bloating IHUs with TS/PC echos, which makes it possible to = use >> a larger TS/PC (e.g. to make it unpredictable by inserting = randomness >> in the low-order bits). >=20 > Given the presence of a challenge-response mechanism, I am not sure = you really need larger space. Quite the opposite really due to requiring = the handshake to create the initial ANM entry.=20 >=20 > Of course, you can stick the nonce in to start/end of =E2=80=99new = TS/PC=E2=80=99 but I would probably rather not transmit it in every = packet on the wire but only in e.g. initial challenge-response step and = after that assume it to be part of the ANM table entry. >=20 > e.g. >=20 > -> who are you? nonce=3DX >=20 > <- I am Y! [nonce .]mynonce . hash-with-key(nonce,mynonce) > .. >=20 > <- stuff . counter . hash-with-key(mynonce . counter . pseudoheader . = stuff) >=20 > counter on the wire could just be e.g. 16 bits, and mynonce = arbitrarily large (but probably e.g. 64 bits with reasonable randomness = would be enough). >=20 >> Disadvantages: >>=20 >> - slightly more complicated implementation, since the challenge is = stateful; >> - occasional packet loss while a challenge is in progress. >>=20 >> I rather like it, so we're probably going to start the = implementation. >> Please object now rather than later. >=20 > Bit of a strawman proposal but in general I like the idea, usually it = is muuch easier to stick in challenge-response to prevent replay attacks = than do it fully passively when there is no time/nvram available. >=20 > Cheers, >=20 > -Markus > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Tue Jun 26 13:29:50 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D25130E3A for ; Tue, 26 Jun 2018 13:29:48 -0700 (PDT) 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, 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 opb1lvqgST-h for ; Tue, 26 Jun 2018 13:29:46 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74279130E2C for ; Tue, 26 Jun 2018 13:29:46 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5QKT2T7017219; Tue, 26 Jun 2018 22:29:02 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 19C82EB22E; Tue, 26 Jun 2018 22:29:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Chg8VY7eWqpK; Tue, 26 Jun 2018 22:29:43 +0200 (CEST) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 77DF2EB200; Tue, 26 Jun 2018 22:29:38 +0200 (CEST) Date: Tue, 26 Jun 2018 22:29:38 +0200 Message-ID: <87k1qlp9zh.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: babel@ietf.org, Clara =?ISO-8859-1?Q?D=F4?= , Weronika =?ISO-8859-2?Q?Ko=B3odziejak?= , Denis Ovsienko In-Reply-To: <7D5ACD36-0D7B-4F7C-AC09-43370DFBD0BC@iki.fi> References: <87in65rdl1.wl-jch@irif.fr> <7D5ACD36-0D7B-4F7C-AC09-43370DFBD0BC@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 26 Jun 2018 22:29:02 +0200 (CEST) X-Miltered: at korolev with ID 5B32A20E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B32A20E.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B32A20E.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] HMAC authentication: remove TS/PC echo, use a cryptographic handshake X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 20:29:49 -0000 > Given the presence of a challenge-response mechanism, I am not sure you > really need larger space. Quite the opposite really due to requiring the > handshake to create the initial ANM entry. I'll think it over. > Of course, you can stick the nonce in to start/end of ’new TS/PC’ but > I would probably rather not transmit it in every packet on the wire but > only in e.g. initial challenge-response step and after that assume it to > be part of the ANM table entry. You couldn't even if you wanted to. The TS/PC is chosen by the sender, so it can be the same for all neighbours. The nonce is chosen by the receiver, so it must be per-neighbour, and you don't have space in a Babel packet to send nonces for all neighbours. -> who are you? nonce=X > <- I am Y! [nonce .]mynonce . hash-with-key(nonce,mynonce) > .. > <- stuff . counter . hash-with-key(mynonce . counter . pseudoheader . stuff) Exactly. -- Juliusz From nobody Tue Jun 26 13:37:48 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90604130EA2 for ; Tue, 26 Jun 2018 13:37:46 -0700 (PDT) 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, 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 5ZVmgtJbAHIC for ; Tue, 26 Jun 2018 13:37:45 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D505A130E3D for ; Tue, 26 Jun 2018 13:37:44 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5QKauqe018718; Tue, 26 Jun 2018 22:36:56 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 7DFD2EB200; Tue, 26 Jun 2018 22:37:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id UQs8ky5E3FJa; Tue, 26 Jun 2018 22:37:37 +0200 (CEST) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7FE7AEB27A; Tue, 26 Jun 2018 22:37:37 +0200 (CEST) Date: Tue, 26 Jun 2018 22:37:37 +0200 Message-ID: <87in65p9m6.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Markus Stenberg , Weronika =?ISO-8859-2?Q?Ko?= =?ISO-8859-2?Q?=B3odziejak?= , Clara =?ISO-8859-1?Q?D=F4?= , babel@ietf.org, Denis Ovsienko In-Reply-To: References: <87in65rdl1.wl-jch@irif.fr> <7D5ACD36-0D7B-4F7C-AC09-43370DFBD0BC@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 26 Jun 2018 22:36:56 +0200 (CEST) X-Miltered: at korolev with ID 5B32A3E8.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B32A3E8.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B32A3E8.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] HMAC authentication: remove TS/PC echo, use a cryptographic handshake X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 20:37:47 -0000 > The security property we need here is to ensure the freshness of the > peer's counter. The property that's easy to prove is that we're not vulnerable to replay if all TS/PC are strictly monotonic, e.g. because you have a (monotonic) hardware clock or because you have persistent storage. The other property is that we're not vulnerable to replay if Alice has lost her state and Bob has disappeared from the network (since in that case there's nobody to complete the challenge). We are vulnerable to replay in the case where both Alice and Bob have lost their state, and Chloe has replayable packets that match Bob's initial TS/PC. With the properties above, I believe we're already doing much better than all other multicast HMAC-based protocols. I'll be checking the literature to confirm that over the next days. So : - we're not vulnerable in the "reasonable" cases; - the cases in which we're vulnerable are well understood, which means we can easily write the Security Considerations section. As Markus is prone to say, Bob is your uncle. (I'll answer your other points later, Antonin is telling me that we need to get some work done before the last metro.) -- Juliusz From nobody Tue Jun 26 14:34:26 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD81130E50; Tue, 26 Jun 2018 14:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info 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 cnX2JYCuoHw6; Tue, 26 Jun 2018 14:34:22 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BCBB130E46; Tue, 26 Jun 2018 14:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1530048858; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=503; bh=6Tga0lFWXAa3Q7aaHH4VxiFSjVK4RNDjdRH316jACjQ=; b=kKgj9VnU/pDsVsvFVkTSpR/nNVLJjQbuM5gHi3rrQ9+Kh/Saeo4zBqE2+9SLB4Az XPqiwiJBCJ3mSWoUqKw4NDw60T/FR4GhfyajLRex7Mdvxuytcm7brzYxN1+UGFsslnV mIT4usJ8m0wrqWAK8L9yvxuQ1lYEOeyUCpq0Dw/c= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1530048858617833.7741713911664; Tue, 26 Jun 2018 14:34:18 -0700 (PDT) Date: Tue, 26 Jun 2018 22:34:18 +0100 From: Denis Ovsienko To: "Babel at IETF" , Message-ID: <1643e04c9f8.10030774874779.3627474589557109802@ovsienko.info> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] Consensus Determined for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 21:34:25 -0000 ---- On Tue, 26 Jun 2018 17:39:40 +0100 Donald Eastlake wrote ---- > Hi, > Based on the responses that have been received and on the prior discussion on the mailing list, the Babel Charter Update below is determined to have WG consensus. Hello. Thank you for making this update. For the avoidance of doubt, which specific consensus are the chairs declaring: the consensus to leave the charter intact or the consensus to request the proposed change? -- Denis Ovsienko From nobody Tue Jun 26 16:24:04 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63A4130E69 for ; Tue, 26 Jun 2018 16:24:02 -0700 (PDT) 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, 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 AUxMlBo1ZgTr for ; Tue, 26 Jun 2018 16:24:01 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B47130E5E for ; Tue, 26 Jun 2018 16:24:00 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5QNNDNh011188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 Jun 2018 01:23:13 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w5QNNQ7l030817; Wed, 27 Jun 2018 01:23:26 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 02A6FEB22D; Wed, 27 Jun 2018 01:23:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id DeYB-CHlQ6A2; Wed, 27 Jun 2018 01:23:54 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E1600EB200; Wed, 27 Jun 2018 01:23:53 +0200 (CEST) Date: Wed, 27 Jun 2018 01:23:53 +0200 Message-ID: <874lhp5dyu.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Clara =?ISO-8859-1?Q?D=F4?= , Weronika =?ISO-8859-2?Q?Ko=B3odziejak?= , babel@ietf.org, Denis Ovsienko In-Reply-To: References: <87in65rdl1.wl-jch@irif.fr> <7D5ACD36-0D7B-4F7C-AC09-43370DFBD0BC@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 27 Jun 2018 01:23:13 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 27 Jun 2018 01:23:26 +0200 (CEST) X-Miltered: at korolev with ID 5B32CAE1.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B32CAEE.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B32CAE1.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B32CAEE.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B32CAE1.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B32CAEE.002 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] HMAC authentication: remove TS/PC echo, use a cryptographic handshake X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 23:24:03 -0000 > Another caveat is denial of service, since anyone can cause you to > generate a nonce and request echo, ideally we would want to recommend > a way to generate them statelessly, similar to TCP SYN cookies (not sure > if possible here), or ensure that nonces only be generated if the original > packet triggering them was properly MACed, just with an untrusted counter. That's already the case -- the very first thing we do is to check the HMAC, and if that fails, the packet is silently dropped. I think that's an important property of Denis' protocol, and one that we're trying not to break. Still, it doesn't prevent DoS -- if Chloe has captured Bob's authentic packet with a stale TS/PC, she can multicast it around, and cause everyone to send challenges to Bob. Cookies won't help here, since Bob is still getting spammed by the challenges. > Another minor point I'll add about nonces: the recommended security > practice is to use nonces at least half the number of bits of the hash > function used, so if we use SHA2-256, that would be 128bits. The spec > should just allow the requester to set an arbitrary nonce length as a TLV > or sub-TLV whose length can be 0-255, and the peer should just echo that > entire nonce TLV without stopping to think about the length. Clara, Weronika? > Also, once you've successfully challenged a peer, I don't think you need > to expire that or challenge them again as long as packets are increasing > and in the replay window. Clara, Weronika? -- Juliusz From nobody Tue Jun 26 16:50:07 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8CD130EA3 for ; Tue, 26 Jun 2018 16:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 vpB0-tz-W9ig for ; Tue, 26 Jun 2018 16:50:04 -0700 (PDT) Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206A5130E6E for ; Tue, 26 Jun 2018 16:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530057003; x=2393970603; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HRDVc/xVTLO+q9ll7SHdjzv4CLS9tosPB++sedukFbo=; b=DB1PhhB6iyjhr4h+K9vfCIDDpktGQSjt5+Jh4T8yFEYvA4nJKVZ05hpUtN8J1bdy Su0BvGYHRyn8twfL4st/z2TQS11L3ffuLno6h+/KKFdI0QCybhOMfGV6fhwbtZqJ PLyNMVQZOZxptUvv8iTC1ijnFF8j/7TpcY0j2WTyRKdtfhng3Kpg4MoRehVnjXg2 CYXXzG2xfYxoRu8NxOEeTHWbMC7Y0kV/Ss8asEO9zk1U1BIq3az5p0bXDoBqM4cB PX6dg37QqqN4JACGUVR1UO+AzdOCtc932aDnGF8tTbshZ07BecVRaTzIkdW32YKd m+2aFvjzz7zHWhOQ1QcVPA==; Received: from relay1.euro.apple.com (relay1.euro.apple.com [17.66.55.11]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id 66.45.19483.A21D23B5; Tue, 26 Jun 2018 16:50:03 -0700 (PDT) X-AuditID: 11ab0219-56fff70000004c1b-88-5b32d129f8fe Received: from crk-mmpp-sz04.euro.apple.com (crk-mmpp-sz04.euro.apple.com [17.66.12.168]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay1.euro.apple.com (Symantec Mail Security) with SMTP id 62.CE.23007.921D23B5; Wed, 27 Jun 2018 00:50:01 +0100 (BST) Received: from [17.192.155.180] by crk-mmpp-sz04.euro.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PAY00D2SFJAVQB0@crk-mmpp-sz04.euro.apple.com>; Wed, 27 Jun 2018 00:50:01 +0100 (IST) Sender: dschinazi@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: David Schinazi In-reply-to: <87in65p9m6.wl-jch@irif.fr> Date: Tue, 26 Jun 2018 16:49:56 -0700 Cc: =?utf-8?B?Q2xhcmEgRMO0?= , Markus Stenberg , =?utf-8?Q?Weronika_Ko=C5=82odziejak?= , babel@ietf.org, Denis Ovsienko Content-transfer-encoding: quoted-printable Message-id: References: <87in65rdl1.wl-jch@irif.fr> <7D5ACD36-0D7B-4F7C-AC09-43370DFBD0BC@iki.fi> <87in65p9m6.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUi6GTOrat90Sja4NQDcYsti7pZLDZcXsds MefWdxaL+a3L2Cz2zl3BYvHh0x1WBzaPnbPusnssWfKTyePw14UsHou3vGX0WHFyI5vHq+kP 2QPYorhsUlJzMstSi/TtErgyJq7YyFrwlrniTWtAA2MXcxcjJ4eEgInEurML2boYuTiEBLYw STw8f4gVJrGo5z47ROIIk8Ta5tlMEE4Dk8S/z7fAqoQFpCW6LtwFs5kFtCTW7zzOBGLzChhL rN+8EKomRmLvwZ9Akzg42IBqDqwxAglzCmhIPDjXxA5iswioSqw6cAPsCmaBx4wSz9tuskHM 1JZ48u4CK8RMG4nXfd9YII5Yxiix7v4dRpCEiICKxPJpz9ghzlaU6F9zCGyShMARNokrq+aw T2AUnoXkwFlIDpyFZMkCRuZVjMK5iZk5upl5RqZ6iQUFOal6yfm5mxhBEbOaSXIH49fXhocY BTgYlXh4b9gbRQuxJpYVV+YeYpTmYFES5/24SyxaSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6cU MMQXSUyJfLJMZAe758EQvc0HH/2f94/v2vvZd382BCkzrMhMyigu++Rqv3Dmzd7V/XMvRMae 8HjX3leSadf/uSLaddL2005TtgYZnlGbVFm1YdtCVtPGYibvQ1kVOvzhXR4JJpfCpLaFLngb 42xzrlbf1jFx+tbp/7OuS23eul2x+wljWtbt10osxRmJhlrMRcWJADL3UF95AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUi6MSzQlfzolG0we+VIhZbFnWzWGy4vI7Z Ys6t7ywW81uXsVnsnbuCxeLDpzusDmweO2fdZfdYsuQnk8fhrwtZPBZvecvoseLkRjaPV9Mf sgewRXHZpKTmZJalFunbJXBlTFyxkbXgLXPFm9aABsYu5i5GTg4JAROJRT332bsYuTiEBI4w Saxtns0E4TQwSfz7fIsVpEpYQFqi68JdMJtZQEti/c7jTCA2r4CxxPrNC6FqYiT2HvwJNImD gw2o5sAaI5Awp4CGxINzTewgNouAqsSqAzfYQOYzCzxmlHjedpMNYqa2xJN3F1ghZtpIvO77 xgJxxDJGiXX37zCCJEQEVCSWT3vGDnG2okT/mkNsExgFZiG5aRaSm2YhmbuAkXkVo2hRak5i paFeamlRvl5iQUFOql5yfu4mRnCgm3PvYDy+2/AQowAHoxIPL8Mxo2gh1sSy4srcQ4wSHMxK IrzH3hpGC/GmJFZWpRblxxeV5qQWH2KU5mBREuedrMQcLSSQnliSmp2aWpBaBJNl4uCUamCM +2wl8vH5oS0JZ+z9hFYe+1gcrKX02eei1QSHg9rXXt/6z8/wwLe6gXvG9j/r2SpzH37XFHh5 6F7kRYW9345c0T+94Jj02TUxvupL9OI2aadG/ahgPOjlkbH/WVU553vbk1dUN3etTmFJev7o /aXtr9J/79uYEnfve4XbjgL3NzE8naeDrXPeKrEUZyQaajEXFScCAMVezcdwAgAA Archived-At: Subject: Re: [babel] HMAC authentication: remove TS/PC echo, use a cryptographic handshake X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 23:50:06 -0000 > On Jun 26, 2018, at 13:37, Juliusz Chroboczek wrote: >=20 > We are vulnerable to replay in the case where both Alice and Bob have = lost > their state, and Chloe has replayable packets that match Bob's initial > TS/PC. I think we can solve this vulnerability without making the protocol too = complex so I'd recommend trying to solve all scenarios we can and then make = tradeoffs if there's consensus that solving one case adds unreasonable complexity. David= From nobody Tue Jun 26 16:54:39 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57C4130E6A for ; Tue, 26 Jun 2018 16:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 lmTi7j47XBOG for ; Tue, 26 Jun 2018 16:54:36 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9367130E61 for ; Tue, 26 Jun 2018 16:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530057276; x=2393970876; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ueGB5l/y0JmKuJHD8H3cYqyxs7EvrlvTz8oCUR4+6zQ=; b=1Qo+Kd9dxSdAuXyRqVegD4r/GOMuvHjLPr6+rLKIotajuKcxtmhV3hq9jT5VXS4T IXGVGng1volo5to4OC3dkcI/M+s9/8jShywGdtjej3exA/sMrRJt65pbSFVrG21R aNj2paF6uFkhsIenAqpXjmQLqsph/QJim99x/KtCkm0F9swqucCOErrh8ZtX1Ecu Lk8jXxv/Hr4HSfMSeXa4B5+kPZGwyvZG2+UFbhVyB+n+GyH23QXRGSIAOWrMefeO vQ5KXmV6LrT/U1ZQk1kRyvuqVAkZDetvbDEAgmO6yxxXfOhvb28cjJd37tzFfwHc xpTcLZ3AlNt+4iBkPxI5Fg==; Received: from relay1.euro.apple.com (relay1.euro.apple.com [17.66.55.11]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 66.0C.15050.B32D23B5; Tue, 26 Jun 2018 16:54:36 -0700 (PDT) X-AuditID: 11973e11-a13ff70000003aca-32-5b32d23a66b5 Received: from crk-mmpp-sz04.euro.apple.com (crk-mmpp-sz04.euro.apple.com [17.66.12.168]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay1.euro.apple.com (Symantec Mail Security) with SMTP id 5F.CE.23007.932D23B5; Wed, 27 Jun 2018 00:54:34 +0100 (BST) Received: from [17.192.155.180] by crk-mmpp-sz04.euro.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PAY00LJLFQUIX40@crk-mmpp-sz04.euro.apple.com>; Wed, 27 Jun 2018 00:54:33 +0100 (IST) Sender: dschinazi@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: David Schinazi In-reply-to: <874lhp5dyu.wl-jch@irif.fr> Date: Tue, 26 Jun 2018 16:54:29 -0700 Cc: =?utf-8?B?Q2xhcmEgRMO0?= , =?utf-8?Q?Weronika_Ko=C5=82odziejak?= , babel@ietf.org, Denis Ovsienko Content-transfer-encoding: 7bit Message-id: References: <87in65rdl1.wl-jch@irif.fr> <7D5ACD36-0D7B-4F7C-AC09-43370DFBD0BC@iki.fi> <874lhp5dyu.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUi6GTOrWtzySjaoHebhsWWRd0sFhsur2O2 mHPrO4vF/NZlbBYfPt1hdWD12DnrLrvHkiU/mTwWb3nL6LHi5EY2j1fTH7IHsEZx2aSk5mSW pRbp2yVwZZz+M5+loJuzYl3jIrYGxjnsXYycHBICJhIHG3YwdTFycQgJbGaSuPViOTNM4ueV KWC2kMARJonL/2sgihqYJBZ/mswGkhAWkJbounCXFcRmFtCSWL/zOBOIzStgLLF+80JWiJoY ib0HfwJt4+BgA6o5sMYIJMwpoCHxe9VfRhCbRUBVYvvy2VBjtjNKzF/hCWHLS2xe85YZYqSN RMP+KWwQ9yxjlJjTJQBiiwioSCyf9gzqGUWJ/jWH2EDulBDYwCbx/+sl1gmMwrOQnDcLyXmz kOxYwMi8ilEoNzEzRzczz0gvsaAgJ1UvOT93EyMoLqbbCe5gPL7K6hCjAAejEg+vgZNRtBBr YllxZe4hRmkOFiVx3stTDaOFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MOp1v8913N637nWz owTbpnrriVIfw42usXWI6P1V1ZwZb7X36ToGa63kmrzLOzwmHpCU15HYUpzxbv7e1gL2iAlp //r2NnjmTNX2f/GhMU6zgfmwLN89GyVHw4mMCc3LJn8XeLnvybu44rNXSwM38a7W+DlpJ3OS wkLXUysaAvl9UxQk/lfcVWIpzkg01GIuKk4EAIW0iqtsAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUi6MSzQtfqklG0wfYDLBZbFnWzWGy4vI7Z Ys6t7ywW81uXsVl8+HSH1YHVY+esu+weS5b8ZPJYvOUto8eKkxvZPF5Nf8gewBrFZZOSmpNZ llqkb5fAlXH6z3yWgm7OinWNi9gaGOewdzFyckgImEj8vDKFGcQWEjjCJHH5f00XIxeQ3cAk sfjTZDaQhLCAtETXhbusIDazgJbE+p3HmUBsXgFjifWbF7JC1MRI7D34E2goBwcbUM2BNUYg YU4BDYnfq/4ygtgsAqoS25fPhhqznVFi/gpPCFteYvOat8wQI20kGvZPYYO4ZxmjxJwuARBb REBFYvm0Z1A3K0r0rznENoFRYBaSi2YhuWgWkrELGJlXMYoWpeYkVhrqpZYW5eslFhTkpOol 5+duYgQHtDn3Dsbjuw0PMQpwMCrx8DIcM4oWYk0sK67MPcQowcGsJMJ77K1htBBvSmJlVWpR fnxRaU5q8SFGaQ4WJXHeyUrM0UIC6YklqdmpqQWpRTBZJg5OqQbGLQvVDugWpPjtnxrxqeB/ 27Pa8x7CKQfXLDsffiOE9ePzSdbxH4TqnjSZGW3887ZakpOn9NDl9Ckv3tT/Z6iZY3roL+/n Y9Ja0QdeZmT2rjXubFI4GeE8K2XH02d876ZJuW+e5ljXs+NQ+4P/rm96ajk2VYWdjUvO83jC 9/Ok6XSPCXd+uTYLKbEUZyQaajEXFScCAFwD775kAgAA Archived-At: Subject: Re: [babel] HMAC authentication: remove TS/PC echo, use a cryptographic handshake X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 23:54:38 -0000 > On Jun 26, 2018, at 16:23, Juliusz Chroboczek wrote: > >> Another caveat is denial of service, since anyone can cause you to >> generate a nonce and request echo, ideally we would want to recommend >> a way to generate them statelessly, similar to TCP SYN cookies (not sure >> if possible here), or ensure that nonces only be generated if the original >> packet triggering them was properly MACed, just with an untrusted counter. > > That's already the case -- the very first thing we do is to check the > HMAC, and if that fails, the packet is silently dropped. I think that's > an important property of Denis' protocol, and one that we're trying not to > break. Cool. > Still, it doesn't prevent DoS -- if Chloe has captured Bob's authentic > packet with a stale TS/PC, she can multicast it around, and cause everyone > to send challenges to Bob. Cookies won't help here, since Bob is still > getting spammed by the challenges. You could mitigate this by only allowing one challenge per some multiple of the interval. It's often incredibly hard to entirely solve DoS but we can do our best to mitigate it. David From nobody Tue Jun 26 17:07:34 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89381130EDA; Tue, 26 Jun 2018 17:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjrlHrKJ_mHC; Tue, 26 Jun 2018 17:07:31 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 89A84130E75; Tue, 26 Jun 2018 17:07:31 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id e13-v6so200816iof.6; Tue, 26 Jun 2018 17:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EYb3Xw9PN1uN7aiJTYkd9v5AGHXTs1vLRk3FIcvfQko=; b=FMGtxRSlTnxNB6FE1eaM3oqe/6j6onRhBsnhR6W3BWvhBPgawoauQ8TJBNYfTYofXa w9E6NmyHT9X6Zm3RulTynrINDw97cBpT0m+89ceMIK0OL4o76UNH+023gGGUsZC0DF3i MT83d+MACY2NwnaBq8TyotH94enMfrSQcnh4N+bX73u+x8xJ2ePUf56QunbdID7V2Ovl aCaXuHKjLRCOjg96+M8eig/ZKu2j8l9z2o6/GRFpUMRJvMW/yoVWD4J9afzRjTFvwvrE B9ngSQIkivr8hi44iLzMKH2zmA8mfN+4wmxbEk1DoEFsr4V+/KtgSZ9cyQuAu/+E4FQf 5ZSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EYb3Xw9PN1uN7aiJTYkd9v5AGHXTs1vLRk3FIcvfQko=; b=jcQ4acmPI5s2s7RcmhZfTMz5WIHckvtJ/bR4GjXMl9Mh1KbRrK1xtu34Az/kcTSuEL HNyife8CJPHJDaeodw7fYnNxZB7pTJv9TcnIV5tJB1NyIFExtPsT3ICEmo6r1lwUFHv3 ern7RYlMaANU5MWaLr8X1BzTKmHxD1hlOsl+5VV6zxLdx4WlTmvjZriR1VkyTLAWIwdd ga4XVHYSWMaCybxHyzs0GqdIBs/7tshZy7SB3KmPwXTCkuOJU9cEPhICDg24OzvolFnz RphTOZLsvKwV3OuD5ih1goLLSp6GO1GoYpMw1m8IITB/78vj3e3rfzpfud6jGHWZ0lQQ Cnvw== X-Gm-Message-State: APt69E1s7qQgg8EEidf+qwN5fOLwVJ/aSrgJpn77Te5lX99rnMaytE/X dPxsXhog69Tom/n7YDKZ3+rtvs0WH/E/Fa0DMY5wGg== X-Google-Smtp-Source: AAOMgpcNaYHjhZYs+RL64KX6a9QiPeVEXz0IZ4iqN1KUKQLURJrLQYUu7IetVKPeD+P3NEamFF9F6mX2BpVx6swBtLI= X-Received: by 2002:a6b:ed11:: with SMTP id n17-v6mr3132121iog.132.1530058050722; Tue, 26 Jun 2018 17:07:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bf84:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 17:07:15 -0700 (PDT) In-Reply-To: <1643e04c9f8.10030774874779.3627474589557109802@ovsienko.info> References: <1643e04c9f8.10030774874779.3627474589557109802@ovsienko.info> From: Donald Eastlake Date: Tue, 26 Jun 2018 20:07:15 -0400 Message-ID: To: Denis Ovsienko Cc: Babel at IETF , babel-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000009962e9056f9466c8" Archived-At: Subject: Re: [babel] Consensus Determined for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 00:07:33 -0000 --0000000000009962e9056f9466c8 Content-Type: text/plain; charset="UTF-8" The consensus of the WG is to Update the Charter as indicated. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Jun 26, 2018 at 5:34 PM, Denis Ovsienko wrote: > ---- On Tue, 26 Jun 2018 17:39:40 +0100 Donald Eastlake > wrote ---- > > Hi, > > Based on the responses that have been received and on the prior > discussion on the mailing list, the Babel Charter Update below is > determined to have WG consensus. > > Hello. > > Thank you for making this update. For the avoidance of doubt, which > specific consensus are the chairs declaring: the consensus to leave the > charter intact or the consensus to request the proposed change? > > -- > Denis Ovsienko > > > --0000000000009962e9056f9466c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The consensus of the WG is to Update the Charter as indica= ted.

Thanks,
Donald
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cel= l)
=C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

On Tue, Jun 26, 2018 at 5:34 PM, Denis Ovsie= nko <denis@ovsienko.info> wrote:
=C2=A0---- On Tue, 26 Jun 2018 17:39:40 +0100 Donald Eastlake <= d3e3e3@gmail.com> wrote ---- =C2=A0> Hi,
=C2=A0> Based on the responses that have been received and on the prior = discussion on the mailing list, the Babel Charter Update below is determine= d to have WG consensus.

Hello.

Thank you for making this update. For the avoidance of doubt, which specifi= c consensus are the chairs declaring: the consensus to leave the charter in= tact or the consensus to request the proposed change?

--
=C2=A0 =C2=A0 Denis Ovsienko



--0000000000009962e9056f9466c8-- From nobody Wed Jun 27 03:18:00 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1932130EF7 for ; Wed, 27 Jun 2018 03:17:45 -0700 (PDT) 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, 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 2XSGA65M5PHS for ; Wed, 27 Jun 2018 03:17:43 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B2C5130F86 for ; Wed, 27 Jun 2018 03:17:42 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5RAGuPW018257; Wed, 27 Jun 2018 12:16:56 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 0621BEB22D; Wed, 27 Jun 2018 12:17:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id ZErQMuSkXz8n; Wed, 27 Jun 2018 12:17:37 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D8879EB200; Wed, 27 Jun 2018 12:17:36 +0200 (CEST) Date: Wed, 27 Jun 2018 12:17:36 +0200 Message-ID: <87lgb0v8hr.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Clara =?ISO-8859-1?Q?D=F4?= , Markus Stenberg , Weronika =?ISO-8859-2?Q?Ko=B3odziejak?= , babel@ietf.org, Denis Ovsienko In-Reply-To: References: <87in65rdl1.wl-jch@irif.fr> <7D5ACD36-0D7B-4F7C-AC09-43370DFBD0BC@iki.fi> <87in65p9m6.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 27 Jun 2018 12:16:56 +0200 (CEST) X-Miltered: at korolev with ID 5B336418.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B336418.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B336418.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] HMAC authentication: remove TS/PC echo, use a cryptographic handshake X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 10:17:59 -0000 >> We are vulnerable to replay in the case where both Alice and Bob have lost >> their state, and Chloe has replayable packets that match Bob's initial >> TS/PC. > I think we can solve this vulnerability without making the protocol too > complex We spent a few hours yesterday puzzling over it (together with Florian Horn and Paul Rozière, to whom thanks), and failed. > I'd recommend trying to solve all scenarios we can and then make > tradeoffs if there's consensus that solving one case adds unreasonable > complexity. I believe we're already doing better than RFC 7182, which would imply that the existing security properties are good enough for a Standards Track protocol. We've got very little time left (my funding ends this Friday, and it's up to the ladies whether they wish to continue working on the project after their internship ends), but I hope we'll be able to document precisely the conditions under which the protocol is known to be secure. -- Juliusz From nobody Wed Jun 27 03:25:17 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA45C130E90 for ; Wed, 27 Jun 2018 03:25:15 -0700 (PDT) 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, 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 Q1TKFksIMf4h for ; Wed, 27 Jun 2018 03:25:14 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECBD6130E52 for ; Wed, 27 Jun 2018 03:25:13 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5RAOUs1026945; Wed, 27 Jun 2018 12:24:30 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id CFB9AEB22E; Wed, 27 Jun 2018 12:25:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id sVulxWecWQ4B; Wed, 27 Jun 2018 12:25:10 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id CB844EB200; Wed, 27 Jun 2018 12:25:10 +0200 (CEST) Date: Wed, 27 Jun 2018 12:25:10 +0200 Message-ID: <87k1qkv855.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: Weronika =?ISO-8859-2?Q?Ko=B3odziejak?= , Clara =?ISO-8859-1?Q?D=F4?= , babel@ietf.org, Denis Ovsienko In-Reply-To: <7D5ACD36-0D7B-4F7C-AC09-43370DFBD0BC@iki.fi> References: <87in65rdl1.wl-jch@irif.fr> <7D5ACD36-0D7B-4F7C-AC09-43370DFBD0BC@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 27 Jun 2018 12:24:30 +0200 (CEST) X-Miltered: at korolev with ID 5B3365DE.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B3365DE.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B3365DE.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] HMAC authentication: remove TS/PC echo, use a cryptographic handshake X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 10:25:16 -0000 > Given the presence of a challenge-response mechanism, I am not sure you > really need larger space. Quite the opposite really due to requiring the > handshake to create the initial ANM entry. I'm not sure. The protocol is vulnerable to replay whenever the TS/PC decreases, or, if you prefer, the protocol expects TS/PC to be strictly monotonic but provides a mechanism for gracefully recovering from a TS/PC discontinuity, at the cost of a vulnerability to replay. Implementations are strongly encouraged to make heroic efforts to make sure that the TS/PC remains strictly increasing. =46rom an implementation point of view, that's easier if you have enough space in the TS/PC to encode a timestamp or a reboot counter. Still, 48 bits is plenty -- it's enough for 32 bits seconds timestamp + 16 bits packet counter, or 24 bits reboot counter + 24 bits packet counter. 32 bits seems a little short. I'm tempted to make it 64 bits and be done with it, but I'm fine with 48 bi= ts. -- Juliusz From nobody Wed Jun 27 05:03:07 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84EE127148; Wed, 27 Jun 2018 05:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info 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 2L9XMJ3Dx53T; Wed, 27 Jun 2018 05:03:03 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0915A1277C8; Wed, 27 Jun 2018 05:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1530100970; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=881; bh=inATtiUXyNhnNWWyBY3L6pQehYd+B/JiZovCP6Edfyk=; b=zcW+i4quTliG6KEb95l3QWFEt8mGZimuEqxLqITqrDVLCfZC5A3CkldlOeM/O3+y FkkqpkwzNszWgGYH7tDzMgVYQTSHQFExy3JmyO76EW2k14ILTXIAx2fxC1G02I/Sboe khWzEqz0rChcNpT5kO/zlZOdY4QOk+G3/D/xkRRo= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1530100970769824.6539231721723; Wed, 27 Jun 2018 05:02:50 -0700 (PDT) Date: Wed, 27 Jun 2018 13:02:50 +0100 From: Denis Ovsienko To: , "\"Babel at IETF\"" Message-ID: <164411ff50e.b5e8fd6c21486.4668430685875145605@ovsienko.info> In-Reply-To: References: <1643e04c9f8.10030774874779.3627474589557109802@ovsienko.info> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] Consensus Determined for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 12:03:05 -0000 ---- On Wed, 27 Jun 2018 01:07:15 +0100 Donald Eastlake wrote ---- > The consensus of the WG is to Update the Charter as indicated. Thank you for the clarification Donald. I believe it is right to leave a record on the Babel WG mailing list with the summary of this consensus call, as far as it looked from my point of view: * I had provided an objection to the suggested change and explained the grounds for my position. * Other working group members had voted in support of the suggested change, none bothered to explain their grounds, even when explicitly prompted. * I had explained that there was no consensus, that voting is not the IETF way of reaching rough consensus, and provided supporting reference to RFC 7282. * The chairs left the objection unaddressed and had declared the situation a consensus. Cheers. -- Denis Ovsienko From nobody Wed Jun 27 05:39:34 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEDE127598 for ; Wed, 27 Jun 2018 05:39:32 -0700 (PDT) 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, 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 atc2IDFoIFY9 for ; Wed, 27 Jun 2018 05:39:31 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E35F126CC7 for ; Wed, 27 Jun 2018 05:39:30 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5RCclSP010883 for ; Wed, 27 Jun 2018 14:38:47 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id CC87EEB22E for ; Wed, 27 Jun 2018 14:39:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id gl5ExEY3A-7Y for ; Wed, 27 Jun 2018 14:39:27 +0200 (CEST) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id AAD0EEB22D for ; Wed, 27 Jun 2018 14:39:27 +0200 (CEST) Date: Wed, 27 Jun 2018 14:39:27 +0200 Message-ID: <87muvgh08w.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 27 Jun 2018 14:38:47 +0200 (CEST) X-Miltered: at korolev with ID 5B338557.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B338557.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B338557.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 12:39:33 -0000 Dear all, I think I've just solved the replay problem in a provably correct manner. I've run the protocol through Clara and Weronika, and they didn't object, please double-check. HMAC is left unchanged -- all packets are protected by HMAC, and a packet is immediately dropped if the HMAC check fails. The main idea is that we now have two nonces -- the sender's nonce and the receiver's nonce. The sender's nonce is chosen by the sender, is the same for all receivers, and is sent in each packet. The receiver's nonce is per receiver-sender pair, and is only used in a challenge. Replay protection is achieved by drawing a new sender's nonce whenever the sender cannot guarantee monotonicity of the packet counter. Packet format ============= Packet counter -------------- Instead of TS/PC, we have a simple packet counter that can be reset at any time; it carries the sender's nonce: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD | Length | PC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's Nonce... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- The packet counter is a simple per-interface counter, it starts at 0 and is incremented every time a packet is sent (unicast or multicast). Whenever the sender resets the counter (either because it is restarted or because the packet counter overflows), it generates a new, unique Sender's Nonce. As suggested by David, the Sender's Nonce is of arbitrary length (up to 251 octets). Challenge and challenge reply ----------------------------- A challenge contains the receiver's nonce. The challenge reply contains an echo of the receiver's nonce. We haven't decided the exact format yet -- should it be a separate TLV, a sub-TLV of Hello/IHU, or a sub-TLV of Ack Request and Ack Reply. As suggested by David, the Receiver's Nonce is of arbitrary length (up to 255 octets, eek, inconsistend with the Sender's Nonce.). Protocol operation ================== Bob is the sender. When he boots, he picks a sufficiently large Sender's Nonce for each interface, and initialises its per-interface packet counter to 0. Whenever he sends a packet, he includes a PC TLV with the interface's packet counter and nonce, protects the packet with HMAC, and ships it out. Alice is the receiver. She maintains a per-neighbour table of (sender's nonce, PC). When she receives a packet from Bob: - if there's no information about Bob, she drops Bob's packet and sends a challenge; - if there's information about Bob, the Sender's Nonces match and the PC is strictly increasing, the packet is accepted; - if there's information about Bob, and either the Nonces mismatch or the PC has decreased, she drops the packet and sends a challenge. Protocol properties =================== We haven't worked on the proof yet, but I'm confident that the protocol is provably invulnerable to replay. There's one obvious property: Property 1: a given Nonce/PC pair is never reused This is due to Bob generating a new Nonce whenever he cannot guarantee strict monotonicity of the PC. Implementability ================ Implementation is simpler for a reason: both the sender and the receiver can force a challenge at any time; thus, the sender may lose its Packet Counter and the receiver may lose its per-peer counter, and the cost is just one extra challenge. Consequences: - there is no need for a persistent packet counter or a hardware clock; - there is no need for a persistent ANM; - the use of an ANM becomes optional -- a simple implementation may choose to keep the per-peer packet counter in the Neighbour Table, at the cost of an extra challenge at each mobility event. The only requirement is a cryptographic PRNG, which is something we may reasonably assume to be present even in small routers. Does that sound like a plan? -- Juliusz From nobody Wed Jun 27 05:49:49 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FCC127598 for ; Wed, 27 Jun 2018 05:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=kapsi.fi 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 OKklzdG3h4eG for ; Wed, 27 Jun 2018 05:49:44 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (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 90F37126CC7 for ; Wed, 27 Jun 2018 05:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=rYNhuj2O0Sq7vLFk13uRn75VtEBeHuV0xodN5859KSo=; b=pTq4RmIyVHjR517yfIjWPrRBoB4krHeYEEfTcWThNhLnpGlq0B4llLfAJDCNSEu68Lr6Nl+oooR7MvrqRx4Cot34jqZPVnCJFvRWMvDzXddvE+J4Xt8v03xdvRGvx1ZXKxiInUMXM5UHD7M/eNPrQ/vygMCSnLS+i06rPPoVMQFK5IxvVOztlkJKCM3/cwEZouBi4alqgSCp768j6XEdEO31NaBR/CJZEWDVc29kZfDEHKbDRzHXuCNAzguodOo1CwMtmGewsa01ra6XIpS8+lhobWHdR+yJtWaP16AwU+n3WrWQ82D8xig0sEqtBhw4W1lVywfr/OUMwMrPVTSr6A==; Received: from [194.100.69.221] (helo=[172.20.21.37]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fY9tF-0007Z7-St; Wed, 27 Jun 2018 15:49:41 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Markus Stenberg In-Reply-To: <87muvgh08w.wl-jch@irif.fr> Date: Wed, 27 Jun 2018 15:49:41 +0300 Cc: babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <87muvgh08w.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.8.2) X-SA-Exim-Connect-IP: 194.100.69.221 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 12:49:47 -0000 I thought this is what I tried to describe but apparently not in enough = detail (nonce =3D receiver=E2=80=99s nonce, mynonce =3D sender=E2=80=99s = nonce).=20 Anyway, you don=E2=80=99t really need to send either of the nonces = except in challenges, if you use them in pseudoheader otherwise. If hmac = fails due to wrong nonce in pseudoheader, you can do challenge (or not, = for DoS protection). > The only requirement is a cryptographic PRNG, which is something we = may > reasonably assume to be present even in small routers. _or_ semi-working RTC. -Markus From nobody Wed Jun 27 06:11:26 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA604130DD8 for ; Wed, 27 Jun 2018 06:11:20 -0700 (PDT) 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, 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 zhUxHzVfBfrJ for ; Wed, 27 Jun 2018 06:11:18 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A7A130DCD for ; Wed, 27 Jun 2018 06:11:17 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5RDAXBM026323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 Jun 2018 15:10:33 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w5RDAksO025375; Wed, 27 Jun 2018 15:10:46 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id E97ADEB22D; Wed, 27 Jun 2018 15:11:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id I8cyXvL9buiv; Wed, 27 Jun 2018 15:11:13 +0200 (CEST) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 42997EB200; Wed, 27 Jun 2018 15:11:10 +0200 (CEST) Date: Wed, 27 Jun 2018 15:11:10 +0200 Message-ID: <87k1qkgys1.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: babel@ietf.org In-Reply-To: References: <87muvgh08w.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 27 Jun 2018 15:10:33 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 27 Jun 2018 15:10:46 +0200 (CEST) X-Miltered: at korolev with ID 5B338CC9.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B338CD6.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B338CC9.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B338CD6.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B338CC9.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B338CD6.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 13:11:24 -0000 > I thought this is what I tried to describe but apparently not in enough > detail (nonce = receiver’s nonce, mynonce = sender’s nonce). So either your mail worked on my unconscious, or great minds meet ;-) Sorry for not realising that earlier. > Anyway, you don’t really need to send either of the nonces except in > challenges, if you use them in pseudoheader otherwise. If hmac fails due > to wrong nonce in pseudoheader, you can do challenge (or not, for DoS > protection). Interesting idea. How do you suggest we decide when to challenge? >> The only requirement is a cryptographic PRNG, which is something we may >> reasonably assume to be present even in small routers. > _or_ semi-working RTC. Uh-huh. (The nonces don't need to be truly random, just never reused.) -- Juliusz From nobody Wed Jun 27 06:12:21 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F125112D7F8; Wed, 27 Jun 2018 06:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkke4wT7Bp3V; Wed, 27 Jun 2018 06:12:17 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75421277C8; Wed, 27 Jun 2018 06:12:17 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id p17-v6so2407473itc.2; Wed, 27 Jun 2018 06:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4bhY9okVmZmNx3h7ZabV0UD3tn4Nyjl3o5t/DJEvzOo=; b=r1Fl0IN9YbPMQF1MivtfI7gxVL+7V8bMhAhj/xWcWmFMpFB6zQK1mq7qvhQjjs2MVh q4sBEg9hFUf4xJP8lgrbqC+khQNaDXEDT/fqSPBpXMILYuQj0v84+2jkOqgEfMewxweg 3FYmwKgqJosC9oogb67A2bA9lpkjKY/+9VXyay+1C5bjdDHaw/7lSl4V6onkZYIIg1Bs VqlqA/9/Ab3QnDFZCd25vLIOO9BLiOwvUqFKiFz5zDQ5Rcwp1lPAqvY0mue/ZuaEMJth 3t+IvvhVLB6+uBLePfcBm8/DX9AREpj2UK4vUvbGgHQ1rZft+gpAmsHjVYp7ATLTNu6X lVxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4bhY9okVmZmNx3h7ZabV0UD3tn4Nyjl3o5t/DJEvzOo=; b=JkUD6zmTwmQFbqb4U3SwbOjpULkdvUZ1X0MrLRvZKmtNDBabHGoFMC7DjYLWbG9qa8 twSNsSUacajpPyyhAUFPc58XaLzyniS+cRoKhjqabfm+2aS+J+WUYhUPIiopoo0EWbdl bPYMqSXXsRa5u9M3wZnyb1tNYs0dE4dLnVuBSGfk6DExB6UEwKG9pjJBxp6dO8ld9TB8 DWm6M4ZWzJnSLMRpXdD+7wtftXsYF7+4AajKcxcl0R5eQ/fS94C6qfBoyFGyPD9hiLfw /v2/68YfrcsGR3NHVY6qi9e2Hnprv4ob95hbjQJ+R5ishd6ZDLWUZ4ECOFImAFm0ie3v Xz+A== X-Gm-Message-State: APt69E13QzCn4ZmzkwFC5iHavv/CtqXA97VfuKimWV5aeHx68ZA8cCb+ 1C/OoaB9k1bAUxRc9yWz8W8OONgXZBjdsgRHCo4= X-Google-Smtp-Source: AAOMgpfr1YdsplM+UXoeXnXGkRfxEo5gvHMmSEN1pNVkktoTFDdSvBPGBB4zbWFv3UrBzFmBOv4q5r+vOZWQsu7mAXo= X-Received: by 2002:a24:c054:: with SMTP id u81-v6mr4671485itf.94.1530105136848; Wed, 27 Jun 2018 06:12:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bf84:0:0:0:0:0 with HTTP; Wed, 27 Jun 2018 06:12:01 -0700 (PDT) In-Reply-To: <164411ff50e.b5e8fd6c21486.4668430685875145605@ovsienko.info> References: <1643e04c9f8.10030774874779.3627474589557109802@ovsienko.info> <164411ff50e.b5e8fd6c21486.4668430685875145605@ovsienko.info> From: Donald Eastlake Date: Wed, 27 Jun 2018 09:12:01 -0400 Message-ID: To: Denis Ovsienko Cc: babel-chairs@ietf.org, Babel at IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] Consensus Determined for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 13:12:19 -0000 Hi Denis, On Wed, Jun 27, 2018 at 8:02 AM, Denis Ovsienko wrote: > > ---- On Wed, 27 Jun 2018 01:07:15 +0100 Donald Eastlake wrote ---- > > The consensus of the WG is to Update the Charter as indicated. > > Thank you for the clarification Donald. > > I believe it is right to leave a record on the Babel WG mailing list with the summary of this consensus call, as far as it looked from my point of view: > > * I had provided an objection to the suggested change and explained the grounds for my position. > * Other working group members had voted in support of the suggested change, none bothered to explain their grounds, even when explicitly prompted. I believe there has been ample discussion of the need for the change on the WG mailing list, frequently by the same persons who indicated they supported the change. In determining WG consensus, the chairs are entitled to take into account such discussions. In fact, the IETF rules do not require a consensus call (or WG Last Call for a draft) to determine consensus. If the chair(s) of a WG are convinced there is consensus for some draft or position based on the WG discussions, they are entitled to declare consensus without a last call or consensus call. > * I had explained that there was no consensus, that voting is not the IETF way of reaching rough consensus, and provided supporting reference to RFC 7282. I note that in your point further above, you say "voted". Perhaps it would be better to say "indicated support" or the like. Also, in an earlier message, you stated that you were a "member" of the Babel WG. IETF WGs do not have members or a defined membership. The term usually used is "participant". > * The chairs left the objection unaddressed and had declared the situation a consensus. I responded to your earlier objection message and will respond to your more recent objection message later today. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Cheers. > > -- > Denis Ovsienko > > From nobody Wed Jun 27 06:28:27 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484C4130DC5 for ; Wed, 27 Jun 2018 06:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=kapsi.fi 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 t15ej_Dq0Do5 for ; Wed, 27 Jun 2018 06:28:24 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (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 1D328130DC0 for ; Wed, 27 Jun 2018 06:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=JD9qIXDCVp8M6EvqRZVN8ncy8va+KibqcHGK8KZLgnA=; b=uRZ3ph4kQFlE4p1ng/1GpIkIKIIHTX8gIL9YIxk0aYAibmK+4fZ9X0c+QLQ+9oXR761kRiiK++5263O8VYGFTLnwloWtlDcGKNh8aTeZUBrWMYnG6+beDddOJaCaCHlAOZXCszgpmTOPrjy3W6RnOtzLtlnnQmf3qH8Nj9DpB9YQqO9ujZatZSvd/1LhCnN3O+2qh4SEksjZTVbxrXtEkftgZfLB/tgqv6Y52fsUc7QOCTWOgMRbB8uKClon9bMF5MYIPq7GOUX+UW7KZBPrF69z5rMT9I7vE4XGIOXieh5wz7hGRSpDiUTP6+1Y0GZzVhPD0zKsCsx14ACijq3zew==; Received: from [194.100.69.221] (helo=[172.20.21.37]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fYAUg-00087v-H1; Wed, 27 Jun 2018 16:28:22 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Markus Stenberg In-Reply-To: <87k1qkgys1.wl-jch@irif.fr> Date: Wed, 27 Jun 2018 16:28:21 +0300 Cc: babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.8.2) X-SA-Exim-Connect-IP: 194.100.69.221 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 13:28:25 -0000 On 27 Jun 2018, at 16.11, Juliusz Chroboczek wrote: > So either your mail worked on my unconscious, or great minds meet ;-) > Sorry for not realising that earlier. No prob, as I said, sick so not neccessarily too lucid emails. >> Anyway, you don=E2=80=99t really need to send either of the nonces = except in >> challenges, if you use them in pseudoheader otherwise. If hmac fails = due >> to wrong nonce in pseudoheader, you can do challenge (or not, for DoS >> protection). > Interesting idea. How do you suggest we decide when to challenge? If hmac fails (and we feel we=E2=80=99re not participating in a DoS by = doing it too often). The sender nonce should be part of hmac in the = pseudoheader. If it changes, challenge is warranted. -Markus= From nobody Wed Jun 27 07:05:32 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD84A130DC8 for ; Wed, 27 Jun 2018 07:05:30 -0700 (PDT) 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, 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 U_X25uVkcVxR for ; Wed, 27 Jun 2018 07:05:29 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89C71294D7 for ; Wed, 27 Jun 2018 07:05:28 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5RE4jVD023431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 Jun 2018 16:04:45 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w5RE4vYQ014309; Wed, 27 Jun 2018 16:04:57 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 18916EB22D; Wed, 27 Jun 2018 16:05:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id ybwR_R_Zm4PN; Wed, 27 Jun 2018 16:05:20 +0200 (CEST) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 577CEEB913; Wed, 27 Jun 2018 16:05:20 +0200 (CEST) Date: Wed, 27 Jun 2018 16:05:20 +0200 Message-ID: <87fu18gw9r.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: babel@ietf.org In-Reply-To: <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 27 Jun 2018 16:04:45 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 27 Jun 2018 16:04:58 +0200 (CEST) X-Miltered: at korolev with ID 5B33997D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B339989.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B33997D.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B339989.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B33997D.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B339989.002 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 14:05:31 -0000 >> So either your mail worked on my unconscious, or great minds meet ;-) >> Sorry for not realising that earlier. > No prob, as I said, sick so not neccessarily too lucid emails. It was obviously your idea, I just didn't understand it at the time, it clicked during the night. Full credit where credit is due. >>> Anyway, you don’t really need to send either of the nonces except in >>> challenges, if you use them in pseudoheader otherwise. If hmac fails due >>> to wrong nonce in pseudoheader, you can do challenge (or not, for DoS >>> protection). We've spoken among ourselves, and we're agreed -- we'll do that. > If hmac fails (and we feel we’re not participating in a DoS by doing it > too often). The sender nonce should be part of hmac in the > pseudoheader. If it changes, challenge is warranted. So challenge on failed HMAC, with rate limiting? That's definitely doable. Please let us know if you have any further suggestions. -- Juliusz From nobody Wed Jun 27 10:10:33 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2F0130DFF for ; Wed, 27 Jun 2018 10:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 nEiXcAYuI62b for ; Wed, 27 Jun 2018 10:10:30 -0700 (PDT) Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AFB7130DFE for ; Wed, 27 Jun 2018 10:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530119429; x=2394033029; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=g/kDJPz4spO5yeCoFamev93LmNlE0Klhsv8weELxsVg=; b=w0ZgTqM4i1mWfEQeUuJpuGlk4eww1f3rfi+SWuTn0ywmiA0nCJh2tY84DDASkThs 3ygJGoPbaHtAoINnlqjsZqKa6lJmb92P8O754c3gTJ+xA3RxwxQddqUOaW2Vzp8Z PSXxfSI3xB7L/KCOZ0U8dsVxV9Y01avFhfjVxTNbwtjWOjUJXI+/otNGVwJfkpp/ kCInzKCQu+QJk8SkLtIuOvVr5lvvjNrW8ouvuOYd5OS8Fkxz/OJ8xqJxyPRhSM3G TT7lh9V0Hn0B6ykrFPYUzmydounKoX56VktH2E0mArrmuxERreYiauiSOjJtwWVA tGk6mfiGBHKTq96tmZ9BUA==; X-AuditID: 11ab0219-557ff70000004c1b-2b-5b33c505676c Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id AD.F9.19483.505C33B5; Wed, 27 Jun 2018 10:10:29 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PAZ00L6PRPHQ0D0@ma1-mtap-s02.corp.apple.com>; Wed, 27 Jun 2018 10:10:29 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PAZ00A00R3P9X00@nwk-mmpp-sz09.apple.com>; Wed, 27 Jun 2018 10:10:29 -0700 (PDT) X-Va-A: X-Va-T-CD: d59661a006d810078864a2b5ec0f053f X-Va-E-CD: 56381c10423255a02021214fe2be34ab X-Va-R-CD: 51b264366a03f3713579e9c13de44bee X-Va-CD: 0 X-Va-ID: 8fd07047-d3a5-43b4-94fb-09375d00c144 X-V-A: X-V-T-CD: 7d6566e1ce32e60bd701207e1252a9a5 X-V-E-CD: 56381c10423255a02021214fe2be34ab X-V-R-CD: 51b264366a03f3713579e9c13de44bee X-V-CD: 0 X-V-ID: 529991d2-040e-4cdf-91df-d51280f1665e Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PAZ00H00RMBJU00@nwk-mmpp-sz09.apple.com>; Wed, 27 Jun 2018 10:10:29 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-27_04:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp14.corp.apple.com-10000_instance1 Received: from [17.234.38.243] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PAZ00GCMRPF5G60@nwk-mmpp-sz09.apple.com>; Wed, 27 Jun 2018 10:10:28 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87fu18gw9r.wl-jch@irif.fr> Date: Wed, 27 Jun 2018 10:10:26 -0700 Cc: Markus Stenberg , babel@ietf.org Message-id: <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUiqOHDpst61Dja4MZ0I4sti7pZLOa3LmOz 2Dt3BYsDs8eSJT+ZPA5/XcjisXjLW8YA5igum5TUnMyy1CJ9uwSujEUn/7EWHGKv6Lx2jq2B 8QdrFyMnh4SAicSXB+fZuxi5OIQE9jNJLNv9BSzBKyAo8WPyPZYuRg4OZgF5iYPnZUHCzAJa Et8ftbJA1G9gkmhu+cwI4XQxSZyfNJUZYiq7xJ9fO1ggbG2Jg3eWscLY3+5MZ4Sxd+4/BVXD JbFg62moGl2JE29PQNWwSaw/sYQJwtaSeLr9OSuM3TnzD1x8UsNJqDmcEue/TGSHsHUkriy7 xwZiCwl0MknsbXCCiGdLnFjeAHVnsMTJdY3sEDVfGSXu7E0CsYUFpCW6LtxlhbAtJe7NXMQM Cgg2oF0H1hiBhDkFNCTO/rsAFmYRUJX4eJwVEj42Ev8mtDBDgtBGYtXcHczQsGWUWP31LFhC REBFYvm0Z+wTGBVnIQX1LERQz0IK6gWMzKsYhXMTM3N0M/OMTPUSCwpyUvWS83M3MYKSxGom yR2MX18bHmIU4GBU4uEN6DKOFmJNLCuuzD3EKM3BoiTO+3GXWLSQQHpiSWp2ampBalF8UWlO avEhRiYOTqkGxiaX5wy3HO+nnf4aLnCY7zRTdW/JIpZJoq7dC7/03HWtfMHK/Cs2d+H53rth X71ebL/U66vDntbyt+KiBWtr4ywZrVbbZ+fLKyZOvlNkP1fhVEPiIs2t86q397P+jTrEtdf+ 01pm1zOmJUWxj2T5lpvLBUrsfmXx1FyWVU3tROfmv1Vy0z94KbEUZyQaajEXFScCAA2pTCbz AgAA Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 17:10:33 -0000 I'm that sure this addresses my earlier concern. Let's say Alice and Bob are brand new routers and join the network for the first time. They have no information about each other, so we follow this path: > - if there's no information about Bob, she drops Bob's packet and sends > a challenge; - Bob sends Hello - Alice has no information about Bob, Alice drops Bob's Hello and sends a Challenge - Bob doesn't have information about Alice, so Bob drops Alice's challenge instead of responding. How do they get into a state where they accept the challenge? I feel I'm missing something here, can someone walk me through it? Also, my first instinct is to be against the nonce in pseudo-header, because that requires us to challenge on failed HMAC, which means an attacker can now cause DoS traffic without even needing to have observed packets to replay. Anyway, I haven't had my morning coffee yet so I might be confused. David From nobody Wed Jun 27 12:44:34 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951F61292F1; Wed, 27 Jun 2018 12:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qw0FSOACOrCP; Wed, 27 Jun 2018 12:44:30 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981D4130E14; Wed, 27 Jun 2018 12:44:30 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id p17-v6so4178731itc.2; Wed, 27 Jun 2018 12:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=m4SkXZRInFYn4dPImSXrCX97LtbZ9ROk/iRZy8F3cY8=; b=MYKl14F8aJ0swzCZ1i+ft6NRvwRfiLAalgtRrlK9SOMSN2PlH9S6nOJLiGL/K7BT8N pUq01K1j670OqASQy4XLs0nP5L0bUsRWfQuhhJa+6ayEQpJSyIBMo3C76FfiUbAWvgOH 3DbZTd9pE+zAnCSXyUAqBuLe5YP3Asy2PkSUjx7Js5c9u4QehwGFl6z7i93b1ndDto+D Bsc2ZxzNdyYV6T/oXVgw2ykkw9l5e/aGTtH0NoTPqvY9143lQmBjntZA3HVTe8zxiSs1 FPJmfKMWpfLeM7bjZCpEfboGcEdj70sVU8v8sie0Q1ndFgsjzSt/Upuq6pXXOqNZwYBX +ssg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=m4SkXZRInFYn4dPImSXrCX97LtbZ9ROk/iRZy8F3cY8=; b=GZVXYzElSnXQdXCd8H2L1xbnnNWQT2yr0luu3hRGA+Eqo6R9gJMX66Zt3uML1ZAv2d +AfA3WucNZ1bT8jwx3FlpEjLd/G3QB+I4cdorkwqrDjI3LxUhvW8cXXlDokz+ZMMqvUG dnd1y8xhzjufLthcF5qHRaPwkddYqNig+GuHAtR/IEiuKWYe4bJtgMV5eilL7zYl7unY 98wsO8Rb2oUOBSld2a6k6rkjOgVvUQukVnJkfCq4MMHV8vgm7mrXdbnUr9lNDiX1sVxy sCLkznc6pQbp6k0++PObXAPOSuIM27FAgswp3fB2r+pjS1qfY+GoSQXecs8CR1RRHJR+ sk5w== X-Gm-Message-State: APt69E3DGgBPV3p8GvSV6ZzVLsJRU6CzbqkURTrCG0cXZeV4v02PcckL IftjpUYE/BdD79/t6jwgv7ow+gXk6ciewjqLsT4= X-Google-Smtp-Source: AAOMgpcmGlIIzg+RsvQAZqCLdU2gyM5pBPUHYduufGUyzLncxkcUQ/35Hhh2KLPNfCXp4V70QZ8r7rGnpC9wJcBNHGw= X-Received: by 2002:a24:1155:: with SMTP id 82-v6mr5806129itf.59.1530128669808; Wed, 27 Jun 2018 12:44:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bf84:0:0:0:0:0 with HTTP; Wed, 27 Jun 2018 12:44:14 -0700 (PDT) In-Reply-To: <1641dd2ca78.c00b97523761.4967171539240276911@ovsienko.info> References: <1640f31963d.e3da2ad4319526.4149190004246054001@ovsienko.info> <1641dd2ca78.c00b97523761.4967171539240276911@ovsienko.info> From: Donald Eastlake Date: Wed, 27 Jun 2018 15:44:14 -0400 Message-ID: To: Denis Ovsienko Cc: babel-chairs@ietf.org, Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 19:44:33 -0000 Hi Denis, On Wed, Jun 20, 2018 at 11:31 AM, Denis Ovsienko wrot= e: > Thank you for your comments Donald, please see my questions and comments = below. > > ---- On Mon, 18 Jun 2018 15:27:51 +0100 Donald Eastlake wrote ---- > > Hi Denis, > > > > Thanks for your comments. > > > > On Sun, Jun 17, 2018 at 3:21 PM, Denis Ovsienko = wrote: > > > > ... > > > > > > Hello all. > > > > > > I oppose the proposed change for the following reasons. > > > > > > First, the fault is not in the charter. As my previous message to th= e list discusses, it looks like we (the working group as a whole) have negl= ected some meaningful parts of our charter: "Particular emphasis will be pl= aced on work needed for a Proposed Standard routing protocol, such as ensur= ing manageability and strong security." We have achieved exactly the opposi= te so far, and it would be fair to fix first what is actually broken (speci= fic suggestions are in that message). > > > > This Charter change is about process and gating, not about ultimate > > goals. There is substantial work on manageability in the Information > > Model and we do have a volunteer to do a preliminary YANG model. The > > problem is the interlock in the current Charter between the YANG model > > and the base protocol getting to Proposed Standard status and the > > normative dependency on Babel in the HOMENT WG. > > I am sorry, but the only way I can read the above is it begins saying it = is not about ultimate goals, and then says Proposed Standard is an ultimate= goal and justifies bending the rules. Can you see it from this point of vi= ew? No, I don't see that. There is no rule being bent. The Charter is something specified by the IESG, the IESG can change it, and the WG can ask the IESG to change it. Standards track status for Babel was and remains a goal. Manageability for Babel was and remain a goal. > The _intentional_ dependency on YANG has been in the charter for 2 years,= but only now it suddenly became a "problem", do you agree it looks strange= enough to deserve a proper explanation? No, I do not agree. Perhaps everyone should always keep the WG Charter details in mind but many IETF participants, even WG Officers, sometimes overlook those details. And the longer it has been since the WG was Chartered, the more memory of those details may fade although, of course, they are still documented in writing in the Charter itself. And the longer it has been since the WG was Chartered, the more likely it is that circumstances have changed so that an adjustment to the Charter is called for. So I do not think it is strange that the "problem" is noticed now. Let me give an example of people missing something in a Charter, although it is a little embarrassing. When I took over as Chair of the PPPEXT WG, Jim Carlson had long been the Chair. At the time, a draft targeted for Proposed Standard was going through the WG, was found to have WG consensus, and forwarded to the IESG. The only problem with this was that the PPPEXT Charter said that the purpose of the WG was only to review documents related to PPP and that the PPPEXT WG was specifically prohibited from producing any new documents. :-) Neither Jim Carlson, who had been Chair for years, nor myself who had taken over had noticed this. In fact, the Area Director for the WG didn't notice this either and went ahead and issued an IETF Last Call on the draft before this problem was noticed by another IESG member. (The IESG solved the problem in this case by treating the document as if it was not a WG document and re-issuing the IETF Last Call for the required longer period of time.) > > > Second, de-rating of the requirements level should mean de-rating of= the publication category. If the working group explicitly finds itself una= ble to produce a quality YANG deliverable in time, it could _potentially_ (= if the charter allowed it) capture its core (6126bis + whatever security) d= eliverables as IETF Experimental publications, take a break and retain the = motivation to have YANG eventually done and aim for Proposed Standard. But = neither the current charter nor the proposed change take this into account. > > > > The entire thrust of this WG effort is to move Babel to the Standards > > Track and any change from that would be a major change for which I > > have not seen any support except your message. > > Standards Track work indeed has been the IETF's expectation of this worki= ng group. This was a reasonable initial expectation based on the way the pr= e-IETF work was presented at the IETF. That said, if the actual in-IETF res= ults were as good as expected, there would not be this call and this discus= sion in the first place, do you agree? I do not agree. Whether results are "good" or not is a judgement call. Whether or not there is a YANG model is a factor some people would include in such a judgement. But there are many other factors. > I agree the proportional de-rating would be a major change to the charter= . However, just writing deliverables off with no consequences would be a ma= jor change too, and in addition to that it would be difficult to distinguis= h from just gaming the Standards Track process. Does one of the evils look = significantly less than the other? > > I agree 8 people on the list have voted to support the charter change so = far, and I am the only one who has objected so far. Notwithstanding the fac= t, I believe this working group does not yet have valid grounds to declare = consensus on this call and to ask to change the charter. The matter is, you= r message that starts this call asks for _comments_. This is indeed a valid= way to start a consensus process, and it is not a warrant to reduce it to = a voting. To emphasize the difference, let me quote this: > > "We reject kings, presidents and voting. We believe in rough consensus an= d running code." > > One of the reasons I decided to join the IETF in 2016 was I knew what thi= s saying is intended to mean -- long before that I had read RFC 7282 (On Co= nsensus and Humming in the IETF). The document explains in detail why oppos= ing a majority of _votes_ with a reasoned _objection_ in a call for _consen= sus_ is a normal IETF approach and it should not be questioned or dismissed= . Specifically, it tells why the situation with this call is _not_ a consen= sus (and what could be done to try to achieve it). You are entitled to your opinion that this Charter change is not a good idea and that either Charter should not be changed or, if it is changed as indicated, the based Babel draft should re-cycle at Experimental. However, that is not the consensus of the WG. Any objection can be written up at great length and with many reasons as to why it is a good objection. This does not mean that one person can just block progress by writing up their objection that way. RFC 7282 applies only to technical objections and we are discussing process here. I'd be willing to say that a minority or one person who point to a significant violation of process rules can stop something even if many are in favor of it. But there is no process rules violation in asking the IESG to make this minor Charter change. That's not just my opinion but we have an explicit post by our AD stating it. > To sum my position up, the right thing to do would be either to leave the= charter intact or to ask for proportional de-rating on both sides of the d= eal like suggested, in either case the working group should keep to the int= ended IETF methods of work. I am willing to address any comments regarding = my input to this consensus call. "Experimental" is not a de-rating of "Proposed Standard". They are different things for different purposes. I do not think the WG is going outside of "intended IETF methods of work". I'm sorry you are not happy but I do not see a reason to revisit the determination that the WG consensus is in favor of the Charter change. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Thank you. > > -- > Denis Ovsienko From nobody Wed Jun 27 14:16:51 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F6F130E33; Wed, 27 Jun 2018 14:16:48 -0700 (PDT) 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, 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 pz5JznTcNOqv; Wed, 27 Jun 2018 14:16:45 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A799124BE5; Wed, 27 Jun 2018 14:16:45 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5RLG1jE021051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 Jun 2018 23:16:01 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w5RLGELY014091; Wed, 27 Jun 2018 23:16:14 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 8D348EB22E; Wed, 27 Jun 2018 23:16:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 7ZW6rl1YFj_6; Wed, 27 Jun 2018 23:16:41 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 16EADEB22D; Wed, 27 Jun 2018 23:16:39 +0200 (CEST) Date: Wed, 27 Jun 2018 23:16:38 +0200 Message-ID: <87vaa43p6x.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko Cc: , "\"Babel at IETF\"" In-Reply-To: <164411ff50e.b5e8fd6c21486.4668430685875145605@ovsienko.info> References: <1643e04c9f8.10030774874779.3627474589557109802@ovsienko.info> <164411ff50e.b5e8fd6c21486.4668430685875145605@ovsienko.info> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 27 Jun 2018 23:16:01 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 27 Jun 2018 23:16:14 +0200 (CEST) X-Miltered: at korolev with ID 5B33FE91.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B33FE9E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B33FE91.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B33FE9E.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B33FE91.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B33FE9E.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Consensus Determined for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 21:16:49 -0000 > I believe it is right to leave a record on the Babel WG mailing list > with the summary of this consensus call, as far as it looked from my > point of view: These are personal opinions presented as facts. I don't think it is entirely honest to present personal opinions as if they were facts. -- Juliusz From nobody Wed Jun 27 14:19:04 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD02A130E2A for ; Wed, 27 Jun 2018 14:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 MEQkLRYeuRxs for ; Wed, 27 Jun 2018 14:19:01 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A45124BE5 for ; Wed, 27 Jun 2018 14:19:00 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1530134339; bh=AoZkGPEKWNM00wClB4ANMrctT5effIMnHdBPxwUp30s=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=oofGf2E68LWhePnohTMtR5UUavQ/TYipJihsSnumKWXgfG3VrgbzzFhJp6f+5yJpR 4dlebbKhCgj/JPZOFECmnHmu2XTNq+RZwfJTXp65jlNxa2BaDgZHLLKQTtM0f8NH8R LcNpr1Ojo5NV3Mo+QMnMNK2Q2Xx1FcyNCSzEDpLiyo0pyj108lPraXTPmBTV3SKm6b k0boACDjoqboDs1I9Nz8OtMD/mNpV3MImu/NqUVdrZB9EZv4lSqFbbhByGnOKrebSU 7LRMF4nRW549fvIe2DGGvpKArH2//C56b2fquHjH54VKLesqH8LGVW4qn75LVJlSLB 9a6Q6W7f99PXQ== To: David Schinazi , Juliusz Chroboczek Cc: Markus Stenberg , babel@ietf.org In-Reply-To: <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> Date: Wed, 27 Jun 2018 23:19:01 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87in64kjwa.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 21:19:03 -0000 David Schinazi writes: > I'm that sure this addresses my earlier concern. > > Let's say Alice and Bob are brand new routers and join the network for the first time. > > They have no information about each other, so we follow this path: > >> - if there's no information about Bob, she drops Bob's packet and sends >> a challenge; > > > - Bob sends Hello > - Alice has no information about Bob, Alice drops Bob's Hello and sends a Challenge > - Bob doesn't have information about Alice, so Bob drops Alice's challenge instead of responding. > > How do they get into a state where they accept the challenge? > I feel I'm missing something here, can someone walk me through it? Presumably the challenge TLV will need to be the only TLV in that packet (or, depending on the encoding, that packet will only contain HMAC-related TLVs), in which case it can be treated as a distinct case and challenges can be replied to (as long as the HMAC is valid). > Also, my first instinct is to be against the nonce in pseudo-header, > because that requires us to challenge on failed HMAC, which means an > attacker can now cause DoS traffic without even needing to have > observed packets to replay. I don't think raising the bar for DoS to 'has to sniff a packet off the network' is really worth putting a lot of effort into. If we are going to protect against DoS, we need another mechanism anyway, such as the rate limiting Juliusz and Markus was discussing. > Anyway, I haven't had my morning coffee yet so I might be confused. Emailing before coffee? How very brave of you ;) -Toke From nobody Wed Jun 27 14:35:41 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA28130E36 for ; Wed, 27 Jun 2018 14:35:39 -0700 (PDT) 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, 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 UP0Sxv6OjYgd for ; Wed, 27 Jun 2018 14:35:38 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 783A7130E3A for ; Wed, 27 Jun 2018 14:35:37 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5RLYoGL025834; Wed, 27 Jun 2018 23:34:50 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id B79B3EB200; Wed, 27 Jun 2018 23:35:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 5p54eQtzCUo8; Wed, 27 Jun 2018 23:35:30 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A19EEEB27A; Wed, 27 Jun 2018 23:35:30 +0200 (CEST) Date: Wed, 27 Jun 2018 23:35:30 +0200 Message-ID: <87po0b52vx.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Markus Stenberg , babel@ietf.org In-Reply-To: <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 27 Jun 2018 23:34:50 +0200 (CEST) X-Miltered: at korolev with ID 5B3402FA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B3402FA.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B3402FA.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 21:35:40 -0000 > Let's say Alice and Bob are brand new routers and join the network for > the first time. > They have no information about each other, so we follow this path: >> - if there's no information about Bob, she drops Bob's packet and sends >> a challenge; > - Bob sends Hello > - Alice has no information about Bob, Alice drops Bob's Hello and sends > a Challenge > - Bob doesn't have information about Alice, so Bob drops Alice's > challenge instead of responding. Noted. We'll think some more. (Toke, just because I'm not answering doesn't mean we're not listening.) > Also, my first instinct is to be against the nonce in pseudo-header, > because that requires us to challenge on failed HMAC, which means an > attacker can now cause DoS traffic without even needing to have observed > packets to replay. The DoS attack is pretty trivial in either case -- you just need to capture one packet and wait until its PC becomes obsolete. I'm not sure you're gaining much by encoding the nonce explicitly, I'd like to know why you think otherwise. -- Juliusz From nobody Wed Jun 27 15:05:25 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2751130E2E for ; Wed, 27 Jun 2018 15:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 TNjOSENRhLuE for ; Wed, 27 Jun 2018 15:05:22 -0700 (PDT) Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33481124BE5 for ; Wed, 27 Jun 2018 15:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530137121; x=2394050721; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Zgjq5Sa27rRoHlp3mUE9+kM+ZpBN/aUCUN8TDapnI0M=; b=uPkNIYhmFg3xUXH/2oSQdyoJwOrrwDpSvXrBlECYLceZvXRpOFwo7OvWuwCF73O7 Jcqf+ID+Lqn5dYDBSpp2W1b+4uMDynrG/Wb+BObbALqEhSHRwGs6sLCfFsffi+Ba rJDN3h2g3vgSVU1WRJSVGKWv6XuctPLsFdk4461Hm1jYQMzY5r9D/HkN6xgXtl5b S3WJZfEV51Sk4H5+zp///cUQ07Oe2l32GmDxeKF/SOG6eRU/lF6TjjeoviBXcTdR fHn5PxJpxC+VhTSv7Q/xS9JLrs/URb7/DlivOR82cnBIcK2obTaaA/oQuXTHL68P luKCDpZFnmTFtSTaUyab1A==; X-AuditID: 11ab0219-a862c9e000004c1b-ea-5b340a218dce Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in25.apple.com (Apple Secure Mail Relay) with SMTP id 47.C9.19483.12A043B5; Wed, 27 Jun 2018 15:05:21 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PB0002445CVV060@ma1-mtap-s02.corp.apple.com>; Wed, 27 Jun 2018 15:05:20 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB0008004GTS700@nwk-mmpp-sz10.apple.com>; Wed, 27 Jun 2018 15:05:19 -0700 (PDT) X-Va-A: X-Va-T-CD: d59661a006d810078864a2b5ec0f053f X-Va-E-CD: 56381c10423255a02021214fe2be34ab X-Va-R-CD: 51b264366a03f3713579e9c13de44bee X-Va-CD: 0 X-Va-ID: cd0a4868-a5f7-4c77-9270-5cce6b5aad57 X-V-A: X-V-T-CD: 7d6566e1ce32e60bd701207e1252a9a5 X-V-E-CD: 56381c10423255a02021214fe2be34ab X-V-R-CD: 51b264366a03f3713579e9c13de44bee X-V-CD: 0 X-V-ID: 4cf6c9e3-6a1f-49d8-be1d-ad7e6d1a2860 Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB000F0050J5U00@nwk-mmpp-sz10.apple.com>; Wed, 27 Jun 2018 15:05:18 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-27_07:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp17.corp.apple.com-10000_instance1 Received: from [17.234.125.237] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PB000I8R5CS1500@nwk-mmpp-sz10.apple.com>; Wed, 27 Jun 2018 15:05:18 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87po0b52vx.wl-jch@irif.fr> Date: Wed, 27 Jun 2018 15:05:15 -0700 Cc: Markus Stenberg , babel@ietf.org Message-id: References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUiqOHDpqvIZRJt8PKJkMWWRd0sFvNbl7FZ 7J27gsWB2WPJkp9MHoe/LmTxWLzlLWMAcxSXTUpqTmZZapG+XQJXxo0D+1kKjnBVrDn7iqmB cStHFyMnh4SAicT6C08Yuxi5OIQE9jNJfDj7iQUkwSsgKPFj8j0gm4ODWUBe4uB5WZAws4CW xPdHrWAlQgIbmSQ29WVA9HYxSZw7Pp8ZYii7xJ9fO1ggbG2Jg3eWscLY3+5MZ4Sxd+4/BVXD JbFg62moGl2J5VfWskHYbBLrTyxhgrC1JJ5uf84KY3fO/AMXn9RwEmoOp8T5LxPZIWwdiYlT z7BAHNfJJHHwwGuoxdkSW+bugSoKlng4oQ3q+2+MEpcfXwXbICwgLdF14S6UbSlxb+YiZlBI sAFtO7DGCCTMKaAh8fDgS7CZLAKqEt2XZzNBQshG4t+EFrByXiB72bxaiPF9TBK/Z0BCTkRA RWL5tGfsExgVZyGF9SxEWM9CCusFjMyrGIVzEzNzdDPzjEz1EgsKclL1kvNzNzGC0sRqJskd jF9fGx5iFOBgVOLhDegyjhZiTSwrrsw9xCjNwaIkzvtxl1i0kEB6YklqdmpqQWpRfFFpTmrx IUYmDk4pYErIcBIxcu+zLlkRfOGKSM+1/+sV1vefZ5tUp3A9m6nE9wRPdF9ZrdWF29e8/7jx H97md/SPekeoVZsgv12OT/aTpL1L7n658Hz1z7tGe14sqf7BYL8+UbIn+PA8vRV/M2fe/i32 T4+9w0Ryzfb3nR7K2pPuS13VzE9ut3gsxfpEiH9qMauzlhJLcUaioRZzUXEiAAxhDyT0AgAA Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 22:05:24 -0000 > On Jun 27, 2018, at 14:35, Juliusz Chroboczek wrote: > > Noted. We'll think some more. (Toke, just because I'm not answering > doesn't mean we're not listening.) I agree with Toke's approach - having a separate TLV with different semantics solves the problem. >> Also, my first instinct is to be against the nonce in pseudo-header, >> because that requires us to challenge on failed HMAC, which means an >> attacker can now cause DoS traffic without even needing to have observed >> packets to replay. > > The DoS attack is pretty trivial in either case -- you just need to > capture one packet and wait until its PC becomes obsolete. I'm not sure > you're gaining much by encoding the nonce explicitly, I'd like to know why > you think otherwise. Basically this breaks the property that "any packet without a valid HMAC is silently ignored" and that worries me, as it was a good property to have. Having some data be implicit in the pseudo header can cause issues when peers get out of sync. Whereas an explicit signal allows us to more easily detect problems and send challenges to resync. Note that if my understanding is correct, having a separate TLV for challenges with separate semantics solves all of these problems at once without adding the overhead of a nonce in each packet. David From nobody Wed Jun 27 15:18:03 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF0B130E34 for ; Wed, 27 Jun 2018 15:18:01 -0700 (PDT) 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, 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 QdXYwETPxgKB for ; Wed, 27 Jun 2018 15:18:00 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68257130E2E for ; Wed, 27 Jun 2018 15:18:00 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5RMHDcM002700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 Jun 2018 00:17:13 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w5RMHQri026148; Thu, 28 Jun 2018 00:17:26 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 46FDAEB22D; Thu, 28 Jun 2018 00:17:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id KhGU0Oo8zvZi; Thu, 28 Jun 2018 00:17:54 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 57FDFEB200; Thu, 28 Jun 2018 00:17:54 +0200 (CEST) Date: Thu, 28 Jun 2018 00:17:54 +0200 Message-ID: <87in63an71.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Markus Stenberg , babel@ietf.org In-Reply-To: References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 28 Jun 2018 00:17:13 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 28 Jun 2018 00:17:26 +0200 (CEST) X-Miltered: at korolev with ID 5B340CE9.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B340CF6.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B340CE9.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B340CF6.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B340CE9.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B340CF6.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 22:18:02 -0000 >> The DoS attack is pretty trivial in either case -- you just need to >> capture one packet and wait until its PC becomes obsolete. I'm not sure >> you're gaining much by encoding the nonce explicitly, I'd like to know why >> you think otherwise. > Basically this breaks the property that "any packet without a valid HMAC is > silently ignored" and that worries me, as it was a good property to have. Good point, noted. From nobody Wed Jun 27 15:21:08 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51E4130E39 for ; Wed, 27 Jun 2018 15:21:06 -0700 (PDT) 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, 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 LUal4hfPt64j for ; Wed, 27 Jun 2018 15:21:05 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBEC2130E2E for ; Wed, 27 Jun 2018 15:21:04 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5RMKIjL003314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 Jun 2018 00:20:18 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w5RMKU13026660; Thu, 28 Jun 2018 00:20:30 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A928CEB279; Thu, 28 Jun 2018 00:20:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id pyM75VZDmMeM; Thu, 28 Jun 2018 00:20:57 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B629AEB22E; Thu, 28 Jun 2018 00:20:57 +0200 (CEST) Date: Thu, 28 Jun 2018 00:20:57 +0200 Message-ID: <87fu17an1y.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Markus Stenberg , babel@ietf.org In-Reply-To: <87in63an71.wl-jch@irif.fr> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 28 Jun 2018 00:20:18 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 28 Jun 2018 00:20:31 +0200 (CEST) X-Miltered: at korolev with ID 5B340DA2.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B340DAE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B340DA2.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B340DAE.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B340DA2.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B340DAE.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 22:21:07 -0000 >> Basically this breaks the property that "any packet without a valid HMAC is >> silently ignored" and that worries me, as it was a good property to have. > Good point, noted. So: Property D: a packet is silently ignored after an HMAC failure, and Property M: nonces are not carried in every packet. are both good properties to have. Can we have both? -- Juliusz From nobody Wed Jun 27 16:16:59 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04024130E3B for ; Wed, 27 Jun 2018 16:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 c0qj9-6LNBgo for ; Wed, 27 Jun 2018 16:16:55 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A987130E39 for ; Wed, 27 Jun 2018 16:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530141415; x=2394055015; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5juJ72BfJ7gETcV7MjYlqn7M8fUPcaqoVm2kCby2snQ=; b=aX5RMCzRWvWWCuXeDVtY9viCrtSOM5u9Af4VatbMMBtct7KzOiuoG/lzviCPYUyT t+c/xqozppvu/BTsEsOVYlXB62YjhN1UjClU+fH/mp7fPgMSMJNzqi1kJQ7vMeWo qsvyGYmPGELVVL6HQKLV8mbPX53p7BqA7uYW1lfwEkJFoffYtBpPDXSZm/dCrXLf lrISJrQapcwfm5krxABhZJjiszM3gFKQslIqCIHtWwWS+GFen9xOSGos+0f5U07Y LiIc6VLbaVe2twTK2XPCs+WLlsPPXL64myPLGWU9S79u8cew5/52QH+EO1u4iBHl H3aUw1UVYcy8ccADtGOf6Q==; Received: from relay1.euro.apple.com (relay1.euro.apple.com [17.66.55.11]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 23.7E.09260.6EA143B5; Wed, 27 Jun 2018 16:16:55 -0700 (PDT) X-AuditID: 11973e13-615ff7000000242c-f6-5b341ae57581 Received: from crk-mmpp-sz04.euro.apple.com (crk-mmpp-sz04.euro.apple.com [17.66.12.168]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay1.euro.apple.com (Symantec Mail Security) with SMTP id A7.03.23007.4EA143B5; Thu, 28 Jun 2018 00:16:52 +0100 (BST) Received: from [17.192.155.180] by crk-mmpp-sz04.euro.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PB0008478O13T80@crk-mmpp-sz04.euro.apple.com>; Thu, 28 Jun 2018 00:16:52 +0100 (IST) Sender: dschinazi@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: David Schinazi In-reply-to: <87fu17an1y.wl-jch@irif.fr> Date: Wed, 27 Jun 2018 16:16:48 -0700 Cc: Markus Stenberg , babel@ietf.org Content-transfer-encoding: quoted-printable Message-id: <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUi6GTOrftcyiTa4PoyPosti7pZLOa3LmOz 2Dt3BYsDs8eSJT+ZPA5/XcjisXjLW8YA5igum5TUnMyy1CJ9uwSujLbHt1gKrotVnN+xiL2B sUWoi5GTQ0LAROLuxI8sXYxcHEICm5kkrpx4xwqTuNE2mxUicYRJYvXMJiYIp4FJ4n3PNkaQ KmEBaYmuC3fBOpgFtCTW7zzOBGLzChhLrN+8kBWixlLi3sxFzF2MHBxsQDUH1hiBhDkFNCTO 71jIDGKzCKhKtM0/wQQxxkbi34QWZghbW+LJuwusECNtJCb+mg516W8midcPLrGAJEQEVCSW T3vGDnG1okT/mkNsEPYMNokTfVITGIVnITlvFpLzZiHZsYCReRWjUG5iZo5uZp6pXmJBQU6q XnJ+7iZGUMBPtxPewXh6ldUhRgEORiUe3hU9xtFCrIllxZW5hxilOViUxHk7xEyihQTSE0tS s1NTC1KL4otKc1KLDzEycXBKNTDuWzsn8dSzl8tk2rN6u082SgocSw00r1K/Nb2mLcno8O4Z i+X35jB0X3VXCeMymTgnlq0nbuGWndsS5dYIuevW+854HXDnnIbNRxkvhXvvWpgM95ff0Puu cnVOyqR9888ufHhuyiRuaeUdBub3rNdNKX35cLvKbK77iWe22opcenumOKC9eIGjEktxRqKh FnNRcSIAPPlCL1kCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUi6MSzQveJlEm0wfEnRhZbFnWzWMxvXcZm sXfuChYHZo8lS34yeRz+upDFY/GWt4wBzFFcNimpOZllqUX6dglcGW2Pb7EUXBerOL9jEXsD Y4tQFyMnh4SAicSNttmsXYxcHEICR5gkVs9sYoJwGpgk3vdsYwSpEhaQlui6cJcVxGYW0JJY v/M4E4jNK2AssX7zQlaIGkuJezMXMXcxcnCwAdUcWGMEEuYU0JA4v2MhM4jNIqAq0Tb/BBPE GBuJfxNamCFsbYkn7y6wQoy0kZj4azoLxA2/mSReP7jEApIQEVCRWD7tGTvE1YoS/WsOsU1g FJiF5KRZSE6ahWTuAkbmVYyiRak5iZWGeqmlRfl6iQUFOal6yfm5mxjBwWrOvYPx+G7DQ4wC HIxKPLxGb4yjhVgTy4orcw8xSnAwK4nwStwHCvGmJFZWpRblxxeV5qQWH2KU5mBREuedrMQc LSSQnliSmp2aWpBaBJNl4uCUamCUfrW8wr123iK+6bl1Fzwvn3jfy3Xi4IEiN47ylGvyq/Nb RUt+tkx4vnH23d8q4aEeby/dqq3PmvjH31mCbd1K3g2Z3patOtcKPIUnGspfKY5Wa/dJerGT dc75hPQJj0uZDgfZJmcdT09NOX/p2vfXNy/JPYm6EW5rs1V12/Pri5Xk498t3CeqxFKckWio xVxUnAgAzK7H+lICAAA= Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 23:16:57 -0000 > On Jun 27, 2018, at 15:20, Juliusz Chroboczek wrote: >=20 >>> Basically this breaks the property that "any packet without a valid = HMAC is >>> silently ignored" and that worries me, as it was a good property to = have. >=20 >> Good point, noted. >=20 > So: >=20 > Property D: a packet is silently ignored after an HMAC failure, >=20 > and >=20 > Property M: nonces are not carried in every packet. >=20 > are both good properties to have. Can we have both? I think so, yes. Straw man proposal: We add two new TLVs: ChallengeRequest and ChallengeResponse, which MUST = be sent unicast. Those TLVs are allowed to be parsed if the HMAC validates but the = counter does not. Alice is the receiver. Alice maintains a per-neighbour table of = counters. When Alice receives a packet from Bob: - if HMAC does not validate, Alice drops bob's packet silently - else if Alice has counter information about Bob, and the counter is in = [savedCounter + 1, savedCounter + 256], the packet is accepted and Alice = sets savedCounter(Bob) to the counter from the packet; - else (Alice has no counter information about Bob or Alice has counter = information about Bob and the counter is outside of that range), Alice = parses Challenge TLVs, silently ignores any non-Challenge TLVs in Bob's = packet and sends a challenge (with rate limiting) Only the challenges contain an arbitrary-length opaque nonce. The counter should be 48 or 64 bytes long. - Devices who believe they have reliable monotonically increasing clocks = can use their time as a counter - Devices that can save their counter to disk start at zero and increase = for each packet send - Devices that have neither start off with a random counter then = increment by one for the duration of this boot. The security for those = devices depends on how much entropy they have in the high order bits of = their initial random counter value. This proposal has Properties D and M, and also Property S: if Alice and Bob do not have clocks or storage and they = reboot at the same time, they are still secure as long as there are = enough bits of entropy in the high order bits of their initial counters = to ensure that those won't intersect with values they previously chose. Property R: If something goes wrong (reliable clocks aren't, etc.) = devices are able to reestablish communication after 1RTT Conceptually this is similar to treating the high order bits of the = counter as a nonce in cases where you do not have a clock or storage. So = I guess for those devices property M is somewhat not quite = guaranteed-ish... Also, to handle reordering we can have a replay window similar to = IPsec/ESP where Alice keeps a bit mask of packets received in = [savedCounter - 256, savedCounter - 1] to allow receiving out of order = packets in that range. David= From nobody Wed Jun 27 16:26:59 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63828130E3E for ; Wed, 27 Jun 2018 16:26:57 -0700 (PDT) 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, 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 8wPkqSDfieff for ; Wed, 27 Jun 2018 16:26:56 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B359F130E3C for ; Wed, 27 Jun 2018 16:26:55 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5RNQ8YT016051; Thu, 28 Jun 2018 01:26:08 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 874CEEB22D; Thu, 28 Jun 2018 01:26:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id JLljxptafQDt; Thu, 28 Jun 2018 01:26:49 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 8C1FAEB22E; Thu, 28 Jun 2018 01:26:49 +0200 (CEST) Date: Thu, 28 Jun 2018 01:26:49 +0200 Message-ID: <87bmbvak06.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Markus Stenberg , babel@ietf.org In-Reply-To: <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 28 Jun 2018 01:26:09 +0200 (CEST) X-Miltered: at korolev with ID 5B341D10.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B341D10.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B341D10.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 23:26:58 -0000 > I think so, yes. Straw man proposal: [...] > Conceptually this is similar to treating the high order bits of the > counter as a nonce in cases where you do not have a clock or storage. I think you're carrying a nonce in every packet (thus violating property M), just hiding it in the upper bits of the packet counter. In short, it's the protocol I suggested this morning, just with a more obfuscated encoding. Or am I missing something? From nobody Wed Jun 27 16:34:47 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50848130E3F for ; Wed, 27 Jun 2018 16:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 0WRrw5p1b3YA for ; Wed, 27 Jun 2018 16:34:42 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44CC0130E39 for ; Wed, 27 Jun 2018 16:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530142481; x=2394056081; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Nppiu4DMFZuebSe19Iz99R+hWPC7Ad/UOOg6f9hqKu4=; b=WAxRpNKuhcnTNkkroSklyiYkibLJ+A81WUmi/iI8PovNqmADe5r5YWjHe8UVofrg AJFcAuYSqbqmePb/oLzItV9xSJESMqVloY2NhnJT6Ke8ZSuREcp7HWvwEJ8I0yR5 zlfDJpaSzz2JR1tWxlH+d4ZuQQKDSXXBt4GRUGNs6htX05hjZ3GBP8/zVJ24on0z /B5joSSkueC+wqURYReSDxoPeZD7l2NI2OoUoJLsw0N9HFkJ3iQsoq8HTSV7BVwT pSYSx0RAmWQDXMB3wC089T2EapCy/kV/AdvbeXkhtBJLcgTmzMXDldZ6gSVRxMSq teJ9PZ3xSZe4SUeokclRPQ==; Received: from relay1.euro.apple.com (relay1.euro.apple.com [17.66.55.11]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 32.46.04279.01F143B5; Wed, 27 Jun 2018 16:34:41 -0700 (PDT) X-AuditID: 11973e12-9e9ff700000010b7-80-5b341f0fb1cc Received: from crk-mmpp-sz04.euro.apple.com (crk-mmpp-sz04.euro.apple.com [17.66.12.168]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay1.euro.apple.com (Symantec Mail Security) with SMTP id FD.23.23007.E0F143B5; Thu, 28 Jun 2018 00:34:38 +0100 (BST) Received: from [17.192.155.180] by crk-mmpp-sz04.euro.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PB0008CL9HO3T80@crk-mmpp-sz04.euro.apple.com>; Thu, 28 Jun 2018 00:34:38 +0100 (IST) Sender: dschinazi@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: David Schinazi In-reply-to: <87bmbvak06.wl-jch@irif.fr> Date: Wed, 27 Jun 2018 16:34:35 -0700 Cc: Markus Stenberg , babel@ietf.org Content-transfer-encoding: 7bit Message-id: <1D62C61C-C05B-45FE-B031-C9AF99A0D1E9@apple.com> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <87bmbvak06.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUi6GTOrSsobxJtMOe1gMWWRd0sFvNbl7FZ 7J27gsWB2WPJkp9MHoe/LmTxWLzlLWMAcxSXTUpqTmZZapG+XQJXxv95fAW32CruNAo3MC5k 7WLk5JAQMJFYPmcFSxcjF4eQwGYmiYYnx1hgEm2ne1khEkeYJFZ23mCDcBqYJA5fvAvWLiwg LdF1AcJmFtCSWL/zOBOIzStgLLF+80KoGkuJezMXMXcxcnCwAdUcWGMEEuYU0JBY9msLO4jN IqAq8fLnU3aIMTYS/ya0MEPY8hKb17xlhhhpI9H2DOaGU8wSv5a9AdslIqAisXzaM3aIqxUl +tccAiuSEOhhk3hxvI11AqPwLCT3zUJy3ywkSxYwMq9iFMpNzMzRzcwz0UssKMhJ1UvOz93E CAr36XZCOxhPrbI6xCjAwajEw7uixzhaiDWxrLgy9xCjNAeLkjhvh5hJtJBAemJJanZqakFq UXxRaU5q8SFGJg5OqQbGBh+zzxP3PpQXSd59TuOy6lqrb2If9r9J1/Jg+Rr669ryv9OT9mSu /rHG+NkzwYYlCwXfbp1yX6rkJPPp6nUfja++38RzRHeiaPxNv3cye/h3R/ccvHzqprrlLx/V GZvsYzXm3t606/MTtZ8dDRLSN+/62t6XFtu+vny2wYXntq/CZaLjLuXV+yqxFGckGmoxFxUn AgDdvZcnWAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUi6MSzQpdP3iTaYEOjucWWRd0sFvNbl7FZ 7J27gsWB2WPJkp9MHoe/LmTxWLzlLWMAcxSXTUpqTmZZapG+XQJXxv95fAW32CruNAo3MC5k 7WLk5JAQMJFoO90LZHNxCAkcYZJY2XmDDcJpYJI4fPEuWJWwgLRE1wUIm1lAS2L9zuNMIDav gLHE+s0LoWosJe7NXMTcxcjBwQZUc2CNEUiYU0BDYtmvLewgNouAqsTLn0/ZIcbYSPyb0MIM YctLbF7zlhlipI1E2zOYG04xS/xa9gZsl4iAisTyac/YIa5WlOhfc4htAqPALCQnzUJy0iwk cxcwMq9iFC1KzUmsNNRLLS3K10ssKMhJ1UvOz93ECA5Uc+4djMd3Gx5iFOBgVOLhbZE1iRZi TSwrrsw9xCjBwawkwitx3zhaiDclsbIqtSg/vqg0J7X4EKM0B4uSOO9kJeZoIYH0xJLU7NTU gtQimCwTB6dUA+NWuc7tuvH89sfcGs7dnnkpOV7z6dOOhfdlXVfc1ZnMsDm3UlXp/bvIR4cj jBjMY9ZsvTf76rZJnVlsJ3PlM/SPJWmr/Uln2ySipeYzd5fL7lgfzsXRwSu0nB9tTvhV8WLF HkcltYDtpdPiBA//ed72fJp3xHb5jbnHlO7/vufbkhrXNHMb538lluKMREMt5qLiRAAw2Ws6 UAIAAA== Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 23:34:45 -0000 > On Jun 27, 2018, at 16:26, Juliusz Chroboczek wrote: > >> I think so, yes. Straw man proposal: > > [...] > >> Conceptually this is similar to treating the high order bits of the >> counter as a nonce in cases where you do not have a clock or storage. > > I think you're carrying a nonce in every packet (thus violating property > M), just hiding it in the upper bits of the packet counter. In short, > it's the protocol I suggested this morning, just with a more obfuscated > encoding. > > Or am I missing something? The key difference is that it's more versatile. Only devices that do not have clocks or storage treat it as a nonce. It gives better security properties to devices with clocks or storage because those devices do not have their security depend on a randomly generated number being unique. David From nobody Wed Jun 27 16:40:31 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78450130E3F for ; Wed, 27 Jun 2018 16:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 u8eKNlDT8suq for ; Wed, 27 Jun 2018 16:40:27 -0700 (PDT) Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D88F130E3C for ; Wed, 27 Jun 2018 16:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530142826; x=2394056426; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CKsrZ1e9+MKmSis50KEn5P+UytSW94vICZ0t1fjRTGU=; b=HimUCJV27MNDTHp2U7wlaJeNuqIJRpV7HGASMUg0/zf28+72TBBeF4ZrfaCbJW0K 43Y5te/HQmK4PYp13JeKEV7OLwXu+hz5cl++PDJfI8QYHC+k8Bsl8zjHW9wv4iTq t6uo6Q2h01Uie9OdJSj5Jg7OU3kPNxqeOnelqt8M8/Y+dzVCMmDc3ooVCDefq4V8 9n7vuzDgTqo+imC2UcAN8v7ZWpfqo+jv7UAoOTIfLKHQrS3DJPuXoMtORfKOEeGi mt9utuGpwoIg/eIjy/KE736qVotFRVYhj5eLdJH/Zb34DkVuHuYi66YDY7P5JzgB 9gneOrc7mhkPSF5ldfHjjw==; X-AuditID: 11ab0216-c97ff70000002f11-78-5b34206af993 Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id 00.3D.12049.A60243B5; Wed, 27 Jun 2018 16:40:26 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_RTpFMVXouxByHc5RxmcaIg)" Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PB000CJE9RDML70@ma1-mtap-s03.corp.apple.com>; Wed, 27 Jun 2018 16:40:26 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB000K009EG3900@nwk-mmpp-sz10.apple.com>; Wed, 27 Jun 2018 16:40:25 -0700 (PDT) X-Va-A: X-Va-T-CD: d59661a006d810078864a2b5ec0f053f X-Va-E-CD: 56381c10423255a02021214fe2be34ab X-Va-R-CD: 51b264366a03f3713579e9c13de44bee X-Va-CD: 0 X-Va-ID: a286a8c2-c3f4-47b0-88d5-261a50ae7fa4 X-V-A: X-V-T-CD: 7d6566e1ce32e60bd701207e1252a9a5 X-V-E-CD: 56381c10423255a02021214fe2be34ab X-V-R-CD: 51b264366a03f3713579e9c13de44bee X-V-CD: 0 X-V-ID: 6e1ecd79-efdb-4ae2-865d-45a4699d9c09 Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB000J009D46100@nwk-mmpp-sz10.apple.com>; Wed, 27 Jun 2018 16:40:24 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-27_07:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp14.corp.apple.com-10000_instance1 Received: from [17.192.155.180] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PB000M9I9R5OW00@nwk-mmpp-sz10.apple.com>; Wed, 27 Jun 2018 16:40:17 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <54A1C2F0-4CA7-4D23-A3F8-C1355A7F21F7@apple.com> Date: Wed, 27 Jun 2018 16:40:16 -0700 In-reply-to: <1D62C61C-C05B-45FE-B031-C9AF99A0D1E9@apple.com> Cc: Markus Stenberg , babel@ietf.org To: Juliusz Chroboczek References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <87bmbvak06.wl-jch@irif.fr> <1D62C61C-C05B-45FE-B031-C9AF99A0D1E9@apple.com> X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42IR1PBh181SMIk2WLFYymLLom4Wi/mty9gs 9s5dweLA7LFkyU8mj8NfF7J4LN7yljGAOYrLJiU1J7MstUjfLoErY+a7n8wFHzMqXq+ZwdjA +Cy6i5GTQ0LARKJpUzt7FyMXh5DAfiaJt7vnsYEkeAUEJX5MvscCYjMLhEk8etPADFG0kUni 4sNjUE4Xk8SjW8vYIEaxS/z5tYMFwtaWOHhnGSuM/e3OdEYYe+f+U1A1XBILtp6GqtGVWL7y E9QcNon1J5YwQdhaEk+3P2eFsTtn/oGLT2o4CTWHU+L8l4lAL3AA2ToSe27GQNzWySRx7/4J qL3ZElvm7mGHsIMlTq5rhHr5G6PE78Y5YEXCAtISXRfusoIMYgNacGCNESQkbCQW3JvKDFFi KXFv5iIwm0VAVWLHs7VgN3MK2Er8OLKIHRJaNhL/JrSA1YgIqEgsn/YMatdvZom/N85CPaAo 0b/mENsERoVZSKE9Cym0IWwtie+PWoHiHEC2vMTB87IQYU2JZ/c+sUPY2hJP3l1gXcDItopR ODcxM0c3M8/ISC+xoCAnVS85P3cTIyjlrGYS28F477XhIUYBDkYlHt6ALuNoIdbEsuLK3EOM 0hwsSuK8H3eJRQsJpCeWpGanphakFsUXleakFh9iZOLglGpgDD7mwrp0U0jjoqO3+CSnz9HM ZF7p537kVuea1Gd/py46+3MHc+35syfuOW5fcO7UNgODJB9xOa9uuYmM/U9O38n60ipjesWH zVPEcmpXtvf2D0fKl+/e3HEvn2nF+yvzVgQ8ydi2qDznxMFdxvmHIyfsXZL1cK+2O6OA+MHJ trN/BN1t07abo6nEUpyRaKjFXFScCAD2lVU4GgMAAA== Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 23:40:30 -0000 --Boundary_(ID_RTpFMVXouxByHc5RxmcaIg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Also the proposal differentiates between the challenge nonce (which will be >= 128 bits) and the per-packet "nonce" that's a lot shorter. This allows us to send fewer bytes on the wire per packet. David > On Jun 27, 2018, at 16:34, David Schinazi wrote: > > > >> On Jun 27, 2018, at 16:26, Juliusz Chroboczek wrote: >> >>> I think so, yes. Straw man proposal: >> >> [...] >> >>> Conceptually this is similar to treating the high order bits of the >>> counter as a nonce in cases where you do not have a clock or storage. >> >> I think you're carrying a nonce in every packet (thus violating property >> M), just hiding it in the upper bits of the packet counter. In short, >> it's the protocol I suggested this morning, just with a more obfuscated >> encoding. >> >> Or am I missing something? > > The key difference is that it's more versatile. Only devices that do not > have clocks or storage treat it as a nonce. It gives better security > properties to devices with clocks or storage because those devices > do not have their security depend on a randomly generated number > being unique. > > David > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --Boundary_(ID_RTpFMVXouxByHc5RxmcaIg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Also = the proposal differentiates between the challenge nonce
(which will be >=3D 128 bits) and the per-packet "nonce" = that's a lot shorter.
This allows us to send fewer = bytes on the wire per packet.

David


On Jun 27, 2018, at 16:34, = David Schinazi <dschinazi@apple.com> wrote:



On = Jun 27, 2018, at 16:26, Juliusz Chroboczek <jch@irif.fr> wrote:

I think = so, yes. Straw man proposal:

[...]

Conceptually this is similar to treating the high order bits = of the
counter as a nonce in cases where you do not have a = clock or storage.

I think = you're carrying a nonce in every packet (thus violating property
M), just hiding it in the upper bits of the packet counter. =  In short,
it's the protocol I suggested this = morning, just with a more obfuscated
encoding.

Or am I missing something?

The key difference is that it's more versatile. Only devices = that do not
have clocks = or storage treat it as a nonce. It gives better security
properties to devices with = clocks or storage because those devices
do not have their security depend on a randomly generated = number
being = unique.

David
_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel

= --Boundary_(ID_RTpFMVXouxByHc5RxmcaIg)-- From nobody Wed Jun 27 16:52:13 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB586130E40 for ; Wed, 27 Jun 2018 16:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 4mMw-4aNuhiR for ; Wed, 27 Jun 2018 16:52:09 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172F2129C6A for ; Wed, 27 Jun 2018 16:52:09 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1530143526; bh=8IUbm0AoMyHlkm7ka+fbhagRJKlLZXxHDrxbxMmM+Zo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=EgytfHP8MQOpvahDQLjFqaQKMzT7vhQEdEjujykpUB+zwZ0Duq3q8M76mDHr844i3 DFzlhS1xMQzgGYXhg8LUBiK1CYaSV3PISZGp5ttWgg0o2h5AwB8J3MRWex8kXFi+Pz 44L7SAak40VrbC2Ohk4RVRFVQU0vYZCepIWsko9PNj0ujl6OlKDSab8vB/5UxYZPBR uswSfjrfAvaf/yqGtcjF3zQ78ZYDRZIQgdQqTmhvlrYgQ6ju0XZF8CC1GDGVFnliS+ iqUG96hUvl8ttIuk4+zJGazQGLp2AGDr4dDGrMNbUmr60mbTLO6DPyGI54LDRrfkdc Y/RMrh22W4wSA== To: Juliusz Chroboczek , David Schinazi Cc: Markus Stenberg , babel@ietf.org In-Reply-To: <87fu17an1y.wl-jch@irif.fr> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> Date: Thu, 28 Jun 2018 01:52:12 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87zhzfkcsz.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 23:52:11 -0000 Juliusz Chroboczek writes: >>> Basically this breaks the property that "any packet without a valid HMAC is >>> silently ignored" and that worries me, as it was a good property to have. > >> Good point, noted. > > So: > > Property D: a packet is silently ignored after an HMAC failure, BTW, if we specify this, should we also specify a 'debug mode' in which an implementation MUST COMPLAIN LOUDLY if an HMAC fails? Not everyone has the luxury of recompiling their babel daemon with debugging enabled, and while silently ignoring packets may be good for security, it makes debugging... interesting... -Toke From nobody Wed Jun 27 17:03:07 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB1E130E45 for ; Wed, 27 Jun 2018 17:03:03 -0700 (PDT) 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, 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 2-2NfjnJeVV2 for ; Wed, 27 Jun 2018 17:03:01 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 067A1130E44 for ; Wed, 27 Jun 2018 17:03:00 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5S02Er9021982; Thu, 28 Jun 2018 02:02:14 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 60C86EB22E; Thu, 28 Jun 2018 02:02:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Cn94sAdo1Nhc; Thu, 28 Jun 2018 02:02:55 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 5F266EB200; Thu, 28 Jun 2018 02:02:55 +0200 (CEST) Date: Thu, 28 Jun 2018 02:02:55 +0200 Message-ID: <87a7rfaic0.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Markus Stenberg , babel@ietf.org In-Reply-To: <54A1C2F0-4CA7-4D23-A3F8-C1355A7F21F7@apple.com> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <87bmbvak06.wl-jch@irif.fr> <1D62C61C-C05B-45FE-B031-C9AF99A0D1E9@apple.com> <54A1C2F0-4CA7-4D23-A3F8-C1355A7F21F7@apple.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 28 Jun 2018 02:02:14 +0200 (CEST) X-Miltered: at korolev with ID 5B342586.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B342586.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B342586.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 00:03:04 -0000 David Schinazi writes: > The key difference is that it's more versatile. Only devices that do not > have clocks or storage treat it as a nonce. In the Stenberg-Chroboczek proposal, devices that have a reliable clock and don't fear overflowing the PC space could in principle use a nonce of length 0. (That's not recommended, but a device can reasonably use a 16-bit overflow count as a nonce.) > Also the proposal differentiates between the challenge nonce (which will > be >= 128 bits) and the per-packet "nonce" that's a lot shorter. This > allows us to send fewer bytes on the wire per packet. Same with the Stenberg-Chroboczek proposal -- the nonces are variable size, and implementations can use a short sender's nonce and a long receiver's nonce. I'll sleep over it, but I really feel like your proposal is just a less explicit reencoding of Stenberg-Chroboczek. -- Juliusz From nobody Wed Jun 27 18:09:32 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C18130E6D for ; Wed, 27 Jun 2018 18:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 HIe8zKFxzEXH for ; Wed, 27 Jun 2018 18:09:29 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B3C130E63 for ; Wed, 27 Jun 2018 18:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530148168; x=2394061768; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lYtB7zzg/MxT8Cm67xbff0vxjRRJRvYiEMK2IgncMt8=; b=d0XNHJ67p6X2m/WtTR7/O/55HPP77fariNGOFbrbag3T0XeVcBsr1TVVUPQ68Xuy lhz+ypVfSFxIkAZaXk52RLDiw1BIdhdAH3ZdgsBmg4wMZr1RX5443G4v1DM/a8CT IH2navEdqmdRgmk1MJcQW92FefQF5xAFfoeRW7pM1MKdwC/fX3vVCBXWuhl4WXdP 2ulmn5THjxQroQGsgZ3zoburT61aklDwi6Pjytj9606ZmD/ressIhGl0g8eL8rf5 XKMwL/RzIK4N1mAEO+mcHBzHkuNTsrsg707PjUGB+CLUswdei1QUCfqz4KP694ip bQBQxgM10czjHlhiiC0Ncg==; X-AuditID: 11973e13-b209c9e00000242c-03-5b343548101a Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 82.45.09260.845343B5; Wed, 27 Jun 2018 18:09:28 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PB000MOMDVSKEB0@mr2-mtap-s01.rno.apple.com>; Wed, 27 Jun 2018 18:09:28 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB000100DTXFW00@nwk-mmpp-sz11.apple.com>; Wed, 27 Jun 2018 18:09:28 -0700 (PDT) X-Va-A: X-Va-T-CD: d59661a006d810078864a2b5ec0f053f X-Va-E-CD: 56381c10423255a02021214fe2be34ab X-Va-R-CD: 51b264366a03f3713579e9c13de44bee X-Va-CD: 0 X-Va-ID: 73320edc-306f-4da2-b12a-081059dfbf99 X-V-A: X-V-T-CD: 7d6566e1ce32e60bd701207e1252a9a5 X-V-E-CD: 56381c10423255a02021214fe2be34ab X-V-R-CD: 51b264366a03f3713579e9c13de44bee X-V-CD: 0 X-V-ID: 90ffcb94-e86a-4401-a143-af95cc37f395 Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB000C00D8IQR00@nwk-mmpp-sz11.apple.com>; Wed, 27 Jun 2018 18:09:28 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-27_08:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp17.corp.apple.com-10000_instance1 Received: from [17.192.155.180] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PB000GZ7DVRX620@nwk-mmpp-sz11.apple.com>; Wed, 27 Jun 2018 18:09:28 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87a7rfaic0.wl-jch@irif.fr> Date: Wed, 27 Jun 2018 18:09:26 -0700 Cc: Markus Stenberg , babel@ietf.org Message-id: <77A4DE71-687B-4F18-944E-9411F86DF45C@apple.com> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <87bmbvak06.wl-jch@irif.fr> <1D62C61C-C05B-45FE-B031-C9AF99A0D1E9@apple.com> <54A1C2F0-4CA7-4D23-A3F8-C1355A7F21F7@apple.com> <87a7rfaic0.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUiuPlRq66HqUm0wZ9fRhZbFnWzWMxvXcZm sXfuChYHZo8lS34yeRz+upDFY/GWt4wBzFFcNimpOZllqUX6dglcGRfvX2QqOMlb8fPoT6YG xttcXYycHBICJhITzp5j7WLk4hASOMAk8WzdNHaQBK+AoMSPyfdYuhg5OJgF5CUOnpcFCTML aEl8f9TKAlG/nkni5of9jBBOF5PE90tP2SGmskv8+bWDBcLWljh4ZxkrjP3tznRGGHvn/lNQ NVwSC7aehqrRlTjZPh1qDpvE+hNLmCBsLYmn25+zwtidM//AxSc1nISawylx/stEqF4didtH jkB91skk8XndcqjF2RLNT45BDQqWeDihDeqDb4wS29d2gU0VFpCW6LpwlxXCtpS4N3MRMygo 2IC2HVhjBBLmFNCQ2HPoFBuIzSKgKtF/4xYTJIhsJP5NaGGGhKKNxPvJy9gh5p9ikdgwoQHs CBEBFYnl056xT2BUnIUU2rMQoT0LKbQXMDKvYhTKTczM0c3MM9VLLCjISdVLzs/dxAhKFNPt hHcwnl5ldYhRgINRiYd3RY9xtBBrYllxZe4hRmkOFiVx3g4xk2ghgfTEktTs1NSC1KL4otKc 1OJDjEwcnFINjFKzAs9PTdsjt7ah1UfQ0mNRQMc658CaidvW6LnffG+3zXfVjiTepJOZK17N VgzepufD2sLz6gDPimsTHvq0H0nJZWyaKe4RWipfzHnGj0EjZPOSxEUqD9dPPXpYb+nee0/L ulLO/VDiymfyn3Fh9Zbd5qJhyWExXP11/9Z+yJFP/RXc8X+NsxJLcUaioRZzUXEiAIvet5P1 AgAA Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 01:09:31 -0000 I just reread your proposal and I think I agree with you. If I'm getting this right, my proposal maps to yours with - nonce = receiver's nonce - counter = PC and sender's nonce But I do think in this case less explicit is better. We could give the counter an arbitrary length selected by the sender and get the best of all worlds here. Also, since I'm feeling pedantic, a nonce is a number only used once so your sender's nonce is not technically a nonce and needs to be renamed :) So apart from naming of things we are in agreement. David > On Jun 27, 2018, at 17:02, Juliusz Chroboczek wrote: > > David Schinazi writes: > >> The key difference is that it's more versatile. Only devices that do not >> have clocks or storage treat it as a nonce. > > In the Stenberg-Chroboczek proposal, devices that have a reliable clock > and don't fear overflowing the PC space could in principle use a nonce of > length 0. (That's not recommended, but a device can reasonably use > a 16-bit overflow count as a nonce.) > >> Also the proposal differentiates between the challenge nonce (which will >> be >= 128 bits) and the per-packet "nonce" that's a lot shorter. This >> allows us to send fewer bytes on the wire per packet. > > Same with the Stenberg-Chroboczek proposal -- the nonces are variable > size, and implementations can use a short sender's nonce and a long > receiver's nonce. > > I'll sleep over it, but I really feel like your proposal is just a less > explicit reencoding of Stenberg-Chroboczek. > > -- Juliusz > > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Wed Jun 27 21:18:52 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DD8130F1F for ; Wed, 27 Jun 2018 21:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=kapsi.fi 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 pHU6FWtyPOcv for ; Wed, 27 Jun 2018 21:18:47 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (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 62B2112785F for ; Wed, 27 Jun 2018 21:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=+eY/2WrklfyiuWJnoL5dEPu/2RhjKWpHkrZjaKc9c1Q=; b=MIgjDXWZ6qESDbNpzUu8xkt5VyRbWv9SjZB3sM4G3ONx+tQRAzncWKkil7MbU8wZs/PQ8zFCvM6ykBQi5JHV33KffBT3ZuJ9oT0z65MBrSNIK6DwKyBm+yUOPqq5z39+0bhKUMMPI3l6GrFH+P2RZvr3sIwyyX5CL6A187m+1Z++gOSLXpCv+OLjX5RmG7oftUcRj46/Pz8ZaxhbSQkII48Ud/3mdj2Q8da5RlbH8mdExNpsDpBGH+hwPONGid6V6JFFRFDzVIn0kx8yl2LlE2PJ+TJ+KoBTVXJfd7k/n7K4A5vfhila4zaVeq0aHiVoM51QXcd38is4FC4Z1VCPcQ==; Received: from 91-155-69-32.elisa-laajakaista.fi ([91.155.69.32] helo=suiren.lan) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fYOOI-0007GH-GO; Thu, 28 Jun 2018 07:18:42 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Markus Stenberg In-Reply-To: <77A4DE71-687B-4F18-944E-9411F86DF45C@apple.com> Date: Thu, 28 Jun 2018 07:18:41 +0300 Cc: Juliusz Chroboczek , babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0F56F9AB-6230-4B1B-8CA5-56484E8D52BC@iki.fi> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <87bmbvak06.wl-jch@irif.fr> <1D62C61C-C05B-45FE-B031-C9AF99A0D1E9@apple.com> <54A1C2F0-4CA7-4D23-A3F8-C1355A7F21F7@apple.com> <87a7rfaic0.wl-jch@irif.fr> <77A4DE71-687B-4F18-944E-9411F86DF45C@apple.com> To: David Schinazi X-Mailer: Apple Mail (2.3445.8.2) X-SA-Exim-Connect-IP: 91.155.69.32 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 04:18:50 -0000 > On 28.06.2018, at 4.09, David Schinazi wrote: > I just reread your proposal and I think I agree with you. > If I'm getting this right, my proposal maps to yours with > - nonce =3D receiver's nonce > - counter =3D PC and sender's nonce > But I do think in this case less explicit is better. We could give the = counter an > arbitrary length selected by the sender and get the best of all worlds = here. >=20 > Also, since I'm feeling pedantic, a nonce is a number only used once > so your sender's nonce is not technically a nonce and needs to be = renamed :) Well if it's transmitted only once (in challenge-response if we choose = the not-on-wire property) and used later just as hmac parameter I am not = sure I agree with you. Plenty of protocols do e.g. key derivation based on nonces or establish = session in some other way using them. Admittedly here the scheme is bit = more interlinked perhaps (as the actual value and not derived key has to = be retained). Do you have a better suggestion? Technically it is some sort of per-boot = (or per-router-daemon-lifetime) token. -Markus= From nobody Wed Jun 27 21:23:50 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C51F130FBF for ; Wed, 27 Jun 2018 21:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=kapsi.fi 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 GKIkzUjd1-PA for ; Wed, 27 Jun 2018 21:23:39 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (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 8A309130F97 for ; Wed, 27 Jun 2018 21:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=LN8v+YIsbqLLnMS5t2S5+X5FQsgazWcCGFnkQH5q6eM=; b=TxqzHrnZtwrGbiCnhoQQmVj8wCYX+2Dpk0jbVeE4iRzaZgAh/0PBDcF2tJZ2trYo14tjfp79mC7fXLSy/LZDLDN6QdS20L78LuH1Sy4ZWa6eXZknJGo0Mh/GshxRa0fsp6ohK5X9+9F0AVfGHGpDL7iteA1ak9aGKxZzLbndJsELYmTurlTdAOd97RVcHZMWYYTb761H0R1iADUbHMj7wc01TuFLwJ7A0nOV9mRZFevv/m3Rl6ShmWXaPoWS9H6wraSlNv5G6yTKKKM1dQHiA8aN11VwEEEQZitVQtdN1cUkEB+B7w0/etm5fAI16uZLzdsW8cEEXLqum93BXia/iw==; Received: from 91-155-69-32.elisa-laajakaista.fi ([91.155.69.32] helo=suiren.lan) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fYOT2-0000nE-Uj; Thu, 28 Jun 2018 07:23:37 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Markus Stenberg In-Reply-To: <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> Date: Thu, 28 Jun 2018 07:23:36 +0300 Cc: Juliusz Chroboczek , babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6DBB10F7-6F1B-4909-894D-16FCD2C7DEF0@iki.fi> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> To: David Schinazi X-Mailer: Apple Mail (2.3445.8.2) X-SA-Exim-Connect-IP: 91.155.69.32 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 04:23:49 -0000 > On 28.06.2018, at 2.16, David Schinazi wrote: > Also, to handle reordering we can have a replay window similar to = IPsec/ESP where Alice keeps a bit mask of packets received in = [savedCounter - 256, savedCounter - 1] to allow receiving out of order = packets in that range. I wonder if packet reordering is something we should really incorporate = to this design or not. Typically on one link it does not happen, but if you e.g. have some = wireless lower layer with unreliable multicast and 'reliable' unicast, = it would be possible to have reordering occur here between unicast and = multicast (as seen by receiver).=20 I guess also given some sort of bit 'larger' lower layer network (hello = ethernet+ISIS) it is possible for packets to use different paths and = show up in different order.. Not maybe target domain for Babel but = still. Now that I think more of it, I think ordered delivery is a likely = property but not always present one even for stuff that seems like one = IP layer link. -Markus= From nobody Thu Jun 28 01:51:47 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFCB130F07 for ; Thu, 28 Jun 2018 01:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kapsi.fi 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 aPxYUFkbirLx for ; Thu, 28 Jun 2018 01:51:42 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (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 F094C12F1AC for ; Thu, 28 Jun 2018 01:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=nsN9yfA48D/Nnom2RBtob38CM+bKTk4m5uUN8rky8Fs=; b=Rn+r2BTYWHEwXx3g4EQL+6/nSvkZsKKa9BN6PW7+inPobqo7EGapUCz9s3GmZPp+93kdOgsdZM6wRJ+RUgfjN8ZTHe6/xKIfAvkYi+S+kDow3RrLRGiHm/E6dJ3kyCIDglc0znZk++erCh99dTJAn7pfBE1UKdBDrhCTM2+30cB4kg87fiuo3xRyP87two7bnVwbevIJyxlhRj4PG0wRDwXrCydQOXXeHIXeuIuM5oWFnpWdmoWE+TZtCxpsFw+KExE2lLW47kr/+8fFFT7x0b/3HGyfclYhCtpQFGRAR5MnZKpJxKXhu90kVNQxYyCCAV2xdRa2DeI4bZVOQGTk3w==; Received: from [194.100.69.221] (helo=[172.20.21.37]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fYSeO-0002RI-4f; Thu, 28 Jun 2018 11:51:36 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Markus Stenberg In-Reply-To: <6DBB10F7-6F1B-4909-894D-16FCD2C7DEF0@iki.fi> Date: Thu, 28 Jun 2018 11:51:35 +0300 Cc: babel@ietf.org, Juliusz Chroboczek Content-Transfer-Encoding: quoted-printable Message-Id: <3D958DDA-4382-45AB-B87D-3B93EF330D05@iki.fi> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <6DBB10F7-6F1B-4909-894D-16FCD2C7DEF0@iki.fi> To: David Schinazi X-Mailer: Apple Mail (2.3445.8.2) X-SA-Exim-Connect-IP: 194.100.69.221 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 08:51:45 -0000 On 28 Jun 2018, at 7.23, Markus Stenberg wrote: >> On 28.06.2018, at 2.16, David Schinazi wrote: >> Also, to handle reordering we can have a replay window similar to = IPsec/ESP where Alice keeps a bit mask of packets received in = [savedCounter - 256, savedCounter - 1] to allow receiving out of order = packets in that range. > I wonder if packet reordering is something we should really = incorporate to this design or not. >=20 > Typically on one link it does not happen, but if you e.g. have some = wireless lower layer with unreliable multicast and 'reliable' unicast, = it would be possible to have reordering occur here between unicast and = multicast (as seen by receiver).=20 >=20 > I guess also given some sort of bit 'larger' lower layer network = (hello ethernet+ISIS) it is possible for packets to use different paths = and show up in different order.. Not maybe target domain for Babel but = still. >=20 > Now that I think more of it, I think ordered delivery is a likely = property but not always present one even for stuff that seems like one = IP layer link. (Even more thought, bear with me) With that said, noting some replay = window semantics are probably useful to mention in the text, but the = window size should be left to the implementor. With that, if size=3D1, = the window disappears, so essentially mechanism is implementation-only = optional one. (I think it just leads to some =E2=80=98packet loss=E2=80=99 if we get = stuff outside replay window, so it is fine; the challenge-response = should be probably triggered if and only if no valid stuff has been = received for X from the node..) -Markus= From nobody Thu Jun 28 02:45:05 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35FD130F37 for ; Thu, 28 Jun 2018 02:45:02 -0700 (PDT) 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, 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 OSd-i6ykiPTw for ; Thu, 28 Jun 2018 02:45:00 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1408F130F30 for ; Thu, 28 Jun 2018 02:44:59 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5S9iDx3026623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 Jun 2018 11:44:13 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w5S9iQeT006055; Thu, 28 Jun 2018 11:44:26 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 1E8E7EB200; Thu, 28 Jun 2018 11:44:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id EK62TuJrc2Ex; Thu, 28 Jun 2018 11:44:54 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 40BEEEB279; Thu, 28 Jun 2018 11:44:54 +0200 (CEST) Date: Thu, 28 Jun 2018 11:44:54 +0200 Message-ID: <87lgaznt2h.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: David Schinazi , babel@ietf.org In-Reply-To: <3D958DDA-4382-45AB-B87D-3B93EF330D05@iki.fi> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <6DBB10F7-6F1B-4909-894D-16FCD2C7DEF0@iki.fi> <3D958DDA-4382-45AB-B87D-3B93EF330D05@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 28 Jun 2018 11:44:13 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 28 Jun 2018 11:44:26 +0200 (CEST) X-Miltered: at korolev with ID 5B34ADED.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B34ADFA.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B34ADED.003 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B34ADFA.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B34ADED.003 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B34ADFA.002 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 09:45:03 -0000 > (I think it just leads to some ‘packet loss’ if we get stuff outside > replay window, so it is fine; the challenge-response should be probably > triggered if and only if no valid stuff has been received for X from the > node..) Challenge on nonce change only, not on out-of-order PC? From nobody Thu Jun 28 03:01:45 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E459130F5C for ; Thu, 28 Jun 2018 03:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kapsi.fi 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 JAJmXmkNp6vf for ; Thu, 28 Jun 2018 03:01:39 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (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 1F4C5130EE1 for ; Thu, 28 Jun 2018 03:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=2JKXb7xmOLeQwlG3bUoK8v/zRWIrshtyTVIjTw98UrA=; b=XhEJNVPZGQVo1UibnByAo9R6fwfQ5Wt1ysZbOQjX+XWmvsCGMCUhCNv+nNhcSnlOJSeWRkhaIwIkWniYUYm2x0BoBYy6tudEmAq2B1WG6ShFZgAitCM9IPoMdTzH6OKJHuHnRxzWAN978tT6vHjRXSAiqR3lTqa6e8R2r/mxAAMyT+a/JZCQwRcQVB2M2Dt7QJ5rDaeW6O2Iut9elT009cYkpF09dB9Z/XBVdNAga0JmRGkQyauI2YUNRjIycUUaFxyJUEROY1IRMTiVPwjq5hyTDXe7psoTumsPALmKyzy55YDGi55vzWDixYWZSExqamKUShHt5TL6G+ot/Etxwg==; Received: from [194.100.69.221] (helo=[172.20.21.37]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fYTk8-00018x-09; Thu, 28 Jun 2018 13:01:36 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Markus Stenberg In-Reply-To: <87lgaznt2h.wl-jch@irif.fr> Date: Thu, 28 Jun 2018 13:01:35 +0300 Cc: David Schinazi , babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <6DBB10F7-6F1B-4909-894D-16FCD2C7DEF0@iki.fi> <3D958DDA-4382-45AB-B87D-3B93EF330D05@iki.fi> <87lgaznt2h.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.8.2) X-SA-Exim-Connect-IP: 194.100.69.221 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 10:01:44 -0000 On 28 Jun 2018, at 12.44, Juliusz Chroboczek wrote: >> (I think it just leads to some =E2=80=98packet loss=E2=80=99 if we = get stuff outside >> replay window, so it is fine; the challenge-response should be = probably >> triggered if and only if no valid stuff has been received for X from = the >> node..) > Challenge on nonce change only, not on out-of-order PC? I think there is a tradeoff between DoS resistance (no spurious = challenges) and fast recovery from sender state loss. There seems to be = plenty of design decisions to be made here though, and only based on = them sensible choices can be made, but for the time being I am leaning = towards the former, so I=E2=80=99d say challenge should be sent iff: - no sender nonce for node (duh; new node), _or_ - no valid hmac (with valid sender nonce) received over time period of = (IHU interval * something) The messages with counter outside replay window (if used at all) would = be just ignored if replay window is not used.=20 e.g. sender reboots -> with this scheme, it would only recover with = timeout and that=E2=80=99s bit icky as well.. on the other hand, node = reboots probably take normally some time as well so I am not sure it is = really as bad as one could think on first estimation. Key rotation or = intentional counter reset/roll-over might need further thought though.. -Markus From nobody Thu Jun 28 03:17:20 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5786130EE1 for ; Thu, 28 Jun 2018 03:17:18 -0700 (PDT) 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, 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 2_afR4Xxwugs for ; Thu, 28 Jun 2018 03:17:17 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30744130EA4 for ; Thu, 28 Jun 2018 03:17:17 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5SAGRg0014912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 Jun 2018 12:16:28 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w5SAGfPJ021802; Thu, 28 Jun 2018 12:16:41 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 97D6DEB22E; Thu, 28 Jun 2018 12:17:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 6BTpIutXDN9R; Thu, 28 Jun 2018 12:17:08 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9B02DEB200; Thu, 28 Jun 2018 12:17:08 +0200 (CEST) Date: Thu, 28 Jun 2018 12:17:08 +0200 Message-ID: <87h8lnnrkr.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: David Schinazi , babel@ietf.org In-Reply-To: References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <6DBB10F7-6F1B-4909-894D-16FCD2C7DEF0@iki.fi> <3D958DDA-4382-45AB-B87D-3B93EF330D05@iki.fi> <87lgaznt2h.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 28 Jun 2018 12:16:28 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 28 Jun 2018 12:16:41 +0200 (CEST) X-Miltered: at korolev with ID 5B34B57C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B34B589.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B34B57C.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B34B589.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B34B57C.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B34B589.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 10:17:19 -0000 > - no sender nonce for node (duh; new node), _or_ > - no valid hmac (with valid sender nonce) received over time period of > (IHU interval * something) As you note later in your message, we want to allow the sender to rekey at any time without delay (e.g. because it has just rebooted). So I'd say challenge when: - no state for sender; or - no challenge in the last T seconds AND nonce has changed. This allows rekeying with no delay, but no more than once every T. Two questions: - what's the right value for T (Markus suggests deriving from IHU); - should we challenge when we see old PC, and if so, how do we avoid getting confused in case of packet reordering? > The messages with counter outside replay window (if used at all) would > be just ignored if replay window is not used. Yep. -- Juliusz From nobody Thu Jun 28 03:44:21 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18094130F35 for ; Thu, 28 Jun 2018 03:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kapsi.fi 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 XStAh08ovwsY for ; Thu, 28 Jun 2018 03:44:15 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (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 63491130F49 for ; Thu, 28 Jun 2018 03:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=g/a6sQugq7uvSikNsfDIt/2JzMoUVUtS7T8N1OK/wbs=; b=pru6JVEP1rzHh5ufiDBvWFfvI2Wn3pq7g7+R3dQ9mafcjYcN+52RhwX8K0+48hYbgf9LDL5ITpYt7Sz1rFUyWCBmNsWwLAnLbDegdl3BflvBKEgAo8FH8lBA97xhsmkvDw64sSz3pXkcJRCW28wsHeVr/PzZPxxbrDZgjwO9PbQ5xKel2+2Bv9nDFutHHwHF0hJz0mkuDo4NuJcVSdybGh0eCtZ0JZUWKUbGqrzdzdKGFG9esmr99BIMnOz8ZvaNgDuw5X0kB/HBD1bJZKY4tDf5omgKp2dQ3YvZ7ADa5MsJWKEAvh5BUEr9Bpu17iP35BH6JBBeO0DJSP2wqMeHLA==; Received: from [194.100.69.221] (helo=[172.20.21.37]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fYUPL-0002sR-TY; Thu, 28 Jun 2018 13:44:11 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Markus Stenberg In-Reply-To: <87h8lnnrkr.wl-jch@irif.fr> Date: Thu, 28 Jun 2018 13:44:11 +0300 Cc: David Schinazi , babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <521CBB64-7A4C-497B-AF71-1E23344FC7E6@iki.fi> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <6DBB10F7-6F1B-4909-894D-16FCD2C7DEF0@iki.fi> <3D958DDA-4382-45AB-B87D-3B93EF330D05@iki.fi> <87lgaznt2h.wl-jch@irif.fr> <87h8lnnrkr.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.8.2) X-SA-Exim-Connect-IP: 194.100.69.221 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 10:44:20 -0000 On 28 Jun 2018, at 13.17, Juliusz Chroboczek wrote: >> - no sender nonce for node (duh; new node), _or_ >> - no valid hmac (with valid sender nonce) received over time period = of >> (IHU interval * something) > As you note later in your message, we want to allow the sender to = rekey at > any time without delay (e.g. because it has just rebooted). So I'd = say > challenge when: >=20 > - no state for sender; or > - no challenge in the last T seconds AND nonce has changed. This requires nonce to be on the wire though? I was opting on not having = one and have it just be in pseudoheader (one of the design choices). Otherwise it is impossible to distinguish between hmac failure and = (implicit) nonce failure? > - should we challenge when we see old PC, and if so, how do we avoid > getting confused in case of packet reordering? I would prefer not to. So it actually boils down to getting 2 out of 3: (1) fast reboot reaction (2) (minor) DoS resistance (3) no =E2=80=99sender nonce' in non-challenge packets I am personally keen to have (3), (1) and (2) I am more or less = ambivalent about, both are nice to have but just hmac-based spurious = challenge-responces (in (2)) are not end of the world, and typically = routers boot slower than timeouts involved so (1) is probably not an = issue either. (.. or they can use random router ids if they really care = ..) Cheers, -Markus= From nobody Thu Jun 28 04:15:47 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA080130E52 for ; Thu, 28 Jun 2018 04:15:44 -0700 (PDT) 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, 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 rRzxBZk-UZqh for ; Thu, 28 Jun 2018 04:15:43 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05FC912F1A5 for ; Thu, 28 Jun 2018 04:15:42 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5SBEupi014343; Thu, 28 Jun 2018 13:14:56 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id DBD8FEB22E; Thu, 28 Jun 2018 13:15:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id pYZ7a0JGjQpf; Thu, 28 Jun 2018 13:15:36 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 50B2CEB200; Thu, 28 Jun 2018 13:15:31 +0200 (CEST) Date: Thu, 28 Jun 2018 13:15:31 +0200 Message-ID: <87efgrnovg.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: David Schinazi , babel@ietf.org In-Reply-To: <521CBB64-7A4C-497B-AF71-1E23344FC7E6@iki.fi> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <6DBB10F7-6F1B-4909-894D-16FCD2C7DEF0@iki.fi> <3D958DDA-4382-45AB-B87D-3B93EF330D05@iki.fi> <87lgaznt2h.wl-jch@irif.fr> <87h8lnnrkr.wl-jch@irif.fr> <521CBB64-7A4C-497B-AF71-1E23344FC7E6@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 28 Jun 2018 13:14:56 +0200 (CEST) X-Miltered: at korolev with ID 5B34C330.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B34C330.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B34C330.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 11:15:45 -0000 >> challenge when: >> >> - no state for sender; or >> - no challenge in the last T seconds AND nonce has changed. > This requires nonce to be on the wire though? I was opting on not having > one and have it just be in pseudoheader (one of the design choices). Yes, that's what I'm considering right now, since I really like the property that a spoofed packet (HMAC failure) is dropped right away, it reduces the attack surface and makes it easier to review the code. I haven't spoken with Clara and Weronika yet, though, and they might convince me otherwise. To put it differently -- what we're trying to do here is to design a protocol that is simple to implement safely (i.e. that can be implemented by a reasonably competent fourth year student). Dropping packets with bad HMAC early means that you only need to review for parser vulnerabilities the code that deals with HMAC. > So it actually boils down to getting 2 out of 3: > (1) fast reboot reaction > (2) (minor) DoS resistance > (3) no ’sender nonce' in non-challenge packets > I am personally keen to have (3), I'd like to have (3) if it is compatible with the property above. I'll rather drop (3) than the property above, unless one of youse convinces me otherwise. I do care about (1), since it allows frequent rekeying without any protocol changes (which might turn out handy if we wish to mitigate a vulnerability we find in the future). I don't care about (2), it's a red herring, since we'll need to do rate limiting in any case. (Sorry for the length of this message, I didn't have time to make it shorter.) -- Juliusz From nobody Thu Jun 28 04:20:47 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E10130E52 for ; Thu, 28 Jun 2018 04:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 ygbM2iSnxYDE for ; Thu, 28 Jun 2018 04:20:43 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9AE012F1A5 for ; Thu, 28 Jun 2018 04:20:42 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1530184841; bh=9S07aVwEDhKeOEkMqGZMXwp59Y49P0o2sIwZxjEQ8ag=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=AgB6Jqm8D33IRi3/JQNexBkP2X6EBfLTORaHKZx6UqJ1Cbv82cQkVBnd9J1Mdfpag HxU4yFFMC6u9Xqo4rguUpkN6PgHOmdTIEYIZYn3Yo4HPQJlSgPy8U9dAfs7v+DzTqn F5nt8mkgBYZV1+rRzBv0s+Euu77OLPiIwJ7YOB4ogtQCoznvhLfHN4GBB6vy+rpOEh 2kdPv+UjncGdNuEDSeHDn1rPNbllxcF/9kQM5kzFunlCU/VYr048YE87xpCLdLmnav S88sc+4RE80m0DIoW9ya/w4nbTOoey1PsUjEkRJDlvI7QZ9zrLcYs/eqSTDQTs/XuJ 0v8muxCacUbeQ== To: Juliusz Chroboczek , Markus Stenberg Cc: David Schinazi , babel@ietf.org In-Reply-To: <87efgrnovg.wl-jch@irif.fr> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <6DBB10F7-6F1B-4909-894D-16FCD2C7DEF0@iki.fi> <3D958DDA-4382-45AB-B87D-3B93EF330D05@iki.fi> <87lgaznt2h.wl-jch@irif.fr> <87h8lnnrkr.wl-jch@irif.fr> <521CBB64-7A4C-497B-AF71-1E23344FC7E6@iki.fi> <87efgrnovg.wl-jch@irif.fr> Date: Thu, 28 Jun 2018 13:20:47 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87woujjgxc.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 11:20:45 -0000 Juliusz Chroboczek writes: > Dropping packets with bad HMAC early means that you only need to > review for parser vulnerabilities the code that deals with HMAC. The implicit assumption here being that if someone knows the HMAC key they are going to 'be nice', and not try to crack your parser? Is that really a safe assumption if one wants to build a robust parser? :) -Toke From nobody Thu Jun 28 04:29:47 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA425130EC4 for ; Thu, 28 Jun 2018 04:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kapsi.fi 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 1FcEg_PU7ETV for ; Thu, 28 Jun 2018 04:29:43 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (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 DD140130F5F for ; Thu, 28 Jun 2018 04:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=YuwnI08s2R/ymg8XpxS5GmLVCneZfZ6Y3fqubmZn/qQ=; b=VxMDnbe8FMNoboXZ6vzOWuScEqNYC99Fokz89ae62ARyc43nXEFXBEcoGirdcjfOAiFVWKNBoWrVxJjiZ36n8TmlzJpwyD9dJMEEUK4PfX2vETMk/q8uDXaY82MbDkD4cC+HgWcsW5TfPTtcASX+JIoJ77BuCOyOc7YAuipVfbhyx0dRiV9kbVFZvcu6tLvneAD1fipARFfQCxr7mxz5CQAVMtw/eoVW8tMj1nIyrxJ83gmmQQQUoCje/kn0fxif5V5j+X875LtrJTowIQwQYmMKmd/9nWAJqrpktALYhLv9tHD/JLeaTm0Q1TeGT3gegeoEuYNyrUrrMrvo1nrkdw==; Received: from [194.100.69.221] (helo=[172.20.21.37]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fYV7J-0008Ur-NK; Thu, 28 Jun 2018 14:29:37 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Markus Stenberg In-Reply-To: <87woujjgxc.fsf@toke.dk> Date: Thu, 28 Jun 2018 14:29:37 +0300 Cc: Juliusz Chroboczek , David Schinazi , babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <6DBB10F7-6F1B-4909-894D-16FCD2C7DEF0@iki.fi> <3D958DDA-4382-45AB-B87D-3B93EF330D05@iki.fi> <87lgaznt2h.wl-jch@irif.fr> <87h8lnnrkr.wl-jch@irif.fr> <521CBB64-7A4C-497B-AF71-1E23344FC7E6@iki.fi> <87efgrnovg.wl-jch@irif.fr> <87woujjgxc.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3445.8.2) X-SA-Exim-Connect-IP: 194.100.69.221 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 11:29:46 -0000 On 28 Jun 2018, at 14.20, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: > Juliusz Chroboczek writes: >> Dropping packets with bad HMAC early means that you only need to >> review for parser vulnerabilities the code that deals with HMAC. > The implicit assumption here being that if someone knows the HMAC key > they are going to 'be nice', and not try to crack your parser? Is that > really a safe assumption if one wants to build a robust parser? :) I think that is bit of an optimistic view as well. While in idealistic = OSImodel++ world one would have security in a separate (simple) layer, = in real world that does not occur in my experience. So responding to Juliusz=E2=80=99s comment on (2) being a red herring (I = agree but also think (1) is one as well), if we go for (1) and (3), the = algorithm turns out to be: challenge iff: - global/per-peer challenge rate limit not exceeded _AND_ - no state for sender _OR_ - HMAC error I do not think it makes the implementation much harder; we need = pseudoheader anyway, and it seems we need challenges, and if those are = present, sending sender nonce in every packet seems wasteful to me. The normal packet reception flow just: - computes pseudoheader, hashes that + what was received, and compares = it with the trailer HMAC.=20 - If success, compare counter,=20 - if too old (modulo replay window if any), drop, otherwise process = normally. - If failure, maybe challenge (see above). Challenge/challenge-response handling would be subset of above; the = sender nonce would be explicit in the packet (for challenge-response) = and zeroed in the pseudoheader and obviously you do not want to trigger = challenges.. :-p It would be interesting to compare implementation complexity/size for = the different design choices actually. I wish I had the time.. With my bit-thrifty hat on but in too much hurry to write _enough_, -Markus= From nobody Thu Jun 28 04:52:20 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C614130F62 for ; Thu, 28 Jun 2018 04:52:18 -0700 (PDT) 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 k9xqbeuiE67W for ; Thu, 28 Jun 2018 04:52:17 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E729212777C for ; Thu, 28 Jun 2018 04:52:16 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w5SBjbe4003447; Thu, 28 Jun 2018 07:52:16 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2jvx3dhjqt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Jun 2018 07:52:15 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w5SBqE8B019854; Thu, 28 Jun 2018 07:52:14 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w5SBq82m019754; Thu, 28 Jun 2018 07:52:08 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 53DC540002B1; Thu, 28 Jun 2018 11:52:08 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30486.vci.att.com (Service) with ESMTPS id 42A3F40002B0; Thu, 28 Jun 2018 11:52:08 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.207]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0399.000; Thu, 28 Jun 2018 07:52:07 -0400 From: "STARK, BARBARA H" To: "'David Schinazi'" , Juliusz Chroboczek CC: Markus Stenberg , "babel@ietf.org" Thread-Topic: [babel] Solving HMAC replay once and for all Thread-Index: AQHUDhPvGDbMjOqiXEmQPPQeEO18e6R0UYeAgAAGAQCAAATNgIAAClUAgAAztwCAAEoPAIAACFCAgAADiQCAAADagIAAD5sAgAACzICAAAIsgIAAg7Bw Date: Thu, 28 Jun 2018 11:52:06 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DE10581@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <87bmbvak06.wl-jch@irif.fr> <1D62C61C-C05B-45FE-B031-C9AF99A0D1E9@apple.com> In-Reply-To: <1D62C61C-C05B-45FE-B031-C9AF99A0D1E9@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.245.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-28_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=331 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806280136 Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 11:52:19 -0000 > It gives better security properties to devices with clocks or storage bec= ause those devices=20 > do not have their security depend on a randomly generated number being un= ique. I am reading and enjoying this thread. Just to weigh in with my experience = of the likelihood of a device that is intended to do routing having neither= clock nor storage: unlikely. The likelihood of a device vendor who cares a= t all about security producing a router without clock and storage: nil. Routers that care at all about security have at least some minimal firewall= ing capability. The one absolute requirement of anything that claims some f= irewalling is that it be capable of maintaining a timestamped log. So I have no issue with lower security expectations for router without cloc= k or storage. I wouldn't recommend such a device to anyone. Barbara From nobody Thu Jun 28 10:15:09 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91234130F93 for ; Thu, 28 Jun 2018 10:15:07 -0700 (PDT) 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, 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 RNzSVeuIyxhK for ; Thu, 28 Jun 2018 10:15:04 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E12E130E19 for ; Thu, 28 Jun 2018 10:15:04 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5SHDFFW016826; Thu, 28 Jun 2018 19:13:15 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 86B8EEB279; Thu, 28 Jun 2018 19:13:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id QiSOhUM4Yz4y; Thu, 28 Jun 2018 19:13:56 +0200 (CEST) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id AEF5EEB200; Thu, 28 Jun 2018 19:13:53 +0200 (CEST) Date: Thu, 28 Jun 2018 19:13:53 +0200 Message-ID: <87a7rehm0e.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'David Schinazi'" , Markus Stenberg , "babel@ietf.org" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DE10581@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <87bmbvak06.wl-jch@irif.fr> <1D62C61C-C05B-45FE-B031-C9AF99A0D1E9@apple.com> <2D09D61DDFA73D4C884805CC7865E6114DE10581@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 28 Jun 2018 19:13:17 +0200 (CEST) X-Miltered: at korolev with ID 5B35172B.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B35172B.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B35172B.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 17:15:08 -0000 > I am reading and enjoying this thread. Just to weigh in with my > experience of the likelihood of a device that is intended to do routing > having neither clock nor storage: unlikely. Noted, thanks for the input. As far as I know, though, the mesh networking community is using devices with no hardware clock that synchronise their time through the network, and therefore need to participate in routing before they have reliable time. These devices need to be able to bootstrap routing before they have reliable time, even if for some reason they lost their state (e.g. they've been shut down improperly). Perhaps more convincing, using a protocol that does not require persistent state makes the implementation simpler, since reliable persistent state is not completely trivial to do portably. (In part because the part of the filesystem that is persistent differs between devices, in part because devices can crash at any time.) So I'd say that having a protocol that solves the problem in the general case is a net win, and I'm confident we can do that without excessive complexity. We'll have an implementation by tonight, we'll reconsider if it's too ugly. -- Juliusz From nobody Thu Jun 28 10:26:50 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E39D130E9D for ; Thu, 28 Jun 2018 10:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 RFsKZOgLzTPI for ; Thu, 28 Jun 2018 10:26:47 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 E0EF0130E8B for ; Thu, 28 Jun 2018 10:26:46 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id l19-v6so5984601ioj.5 for ; Thu, 28 Jun 2018 10:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=79IQmrJfvtJdFyi3L3Jwqs9jTyxD4WcTl39IxmumLNE=; b=iXF/hfdFM02HKwsqB3u8fWBkPaPxeu2rBrLnkR2XmilHtbTD4mDoRLVyN8TpxDsDSg VT3wpm9RXiA/9/XIGbbReShO1EaFPJshIKDVhZNxeN8GJQZODV1JzzerV/LsNIzwK6NZ xoEY873lNK4mqUTsmnQywcllylWCGfOJExt5oez8kd7aFAbsiJapAMIRRvDLE8rbMWAn CYrJaRGMGUnwx4+OlZ8prYokBHHYKeP29BSBZz3xAcEszhbSHr41ndVKsO/RrHqrXt+B t5cQQZeiKlm2uKLOyLrHz0T9stVojZS20EmAQ1NGvWW7jz4awOqm+rd7rdzYYzqoxdy3 jBRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=79IQmrJfvtJdFyi3L3Jwqs9jTyxD4WcTl39IxmumLNE=; b=VS94J5c+ikyLvyABchcMBzloHdx4w7GGeFsvCWx+j25JbIf+QQX2Gb4IchjF2FTLtP qMYxDgBezzafA3WK6Qn98RR1KW1R+0UrfFkt46ve9RuTptFFcTrjMsNMC75ALwu0S5+O hGW6bwiZh/LdRWE53ZUmF4Yt3R6Lep09b+eqWXcGCWKlTooXlHCWaRKIAGl4xQkZIPY/ vMkL14gXWl6CvqLcIdUxKOFDwZSphNX81qMQ2HDVNB0cxMUpVi8+s5WCSfZtheplL3Q+ sjgJxUpvh0Ji7HG+Nr+ttkME4FOcDGlDh8ztTWXP/1VIFLsfp2CC75zN+2xvC/oC3KW5 me7g== X-Gm-Message-State: APt69E0Ur68fqKhe39v2rEMWEeXPOptK7sk2dH7UDhOhLXiN+JLRcXxl Y53n4vHm7eZDUlkmWkC9X1vDkeniTUAYAAlKv4nFFg== X-Google-Smtp-Source: AAOMgpdXvb1Nw4o2unRZ1B43U5xUJD4qRCX/sprpY/c8nmQ18bT482tbZu5AU9s4KSHXdONUor/FHukIP++gHwC1lRA= X-Received: by 2002:a6b:b387:: with SMTP id c129-v6mr9868463iof.32.1530206806030; Thu, 28 Jun 2018 10:26:46 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5406:0:0:0:0:0 with HTTP; Thu, 28 Jun 2018 10:26:05 -0700 (PDT) In-Reply-To: <87a7rehm0e.wl-jch@irif.fr> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <87bmbvak06.wl-jch@irif.fr> <1D62C61C-C05B-45FE-B031-C9AF99A0D1E9@apple.com> <2D09D61DDFA73D4C884805CC7865E6114DE10581@GAALPA1MSGUSRBF.ITServices.sbc.com> <87a7rehm0e.wl-jch@irif.fr> From: Ted Lemon Date: Thu, 28 Jun 2018 12:26:05 -0500 Message-ID: To: Juliusz Chroboczek Cc: "STARK, BARBARA H" , Markus Stenberg , David Schinazi , "babel@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001b7387056fb709c9" Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 17:26:49 -0000 --0000000000001b7387056fb709c9 Content-Type: text/plain; charset="UTF-8" How is it that devices of this type manage to keep their clocks synchronized for transmit and receive slot synchronization if they don't have clocks? On Thu, Jun 28, 2018 at 12:13 PM, Juliusz Chroboczek wrote: > > I am reading and enjoying this thread. Just to weigh in with my > > experience of the likelihood of a device that is intended to do routing > > having neither clock nor storage: unlikely. > > Noted, thanks for the input. > > As far as I know, though, the mesh networking community is using devices > with no hardware clock that synchronise their time through the network, > and therefore need to participate in routing before they have reliable > time. These devices need to be able to bootstrap routing before they have > reliable time, even if for some reason they lost their state (e.g. they've > been shut down improperly). > > Perhaps more convincing, using a protocol that does not require persistent > state makes the implementation simpler, since reliable persistent state is > not completely trivial to do portably. (In part because the part of the > filesystem that is persistent differs between devices, in part because > devices can crash at any time.) > > So I'd say that having a protocol that solves the problem in the general > case is a net win, and I'm confident we can do that without excessive > complexity. We'll have an implementation by tonight, we'll reconsider if > it's too ugly. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --0000000000001b7387056fb709c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
How is it that devices of this type manage to keep their c= locks synchronized for transmit and receive slot synchronization if they do= n't have clocks?

On Thu, Jun 28, 2018 at 12:13 PM, Juliusz Chroboczek <jch@irif.fr&g= t; wrote:
> I am reading and en= joying this thread. Just to weigh in with my
> experience of the likelihood of a device that is intended to do routin= g
> having neither clock nor storage: unlikely.

Noted, thanks for the input.

As far as I know, though, the mesh networking community is using devices with no hardware clock that synchronise their time through the network,
and therefore need to participate in routing before they have reliable
time.=C2=A0 These devices need to be able to bootstrap routing before they = have
reliable time, even if for some reason they lost their state (e.g. they'= ;ve
been shut down improperly).

Perhaps more convincing, using a protocol that does not require persistent<= br> state makes the implementation simpler, since reliable persistent state is<= br> not completely trivial to do portably.=C2=A0 (In part because the part of t= he
filesystem that is persistent differs between devices, in part because
devices can crash at any time.)

So I'd say that having a protocol that solves the problem in the genera= l
case is a net win, and I'm confident we can do that without excessive complexity.=C2=A0 We'll have an implementation by tonight, we'll re= consider if
it's too ugly.

-- Juliusz

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel

--0000000000001b7387056fb709c9-- From nobody Thu Jun 28 13:49:56 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB8F130E1D for ; Thu, 28 Jun 2018 13:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 PMvEYqVzoQO2 for ; Thu, 28 Jun 2018 13:49:53 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC6F1130E12 for ; Thu, 28 Jun 2018 13:49:52 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1530218986; bh=aLvUVL3fMymZp93jmdW3vUYTs7UC/zs4lEew/2s/Mfw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Z81iXoOJ/GrzSe4vCup9gLdNDlnkoscNf37ttfQTFArbuePX97nfxP3S1+94uSjcN k3wtUjq279PKMg1ZA4XTE0saBRscGrSiCSrYEBZmbTwLTbh9T3TUOgfchjNRmYGkmD zpdE1TBdswJm3RKSdQFgOozIHnthi0rIfuG0pMCcgDRqNCrp15UnbK5b3mrOLiVPTi pzrCwBc8ZW3XaPQ1lIJtHhCnifw3gFBFjibJk3C+8FoGnKpQlWlw5PXDUUOYKQ+06a Q1AKnFqxVVTQDHjwdjFD63ce2Z+WRTfg5mV4XpWkZQ66rWxIq3V6bzdHhiP5mpEaIb DXPDAfAnXN0Dw== To: Ted Lemon , Juliusz Chroboczek Cc: Markus Stenberg , "STARK\, BARBARA H" , "babel\@ietf.org" , David Schinazi In-Reply-To: References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <87bmbvak06.wl-jch@irif.fr> <1D62C61C-C05B-45FE-B031-C9AF99A0D1E9@apple.com> <2D09D61DDFA73D4C884805CC7865E6114DE10581@GAALPA1MSGUSRBF.ITServices.sbc.com> <87a7rehm0e.wl-jch@irif.fr> Date: Thu, 28 Jun 2018 22:49:50 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87lgayk55d.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 20:49:55 -0000 Ted Lemon writes: > How is it that devices of this type manage to keep their clocks > synchronized for transmit and receive slot synchronization if they > don't have clocks? They have clocks; just not battery-backed RTCs. So a device will keep time while it's powered off, but lose it when power cycling / rebooting. For WiFi rx/tx, the WiFi hardware generally has its own internal clock, though, which has nothing to do with system time... -Toke From nobody Thu Jun 28 14:39:28 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E4B1310D1 for ; Thu, 28 Jun 2018 14:39:26 -0700 (PDT) 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, 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 MY8zXHqco8fp for ; Thu, 28 Jun 2018 14:39:23 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866A4130E2B for ; Thu, 28 Jun 2018 14:39:23 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5SLcd0u012860 for ; Thu, 28 Jun 2018 23:38:39 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 0DC79EB22E for ; Thu, 28 Jun 2018 23:39:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 8S9s7N9cQSaE for ; Thu, 28 Jun 2018 23:39:20 +0200 (CEST) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id F3735EB22D for ; Thu, 28 Jun 2018 23:39:19 +0200 (CEST) Date: Thu, 28 Jun 2018 23:39:19 +0200 Message-ID: <87y3eyfv5k.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 28 Jun 2018 23:38:39 +0200 (CEST) X-Miltered: at korolev with ID 5B35555F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B35555F.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B35555F.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Some news about HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 21:39:27 -0000 The previous thread might be overwhelming to some, so let me summarise. My personal understanding, of course, not necessarily representing WG consensus. We've got a new HMAC protocol, heavily based on Denis Ovsienko's work but significantly reworked by Clara Dô, Weronika KoÅ‚odziejak and myself with important ideas due to Markus Stenberg and David Schinazi, and significant input from Toke Høyland-Jørgensen and a colleagues here in Paris (Florian Horn). I think everyone involved is convinced the protocol is not vulnerable to replay even in the absence of a hardware clock or persistent storage. There are three variants: - the Do-KoÅ‚odziejak-Chroboczek variant, that uses an explicit tag ("nonce") in every packet; - the Stenberg variant, that only encodes the tag in the challenge response, and then makes it explicit; - the Schinazi variant, which combines the tag with the packet counter. We've had a telephone chat with David, and we've come up with the following: - the Schinazi variant doesn't buy us much, and is more difficult to explain; David can live with the DKC variant; - the term "sender's nonce" is badly chosen, David suggests "index", but I'm thinking about using "tag"; the receiver's nonce remains a nonce; - both David and I prefer the more explicit DKC variant, but we're still looking at the Stenberg variant. The plan is to implement and document the DKC variant, and then put the discussion to the list. At any rate, the implementation should be easy to convert to the Stenberg style if that's what the WG settles on. Clara and Weronika are telling me that the new protocol is easier to implement than Denis' original proposal, and requires fewer changes to babeld. Their code is mostly complete, but they've still got some bugs, and it's late. We'll try to publish the implementation tomorrow, but no promises. (Thanks to Clara and Weronika, by the way, for agreeing to redo all of their code with a new protocol just three days before the official end of their internship. That would not have been possible without the moral and especially culinary support of the local Lebanese-Iranian food shop.) -- Juliusz From nobody Thu Jun 28 15:56:26 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15433131109 for ; Thu, 28 Jun 2018 15:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 eHeVBLt1tcYv for ; Thu, 28 Jun 2018 15:56:23 -0700 (PDT) Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6E21310AF for ; Thu, 28 Jun 2018 15:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530226582; x=2394140182; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OyqBBw0Yh2AmhZxL9J8Lsr4Fsvy6YaEalZMrBTan2pM=; b=Na7N1f2nGcG4ZfrJ+omfoUHMGxp7PX+WPhxpAwumW8nwlQCUp2cRl6/d0xAnpquH NS8ROvcA+sGy/r91fFybj9jVh94QehhGqnH7XnbcMzcSu/nE4ygGzw0OjoFRd1QY F8GzWhwwhpfnMXLplavixbEOad54ujdw0mBxcQhH2/FM+0nS0ZkW48A4zARp9i7s 2ddIbg8+WZ1oypc7OyIH5b+0+11KXy2/N8/jy8IWsB6P4iBcF6X0rEz10BOsLByM TYw6sKDlqU8KLekZFVzIZvSj+1wzPEeDqykcDI0tY0GBHGxNzod0KrxBCh5CdaYL irGaoDNDevbOuc3vY4kTcQ==; X-AuditID: 11ab0218-0e9ff70000001a2c-36-5b35679595f1 Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id 51.21.06700.697653B5; Thu, 28 Jun 2018 15:56:22 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PB20033F2DXPX70@mr2-mtap-s03.rno.apple.com>; Thu, 28 Jun 2018 15:56:21 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB200L001X84H00@nwk-mmpp-sz11.apple.com>; Thu, 28 Jun 2018 15:56:21 -0700 (PDT) X-Va-CD: 0 X-Va-ID: 87b5bb18-a47e-44f6-81a4-4aff41e22bfd X-V-A: X-V-T-CD: 7d6566e1ce32e60bd701207e1252a9a5 X-V-E-CD: db47dcd586405c26aa3f4faa8be88c61 X-V-R-CD: 21b5b7e7529fd15e0f95d5f96ec49c1b X-V-CD: 0 X-V-ID: a0b5c3d4-0ede-4cba-a1a5-0c64d5b81470 Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB200L001WZ3S00@nwk-mmpp-sz11.apple.com>; Thu, 28 Jun 2018 15:56:16 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-28_08:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp16.corp.apple.com-10000_instance1 Received: from [17.234.14.49] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PB2001NK2DSTIA0@nwk-mmpp-sz11.apple.com>; Thu, 28 Jun 2018 15:56:16 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87y3eyfv5k.wl-jch@irif.fr> Date: Thu, 28 Jun 2018 15:56:15 -0700 Cc: babel@ietf.org Content-transfer-encoding: quoted-printable Message-id: References: <87y3eyfv5k.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUiuPlRu+60dNNog1s7hC22LOpmsZjfuozN gcljyZKfTB6Lt7xlDGCK4rJJSc3JLEst0rdL4Mp4evQhY8EkqYql9xuZGhifiHQxcnJICJhI nJ65nqmLkYtDSOAgk8SkuxPZQBK8AoISPybfY+li5OBgFlCXmDIlF6JmPZPEopczoRq6mCTO tSxlhZjEJbFg62koW1fi/+47LBA2m8T6E0uYIGwtiafbn7PC2Is/PmODsVedXg9Vwylx/stE dghbR+Lc/fcsEMs6mSTevZrHCJHIlthwu5MZwg6WuL6lDaxBSOALo8SUCWCLhQWkJbou3GUF +UBYQFPi2HUrEJMNaNeBNUYgJqeAhsTpC+BwYBFQlZj78QPYEGYBIYkz12awQNjaEk/eXWCF BImNxK6rXUwQi9Ql/j+eAXa9iICKxPJpz6AuVpToX3OIbQKj7CykUJyFCMVZSKYuYGRexSic m5iZo5uZZ2Sil1hQkJOql5yfu4kRFMermSR2MH55bXiIUYCDUYmHV+G6SbQQa2JZcWXuIUZp DhYlcd6Pu8SihQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDGC/hr3fy56LHo+r/y6oJR5r27 N23KUrjYlny3+0/z6do93d2TleP0zZ+qs04Jv191ykV2mqrHoY4Tbor/jHZ5ZGvPcBHMyGV2 Wuf73pf/+UWJojMa83+VF1v++DfhTU/AG67TlyocmF3qV/ds2JGuHym5Tf3epU6DCSs/yrkH H9vVFfNQwluJpTgj0VCLuag4EQBUSazYxAIAAA== Archived-At: Subject: Re: [babel] Some news about HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 22:56:26 -0000 I agree with Juliusz's summary. I like the DKC variant, it has slightly less configuration knobs than = mine but it reduces complexity which is a good tradeoff. I'll try to find time to implement it before Montreal. The Stenberg variant makes me uneasy because it loses the property of completely ignoring any message with a bad MAC, and that opens up our attack surface to parser bugs. Regarding terminology, I prefer "index" to "tag" because "tag" makes me think about "authentication tag" which is how some protocols refer to the MAC, and we also have a MAC in this protocol. But I can live with "tag", it's better than "nonce". Great work Clara and Weronika, congratulations! David > On Jun 28, 2018, at 14:39, Juliusz Chroboczek wrote: >=20 > The previous thread might be overwhelming to some, so let me = summarise. > My personal understanding, of course, not necessarily representing WG > consensus. >=20 > We've got a new HMAC protocol, heavily based on Denis Ovsienko's work = but > significantly reworked by Clara D=C3=B4, Weronika Ko=C5=82odziejak and = myself with > important ideas due to Markus Stenberg and David Schinazi, and = significant > input from Toke H=C3=B8yland-J=C3=B8rgensen and a colleagues here in = Paris (Florian > Horn). I think everyone involved is convinced the protocol is not > vulnerable to replay even in the absence of a hardware clock or = persistent > storage. >=20 > There are three variants: >=20 > - the Do-Ko=C5=82odziejak-Chroboczek variant, that uses an explicit = tag > ("nonce") in every packet; > - the Stenberg variant, that only encodes the tag in the challenge > response, and then makes it explicit; > - the Schinazi variant, which combines the tag with the packet = counter. >=20 > We've had a telephone chat with David, and we've come up with the > following: >=20 > - the Schinazi variant doesn't buy us much, and is more difficult to > explain; David can live with the DKC variant; > - the term "sender's nonce" is badly chosen, David suggests "index", = but > I'm thinking about using "tag"; the receiver's nonce remains a = nonce; > - both David and I prefer the more explicit DKC variant, but we're = still > looking at the Stenberg variant. >=20 > The plan is to implement and document the DKC variant, and then put = the > discussion to the list. At any rate, the implementation should be = easy to > convert to the Stenberg style if that's what the WG settles on. >=20 > Clara and Weronika are telling me that the new protocol is easier to > implement than Denis' original proposal, and requires fewer changes to > babeld. Their code is mostly complete, but they've still got some = bugs, > and it's late. We'll try to publish the implementation tomorrow, but = no > promises. >=20 > (Thanks to Clara and Weronika, by the way, for agreeing to redo all of > their code with a new protocol just three days before the official end = of > their internship. That would not have been possible without the moral = and > especially culinary support of the local Lebanese-Iranian food shop.) >=20 > -- Juliusz >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Thu Jun 28 17:01:32 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FAF130E3F for ; Thu, 28 Jun 2018 17:01:29 -0700 (PDT) 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, 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 Nxy2vyg9RaRW for ; Thu, 28 Jun 2018 17:01:28 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5EDC130DF1 for ; Thu, 28 Jun 2018 17:01:27 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5T00if3016502 for ; Fri, 29 Jun 2018 02:00:44 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C820BEB22D for ; Fri, 29 Jun 2018 02:01:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 3xvJU-PmEExo for ; Fri, 29 Jun 2018 02:01:24 +0200 (CEST) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id CCBE0EB200 for ; Fri, 29 Jun 2018 02:01:24 +0200 (CEST) Date: Fri, 29 Jun 2018 02:01:24 +0200 Message-ID: <87o9fufokr.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 29 Jun 2018 02:00:44 +0200 (CEST) X-Miltered: at korolev with ID 5B3576AC.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B3576AC.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B3576AC.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Some more questions about HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 00:01:30 -0000 1. Is it legal for multiple PC/INDEX TLVs to appear in a single packet? On the one hand, allowing it does not seem to cause any security issues. On the other hand, it doesn't seem to give any extra flexibility. We currently ignore all PC/INDEX except the last one. It's a simple change to drop any packet with multiple PC/INDEX TLVs. Suggestion: the sender MUST NOT but the receiver need not detect that case. 2. Can the PC/INDEX TLVs appear before any CHALLENGE_RESPONSE? If they can, you need to parse the whole packet before taking a decision. If we say that CHALLENGE_RESPONSE MUST appear before any PC/INDEX, then you can send the challenge and drop the packet as soon as you see an invalid PC/INDEX. We're currently taking the decision at the end of the packet (and incidentally sending the TLVs in the wrong order). 3. How do we encode CHALLENGE_REQUEST/CHALLENGE_RESPONSE? We're currently using a whole new TLV pair, which simplifies the first parsing pass (the one that happens after we've validated HMAC but before we've decided whether to accept the packet). Other possibilities: use sub-TLVs of ACK_REQUEST and ACK_REPLY. C and W want to keep the separate TLV, which makes sense to me, as this keeps the TLVs of the two passes separate (you either handle a TLV in the first pass and ignore it in the main pass, or the opposite). From nobody Thu Jun 28 17:15:16 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4066130E3F for ; Thu, 28 Jun 2018 17:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 C7OhYUlFKizo for ; Thu, 28 Jun 2018 17:15:12 -0700 (PDT) Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19356130E37 for ; Thu, 28 Jun 2018 17:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530231310; x=2394144910; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XscVug8uTkP43e8HUue8VZudt2AIdF70sld20UlwdMk=; b=K7EXKIoW4jYX+xMHNiVYZ+cSV50XqddXqlrCZbf9ITNTVPyWDnKS+rIXii8mtkMQ oZMLdzt+OLeEvkqmooXG0UaElo+46qqcZ1e6YAQLW+p7d6yPYVwpOrktcfuQDlhb F8osv3Nh/ZRBEQcI+wyPr9mRClYaiCOXkzxOGiuQ1fAGc4aNs2kUSWVftifMcsNF DHg0uF6uLm2XN4ivG72JpmHguxIsHNeCFV3hiFbbViMty7+Xfy6L0y6HSW7F6PF8 MHK/mDEURkscE++vHLIGrf46t8GeFJa7AkAJQBIjpjZ6RVeNlV/M/9uhUwTKHvzJ vgk0qyQgBfLrJvReat5Ubg==; X-AuditID: 11ab0218-0e9ff70000001a2c-c5-5b357a0d34f1 Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id 0A.45.06700.E0A753B5; Thu, 28 Jun 2018 17:15:10 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PB200GNL619ZL80@mr2-mtap-s03.rno.apple.com>; Thu, 28 Jun 2018 17:15:09 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB2007005P18T00@nwk-mmpp-sz10.apple.com>; Thu, 28 Jun 2018 17:15:09 -0700 (PDT) X-Va-CD: 0 X-Va-ID: 15e1b9d3-7493-4ccd-8733-525617ffd6de X-V-A: X-V-T-CD: 7d6566e1ce32e60bd701207e1252a9a5 X-V-E-CD: 28a808d8b71207f83bd52b7f03b7bde9 X-V-R-CD: c95b7414da15920b280d56e8433d1e18 X-V-CD: 0 X-V-ID: 5306919c-de4e-404a-9800-634b1d1cae50 Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB2008005VLXQ00@nwk-mmpp-sz10.apple.com>; Thu, 28 Jun 2018 17:15:05 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-28_08:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp16.corp.apple.com-10000_instance1 Received: from [17.234.14.49] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PB20027R6156B10@nwk-mmpp-sz10.apple.com>; Thu, 28 Jun 2018 17:15:05 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87o9fufokr.wl-jch@irif.fr> Date: Thu, 28 Jun 2018 17:15:04 -0700 Cc: babel@ietf.org Message-id: <81D01E09-C5ED-4BCB-8A4F-4FA841CB1AD8@apple.com> References: <87o9fufokr.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsUiuPlRuy5flWm0wcut0hZbFnWzWMxvXcbm wOSxZMlPJo/FW94yBjBFcdmkpOZklqUW6dslcGXs/vSAqWCeUMWCw3kNjLv5uhg5OSQETCQu 3mpm7GLk4hASOMgksX56GytIgldAUOLH5HssXYwcHMwC8hIHz8uChJkFtCS+P2plgahfzyRx b+MRdgini0mi8cZbNoipXBILtp5mBWmWENCVWPLaBSLMJrH+xBImCFtL4un256ww9sRzsxkh yrUkfmyUgghzSpz/MpEdIqwj8W5vOcSmTiaJ9nkzWSBqsiU23O5khrCDJa5vaYM65wujxK1T F8DmCwtIS3RduAt2jrCAscS3lnAQkw1o1YE1RiAVnAIaEq8PTAYbySKgKnHr/ApGiHeFJM5c m8ECCREbiUXXJ4NNFBJQl3jceQtsrYiAisTyac/YIU5QlOhfc4htAqPsLKRAnIUIxFlIgbiA kXkVo3BuYmaObmaekYleYkFBTqpecn7uJkZQDK9mktjB+OW14SFGAQ5GJR5ehesm0UKsiWXF lbmHGKU5WJTEeT/uEosWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwCiRdiFv71u7p0+lmd9e iEpyeRvE2XJty0XL6P7X7f9PfFb3tVt3q0fxNmdG4K5gC8PvbuoTcq8xpPrJ8mYnPU61ubo2 t9hWbMPSx4GPZiixPmfg6Qm5reB7qqfQPSF8nfYclWWVl1+KL+zce9EtK+LZ7u+h3u/abs3a 591f29xmGSt+qcDRV4mlOCPRUIu5qDgRAIlzjWzCAgAA Archived-At: Subject: Re: [babel] Some more questions about HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 00:15:14 -0000 > On Jun 28, 2018, at 17:01, Juliusz Chroboczek wrote: > > 1. Is it legal for multiple PC/INDEX TLVs to appear in a single packet? > > On the one hand, allowing it does not seem to cause any security issues. > On the other hand, it doesn't seem to give any extra flexibility. > > We currently ignore all PC/INDEX except the last one. It's a simple > change to drop any packet with multiple PC/INDEX TLVs. > > Suggestion: the sender MUST NOT but the receiver need not detect that case. Sounds good to me. We could add "receiver MUST silently ignore any PC/INDEX after the first one to allow future extensibility? It doesn't get us anything today but it also doesn't complicate things much - I could go either way. > 2. Can the PC/INDEX TLVs appear before any CHALLENGE_RESPONSE? > > If they can, you need to parse the whole packet before taking a decision. > If we say that CHALLENGE_RESPONSE MUST appear before any PC/INDEX, then > you can send the challenge and drop the packet as soon as you see an > invalid PC/INDEX. > > We're currently taking the decision at the end of the packet (and > incidentally sending the TLVs in the wrong order). As far as I know today Babel has no requirement of ordering of TLVs (apart from updating the parser state for compression). I'd prefer leaving the ordering open to implementors. Technically an implementation can decide to not reparse a packet that had a valid challenge response, it'll be like a packet loss. > 3. How do we encode CHALLENGE_REQUEST/CHALLENGE_RESPONSE? > > We're currently using a whole new TLV pair, which simplifies the first > parsing pass (the one that happens after we've validated HMAC but before > we've decided whether to accept the packet). Other possibilities: use > sub-TLVs of ACK_REQUEST and ACK_REPLY. > > C and W want to keep the separate TLV, which makes sense to me, as this > keeps the TLVs of the two passes separate (you either handle a TLV in the > first pass and ignore it in the main pass, or the opposite). I prefer using brand new TLVs because they are the only ones that are allowed to be parsed when the PC/INDEX is wrong or unknown. If we want to save a slot in the registry we could have one CHALLENGE TLV that has a bit in it to indicate request or response. David From nobody Thu Jun 28 17:56:53 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0868D130E40 for ; Thu, 28 Jun 2018 17:56:52 -0700 (PDT) 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, 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 5MmBnLvUfDGa for ; Thu, 28 Jun 2018 17:56:50 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1793130DEF for ; Thu, 28 Jun 2018 17:56:49 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5T0u36J026633; Fri, 29 Jun 2018 02:56:03 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 381CDEB22D; Fri, 29 Jun 2018 02:56:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id m7jB-rmmI5xC; Fri, 29 Jun 2018 02:56:44 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1379DEB200; Fri, 29 Jun 2018 02:56:44 +0200 (CEST) Date: Fri, 29 Jun 2018 02:56:43 +0200 Message-ID: <874lhm76lw.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: babel@ietf.org In-Reply-To: <81D01E09-C5ED-4BCB-8A4F-4FA841CB1AD8@apple.com> References: <87o9fufokr.wl-jch@irif.fr> <81D01E09-C5ED-4BCB-8A4F-4FA841CB1AD8@apple.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 29 Jun 2018 02:56:03 +0200 (CEST) X-Miltered: at korolev with ID 5B3583A3.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B3583A3.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B3583A3.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Some more questions about HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 00:56:52 -0000 >> 2. Can the PC/INDEX TLVs appear before any CHALLENGE_RESPONSE? > Technically an implementation can decide to not reparse a packet that > had a valid challenge response, it'll be like a packet loss. No, you cannot do that -- you need to handle the PC/INDEX in order to reset your per-peer state. And you don't need to reparse -- you just save the PC/INDEX when you encounter it, and delay acting upon it until you've reached the end of the packet. -- Juliusz From nobody Thu Jun 28 18:04:27 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB17130E44 for ; Thu, 28 Jun 2018 18:04:25 -0700 (PDT) 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, 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 Erc6FjWWyChn for ; Thu, 28 Jun 2018 18:04:23 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC570130E40 for ; Thu, 28 Jun 2018 18:04:22 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5T13dhd027436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 29 Jun 2018 03:03:39 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w5T13pmW025667 for ; Fri, 29 Jun 2018 03:03:52 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 4496CEB22D for ; Fri, 29 Jun 2018 03:04:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id kbZXCnO43Q45 for ; Fri, 29 Jun 2018 03:04:19 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 471E6EB200 for ; Fri, 29 Jun 2018 03:04:19 +0200 (CEST) Date: Fri, 29 Jun 2018 03:04:19 +0200 Message-ID: <8736x67698.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org In-Reply-To: <87y3eyfv5k.wl-jch@irif.fr> References: <87y3eyfv5k.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 29 Jun 2018 03:03:39 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 29 Jun 2018 03:03:52 +0200 (CEST) X-Miltered: at korolev with ID 5B35856B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B358577.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B35856B.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B358577.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B35856B.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B358577.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Some news about HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 01:04:26 -0000 > - the Stenberg variant, that only encodes the tag in the challenge > response, and then makes it explicit; This sentence makes no sense. Sorry. In the Stenberg variant, the index (or tag, or sender's nonce) is only sent in the Challenge Response. In later packets, it is hashed as part of the pseudo-header, but not sent explicitly, on the assumption that the receiver has saved it during the challenge. The advantage is that the index does not need to be sent in every packet, saving 10 octets per packet or so. The disadvantage is that upon an HMAC failure the receiver has no way to distinguish between a spoofed packet and a sender reset, and must therefore send a challenge unconditionally. Unlike David, I rather like the Stenberg variant, but I need to think the implications through. For now, we're implementing the DKC variant, and we'll do the thinking later. -- Juliusz From nobody Thu Jun 28 18:08:18 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68267130DEF for ; Thu, 28 Jun 2018 18:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 tfVNiydM95dg for ; Thu, 28 Jun 2018 18:08:15 -0700 (PDT) Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A743130DDF for ; Thu, 28 Jun 2018 18:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530234494; x=2394148094; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vscmM7lvtmy8/ZT+9yMHQvFYonEJhGgqBK6omodcQLw=; b=EYBiznWcM2KiTdVqoAxHhgjlXK7mXHq7Pt/Wfra6/foZzzDMCbyj3T/BcN5ZxT2+ qZ6XY68l6ZSdqkB0hdmKHUwQuj2/PJ4hUO9BaDtsH1QV2cTLzqtD6Y5CTA2Lb/HX eSOwDviVWcEpbRpPm8o+JIwvqUa/ujoCZY4zkvjfvFP+RL1fBXpG7QQeTOpgxJCu QJ76AgNXUycPwpOXWmOscpx+4J5H3nIbZkdt/oQTpZ8RutyGddkupIQcd2YlPcaX pmB7aLiQ0+0vHCeb3JaBKn2akuml2mMFfGoTbTnh9Ibvk1OnW4oqOXveXHgOYFFw uWonGZ7Iv6yZXoBc/BSVUA==; X-AuditID: 11ab0218-0e9ff70000001a2c-ab-5b35867dd675 Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id 58.D7.06700.E76853B5; Thu, 28 Jun 2018 18:08:14 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PB200B9L8HPRID0@mr2-mtap-s01.rno.apple.com>; Thu, 28 Jun 2018 18:08:13 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB200B0082HFS00@nwk-mmpp-sz10.apple.com>; Thu, 28 Jun 2018 18:08:13 -0700 (PDT) X-Va-CD: 0 X-Va-ID: a8e63af5-7eef-46f0-b706-c63dfc4153e4 X-V-A: X-V-T-CD: 7d6566e1ce32e60bd701207e1252a9a5 X-V-E-CD: db47dcd586405c26aa3f4faa8be88c61 X-V-R-CD: 21b5b7e7529fd15e0f95d5f96ec49c1b X-V-CD: 0 X-V-ID: 3969c4ef-fbda-4999-b14d-7851513eec9c Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB200D00881HQ00@nwk-mmpp-sz10.apple.com>; Thu, 28 Jun 2018 18:08:10 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-28_09:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp14.corp.apple.com-10000_instance1 Received: from [17.234.14.49] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PB200D3N8HM6E70@nwk-mmpp-sz10.apple.com>; Thu, 28 Jun 2018 18:08:10 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <8736x67698.wl-jch@irif.fr> Date: Thu, 28 Jun 2018 18:08:09 -0700 Cc: babel@ietf.org Message-id: <72F35E4A-0C7E-4871-812A-2BB82B887831@apple.com> References: <87y3eyfv5k.wl-jch@irif.fr> <8736x67698.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUiuPlRq25dm2m0wdmvihZbFnWzWMxvXcbm wOSxZMlPJo/FW94yBjBFcdmkpOZklqUW6dslcGXcmuxTMJO54m3/etYGxsNMXYycHBICJhJH ts5j7mLk4hASOMgkMXfXLmaQBK+AoMSPyfdYuhg5OJgF5CUOnpcFCTMLaEl8f9TKAlG/nkni 5tMX7BBOF5PExn3vWSCmckks2HqaFaRZQkBXYmNnJkSYTWL9iSVQi7Uknm5/zgpjL/74jA3G XnV6PVQNp8T5LxPZIWwdiYktLWwQuzqZJN69nsIMkciWuPR2NVRRsMTJdY1gtpDAF0aJ5dPz QGxhAWmJrgt3we4RFtCUOHbdCsRkA9p1YI0RSAWngIbE433nwU5gEVCVWPa8jwXiXyGJM9dm sECCxEbi4+oVUNOdJc62vAQ7X0RARWL5tGdQFyhK9K85xDaBUXYWUijOQoTiLKRQXMDIvIpR ODcxM0c3M8/IRC+xoCAnVS85P3cTIyiKVzNJ7GD88trwEKMAB6MSD6/CdZNoIdbEsuLK3EOM 0hwsSuK8H3eJRQsJpCeWpGanphakFsUXleakFh9iZOLglGpg5HrLsirnbPf9wLW3dW1Zbdsf OHHveGN3r3NNRKDhofmq715wFpntizps4qkTFHlY+9/lfQ5+j7wnbxGNOL/cI1dlt/71WpbK k6W2RlJffk5buPPL1NaSmI4Z8+/xC6/59uWBlOFXy67s5mMau97+F1zneeTR/I4pi7eZRRlt uv2sqtrR9f3UAiWW4oxEQy3mouJEADKTd9vDAgAA Archived-At: Subject: Re: [babel] Some news about HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 01:08:17 -0000 > On Jun 28, 2018, at 18:04, Juliusz Chroboczek wrote: > > Unlike David, I rather like the Stenberg variant, but I need to think the > implications through. For now, we're implementing the DKC variant, and > we'll do the thinking later. I didn't say I didn't like it. I actually think it's very clever. It's just the property that we lose because of it that makes me uneasy. David From nobody Thu Jun 28 18:13:31 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B815130DEF for ; Thu, 28 Jun 2018 18:13:29 -0700 (PDT) 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, 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 Kfzzq4kuP-MS for ; Thu, 28 Jun 2018 18:13:27 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A471129C6A for ; Thu, 28 Jun 2018 18:13:27 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5T1CeAB032623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 Jun 2018 03:12:40 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w5T1CqBh026698; Fri, 29 Jun 2018 03:12:52 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 915CEEB22D; Fri, 29 Jun 2018 03:13:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id EKmugdEnfMSu; Fri, 29 Jun 2018 03:13:19 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 55D17EB200; Fri, 29 Jun 2018 03:13:17 +0200 (CEST) Date: Fri, 29 Jun 2018 03:13:17 +0200 Message-ID: <871scq75ua.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: Markus Stenberg , David Schinazi , babel@ietf.org In-Reply-To: <87woujjgxc.fsf@toke.dk> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <6DBB10F7-6F1B-4909-894D-16FCD2C7DEF0@iki.fi> <3D958DDA-4382-45AB-B87D-3B93EF330D05@iki.fi> <87lgaznt2h.wl-jch@irif.fr> <87h8lnnrkr.wl-jch@irif.fr> <521CBB64-7A4C-497B-AF71-1E23344FC7E6@iki.fi> <87efgrnovg.wl-jch@irif.fr> <87woujjgxc.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 29 Jun 2018 03:12:41 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 29 Jun 2018 03:12:53 +0200 (CEST) X-Miltered: at korolev with ID 5B358788.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B358794.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B358788.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B358794.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B358788.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B358794.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 01:13:30 -0000 >> Dropping packets with bad HMAC early means that you only need to >> review for parser vulnerabilities the code that deals with HMAC. > The implicit assumption here being that if someone knows the HMAC key > they are going to 'be nice', and not try to crack your parser? Is that > really a safe assumption if one wants to build a robust parser? :) No, that's not the assumption. The last 50 years have shown us that no matter how hard we try, security flaws happen, and unlike our predecessors, we no longer have the hubris to think that we can count on writing bug-free code. So we strive to write bug-free code, while at the same time making our best to ensure that, should we fail, our bugs will have no security consequences. I'll put it differently. According to github, there are currently 55 forks of babeld. At least some of these forks make non-trivial changes to the protocol, and I'm not quite sure how secure their code is. I want to make it likely that any bugs that they introduce are as difficult to exploit as possible, and dropping evil packets as early as possible is one of the defenses I'm counting on. -- Juliusz From nobody Thu Jun 28 18:15:27 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AD0130DEF for ; Thu, 28 Jun 2018 18:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 f_3ilGSByEsA for ; Thu, 28 Jun 2018 18:15:23 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51FE4120049 for ; Thu, 28 Jun 2018 18:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1530234923; x=2394148523; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=LKauozoahpVKWFM8LLjAbIngXmNyvPNEJTCF90FBIy0=; b=akcpbsquPUwXO6mN625Gpan0d/ZS8MMvAiyF/40hR1/53B2TmUJCs7zTWcbgUMIi jI1FD/XCOx9Sc5BTAgbaphkz1uMrb6y9dBLQYxd4uQiiCJ6g4pM6RXAxFxhOhP/+ HMmVcXLAW+FFw0TRyEmZVtag5IOvosJg9aiVzvJDtBoJvMqiH63jBls9A/dxbxZg aA/n3WPXPR8WcTVK5wg8RKgIG87u20ozlbEkMitczWLYAWrySxRzfrwriI0R5gC+ gcN9zjqjULIHKdN0tOx4q4t30KACxUtA4CM/yXwnFPIqKj5Gw39rxLrD10wtdwCs Qd69tKYx0AXFiIxXuzny1w==; X-AuditID: 11973e16-6f1ff7000000740c-32-5b35882ac0d6 Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 31.76.29708.A28853B5; Thu, 28 Jun 2018 18:15:23 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PB200INS8TMLS30@mr2-mtap-s01.rno.apple.com>; Thu, 28 Jun 2018 18:15:22 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB200J008RHIO00@nwk-mmpp-sz10.apple.com>; Thu, 28 Jun 2018 18:15:22 -0700 (PDT) X-Va-CD: 0 X-Va-ID: 03a2fe2d-5cf3-4074-b1a3-1779e3899318 X-V-A: X-V-T-CD: 7d6566e1ce32e60bd701207e1252a9a5 X-V-E-CD: 28a808d8b71207f83bd52b7f03b7bde9 X-V-R-CD: c95b7414da15920b280d56e8433d1e18 X-V-CD: 0 X-V-ID: 62357ec2-bf62-4b79-9ef1-094bd1463491 Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PB200G008IRPZ00@nwk-mmpp-sz10.apple.com>; Thu, 28 Jun 2018 18:15:22 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-28_09:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp17.corp.apple.com-10000_instance1 Received: from [17.234.14.49] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PB2002Q88TM6B60@nwk-mmpp-sz10.apple.com>; Thu, 28 Jun 2018 18:15:22 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <874lhm76lw.wl-jch@irif.fr> Date: Thu, 28 Jun 2018 18:15:21 -0700 Cc: babel@ietf.org Message-id: <3B33B533-4355-4553-BEB9-6CE6718EBB06@apple.com> References: <87o9fufokr.wl-jch@irif.fr> <81D01E09-C5ED-4BCB-8A4F-4FA841CB1AD8@apple.com> <874lhm76lw.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUiuPlRq652h2m0wfx+Nosti7pZLOa3LmNz YPJYsuQnk8fiLW8ZA5iiuGxSUnMyy1KL9O0SuDIWvlrOUvCSveL1l1fMDYzz2boYOTkkBEwk bp8/wNrFyMUhJHCASeLr/r8sIAleAUGJH5PvAdkcHMwC8hIHz8uChJkFtCS+P2plgahfzyQx ZfYRRgini0liaeNTZoipXBILtp5mhbB1JVqfT2aCsNkk1p9YAmVrSTzd/pwVxp54bjYjyDIQ +8dGKYgwp8T5LxPZIWwdiaeLe6AO7WSSeLsIZk62xKW3q6GKgiUeTmiDOugLo8SKxS/BFggL SEt0XbjLCrJAWMBY4ltLOIjJBrTrwBojkApOAQ2JGwcWgAOFRUBV4uTMD8wQDwtJnLk2Axom NhJ/n7xmBLGFBMokHi/6B7ZWREBFYvm0Z1AnKEr0rznENoFRdhZSMM5CBOMspGBcwMi8ilEo NzEzRzczz1wvsaAgJ1UvOT93EyMojqfbie1gfLjK6hCjAAejEg+vwnWTaCHWxLLiytxDjNIc LErivGZJptFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGA39tJazry41+yH+spVremOqnjzz oa6zX0113T4sDelmz9rwZpuidMyhhLuh3hcZI7xYMtvlM8/3fn/ZpRZ4L102bsecZ43i856v +7ue+0yAUnb12Zrbt1qKue/dYMn9eP0381rbOQFXwu87Xb4mefHEov/Cq3iu202cZL+2uMhB KCC+843/NiWW4oxEQy3mouJEAMQn1F7EAgAA Archived-At: Subject: Re: [babel] Some more questions about HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 01:15:26 -0000 Agree. I was thinking about reparsing the packet for all the other TLVs, but you're right about the PC/INDEX. But since you need to have parsed both PC/INDEX and CHALLENGE_RESPONSE to update the neighbor's index and PC, I don't think forcing ordering gets us much. David > On Jun 28, 2018, at 17:56, Juliusz Chroboczek wrote: > >>> 2. Can the PC/INDEX TLVs appear before any CHALLENGE_RESPONSE? > >> Technically an implementation can decide to not reparse a packet that >> had a valid challenge response, it'll be like a packet loss. > > No, you cannot do that -- you need to handle the PC/INDEX in order to > reset your per-peer state. > > And you don't need to reparse -- you just save the PC/INDEX when you > encounter it, and delay acting upon it until you've reached the end of the > packet. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Thu Jun 28 18:27:17 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F85F130E3C for ; Thu, 28 Jun 2018 18:27:16 -0700 (PDT) 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, 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 yHN5dXUviXzo for ; Thu, 28 Jun 2018 18:27:15 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA65130DD7 for ; Thu, 28 Jun 2018 18:27:14 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5T1QVbd001827; Fri, 29 Jun 2018 03:26:31 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 38CBAEB22D; Fri, 29 Jun 2018 03:27:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id kuRrQ5WlSpep; Fri, 29 Jun 2018 03:27:12 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 13634EB200; Fri, 29 Jun 2018 03:27:12 +0200 (CEST) Date: Fri, 29 Jun 2018 03:27:06 +0200 Message-ID: <87zhze5qmt.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: babel@ietf.org In-Reply-To: References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <6DBB10F7-6F1B-4909-894D-16FCD2C7DEF0@iki.fi> <3D958DDA-4382-45AB-B87D-3B93EF330D05@iki.fi> <87lgaznt2h.wl-jch@irif.fr> <87h8lnnrkr.wl-jch@irif.fr> <521CBB64-7A4C-497B-AF71-1E23344FC7E6@iki.fi> <87efgrnovg.wl-jch@irif.fr> <87woujjgxc.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 29 Jun 2018 03:26:31 +0200 (CEST) X-Miltered: at korolev with ID 5B358AC7.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B358AC7.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B358AC7.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 01:27:17 -0000 > The normal packet reception flow just: > - computes pseudoheader, hashes that + what was received, and compares it with the trailer HMAC. > - If success, compare counter, > - if too old (modulo replay window if any), drop, otherwise process normally. > - If failure, maybe challenge (see above). Hmm... so now both challenges and challenge replies are unprotected by HMAC (since they need to be acted upon even in case of HMAC failure), right? Therefore, we put them in the packet trailer, so that we can retain the property that we don't parse the packet body before HMAC validation. Implementation complexity is comparable, I think. However, now the Neighbour Table entry is created before HMAC validation (to keep the challenge state), so an evil peer is able to create unbounded amounts of state (by spoofing multiple source addresses). I guess you could avoid that by encoding a cookie in your nonce, but that in turn increases implementation complexity. Am I missing something? -- Juliusz "I'll sleep when I retire" Chroboczek From nobody Thu Jun 28 21:43:00 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34AF3130E5C for ; Thu, 28 Jun 2018 21:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=kapsi.fi 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 CwVjE4GCc-1P for ; Thu, 28 Jun 2018 21:42:55 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (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 777D4129C6A for ; Thu, 28 Jun 2018 21:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=ZPORiZwLGwjRjjvHcwitWdn+VYqjg6sI48OIlLH4DsA=; b=0TvNMWlFyqqQDndoONl3zbbgM2BY8ioBmPWVzOiHk8sYuePa3QrfmS10uda1nJNVqcJfhj8Tk9PVwMGxXAtNRt5gAN53/4BEOFSC2Xt9pyFxvHG8VGafhWeL5aASTIv6sNLc/cmAsKb3wxinU0f+aZvSk8I3hsd0jBEfcxgzp2SXL3vYfWFAlYCz32Ev9DLbhiJ91qPXHCLsTF+u8s1cph9SxBkNTAPTETrkeuzRAL2lNFLcRaPpWLqGFk+dePdCAtYHSx8RN9YidUtibIIOk3iubYNl/pPD0vAIPxzJQDr20JBeOHpkk5GBLLdDGl3KCxKU31/+Gr16zGF4iOOgTQ==; Received: from 91-155-69-32.elisa-laajakaista.fi ([91.155.69.32] helo=[192.168.42.130]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fYlFF-0000Be-M3; Fri, 29 Jun 2018 07:42:53 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Markus Stenberg X-Mailer: iPad Mail (15F79) In-Reply-To: <87zhze5qmt.wl-jch@irif.fr> Date: Fri, 29 Jun 2018 07:42:53 +0300 Cc: babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <67F34700-5A2A-4AE2-A271-A188DBF320AB@iki.fi> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <6DBB10F7-6F1B-4909-894D-16FCD2C7DEF0@iki.fi> <3D958DDA-4382-45AB-B87D-3B93EF330D05@iki.fi> <87lgaznt2h.wl-jch@irif.fr> <87h8lnnrkr.wl-jch@irif.fr> <521CBB64-7A4C-497B-AF71-1E23344FC7E6@iki.fi> <87efgrnovg.wl-jch@irif.fr> <87woujjgxc.fsf@toke.dk> <87zhze5qmt.wl-jch@irif.fr> To: Juliusz Chroboczek X-SA-Exim-Connect-IP: 91.155.69.32 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 04:42:59 -0000 Nah. They have just separate branch which uses explicit sender nonce ( chall= enge-response ) or no sender nonce ( challenge ).=20 -Markus Sent from my preciouss, aka iPad ;) On 29 Jun 2018, at 4.27, Juliusz Chroboczek wrote: >> The normal packet reception flow just: >> - computes pseudoheader, hashes that + what was received, and compares i= t with the trailer HMAC.=20 >> - If success, compare counter,=20 >> - if too old (modulo replay window if any), drop, otherwise process norm= ally. >> - If failure, maybe challenge (see above). >=20 > Hmm... so now both challenges and challenge replies are unprotected by > HMAC (since they need to be acted upon even in case of HMAC failure), > right? Therefore, we put them in the packet trailer, so that we can > retain the property that we don't parse the packet body before HMAC > validation. >=20 > Implementation complexity is comparable, I think. However, now the > Neighbour Table entry is created before HMAC validation (to keep the > challenge state), so an evil peer is able to create unbounded amounts of > state (by spoofing multiple source addresses). I guess you could avoid > that by encoding a cookie in your nonce, but that in turn increases > implementation complexity. >=20 > Am I missing something? >=20 > -- Juliusz "I'll sleep when I retire" Chroboczek >=20 From nobody Thu Jun 28 21:46:44 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D843130E5C for ; Thu, 28 Jun 2018 21:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=kapsi.fi 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 JkWd_8cDTHTR for ; Thu, 28 Jun 2018 21:46:40 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (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 D960C129C6A for ; Thu, 28 Jun 2018 21:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=U1+5u6JS9f7WfJqo1yLuhkU365tOfTG/DHKVqGtjJA4=; b=lHdufeA0YCZfMvmwEiB+M1nd+tJl0mKOZOCyWNLVeenTV3TrhOfjL6tJqATdPjLa5x2wQvWATbydsfKGN1KeHolPPL0251dig+EAEvm0OKeFA81Z2XwwoTpIORdFkTDDdE79brK4XF1PHsj5w5Y4szdfz7YDka0CPOKl/w3As3dImnaluVnSuyTSuuagyffKfpHxdhdBRU+y+FPm0JgyyroxNcYdRlvV/YfH84/XkNMNnFGjqTbLz8P+eKjypccmIifYBqHMeY8Phie4Y/CRX6IGcjzsXpQhpb37LAh1pnm3S+UcYxw4mTX+K3xZIzjHxQcVIWInaXe1nDfqyCY1OQ==; Received: from 91-155-69-32.elisa-laajakaista.fi ([91.155.69.32] helo=[192.168.42.130]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fYlIs-0002BM-7L; Fri, 29 Jun 2018 07:46:38 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Markus Stenberg X-Mailer: iPad Mail (15F79) In-Reply-To: <67F34700-5A2A-4AE2-A271-A188DBF320AB@iki.fi> Date: Fri, 29 Jun 2018 07:46:37 +0300 Cc: babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <6DBB10F7-6F1B-4909-894D-16FCD2C7DEF0@iki.fi> <3D958DDA-4382-45AB-B87D-3B93EF330D05@iki.fi> <87lgaznt2h.wl-jch@irif.fr> <87h8lnnrkr.wl-jch@irif.fr> <521CBB64-7A4C-497B-AF71-1E23344FC7E6@iki.fi> <87efgrnovg.wl-jch@irif.fr> <87woujjgxc.fsf@toke.dk> <87zhze5qmt.wl-jch@irif.fr> <67F34700-5A2A-4AE2-A271-A188DBF320AB@iki.fi> To: Juliusz Chroboczek X-SA-Exim-Connect-IP: 91.155.69.32 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 04:46:42 -0000 I think I prefer the idea of inserting that HMAC handling in the challenge/r= esponse TLV itself so in that case strictly speaking you would have no HMAC T= LV but those messages would be authenticated too.=20 Of course downside is the need to use 2-3 TLVs for HMAC but as they are alre= ady used for security not sure there is much of a difference.=20 -Markus Sent from my preciouss, aka iPad ;) > On 29 Jun 2018, at 7.42, Markus Stenberg wrote: >=20 > Nah. They have just separate branch which uses explicit sender nonce ( cha= llenge-response ) or no sender nonce ( challenge ).=20 >=20 > -Markus >=20 > Sent from my preciouss, aka iPad ;) >=20 >=20 > On 29 Jun 2018, at 4.27, Juliusz Chroboczek wrote: >=20 >>> The normal packet reception flow just: >>> - computes pseudoheader, hashes that + what was received, and compares i= t with the trailer HMAC.=20 >>> - If success, compare counter,=20 >>> - if too old (modulo replay window if any), drop, otherwise process norm= ally. >>> - If failure, maybe challenge (see above). >>=20 >> Hmm... so now both challenges and challenge replies are unprotected by >> HMAC (since they need to be acted upon even in case of HMAC failure), >> right? Therefore, we put them in the packet trailer, so that we can >> retain the property that we don't parse the packet body before HMAC >> validation. >>=20 >> Implementation complexity is comparable, I think. However, now the >> Neighbour Table entry is created before HMAC validation (to keep the >> challenge state), so an evil peer is able to create unbounded amounts of >> state (by spoofing multiple source addresses). I guess you could avoid >> that by encoding a cookie in your nonce, but that in turn increases >> implementation complexity. >>=20 >> Am I missing something? >>=20 >> -- Juliusz "I'll sleep when I retire" Chroboczek >>=20 From nobody Thu Jun 28 21:54:07 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA5C130EB2 for ; Thu, 28 Jun 2018 21:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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=kapsi.fi 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 cCgPKHxfOBBh for ; Thu, 28 Jun 2018 21:53:49 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (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 6CE8D130E77 for ; Thu, 28 Jun 2018 21:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=GMmpwA07HyN4wDAmoz3Z0CG1uekKA1pZIXVdaOMobrg=; b=HlZRCgTKZJTxs3+9D1uLHcSyaNrjmm9gcxYzrQ4snbXNOmOcSzZ1XvxKv0akwpzGnZUkMG2vwaqv2UUwZnk9Wu7YrENE4l7c/PkzINxUk3HDe2SXi62Pqx+q2imMKqfCWx6XR0zVAWRyV06lWSYHD+dhwwdKvk0I8cRcdiqUrK6K7iJw2PRxPp09aF3KG3fVpF5OCljF4WfsP9bs4egi9DPnVbYWQj3auqBRPuKf0qmgHcWIXeGK6DIeWavtpQ8+uTBOFqeSBy/GYw8lpkCZckh7lj+PMuR8kwnYa0HiIhI1YtIL0FHj5ozq+AO8fjKOj7wFQ5E+agzgBaGa2fPsCQ==; Received: from 91-155-69-32.elisa-laajakaista.fi ([91.155.69.32] helo=[192.168.42.130]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fYlPn-0004mT-Oo; Fri, 29 Jun 2018 07:53:47 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Markus Stenberg X-Mailer: iPad Mail (15F79) In-Reply-To: Date: Fri, 29 Jun 2018 07:53:47 +0300 Cc: babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8A1900D3-ED8F-446A-88BE-CC7331245894@iki.fi> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <6DBB10F7-6F1B-4909-894D-16FCD2C7DEF0@iki.fi> <3D958DDA-4382-45AB-B87D-3B93EF330D05@iki.fi> <87lgaznt2h.wl-jch@irif.fr> <87h8lnnrkr.wl-jch@irif.fr> <521CBB64-7A4C-497B-AF71-1E23344FC7E6@iki.fi> <87efgrnovg.wl-jch@irif.fr> <87woujjgxc.fsf@toke.dk> <87zhze5qmt.wl-jch@irif.fr> <67F34700-5A2A-4AE2-A271-A188DBF320AB@iki.fi> To: Juliusz Chroboczek X-SA-Exim-Connect-IP: 91.155.69.32 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 04:54:05 -0000 Or maybe have HMAC TLV have subtlv with explicit nonce in these cases ( or e= xplicit nonce TLV outside HMAC ). Hmm. With those just same HMAC processing= would work with just special casing on where nonce is sourced from.=20 I promise this is last one for today,=20 -Markus Sent from my preciouss, aka iPad ;) > On 29 Jun 2018, at 7.46, Markus Stenberg wrote: >=20 > I think I prefer the idea of inserting that HMAC handling in the challenge= /response TLV itself so in that case strictly speaking you would have no HMA= C TLV but those messages would be authenticated too.=20 >=20 > Of course downside is the need to use 2-3 TLVs for HMAC but as they are al= ready used for security not sure there is much of a difference.=20 >=20 > -Markus >=20 > Sent from my preciouss, aka iPad ;) >=20 >=20 >> On 29 Jun 2018, at 7.42, Markus Stenberg wrote: >>=20 >> Nah. They have just separate branch which uses explicit sender nonce ( ch= allenge-response ) or no sender nonce ( challenge ).=20 >>=20 >> -Markus >>=20 >> Sent from my preciouss, aka iPad ;) >>=20 >>=20 >> On 29 Jun 2018, at 4.27, Juliusz Chroboczek wrote: >>=20 >>>> The normal packet reception flow just: >>>> - computes pseudoheader, hashes that + what was received, and compares= it with the trailer HMAC.=20 >>>> - If success, compare counter,=20 >>>> - if too old (modulo replay window if any), drop, otherwise process nor= mally. >>>> - If failure, maybe challenge (see above). >>>=20 >>> Hmm... so now both challenges and challenge replies are unprotected by >>> HMAC (since they need to be acted upon even in case of HMAC failure), >>> right? Therefore, we put them in the packet trailer, so that we can >>> retain the property that we don't parse the packet body before HMAC >>> validation. >>>=20 >>> Implementation complexity is comparable, I think. However, now the >>> Neighbour Table entry is created before HMAC validation (to keep the >>> challenge state), so an evil peer is able to create unbounded amounts of= >>> state (by spoofing multiple source addresses). I guess you could avoid >>> that by encoding a cookie in your nonce, but that in turn increases >>> implementation complexity. >>>=20 >>> Am I missing something? >>>=20 >>> -- Juliusz "I'll sleep when I retire" Chroboczek >>>=20 From nobody Fri Jun 29 00:50:58 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F367C128BAC for ; Fri, 29 Jun 2018 00:50:55 -0700 (PDT) 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, 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 BJ3jQ4ZCdVQ3 for ; Fri, 29 Jun 2018 00:50:53 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CDED124BE5 for ; Fri, 29 Jun 2018 00:50:52 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5T7o93j022651; Fri, 29 Jun 2018 09:50:09 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 437F3EB27A; Fri, 29 Jun 2018 09:50:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id rNkRsaHkhSqi; Fri, 29 Jun 2018 09:50:50 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 202FBEB912; Fri, 29 Jun 2018 09:50:47 +0200 (CEST) Date: Fri, 29 Jun 2018 09:50:46 +0200 Message-ID: <87o9fuyqsp.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: babel@ietf.org In-Reply-To: <67F34700-5A2A-4AE2-A271-A188DBF320AB@iki.fi> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <6DBB10F7-6F1B-4909-894D-16FCD2C7DEF0@iki.fi> <3D958DDA-4382-45AB-B87D-3B93EF330D05@iki.fi> <87lgaznt2h.wl-jch@irif.fr> <87h8lnnrkr.wl-jch@irif.fr> <521CBB64-7A4C-497B-AF71-1E23344FC7E6@iki.fi> <87efgrnovg.wl-jch@irif.fr> <87woujjgxc.fsf@toke.dk> <87zhze5qmt.wl-jch@irif.fr> <67F34700-5A2A-4AE2-A271-A188DBF320AB@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 29 Jun 2018 09:50:09 +0200 (CEST) X-Miltered: at korolev with ID 5B35E4B1.005 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B35E4B1.005 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B35E4B1.005 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 07:50:57 -0000 >> Hmm... so now both challenges and challenge replies are unprotected by >> HMAC (since they need to be acted upon even in case of HMAC failure), >> right? > Nah. They have just separate branch which uses explicit sender nonce ( challenge-response ) or no sender nonce ( challenge ). Ah, I see. But you're not making it easy. -- Juliusz From nobody Fri Jun 29 00:53:01 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD36130F04 for ; Fri, 29 Jun 2018 00:52:49 -0700 (PDT) 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, 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 HsAlL6wOMJzZ for ; Fri, 29 Jun 2018 00:52:45 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D6F5130ECA for ; Fri, 29 Jun 2018 00:52:39 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5T7pu1x023538; Fri, 29 Jun 2018 09:51:56 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id CF08AEB279; Fri, 29 Jun 2018 09:52:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Dld7GCFUcJaH; Fri, 29 Jun 2018 09:52:36 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id EA0A5EB200; Fri, 29 Jun 2018 09:52:36 +0200 (CEST) Date: Fri, 29 Jun 2018 09:52:36 +0200 Message-ID: <87muveyqpn.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: babel@ietf.org In-Reply-To: <8A1900D3-ED8F-446A-88BE-CC7331245894@iki.fi> References: <87muvgh08w.wl-jch@irif.fr> <87k1qkgys1.wl-jch@irif.fr> <572D5E74-BE2D-4CD7-BCF4-4BD008D597AD@iki.fi> <87fu18gw9r.wl-jch@irif.fr> <3EEA555D-F75C-4FD4-BFD5-4344E5EEAEEA@apple.com> <87po0b52vx.wl-jch@irif.fr> <87in63an71.wl-jch@irif.fr> <87fu17an1y.wl-jch@irif.fr> <6CE390DB-EE38-4D62-B56A-A451A02FE723@apple.com> <6DBB10F7-6F1B-4909-894D-16FCD2C7DEF0@iki.fi> <3D958DDA-4382-45AB-B87D-3B93EF330D05@iki.fi> <87lgaznt2h.wl-jch@irif.fr> <87h8lnnrkr.wl-jch@irif.fr> <521CBB64-7A4C-497B-AF71-1E23344FC7E6@iki.fi> <87efgrnovg.wl-jch@irif.fr> <87woujjgxc.fsf@toke.dk> <87zhze5qmt.wl-jch@irif.fr> <67F34700-5A2A-4AE2-A271-A188DBF320AB@iki.fi> <8A1900D3-ED8F-446A-88BE-CC7331245894@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 29 Jun 2018 09:51:56 +0200 (CEST) X-Miltered: at korolev with ID 5B35E51C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B35E51C.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B35E51C.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Solving HMAC replay once and for all X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 07:52:54 -0000 > Or maybe have HMAC TLV have subtlv with explicit nonce in these cases > ( or explicit nonce TLV outside HMAC ). Yes, that looks better. Hmm. With those just same HMAC processing would work with just special casing on where nonce is sourced from. > I promise this is last one for today, I hope that's because you're busy implementing your protocol ;-) -- Juliusz From nobody Fri Jun 29 00:55:32 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D1112F295; Fri, 29 Jun 2018 00:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info 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 ZkHWZEpTHKpf; Fri, 29 Jun 2018 00:55:23 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E589D128BAC; Fri, 29 Jun 2018 00:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1530258918; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=5823; bh=f0AzD0Mo5SFsAEaLWz4n6kETfjtRTQ/A48fHnxNHsoc=; b=PvcSrF22R5kByv8itleHaguNUwWUe6Ru7UL/vPFIabTEYALHty32qY4hOKopoUca la7Ik3v80AdLWSDp1LObJ4AtM5Xbclk0C8BqMqs/copGjlREiUnKr7JlfwPZNFWxAxb yZ7U0+wflS8Gq1qjq/VNAMgTO82BYJFt4r0E4RdE= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 153025891836956.753317683144246; Fri, 29 Jun 2018 00:55:18 -0700 (PDT) Date: Fri, 29 Jun 2018 08:55:18 +0100 From: Denis Ovsienko To: "\"Babel at IETF\"" , "\"homenet\"" Message-ID: <1644a8a0be0.b4caee6f16267.1270300104515944073@ovsienko.info> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: [babel] about Babel security (questions for Juliusz Chroboczek) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 07:55:25 -0000 Hello Juliusz. This is about your contributions to the Babel and Homenet IETF working groups. Given the apparent flood of Babel security related messages you are sending to the Babel WG mailing list, I find it necessary to try putting it into proper context. I tried to attack the problem rather than the person, it is up to you to tell whether I managed to do that or not. In either case, I tried to leave you room to defend yourself and to correct me if I am wrong. A fact is, the Babel WG charter among other things has been saying: "Address security needs for BABEL. This may include using the techniques in RFC 7298, or other alternatives." Another fact is, in early 2016 you were promoting the pre-IETF Babel work before and at the Babel BoF and claimed that besides the HMAC (then RFC 7298) approach to Babel security there was another viable alternative, namely, "Stenberg-style security". You were promoting the idea that the Babel WG should evaluate both mechanisms and choose the best. * Q1: Do you acknowledge these two facts and do you agree they are directly related? (yes/no, please explain if "no") The specification of "Stenberg-style security" for Babel was never published. It is June 2018 and I have never seen it, although I asked to. * Q2: In 2016 did you know "Stenberg-style security" for Babel did not exist as a workable WG item in the first place? (yes/no) * Q3: Why were you promoting a WG option that either you didn't verify exists in the first place (if "no" above) or you definitely knew does not exist (if "yes" above)? Please explain. At some point between 2016 and 2017 you stopped mentioning "Stenberg-style security" and began to promote DTLS for Babel security. The first "running code" prototypes (not implementations) of Babel DTLS began to be discussed between late 2017 and early 2018 (as far as I could see in the mailing list archive). It is June 2018 and I have never seen the DTLS Babel security specification, although I have asked to. * Q4: In 2016-2018 did you know a specification for the "DTLS" Babel security did not exist as a workable WG item? (yes/no) * Q5: same as Q3 Whichever the name of it, mentions of the "alternative" Babel security have consistently been in your regular IETF slides, talks and status updates in the Babel and Homenet WGs, and occasionally elsewhere at IETF. This statement is as factual as the IETF meeting materials and witness of IETF participants including myself. * Q6: Do you agree your long-time presenting effort had created and maintained an impression that the "alternative" security option was viable and workable by the Babel WG, regardless of its actual status at the time? (yes/no, please explain if "no") * Q7: If "yes" to Q6, was this impression what you intentionally were trying to achieve? (yes/no, please explain if "no") * Q8: If "yes" to Q6, do you agree this impression has been influencing decision making in both Babel and Homenet WGs? (yes/no, please explain if "no") * Q9: Do you agree the end effect was that the work on HMAC Babel security was held back in the Babel WG? (yes/no, please explain if "no") In May 2018 the Babel WG had reached the decision not to adopt the HMAC I-D (7298bis) as a working group document. The adoption call lasted for more than 60 days, so every participant had a chance to comment. You supported the adoption at first and later withdrew your opinion in the course of the call. * Q10: After the WG decision about HMAC (which was in line with your latest position at the time) are you still maintaining that choosing between HMAC and DTLS would benefit the Babel WG? (yes/no, please explain if "yes") * Q11: If "no", could you explain why did not you denounce the idea on the mailing list with appropriate comments? Up to this point I could state I understand certain things even if I do not like them. Such as, for example, effectively saying "security is not my problem" in the Homenet Babel profile, or the need to consider DTLS for Babel security, or the decision not to use HMAC. But I kept getting out of the path, as that's what I expect from other people when I am working on something. Now there is something that I cannot understand in the first place: after the Babel WG decision you started to post HMAC-related messages to the mailing list. * Q12: Do you agree, in the sense of your own long time "DTLS or HMAC" idea and the claimed viability of DTLS, that the most consistent next step would be to work towards the adoption of a DTLS Babel security mechanism document? (yes/no, please explain if "no") * Q13: If "yes", could you explain in detail why you started to draw so much attention to HMAC after the WG decision and do not bring up DTLS anymore? I have tried to find (in the first few dozens of your messages) the supposed technical problem you are trying to solve. I could not see a sound technical point not already addressed in RFC 7298, 7298bis I-D or the mailing list discussion before and during the adoption call of 7298bis (including the replay attack you had described and I had addressed). This impression may be wrong, but I believe I have studied those messages well enough to make this statement. * Q14: Could you clarify in proper technical terms what exact technical problem you suddenly started to solve and why? I am sorry if this message upsets you, but please note it concerns only your voluntary activity within IETF. Its purpose is not to block progress, but rather to avoid another couple years of talking/walking in circles. I have a few more pending comments to make on your older messages, including outstanding non-security technical issues in the Babel WG documents. I hope to send them separately later. Thank you. -- Denis Ovsienko From nobody Fri Jun 29 01:26:08 2018 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7232E130DBE; Fri, 29 Jun 2018 01:26:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153026076546.30294.5525077386069660247.idtracker@ietfa.amsl.com> Date: Fri, 29 Jun 2018 01:26:05 -0700 From: IETF Secretariat Archived-At: Subject: [babel] Datatracker State Update Notice: X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 08:26:06 -0000 State changed to Informal IESG review. Datatracker URL: https://datatracker.ietf.org/doc/charter-ietf-babel/ From nobody Fri Jun 29 01:29:49 2018 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A795C130DF7; Fri, 29 Jun 2018 01:29:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153026098268.30412.11575551898203336291.idtracker@ietfa.amsl.com> Date: Fri, 29 Jun 2018 01:29:42 -0700 From: IETF Secretariat Archived-At: Subject: [babel] Datatracker State Update Notice: X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 08:29:43 -0000 State changed to Internal review. Datatracker URL: https://datatracker.ietf.org/doc/charter-ietf-babel/ From nobody Fri Jun 29 01:50:28 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4339130DE5; Fri, 29 Jun 2018 01:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info 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 EH8XU0mYtIwI; Fri, 29 Jun 2018 01:50:25 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB78612F295; Fri, 29 Jun 2018 01:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1530262220; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=2888; bh=D7wBIrrcRIpiSifQLO4Rlo0vbf3ZauRy42bAo/msbGg=; b=UEEv+spfR6iiAAVKgjXNzJmLwaUCLxPxY4EK9OKsGcU1an8lZO0UvjG/Wm0xgfMm TuVJOPQ2vgsw8U8inF+gvl2CA8p5qzJEWqpGEIDPA9aBdOpHAGfITFXx8fyaWVCrxTF 4ZHKtW8RSWh8FcAhq1HYMCKMG6/Y/pJdb4SZA4Rs= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1530262220584886.1044702665208; Fri, 29 Jun 2018 01:50:20 -0700 (PDT) Date: Fri, 29 Jun 2018 09:50:20 +0100 From: Denis Ovsienko To: , "\"Babel at IETF\"" Message-ID: <1644abc6f26.10e14f6a122005.6658852103006035074@ovsienko.info> In-Reply-To: References: <1643e04c9f8.10030774874779.3627474589557109802@ovsienko.info> <164411ff50e.b5e8fd6c21486.4668430685875145605@ovsienko.info> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] Consensus Determined for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 08:50:27 -0000 Thank you for your response Donald, my comments are below. ---- On Wed, 27 Jun 2018 14:12:01 +0100 Donald Eastlake wrote ---- > Hi Denis, > > On Wed, Jun 27, 2018 at 8:02 AM, Denis Ovsienko wrote: > > > > ---- On Wed, 27 Jun 2018 01:07:15 +0100 Donald Eastlake wrote ---- > > > The consensus of the WG is to Update the Charter as indicated. > > > > Thank you for the clarification Donald. > > > > I believe it is right to leave a record on the Babel WG mailing list with the summary of this consensus call, as far as it looked from my point of view: > > > > * I had provided an objection to the suggested change and explained the grounds for my position. > > * Other working group members had voted in support of the suggested change, none bothered to explain their grounds, even when explicitly prompted. > > I believe there has been ample discussion of the need for the change > on the WG mailing list, frequently by the same persons who indicated > they supported the change. The whole point I tried to make in this discussion was I believe this was not the case. Thank you for explaining your point of view anyway. > In determining WG consensus, the chairs are entitled to take into > account such discussions. In fact, the IETF rules do not require a > consensus call (or WG Last Call for a draft) to determine consensus. > If the chair(s) of a WG are convinced there is consensus for some > draft or position based on the WG discussions, they are entitled to > declare consensus without a last call or consensus call. I accept the above and would only like to add that with great power comes great responsibility. > > * I had explained that there was no consensus, that voting is not the IETF way of reaching rough consensus, and provided supporting reference to RFC 7282. > > I note that in your point further above, you say "voted". Perhaps it > would be better to say "indicated support" or the like. Also, in an > earlier message, you stated that you were a "member" of the Babel WG. > IETF WGs do not have members or a defined membership. The term usually > used is "participant". Excuse me, indeed I had used a wrong term. I belong to a few non-IETF interest groups, where "member" is the traditional term, which I had automatically copied here. Of course I meant "participant". That said, I had intentionally used the term "voting" in this thread to make my point as clear as possible in the sense of RFC 7282. I thought it was easy to see from my comments. > > > * The chairs left the objection unaddressed and had declared the situation a consensus. > > I responded to your earlier objection message and will respond to your > more recent objection message later today. > > Thanks, > Donald -- Denis Ovsienko From nobody Fri Jun 29 02:53:19 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F232C128BAC; Fri, 29 Jun 2018 02:53:12 -0700 (PDT) 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, 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 jrGHA61KBiNC; Fri, 29 Jun 2018 02:53:10 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EEF41277D2; Fri, 29 Jun 2018 02:53:10 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5T9qQOV001622; Fri, 29 Jun 2018 11:52:26 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 42F19EB200; Fri, 29 Jun 2018 11:53:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 8T8Nvh491RGp; Fri, 29 Jun 2018 11:53:06 +0200 (CEST) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 85130EB22E; Fri, 29 Jun 2018 11:53:03 +0200 (CEST) Date: Fri, 29 Jun 2018 11:53:03 +0200 Message-ID: <87tvpl9aww.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko Cc: "\"Babel at IETF\"" , "\"homenet\"" In-Reply-To: <1644a8a0be0.b4caee6f16267.1270300104515944073@ovsienko.info> References: <1644a8a0be0.b4caee6f16267.1270300104515944073@ovsienko.info> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 29 Jun 2018 11:52:26 +0200 (CEST) X-Miltered: at korolev with ID 5B36015A.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B36015A.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B36015A.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] about Babel security (questions for Juliusz Chroboczek) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 09:53:13 -0000 Dear Denis, Thank you very much for your kind mail. Unfortunately, I think there might be some confusion: - DTLS is Stenberg-style security; - HMAC is Ovsienko-style security, - it has four variants (7298, 7298bis, DKC, Stenberg) - two of which have fatal flaws (7298 and 7298bis). I am really sorry for causing confusion by using both DTLS and Stenberg-style for what is the same thing, and for furthering this confusion for using "Stenberg variant" for one variant of the HMAC protocol. > Another fact is, in early 2016 you were promoting the pre-IETF Babel > work before and at the Babel BoF and claimed that besides the HMAC (then > RFC 7298) approach to Babel security there was another viable > alternative, namely, "Stenberg-style security". You were promoting the > idea that the Babel WG should evaluate both mechanisms and choose the > best. > * Q1: Do you acknowledge these two facts and do you agree they are > directly related? (yes/no, please explain if "no") Yes, besides HMAC I have been advocating DTLS, also known as Stenberg-style security. Markus Stenberg is a competent security expert, and I always try to listen to his advice. > The specification of "Stenberg-style security" for Babel was never > published. It is June 2018 and I have never seen it, although I asked > to. It was presented at IETF 101 in March 2018 (at which you were present). The draft lives here: https://github.com/jech/babel-drafts/tree/master/draft-decimo-babel-dtls I am not an author. Please ask the authors, not me, about why it hasn't been published yet. > * Q2: In 2016 did you know "Stenberg-style security" for Babel did not > exist as a workable WG item in the first place? (yes/no) DTLS, also known as Stenberg-style security, has been implemented by Antonin Décimo and independently reimplemented by David Schinazi during the spring of 2018. It took somewhat longer than expected, for various reasons that are none of your business (such as Antonin wanting to pass his exams). > * Q3: Why were you promoting a WG option that either you didn't verify > exists in the first place (if "no" above) or you definitely knew does > not exist (if "yes" above)? Please explain. I knew it didn't exist at the time. I was confident we could make it happen. Antonin and David have made it happen, which shows that I was right. > At some point between 2016 and 2017 you stopped mentioning > "Stenberg-style security" and began to promote DTLS for Babel > security. The first "running code" prototypes (not implementations) The two are the same thing. Sorry again for the confusion. > * Q4: In 2016-2018 did you know a specification for the "DTLS" Babel > security did not exist as a workable WG item? (yes/no) Stenberg-style security and DTLS are the same thing, so my answer to Q2 applies. > * Q5: same as Q3 Stenberg-style security and DTLS are the same thing, so my answer to Q3 applies. > * Q6: Do you agree your long-time presenting effort had created and > maintained an impression that the "alternative" security option was > viable and workable by the Babel WG, regardless of its actual status > at the time? (yes/no, please explain if "no") Yes, I did believe that DTLS was viable, and did my best to communicate this fact to the list. As explained in my answer to Q2 above, I maintain that I was right. > * Q7: If "yes" to Q6, was this impression what you intentionally were > trying to achieve? (yes/no, please explain if "no") Yes. > * Q8: If "yes" to Q6, do you agree this impression has been influencing > decision making in both Babel and Homenet WGs? (yes/no, please explain > if "no") I do not know. Please ask the WG participants. > * Q9: Do you agree the end effect was that the work on HMAC Babel > security was held back in the Babel WG? (yes/no, please explain if > "no") No. I have been actively promoting the HMAC work ("Ovsienko-style"), just as I have been promoting the DTLS work ("Stenberg-style"). The HMAC work has been held up because 7298bis had fatal flaws. > * Q10: After the WG decision about HMAC (which was in line with your > latest position at the time) are you still maintaining that choosing > between HMAC and DTLS would benefit the Babel WG? (yes/no, please > explain if "yes") I would like see both HMAC and DTLS published as Standards Track documents. It will be a lot of work, but I am confident that we will manage it. I would prefer that we didn't choose between the two -- I want to have both. As stated publicly at the microphone at IETF 101 in London, should we be forced to choose, I would support HMAC. Of course, I may change my opinion in the future, it depends on how HMAC and DTLS will develop. > * Q11: If "no", could you explain why did not you denounce the idea on > the mailing list with appropriate comments? I do not understand the question. It is not my role to "denounce" anything or anyone, I merely express my opinions, just like any other WG member. > * Q12: Do you agree, in the sense of your own long time "DTLS or HMAC" > idea and the claimed viability of DTLS, that the most consistent next > step would be to work towards the adoption of a DTLS Babel security > mechanism document? (yes/no, please explain if "no") The DTLS draft hasn't been published yet (by no fault of mine), so it is premature to discuss its adoption. I am doing my best to push for its publication in time for Montréal. > * Q13: If "yes", could you explain in detail why you started to draw so > much attention to HMAC after the WG decision and do not bring up DTLS > anymore? We (me and two students) have spent the last month working on HMAC. I have been trying my best to share our work with the list, which I believe is acceptable procedure. Please describe your complaint precisely. > * Q14: Could you clarify in proper technical terms what exact technical > problem you suddenly started to solve and why? There are two serious technical issues with rfc7298: - it is vulnerable to replay, as described in my mail of 10 May 2018; - it blackholes a peer after it loses its state, up to ANMTimeout. Both of these problems are believed to be solved by our current HMAC work, which is being debugged right now. We intend to write it down as soon as we've pushed the code to github, but we cannot make any promises since the Montréal cutoff date is very soon. > I have a few more pending comments to make on your older messages, > including outstanding non-security technical issues in the Babel WG > documents. I hope to send them separately later. I am always happy to listen to your advice. Please be aware that we are working really hard right now to get the HMAC work published before Monday's cutoff date, and therefore I might not reply straight away. Regards, -- Juliusz From nobody Fri Jun 29 03:21:30 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49DF130E0E; Fri, 29 Jun 2018 03:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 164OJ-GX2sCb; Fri, 29 Jun 2018 03:21:26 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 4EDEE130DFA; Fri, 29 Jun 2018 03:21:26 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id l19-v6so8018354ioj.5; Fri, 29 Jun 2018 03:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c201vvvKcHTOCECvLui9jPiCl9Na/xAmYs5qcL5t5Hk=; b=c7VM4/ZHOpL88uYPLvuryW0Cd9QB5EO2+nJQeY786vq4LqAQRbrzemVRhgsrlwirJo uYTqlM9pMTMuqJPCi8pAF9DD0Woea5gz1G0uM4Om2PmdzBj8F7qGFdd772kYnHdGd97S hOHfprxdZZF4Cvh625kfumHWAd2XTM1wQsst9OmvAwlxAOXu/bbwF9ln58ubJksfJbBL TW8Dta2AQ9JGmyUVexEBBp9+HNz9TxN7TEewn/jn93uEhsnaajUmT4+r2XMNEY4/kIfo zK/HiKM5kFA0QzD+scKgeDr7d9/PwF8YQQgFriERMDGhIMYhE9F7TTLQ5/bc5kANSXY+ QvXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c201vvvKcHTOCECvLui9jPiCl9Na/xAmYs5qcL5t5Hk=; b=obCY1s1eczec9oWesmsu89W/3vvMPRsAYVU7DQYp2wwaHOEyH+C2xV9rSJw0YgKc6F lKOXE+Kks+6lNLEfVAfYMPE6jTsN6y7nJEP1gbgoxDUy4VVdfBrXtNZkQW8NlnTg6IGD p0PM05wuYuQX+MicHEfHUSGxSqdvZqdbIUCnBLQ/0nWOIbTwQWdnI51dJbeJ07ZEfPZG gzg41shyzEhhYmTTr81xA3iSGlXZDL25mlXWAtjRAY9bw7TYAZsTuaIxx9LfF0soFF4H fKj9WchR1IjEW+2CSNTz9+3vXVreFcpJfiZ8NGzC/j/nwFG1IB9Ab03PTVr1onS9x7xi HT7Q== X-Gm-Message-State: APt69E20BO8SQ7PlmVG7/h+ZrEmSyY/zPFXBsWZgK2PcC95KBoBe00Pi /Qf9BpQ9ItD5Dru7wVvmGJFT3/C+Kselk6y/lgahC6Z18HQ= X-Google-Smtp-Source: AAOMgpf3O1jvkCdlWSoEVDfGeb9bd5fVDyzc42917FvWabIVDvC5a6FuBcUj1zoNZKgWyAUqz1uci1JxHjKS6h5DWsw= X-Received: by 2002:a6b:93c6:: with SMTP id v189-v6mr11105167iod.182.1530267685625; Fri, 29 Jun 2018 03:21:25 -0700 (PDT) MIME-Version: 1.0 References: <1644a8a0be0.b4caee6f16267.1270300104515944073@ovsienko.info> <87tvpl9aww.wl-jch@irif.fr> In-Reply-To: <87tvpl9aww.wl-jch@irif.fr> From: =?UTF-8?Q?Antonin_D=C3=A9cimo?= Date: Fri, 29 Jun 2018 12:20:23 +0200 Message-ID: To: Juliusz Chroboczek Cc: denis@ovsienko.info, homenet@ietf.org, babel@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] [homenet] about Babel security (questions for Juliusz Chroboczek) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 10:21:28 -0000 > I am not an author. Please ask the authors, not me, about why it hasn't > been published yet. Little correction here, Juliusz is listed as 3rd author since a few days. It is planned to submit the draft as soon as possible. From nobody Fri Jun 29 04:53:57 2018 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 294EB1274D0; Fri, 29 Jun 2018 04:53:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , "The IESG" , , X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153027323509.30269.2936621920962589182.idtracker@ietfa.amsl.com> Date: Fri, 29 Jun 2018 04:53:55 -0700 From: IETF Secretariat Archived-At: Subject: [babel] Telechat update notice: X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 11:53:56 -0000 Telechat date has been changed to 2018-07-05 from 2016-06-16 Datatracker URL: https://datatracker.ietf.org/doc/charter-ietf-babel/ From nobody Fri Jun 29 04:58:24 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A2C130EAC; Fri, 29 Jun 2018 04:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info 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 DPNbxDgm_NR8; Fri, 29 Jun 2018 04:58:11 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE704130E8A; Fri, 29 Jun 2018 04:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1530273485; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=10088; bh=VRPm4mc/HTqXGUxy2cAPUdqf9BqsOaqN37f2vtsXnME=; b=lu47aVijuJNhmGc7x9wMO4lQ2P9hl+ScAmRV9q/SfnCVOb9Jg36l2Tm19mULKyBh z2QxlK9NXPrmKauMBT3G93lPJmCUEHZWRa9tSxhuG7B/zpsXvjcxp5XZHzseu3CbT9T 69ptbKXxmJS1pRK3KvSv12rvkkZH1g1BlwprNIag= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1530273485484701.0630421927323; Fri, 29 Jun 2018 04:58:05 -0700 (PDT) Date: Fri, 29 Jun 2018 12:58:05 +0100 From: Denis Ovsienko To: , "\"Babel at IETF\"" Message-ID: <1644b6852aa.cfe5659f43444.7389509197263805740@ovsienko.info> In-Reply-To: References: <1640f31963d.e3da2ad4319526.4149190004246054001@ovsienko.info> <1641dd2ca78.c00b97523761.4967171539240276911@ovsienko.info> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] Consensus Call for Babel Charter Update (2018-06-17 to 2018-06-25) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 11:58:22 -0000 Thank you for this follow-up, my comments are inline. ---- On Wed, 27 Jun 2018 20:44:14 +0100 Donald Eastlake wrote ---- > Hi Denis, > > On Wed, Jun 20, 2018 at 11:31 AM, Denis Ovsienko wrote: > > Thank you for your comments Donald, please see my questions and comments below. > > > > ---- On Mon, 18 Jun 2018 15:27:51 +0100 Donald Eastlake wrote ---- > > > Hi Denis, > > > > > > Thanks for your comments. > > > > > > On Sun, Jun 17, 2018 at 3:21 PM, Denis Ovsienko wrote: > > > > > ... > > > > > > > > Hello all. > > > > > > > > I oppose the proposed change for the following reasons. > > > > > > > > First, the fault is not in the charter. As my previous message to the list discusses, it looks like we (the working group as a whole) have neglected some meaningful parts of our charter: "Particular emphasis will be placed on work needed for a Proposed Standard routing protocol, such as ensuring manageability and strong security." We have achieved exactly the opposite so far, and it would be fair to fix first what is actually broken (specific suggestions are in that message). > > > > > > This Charter change is about process and gating, not about ultimate > > > goals. There is substantial work on manageability in the Information > > > Model and we do have a volunteer to do a preliminary YANG model. The > > > problem is the interlock in the current Charter between the YANG model > > > and the base protocol getting to Proposed Standard status and the > > > normative dependency on Babel in the HOMENT WG. > > > > I am sorry, but the only way I can read the above is it begins saying it is not about ultimate goals, and then says Proposed Standard is an ultimate goal and justifies bending the rules. Can you see it from this point of view? > > No, I don't see that. There is no rule being bent. The Charter is > something specified by the IESG, the IESG can change it, and the WG > can ask the IESG to change it. Standards track status for Babel was > and remains a goal. Manageability for Babel was and remain a goal. This is a good statement, but it would be even better if it emphasized the relation between the status and the quality of deliverables. I have closely worked with enough RFCs on the implementer's side to learn that a Standards Track status is not a guarantee of technical quality. An opportunity to improve this situation was another reason why I began to contribute to the IETF. So if anyone is ever concerned, my point of view on lowering the requirements bar is such for reasons that have formed years ago from first-hand experience. I am fine to stand corrected for the exact language I use, but not for this position. > > The _intentional_ dependency on YANG has been in the charter for 2 years, but only now it suddenly became a "problem", do you agree it looks strange enough to deserve a proper explanation? > > No, I do not agree. Perhaps everyone should always keep the WG Charter > details in mind but many IETF participants, even WG Officers, > sometimes overlook those details. And the longer it has been since the > WG was Chartered, the more memory of those details may fade although, > of course, they are still documented in writing in the Charter itself. > And the longer it has been since the WG was Chartered, the more likely > it is that circumstances have changed so that an adjustment to the > Charter is called for. So I do not think it is strange that the > "problem" is noticed now. > > Let me give an example of people missing something in a Charter, > although it is a little embarrassing. When I took over as Chair of the > PPPEXT WG, Jim Carlson had long been the Chair. At the time, a draft > targeted for Proposed Standard was going through the WG, was found to > have WG consensus, and forwarded to the IESG. The only problem with > this was that the PPPEXT Charter said that the purpose of the WG was > only to review documents related to PPP and that the PPPEXT WG was > specifically prohibited from producing any new documents. :-) > Neither Jim Carlson, who had been Chair for years, nor myself who had > taken over had noticed this. In fact, the Area Director for the WG > didn't notice this either and went ahead and issued an IETF Last Call > on the draft before this problem was noticed by another IESG member. > (The IESG solved the problem in this case by treating the document as > if it was not a WG document and re-issuing the IETF Last Call for the > required longer period of time.) Thank you for such a detailed comment Donald. Your experience definitely lets you relate things differently from how they look to me. But my experience lets me see other details that I consider meaningful enough to bring up if nobody else does. > > > > Second, de-rating of the requirements level should mean de-rating of the publication category. If the working group explicitly finds itself unable to produce a quality YANG deliverable in time, it could _potentially_ (if the charter allowed it) capture its core (6126bis + whatever security) deliverables as IETF Experimental publications, take a break and retain the motivation to have YANG eventually done and aim for Proposed Standard. But neither the current charter nor the proposed change take this into account. > > > > > > The entire thrust of this WG effort is to move Babel to the Standards > > > Track and any change from that would be a major change for which I > > > have not seen any support except your message. > > > > Standards Track work indeed has been the IETF's expectation of this working group. This was a reasonable initial expectation based on the way the pre-IETF work was presented at the IETF. That said, if the actual in-IETF results were as good as expected, there would not be this call and this discussion in the first place, do you agree? > > I do not agree. Whether results are "good" or not is a judgement call. > Whether or not there is a YANG model is a factor some people would > include in such a judgement. But there are many other factors. One particular fact I brought up was that the WG is at least a year behind the originally agreed milestones. I do not agree this was just my subjective judgement about the WG performance. I agree there are also other factors to take into account. That said, I do not agree it is OK to act like there is no problem at all. > > I agree the proportional de-rating would be a major change to the charter. However, just writing deliverables off with no consequences would be a major change too, and in addition to that it would be difficult to distinguish from just gaming the Standards Track process. Does one of the evils look significantly less than the other? > > > > I agree 8 people on the list have voted to support the charter change so far, and I am the only one who has objected so far. Notwithstanding the fact, I believe this working group does not yet have valid grounds to declare consensus on this call and to ask to change the charter. The matter is, your message that starts this call asks for _comments_. This is indeed a valid way to start a consensus process, and it is not a warrant to reduce it to a voting. To emphasize the difference, let me quote this: > > > > "We reject kings, presidents and voting. We believe in rough consensus and running code." > > > > One of the reasons I decided to join the IETF in 2016 was I knew what this saying is intended to mean -- long before that I had read RFC 7282 (On Consensus and Humming in the IETF). The document explains in detail why opposing a majority of _votes_ with a reasoned _objection_ in a call for _consensus_ is a normal IETF approach and it should not be questioned or dismissed. Specifically, it tells why the situation with this call is _not_ a consensus (and what could be done to try to achieve it). > > You are entitled to your opinion that this Charter change is not a > good idea and that either Charter should not be changed or, if it is > changed as indicated, the based Babel draft should re-cycle at > Experimental. However, that is not the consensus of the WG. I confirm you understand the position I maintain, and I confirm I understand the position you maintain. > Any objection can be written up at great length and with many reasons > as to why it is a good objection. This does not mean that one person > can just block progress by writing up their objection that way. RFC > 7282 applies only to technical objections and we are discussing > process here. I'd be willing to say that a minority or one person who > point to a significant violation of process rules can stop something > even if many are in favor of it. But there is no process rules > violation in asking the IESG to make this minor Charter change. That's > not just my opinion but we have an explicit post by our AD stating it. Thank you for explaining your grounds as a WG chair in detail Donald. As a WG participant I have made my best to treat this call for consensus as genuine, because I see YANG as a manifestation of a bigger problem. > > To sum my position up, the right thing to do would be either to leave the charter intact or to ask for proportional de-rating on both sides of the deal like suggested, in either case the working group should keep to the intended IETF methods of work. I am willing to address any comments regarding my input to this consensus call. > > "Experimental" is not a de-rating of "Proposed Standard". They are > different things for different purposes. I do not think the WG is > going outside of "intended IETF methods of work". > > I'm sorry you are not happy but I do not see a reason to revisit the > determination that the WG consensus is in favor of the Charter change. I confirm once again I understand your position and its differences from mine. -- Denis Ovsienko From nobody Fri Jun 29 06:36:54 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805D8130EB2 for ; Fri, 29 Jun 2018 06:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 1IKlwpJ_Jkbi for ; Fri, 29 Jun 2018 06:36:50 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 69EBF130E5B for ; Fri, 29 Jun 2018 06:36:50 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id y4-v6so4909440qka.5 for ; Fri, 29 Jun 2018 06:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=nTcjaOqA9CIcxLW6udlQdSsbCktSKwWcc95wqOHVgkg=; b=tQISj8+D9OXZMF7EJsKPQapIz5yM3uC+6rxNPeWz2hTCnbVXwpYLOf7dxtRQYa/sh4 fcM4o/njXARQKkanx6xj+F8m4Xchtx7PSVeEydIJiGc9KgfBUUjkeR06RiE7DuxlqpLd DgjbpMSsbtjdlpLJNihswmXI+G1QzcNVX4A3cN6T0petanxIovK2gtVJk4OIFQUSc3qC D07Kq0CNAUyPfgsVhXLcAReUrnd3MDoViroN7cGTZO6o6c1tU848e+Ep9pYwNTXFpb7A UQehEnSBRiaRjcVGJt44HkB2zVy5om2otu++ydDdqcY5AIe9BeYPDbCI1s7HALNabori KOrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=nTcjaOqA9CIcxLW6udlQdSsbCktSKwWcc95wqOHVgkg=; b=L7rw/xOux4d2SL6GR/2c6VrxuuZvo15u8QQqtZlqiIV/rQhR+xnAJ85MC4o99dploR wjPdrTxZhXg8wgk55tp63k2Z9zbgwtracTgw94ux8h7oqwSUub4GawqzhIqiYdJN0hRS P5YBFxTXzWKFW+tEZEWt+BRIeUJxAuPQgCis0VBo1GlLYZAr68o69MHdGMw9/FFvz3Et YtnhK4BSU+aCEHqTU/wKNqeWdIrB1OH4ger1ZwOwVv46UuWh1T3Jy12Qf6ad9FPCUlfJ +XFy9+4zdSqzv468hlLk2gMJKpVgkzELQ1Xa/dX4FZ/WxUm9Z9Lt2daa6usJxqBTthNa AiNQ== X-Gm-Message-State: APt69E2IESzPCrIxUkznklegkkoSLlwUvRVzsC+05CsECs/DTACzF2ZK iU1yR+9k725VBquEELmqpsZxk49+EMJqDD8DkQU= X-Google-Smtp-Source: AAOMgpf/rdFerGQlusRlSbDp83mAkFiMW9EDayIXvblPc76HJzHOP7Ox9fD8MFBydaLvSDBfnnh1UZLgSIQwSMoxfCQ= X-Received: by 2002:a37:c40d:: with SMTP id d13-v6mr12572540qki.190.1530279409296; Fri, 29 Jun 2018 06:36:49 -0700 (PDT) MIME-Version: 1.0 From: Dave Taht Date: Fri, 29 Jun 2018 09:37:00 -0400 Message-ID: To: Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [babel] partial trust? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 13:36:53 -0000 Presently authentication seems intended as an all or nothing procedure. It would be useful to be able to have some nodes still available to route, but not participating in the authentication protocol. (old nodes that cannot be updated, new nodes as yet unconfigured, nodes on other folk's systems, etc). The only way I can think of implementing this halfway would be to inflate the metrics received from unauthenticated sources by 32768 or some other really high value. --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619 From nobody Fri Jun 29 06:58:27 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302A2130EAC for ; Fri, 29 Jun 2018 06:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 suNL1zvKHmN8 for ; Fri, 29 Jun 2018 06:58:22 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 4D53D130E83 for ; Fri, 29 Jun 2018 06:58:22 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id u18-v6so2203641wmc.1 for ; Fri, 29 Jun 2018 06:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=CZRxBSEBT9g39l/0Tl/69aHhxgYfr//AOYYN2k0Qra4=; b=TWn2BPx33t3e1Wwrc04rxmmq7cB6mwcx8EzA5WKsJUthgMUUCYnl9c+l39gjUqgsqe 6N/FGHCrOL54/m5d9KnA/UqxuvE+wZiUDARanutOFzdUxcss9f1mocVKas07guwU8QaO QH/LdYp8fG6vj9+EbE+RyZWWZa2eqpBi5CTLhvq6l9OsPEkCXKfd84Dfa895Iu9FOuxR WOYhpXmvU3i1oIULyCNLomR7Fxdh5gt4y63weUHSkrmlKLSkpfKDMMKqbA4IgrUFQqpn bGHRUCM6YQMg3u9mZWDMKYf9Ef0M+oN2qP7pN1ZPtuDR09MX+aM9vDnROJH2/9mDMr8D jK5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=CZRxBSEBT9g39l/0Tl/69aHhxgYfr//AOYYN2k0Qra4=; b=caPHrmEOXQFKYakE1qluxsmDs7OiD9KqnNHlhehP/vSuf62U0rg13XlP1NcCZoFAqI 4fB4gCv+m7KSF46yXFa3TopODNSkxiXWMkVKCHIzS+/4pbVpB4/7vA9HrBwV6GvzympF emYPyL8ykSYqASxJ3rAtHWdMOrZtJt7Wyd+At3jDRhtalI9fNMQVb4dO+6RBoi3R7fOm sx64EODh5XXPDQDRMnw8SMMtq3pGLgoAeqJJkRZc0/ckOqcrShHcr0dpb5BepzG0m1du 2b0ZivWmBdGeh28AgHQkE4wZhsWZJ3/geSrgI58wpZ93uLSJnmYX0mDRr8gJaLhttx2C 6JOg== X-Gm-Message-State: APt69E3sQJMV4IU8UKDmtb2M6iOkCos+TdpRjYqIsUCwc9/+3UgIlc9m 9hKc9YAivT0164Tq41tpl3UNmC/0w2p6xgqQgpCf+Q== X-Google-Smtp-Source: AAOMgpeI7b6rGXoD3eXxk2lPDpRyGs2lwuKXaKpyB18reRmM67hbMzp9HUDU4aCJymXmjOhA7otH3jRxzVXmYo/tG3c= X-Received: by 2002:a1c:d287:: with SMTP id j129-v6mr1797641wmg.106.1530280700680; Fri, 29 Jun 2018 06:58:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:9325:0:0:0:0:0 with HTTP; Fri, 29 Jun 2018 06:58:20 -0700 (PDT) From: =?UTF-8?Q?Weronika_Ko=C5=82odziejak?= Date: Fri, 29 Jun 2018 15:58:20 +0200 Message-ID: To: babel@ietf.org, babel-users@lists.alioth.debian.org Cc: =?UTF-8?B?Q2xhcmEgRMO0?= , Juliusz Chroboczek Content-Type: multipart/alternative; boundary="000000000000921dd7056fc83dca" Archived-At: Subject: [babel] ANNOUNCE - HMAC authentication for BABEL, new prototype X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 13:58:26 -0000 --000000000000921dd7056fc83dca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, Clara D=C3=B4, Juliusz Chroboczek and myself have just pushed our new work = on HMAC authentication using challenge TLV's for babeld to Github. The code is available here: https://github.com/wkolod/babeld branch hmac-challenge The hmac branch is now obsolete. The prototype has received almost no testing so every comment is appreciated. There are two limitations that we plan to fix soon: - packet counter is global for now and not per interface (which may cause a vulnerability if the same local address is reused on multiple interfaces); - struct neighbour is created even if HMAC failed (which makes us susceptible to memory exhaustion attacks). Enjoy, Clara D=C3=B4 Juliusz Chroboczek Weronika Kolodziejak --000000000000921dd7056fc83dca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Clara D=C3=B4, Juli= usz Chroboczek and myself have just pushed our new work on HMAC authenticat= ion using challenge TLV's for babeld to Github.

The code is available here:

https://github.com/wkolod/babeld branch hmac-c= hallenge

The hmac branch is now obsolete.

The prototype has received almost no testing so every comm= ent is appreciated.

There are two limitations that= we plan to fix soon:

- packet counter is global f= or now and not per interface (which may cause a vulnerability if the same l= ocal address is reused on multiple interfaces);
- struct neighbou= r is created even if HMAC failed (which makes us susceptible to memory exha= ustion attacks).

Enjoy,

C= lara D=C3=B4
Juliusz Chro= boczek
Weronika Kolodziejak



--000000000000921dd7056fc83dca-- From nobody Fri Jun 29 08:45:35 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7878B12F1A2 for ; Fri, 29 Jun 2018 08:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 MuqfKE21S7LD for ; Fri, 29 Jun 2018 08:45:31 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 1D8C8126CC7 for ; Fri, 29 Jun 2018 08:45:31 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id q4-v6so8846249iob.2 for ; Fri, 29 Jun 2018 08:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u2lbsgN5oaI6G2PvtpOfOW8GsNH/6c6PoXhruYPUMMk=; b=HISBB92AfumVqT4RfIm3+xFoYolSvRKW6Frcmrx0r02At5+Eh1k5jZbYkgew2HHsFI BOnfG5BTHDq/h3LUvTl+6jAvO3nXvVDYr0FqhChyE8snzaZF39/ePqWd37aOel+r4E4O 72JpgNp9PDz7+dvSZBPWM0UwCdvt6ZJHelUB+iCJvEGkexBHYkadPdHO6u9Gzb8A4yVl 5X9Iuv4QN9BFh5SKL2RcJzuut2bCqbqRiSX25fh20WwJ7Nu1pA4IjBBWKz/NEbsmU/oJ e96+7aUp6jMIPKGpkgaTddW40IZs7GIKTRhGX1X+jIm6btQIzsWkFszpygz18veG0if0 Otbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u2lbsgN5oaI6G2PvtpOfOW8GsNH/6c6PoXhruYPUMMk=; b=gINm/+5SZTe+7PosBHGH2/5WqFq/qhJGze0aTbpZ6J9aKeBPC7RCpU2HkRZF6QuZu9 +PF5UR+EwKqnRJecFLXTOqVPbcpnz47esM+gMEWbl5Ngk76cfIVl+V2X9A0zPESSTidp UHihG3PG/BVvAD86JcznFpjnVoxuTgzYRqzwFO2NAaCIOkPSw9s4hThuT1S1YkRzTiDw vCFCdWyWEQoGG9l3BndQ3BMghFs6LSiAqGs9GLLOZyt+96RjCal5HXpF0sM8jDAOpzZS Cf0/xi8ukVmmYyvV3PF24Jk1R4ET9ZjHczlTbtcVZXpGy1G5/6/JdbV87L98hWtGNB6L 8ZVQ== X-Gm-Message-State: APt69E3KfBVEPzOS1bxerZh7QnpPPSuF2eTiETxO39HoFlzCAzo1MnRP RrhBxj1PupG/pX7WhrTope54H2cBjXqO0qxQ7Enoqg== X-Google-Smtp-Source: AAOMgpch4nktTv4Q8h8NWfTYmVgTItK5PIoyZRsaJkxnK8Pn7+q4zXX2FkDxwmEAQJ+bNzcm8cdntZPI8yBnESDsf1Q= X-Received: by 2002:a6b:b387:: with SMTP id c129-v6mr13301122iof.32.1530287130231; Fri, 29 Jun 2018 08:45:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Lemon Date: Fri, 29 Jun 2018 10:45:19 -0500 Message-ID: To: Dave Taht Cc: Babel at IETF Content-Type: multipart/alternative; boundary="000000000000cd5d59056fc9bc9a" Archived-At: Subject: Re: [babel] partial trust? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 15:45:34 -0000 --000000000000cd5d59056fc9bc9a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Why not just update the firmware? On Fri, Jun 29, 2018 at 8:36 AM Dave Taht wrote: > Presently authentication seems intended as an all or nothing procedure. > > It would be useful to be able to have some nodes still available to route= , > but not participating in the authentication protocol. (old nodes that > cannot be updated, new nodes as yet unconfigured, nodes on other > folk's systems, etc). > > The only way I can think of implementing this halfway would be to > inflate the metrics received from unauthenticated sources by 32768 or > some other really high value. > > -- > > Dave T=C3=A4ht > CEO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619 > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --000000000000cd5d59056fc9bc9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why not just update the firmware?
On Fri, Jun 29, 2018 at 8:36 = AM Dave Taht <dave.taht@gmail.com= > wrote:
Presently authentic= ation seems intended as an all or nothing procedure.

It would be useful to be able to have some nodes still available to route,<= br> but not participating in the authentication protocol. (old nodes that
cannot be updated, new nodes as yet unconfigured, nodes on other
folk's systems, etc).

The only way I can think of implementing this halfway would be to
inflate the metrics received from unauthenticated sources by 32768 or
some other really high value.

--

Dave T=C3=A4ht
CEO, TekLibre, LLC
ht= tp://www.teklibre.com
Tel: 1-669-226-2619

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--000000000000cd5d59056fc9bc9a-- From nobody Fri Jun 29 09:29:29 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDBA130DC8; Fri, 29 Jun 2018 09:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info 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 ya8PzVDa_1fc; Fri, 29 Jun 2018 09:29:21 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA70130DC1; Fri, 29 Jun 2018 09:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1530289758; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=1685; bh=KfsfUD1ctHPrzgyEDqe/44KQhNDBsHwLy9CPabHyCOM=; b=otcndfsB2a5KWkRJ1u/Ty6yxbHlSnQ80hw5Orlbf07V8EgyTrTDMjKw4NJw4BAUu AaXd17oAPOx+Q2PkJS9K/7iU+wxqAei7yHOayDpdo+kR0LnDMVLZnhUEW7yeWMQjpo2 zeliAVVy2lTueL7v3hGXQQW5Fw0RXn6SaxJ007Bg= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1530289758260365.99422948025756; Fri, 29 Jun 2018 09:29:18 -0700 (PDT) Date: Fri, 29 Jun 2018 17:29:18 +0100 From: Denis Ovsienko To: "\"Babel at IETF\"" , "\"homenet\"" Message-ID: <1644c60a033.c75360b277726.6584770912151361357@ovsienko.info> In-Reply-To: <87tvpl9aww.wl-jch@irif.fr> References: <1644a8a0be0.b4caee6f16267.1270300104515944073@ovsienko.info> <87tvpl9aww.wl-jch@irif.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] about Babel security (questions for Juliusz Chroboczek) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 16:29:24 -0000 Thank you for a prompt response Juliusz. Right now I will comment only on one specific point, more follow-ups later. ---- On Fri, 29 Jun 2018 10:53:03 +0100 Juliusz Chroboczek wrote ---- [...] > > The specification of "Stenberg-style security" for Babel was never > > published. It is June 2018 and I have never seen it, although I asked > > to. > > It was presented at IETF 101 in March 2018 (at which you were present). I confirm I attended IETF-101 in person and listened to Antonin's talk and slides about DTLS for Babel. I did not see a written specification. At the meeting I did bring up the need to see a written spec. So in this case "presented" does not go as far as "published". > The draft lives here: > > https://github.com/jech/babel-drafts/tree/master/draft-decimo-babel-dtls Thank you for making this update, I am glad a written specification of Babel DTLS now exists (i.e. has been published). I have been asking since early 2016. > I am not an author. Please ask the authors, not me, about why it hasn't > been published yet. As far as the commit history goes, the file was first added to the repository above on 25 June 2018 (four days ago), then it was updated three times on 27 June 2018 and two times on 29 June 2018 (today, last time about three hours ago). The file is a 325 lines long .xml file, which yields a .txt file, which is 8 pages long, 4 of which are boilerplates, the TOC, references and the likes. The other 4 pages are the actual specification. The document lists 3 authors. I have studied the document and I find it difficult to discuss right now, to be honest. -- Denis Ovsienko From nobody Fri Jun 29 14:02:39 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA1C130EEE; Fri, 29 Jun 2018 14:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info 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 qtO0eVInAOTc; Fri, 29 Jun 2018 14:02:26 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C07C130F41; Fri, 29 Jun 2018 14:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1530306143; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=2867; bh=iYaV5V5+3v4izYCESB0vMJUavBcSMrHZwouvXb6GWkU=; b=A6Ux21ZjAyeOaK8yzWikBFgxY257OFBfxYWH6mCLII9rAxhLFygaruUqMkHoJ3FT RuST8o2J/k/xvaXtyaoCupW0fdepOO35340fsH8InQzQ28rWvbDxCOZ9DKlntfc0Z89 niWFB3t93qjFZ1n84q9Xcz3+aUI+NFofqLxhSI14= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 153030614336139.76175623339043; Fri, 29 Jun 2018 14:02:23 -0700 (PDT) Date: Fri, 29 Jun 2018 22:02:23 +0100 From: Denis Ovsienko To: "\"Babel at IETF\"" , "\"homenet\"" , "\"homenet-chairs@ietf.org\"" Message-ID: <1644d5aa47f.1194b8d54103274.8245671545650864553@ovsienko.info> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DE13054@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <1644a8a0be0.b4caee6f16267.1270300104515944073@ovsienko.info> <87tvpl9aww.wl-jch@irif.fr> <1644c60a033.c75360b277726.6584770912151361357@ovsienko.info> <2D09D61DDFA73D4C884805CC7865E6114DE13054@GAALPA1MSGUSRBF.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] [homenet] about Babel security (questions for Juliusz Chroboczek) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 21:02:31 -0000 ---- On Fri, 29 Jun 2018 17:46:35 +0100 STARK, BARBARA H wrote ---- > Hi Denis, Hello Barbara. I hope you are well. > You appear to have perceived events and statements different from how others' have perceived these. I agree there is some difference. I do not agree this automatically infers I am doing a wrong thing by trying to work through this difference. My goal is to clarify this situation for myself and other participants. > I don't find this thread accusing Juliusz of bad behavior to be an appropriate way of addressing your perceptions. I am sorry to object, but I am doing my best not to accuse Juliusz, as much as is reasonably practicable, in the course of this discussion of facts and problems. If I may suggest, you might see it better after reading my messages with more attention. I agree some of those facts and problems are not really enjoyable to discuss. As just one example, the Babel DTLS specification is a 4 days old publicly available document and a few hours old Internet-Draft. It consists of 8 pages, including 4 pages of technical prose. The Babel HMAC specification that is not 7298bis (feel free to suggest a better term) is a few hours old, smaller, publicly available document and isn't an Internet-Draft yet as this is being written. It says "draft-ietf-babel-rfc7298bis" at the top (sic!). Those are facts. I have spared the participants of how I [subjectively] perceive those facts. You are welcome to verify the facts if you want. I emphasize the facts are not my perceptions. I am willing to listen if you tell me specifically what you find wrong. > As chair of homenet (your email was sent to homenet and babel), I would appreciate an opportunity to talk to you directly (by phone / VoIP) to try to better address your perceptions. I find trying to do this by email very challenging. Your statement is correct, in that I had intentionally cross-posted to both mailing lists. This is because Babel security is meaningful for Homenet (I have been a reader of the Homenet mailing list for some time). I understand you are expecting a direct e-mail conversation with me to be difficult. I accept you may have reasons for this, but it seems to me you had not tried to reach me before, so it would not be right to put the blame on me. I am not putting the blame on you either. >From my own practical experience, e-mail works much better than phone: I can take the time to think and to read my messages before sending to make sure they say what was intended. If you insist anyway, we can have a voice/video call, but if I see this causing even more misunderstanding to pile up, I will have to switch back to e-mail. Hopefully that is workable enough for you. Have a nice day. > If others share Denis' perceptions, please let the chairs know. -- Denis Ovsienko From nobody Fri Jun 29 15:56:29 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419D3130E9F for ; Fri, 29 Jun 2018 15:56:27 -0700 (PDT) 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, 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 QYc7Vt8Pa-fQ for ; Fri, 29 Jun 2018 15:56:25 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0186C130E29 for ; Fri, 29 Jun 2018 15:56:24 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5TMte4p030322; Sat, 30 Jun 2018 00:55:40 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id BEAF5EB200; Sat, 30 Jun 2018 00:56:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id OHrk_k2d7nUM; Sat, 30 Jun 2018 00:56:20 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 2CE27EB22E; Sat, 30 Jun 2018 00:56:18 +0200 (CEST) Date: Sat, 30 Jun 2018 00:56:18 +0200 Message-ID: <87k1qhyzfx.wl-jch@irif.fr> From: Juliusz Chroboczek To: Dave Taht Cc: Babel at IETF In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 30 Jun 2018 00:55:40 +0200 (CEST) X-Miltered: at korolev with ID 5B36B8EC.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B36B8EC.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B36B8EC.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] partial trust? X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 22:56:28 -0000 Dave! > It would be useful to be able to have some nodes still available to route, > but not participating in the authentication protocol. (old nodes that > cannot be updated, new nodes as yet unconfigured, nodes on other > folk's systems, etc). Note that we haven't implemented key rotation yet, so we're pretty far from supporting graceful transition from an unauthentified network to an authentified one. > The only way I can think of implementing this halfway would be to > inflate the metrics received from unauthenticated sources by 32768 or > some other really high value. Babel supports fairly arbitrary route selection policies, so we can prefer authentified routes without tweaking the metric. We could use a sub-TLV to carry the authentication status of a route, end-to-end. I'd like your use-case precisely described first, though. -- Juliusz From nobody Fri Jun 29 16:10:37 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2887B130E9F; Fri, 29 Jun 2018 16:10:36 -0700 (PDT) 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, 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 kOQvg4ZcBI9E; Fri, 29 Jun 2018 16:10:34 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9E7130E29; Fri, 29 Jun 2018 16:10:33 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5TN9oHs000679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 30 Jun 2018 01:09:50 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w5TNA3vo008625; Sat, 30 Jun 2018 01:10:03 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3A536EB22D; Sat, 30 Jun 2018 01:10:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id eoxXp39LKWb9; Sat, 30 Jun 2018 01:10:30 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id DFD94EB200; Sat, 30 Jun 2018 01:10:30 +0200 (CEST) Date: Sat, 30 Jun 2018 01:10:30 +0200 Message-ID: <87in61yys9.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko Cc: "\"Babel at IETF\"" , "\"homenet\"" In-Reply-To: <1644c60a033.c75360b277726.6584770912151361357@ovsienko.info> References: <1644a8a0be0.b4caee6f16267.1270300104515944073@ovsienko.info> <87tvpl9aww.wl-jch@irif.fr> <1644c60a033.c75360b277726.6584770912151361357@ovsienko.info> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 30 Jun 2018 01:09:50 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 30 Jun 2018 01:10:03 +0200 (CEST) X-Miltered: at korolev with ID 5B36BC3E.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B36BC4B.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B36BC3E.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B36BC4B.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B36BC3E.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B36BC4B.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] [homenet] about Babel security (questions for Juliusz Chroboczek) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 23:10:37 -0000 >> The draft lives here: >> >> https://github.com/jech/babel-drafts/tree/master/draft-decimo-babel-dtls > As far as the commit history goes, the file was first added to the > repository above on 25 June 2018 (four days ago), then it was updated > three times on 27 June 2018 and two times on 29 June 2018 (today, last > time about three hours ago). This is partly my fault. Antonin is a full-time student, and I have been recommending that he follow his classes and pass his exams in priority to doing IETF work. I stand by this advice, and remain convinced that this was the right thing to do. > I have studied the document and I find it difficult to discuss right > now, to be honest. Please let us know what it is that you didn't understand. -- Juliusz From nobody Fri Jun 29 20:44:58 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3894A130DF9; Fri, 29 Jun 2018 20:44:50 -0700 (PDT) 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 24D1JUdIyLAB; Fri, 29 Jun 2018 20:44:48 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B97130DF3; Fri, 29 Jun 2018 20:44:48 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w5TGjXhs034963; Fri, 29 Jun 2018 12:46:42 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2jwqama5r0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 29 Jun 2018 12:46:42 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w5TGkfiS011479; Fri, 29 Jun 2018 12:46:41 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w5TGkb2Y011202; Fri, 29 Jun 2018 12:46:37 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 0CB4A4000353; Fri, 29 Jun 2018 16:46:37 +0000 (GMT) Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (unknown [130.8.218.150]) by zlp30484.vci.att.com (Service) with ESMTPS id ECE9F40006D5; Fri, 29 Jun 2018 16:46:36 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.207]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0399.000; Fri, 29 Jun 2018 12:46:36 -0400 From: "STARK, BARBARA H" To: "'Denis Ovsienko'" , "\"Babel at IETF\"" , "\"homenet\"" CC: "homenet-chairs@ietf.org" Thread-Topic: [homenet] [babel] about Babel security (questions for Juliusz Chroboczek) Thread-Index: AQHUD48JZ3Ws32VB3UG81rWGQ/vp56R3sJcA//++4lA= Date: Fri, 29 Jun 2018 16:46:35 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DE13054@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <1644a8a0be0.b4caee6f16267.1270300104515944073@ovsienko.info> <87tvpl9aww.wl-jch@irif.fr> <1644c60a033.c75360b277726.6584770912151361357@ovsienko.info> In-Reply-To: <1644c60a033.c75360b277726.6584770912151361357@ovsienko.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.242.224] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-29_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806290180 Archived-At: Subject: Re: [babel] [homenet] about Babel security (questions for Juliusz Chroboczek) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 03:44:51 -0000 Hi Denis, You appear to have perceived events and statements different from how other= s' have perceived these. I don't find this thread accusing Juliusz of bad behavior to be an appropri= ate way of addressing your perceptions. As chair of homenet (your email was sent to homenet and babel), I would app= reciate an opportunity to talk to you directly (by phone / VoIP) to try to = better address your perceptions. I find trying to do this by email very cha= llenging. If others share Denis' perceptions, please let the chairs know. Thx, Barbara > -----Original Message----- > From: homenet On Behalf Of Denis Ovsienko > Sent: Friday, June 29, 2018 12:29 PM > To: "Babel at IETF" ; "homenet" > Subject: Re: [homenet] [babel] about Babel security (questions for Julius= z > Chroboczek) >=20 > Thank you for a prompt response Juliusz. >=20 > Right now I will comment only on one specific point, more follow-ups late= r. >=20 > ---- On Fri, 29 Jun 2018 10:53:03 +0100 Juliusz Chroboczek = wrote > ---- [...] > > The specification of "Stenberg-style security" for Babel = was > never > > published. It is June 2018 and I have never seen it, although = I > asked > > to. > > > > It was presented at IETF 101 in March 2018 (at which you were present)= . >=20 > I confirm I attended IETF-101 in person and listened to Antonin's talk an= d > slides about DTLS for Babel. I did not see a written specification. At th= e > meeting I did bring up the need to see a written spec. >=20 > So in this case "presented" does not go as far as "published". >=20 > > The draft lives here: > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__github.com_jech_babel-2Ddrafts_tree_master_draft-2Ddecimo- > 2Dbabel-2Ddtls&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3DY3Hx49JV7xQXqwscUPkJtZiOFJkWg8DMoMcJq7RLJ7A& > s=3DkEGB_5PgC8bf4Eby4oWRpm9ncUbR1a7KmmuTccFv9qo&e=3D >=20 > Thank you for making this update, I am glad a written specification of Ba= bel > DTLS now exists (i.e. has been published). I have been asking since early > 2016. >=20 > > I am not an author. Please ask the authors, not me, about why it hasn= 't > > been published yet. >=20 > As far as the commit history goes, the file was first added to the reposi= tory > above on 25 June 2018 (four days ago), then it was updated three times on > 27 June 2018 and two times on 29 June 2018 (today, last time about three > hours ago). The file is a 325 lines long .xml file, which yields a .txt f= ile, which is > 8 pages long, 4 of which are boilerplates, the TOC, references and the li= kes. > The other 4 pages are the actual specification. The document lists 3 auth= ors. >=20 > I have studied the document and I find it difficult to discuss right now,= to be > honest. >=20 > -- > Denis Ovsienko >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_homenet&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3DY3Hx49JV7xQXqwscUPkJtZiOFJkWg8DMoMcJq7RLJ7A& > s=3DZSAkpu4dIvdCqrdMUXoOu4QqeagnuF1ji4pt99IPz2U&e=3D From nobody Sat Jun 30 06:04:50 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C73D130E09 for ; Sat, 30 Jun 2018 06:04:48 -0700 (PDT) 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, 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 zD9hdeZUAqmL for ; Sat, 30 Jun 2018 06:04:45 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE8F1274D0 for ; Sat, 30 Jun 2018 06:04:44 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w5UD400S000951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 30 Jun 2018 15:04:00 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w5UD4DWZ004644; Sat, 30 Jun 2018 15:04:13 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 25D4BEB279; Sat, 30 Jun 2018 15:04:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Z-l-U0uhgokF; Sat, 30 Jun 2018 15:04:40 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B1CE9EB22E; Sat, 30 Jun 2018 15:04:40 +0200 (CEST) Date: Sat, 30 Jun 2018 15:04:40 +0200 Message-ID: <87sh545st3.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org CC: Clara =?ISO-8859-1?Q?D=F4?= , Weronika =?ISO-8859-2?Q?Ko=B3odziejak?= User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 30 Jun 2018 15:04:00 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 30 Jun 2018 15:04:14 +0200 (CEST) X-Miltered: at korolev with ID 5B377FC0.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B377FCD.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B377FC0.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B377FCD.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5B377FC0.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B377FCD.002 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Some open HMAC issues X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 13:04:49 -0000 0. Explicit vs. implicit Indices The discussion between explicit (DKC variant) and implicit (Stenberg variant) indices is still open. Just because we've made DKC code available doesn't mean the WG needs to follow our idiosyncrasies. (I'll try to find the inner strength to summarise the discussion at some point.) 1. Implemented and MTI HMACs We've followed Denis' text, and implemented SHA1 and RIPEMD160. Could any security specialists please advise: - which algorithms should be implemented; - which algorithms should we propose to the WG as Mandatory to Implement (MTI)? On a related note, should we be looking at algorithms other than HMAC? The challenge mechanism is fairly generic, and the actual hashing is just a tiny part of the protocol. 2. Should the HMAC cover the packet header? The Babel packet header has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic | Version | Body length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Right now, Version is fixed at 2, but if we ever define Babel version 3, we might become susceptible to downgrade attacks. I don't recall why we skipped the header in HMAC computation, but I think it's a bug. (As far as I can tell, 7298bis hashes the whole packet, including the packet trailer.) 3. Packet format There are three new TLVs (HMAC, Challenge, Challenge Reply). They are variable-length and therefore non-terminating in the sense of rfc6126bis Section 4.4, which means that they cannot carry sub-TLVs. This follows Denis' original design, and I think it's the right thing to do since it makes the packet format simpler. Does anyone envision a need to carry sub-TLVs on these TLVs? 4. Challenge timeout How long does a receiver have to reply to a challenge? We see no vulnerability here, but we feel that a challenge reply coming a few hours late is at the very least suspicious. (Our code apparently uses 300ms, but I think it's a bug -- it should be on the order of tens of seconds, since a peer is allowed to aggregate its challenge reply with other unicast TLVs -- that's the first time I see a convincing use-case for Unicast Hellos, by the way. Note that we don't necessarily know the peer's Hello and IHU intervals when we challenge. Perhaps we should make the timeout explicit in the challenge TLV?) 5. Use of the packet trailer The HMAC TLV is carried in the packet trailer, which makes it clear which part of the packet is protected by HMAC and avoids the need to clear parts of the packet body before hashing. (Think about extensibility -- there might be other TLVs in the future that must not be protected, and if different extensions require clearing different parts of the packet, we're going to end up with some pretty enjoyable code obfuscation.) Does anyone have technical arguments against the use of the packet trailer? For the record, Denis didn't use a packet trailer, and David has expressed some mild reservations about its use (he feels that we're trading specification simplicity for implementation simplicity and extensibility, and while I agree with this, I happen to think it's the right tradeoff in this particular case). If we keep the trailer, well need to add something to 6126bis. I suggest the following RFCese: - the packet trailer is a sequence of TLVs, just like the packet body, and the TLV number space is the same; - a TLV that appears in the packet trailer MUST be ignored on reception unless its definition explicitly states that it is allowed in the packet trailer; - the mandatory bit MUST NOT be acted upon when it appears in the packet trailer; as a consequence, an implementation that doesn't grok any TLVs that can appear in the trailer MAY simply ignore the packet trailer without ever parsing it. 6. Cryptographic Seqno increase A peer is allowed to increase its Cryptographic Seqno by an arbitrary value (more than 1). This allows the use of fast-running counters, for example based on a hardware clock. For example, an implementation might encode a 1µs-granularity clock in the Cryptographic Seqno, end encode the top-order 16 bits in the Index. There would be a spurious challenge every 72 minutes, and the Index would overflow every 9 years (meaning you'd need to perform key rotation at least that often). Does anyone see a problem with that? 7. Cryptographic Seqno size The Cryptographic Seqno is of a fixed size; if it overflows, the sender must pick a new index and suffer packet loss during at least one RTT (while it's waiting for a new challenge). The Cryptographic Seqno is currently 32 bits long. Does it make sense to reduce it to 16 bits? That would shave 2 octets from each packet, at the cost of more frequent challenges. I think it should stay at 32 bits, since it makes it possible for people to use a fast-running counter (see point 5 above). (In a stable network with 1000 nodes and the default parameters, babeld should be sending on the order of 1.2 packets per second. A 16-bit counter will overflow after 15 hours, a 32-bit counter will overflow after 113 years. All bets are off if you use a fast-running counter, of course.) 8. Index and Nonce size Indices and Nonces are of variable size (up to the maximum TLV size): our implementation selects 80-bit values, but it will handle values of up to 251 resp. 255 octets (as much as fits in a TLV). While having variable-length values slightly complicates the implementation, I think it's a good idea: - an implementation might want to encode a cookie in the Nonce in order to have stronger DoS protection, thus needing a larger Nonce; - an implementation with a stable clock might want to use a tiny Index (see point 5 above). I suggest we should limit indices and nonces to 192 octets, indices and nonces larger than that MUST NOT be sent. This gives enough margin to carry a nonce or index in a sub-TLV (which we're not currently planning to do, but what the heck). (This means we allow 0-octet Nonces. Haha.) 9. Lack of an ANM Since the new protocol is not vulnerable to replay, we don't use a separate ANM, but keep all the per-peer state in the ordinary Neighbours Table -- if a neighbour entry expires, we'll need to challenge again. We intend to put this in the spec, and add an implementation note to explain that implementations that wish to avoid spurious challenges may use a persistent ANM to keep the neighbour state. Does anyone see a problem with that? -- Juliusz From nobody Sat Jun 30 10:51:36 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD39130F11 for ; Sat, 30 Jun 2018 10:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kapsi.fi 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 SL9uJ3C8LVn2 for ; Sat, 30 Jun 2018 10:51:31 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (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 9FEC7130EE2 for ; Sat, 30 Jun 2018 10:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=Ix2R2MdNHLoMdqIdalj2Wy9KOWbzdLNBki5yrLdXrYY=; b=c99+9sG9nEn+J0Cyg4qNbshndwOdtJnBP4qgN87rq5Uqf5J8llmFI9uRFHcPL/cYqVTRbfv/5bx74lhBiZPBtXgeFEBSbcKFYuBvIrpbUZvsPca9cNfJP9r9mo6O0UU7ADJBn4rDixiP7N44zv+puHkweojzROQbrC30+NDb0pCdmXjvzJvwYurEvMS9riFUWDWL2rJC3kFXUx4dUkvYLDP0PgUKLze+GluRjeZHEU669T6CTlqPHoU5umN3IFSq9jINr88CofzS7YP6bUYs0EWBAGjuAEGjBdmgF722T3iH6TvbEXWVcLFZc/H2tMwr5FNESrDa/LTrTzCOSSYzfA==; Received: from dgs0dcygyh12t4dbnc6ct-3.rev.dnainternet.fi ([2001:14ba:2bfc:3100:a035:6d0c:c2b:1685]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fZK1R-00025E-1K; Sat, 30 Jun 2018 20:50:57 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Markus Stenberg In-Reply-To: <87sh545st3.wl-jch@irif.fr> Date: Sat, 30 Jun 2018 20:50:50 +0300 Cc: Babel at IETF , =?utf-8?Q?Weronika_Ko=C5=82odziejak?= , =?utf-8?B?Q2xhcmEgRMO0?= Content-Transfer-Encoding: quoted-printable Message-Id: References: <87sh545st3.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.8.2) X-SA-Exim-Connect-IP: 2001:14ba:2bfc:3100:a035:6d0c:c2b:1685 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] Some open HMAC issues X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 17:51:35 -0000 > On 30.06.2018, at 16.04, Juliusz Chroboczek wrote: > 0. Explicit vs. implicit Indices >=20 > The discussion between explicit (DKC variant) and implicit (Stenberg > variant) indices is still open. Just because we've made DKC code > available doesn't mean the WG needs to follow our idiosyncrasies. >=20 > (I'll try to find the inner strength to summarise the discussion at = some > point.) I am obviously biased.. ;)=20 > 1. Implemented and MTI HMACs >=20 > We've followed Denis' text, and implemented SHA1 and RIPEMD160. Could = any > security specialists please advise: >=20 > - which algorithms should be implemented; > - which algorithms should we propose to the WG as Mandatory to > Implement (MTI)? >=20 > On a related note, should we be looking at algorithms other than HMAC? > The challenge mechanism is fairly generic, and the actual hashing is = just > a tiny part of the protocol. SHA1 should not be done in new algs, and RIPEMD160 is bit niche. SHA256 is the way to go IMHO. In theory some (nowadays HW accelerated) AES based thing such as CMAC = might be interesting. In practise I haven't seen much uptake on those in = recent protocols (typically you go with e.g. AES GCM which also provides = encryption in same single pass). > 2. Should the HMAC cover the packet header? >=20 > The Babel packet header has the following format: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Magic | Version | Body length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Right now, Version is fixed at 2, but if we ever define Babel version = 3, > we might become susceptible to downgrade attacks. I don't recall why = we > skipped the header in HMAC computation, but I think it's a bug. >=20 > (As far as I can tell, 7298bis hashes the whole packet, including the > packet trailer.) It should. > 3. Packet format >=20 > There are three new TLVs (HMAC, Challenge, Challenge Reply). They are > variable-length and therefore non-terminating in the sense of = rfc6126bis > Section 4.4, which means that they cannot carry sub-TLVs. This = follows > Denis' original design, and I think it's the right thing to do since = it > makes the packet format simpler. >=20 > Does anyone envision a need to carry sub-TLVs on these TLVs? Depends bit on choice 0. > 4. Challenge timeout >=20 > How long does a receiver have to reply to a challenge? We see no > vulnerability here, but we feel that a challenge reply coming a few = hours > late is at the very least suspicious. >=20 > (Our code apparently uses 300ms, but I think it's a bug -- it should = be on > the order of tens of seconds, since a peer is allowed to aggregate its > challenge reply with other unicast TLVs -- that's the first time I see > a convincing use-case for Unicast Hellos, by the way. Note that we = don't > necessarily know the peer's Hello and IHU intervals when we challenge. > Perhaps we should make the timeout explicit in the challenge TLV?) Should be long-ish, but not too long.=20 > 5. Use of the packet trailer >=20 > The HMAC TLV is carried in the packet trailer, which makes it clear = which > part of the packet is protected by HMAC and avoids the need to clear = parts > of the packet body before hashing. (Think about extensibility -- = there > might be other TLVs in the future that must not be protected, and if > different extensions require clearing different parts of the packet, = we're > going to end up with some pretty enjoyable code obfuscation.) Must not be protected things sound weird. I do not understand such = concept in this context. > Does anyone have technical arguments against the use of the packet > trailer? For the record, Denis didn't use a packet trailer, and David = has > expressed some mild reservations about its use (he feels that we're > trading specification simplicity for implementation simplicity and > extensibility, and while I agree with this, I happen to think it's the > right tradeoff in this particular case). >=20 > If we keep the trailer, well need to add something to 6126bis. I = suggest > the following RFCese: >=20 > - the packet trailer is a sequence of TLVs, just like the packet = body, > and the TLV number space is the same; > - a TLV that appears in the packet trailer MUST be ignored on = reception > unless its definition explicitly states that it is allowed in the > packet trailer; > - the mandatory bit MUST NOT be acted upon when it appears in the = packet > trailer; as a consequence, an implementation that doesn't grok any > TLVs that can appear in the trailer MAY simply ignore the packet > trailer without ever parsing it. I think it could be just (usually) last(ish) TLV. Trailers are clunky, = traversing toplevel TLVs is easy enough and has less special casing. > 6. Cryptographic Seqno increase >=20 > A peer is allowed to increase its Cryptographic Seqno by an arbitrary > value (more than 1). This allows the use of fast-running counters, = for > example based on a hardware clock. >=20 > For example, an implementation might encode a 1=C2=B5s-granularity = clock in > the Cryptographic Seqno, end encode the top-order 16 bits in the = Index. > There would be a spurious challenge every 72 minutes, and the Index = would > overflow every 9 years (meaning you'd need to perform key rotation at > least that often). >=20 > Does anyone see a problem with that? No. > 7. Cryptographic Seqno size >=20 > The Cryptographic Seqno is of a fixed size; if it overflows, the = sender > must pick a new index and suffer packet loss during at least one RTT > (while it's waiting for a new challenge). >=20 > The Cryptographic Seqno is currently 32 bits long. Does it make sense = to > reduce it to 16 bits? That would shave 2 octets from each packet, at = the > cost of more frequent challenges. I think it should stay at 32 bits, > since it makes it possible for people to use a fast-running counter = (see > point 5 above). >=20 > (In a stable network with 1000 nodes and the default parameters, = babeld > should be sending on the order of 1.2 packets per second. A 16-bit > counter will overflow after 15 hours, a 32-bit counter will overflow = after > 113 years. All bets are off if you use a fast-running counter, of = course.) I think I prefer 32 bits on further thought. 16 feels bit limited. > 8. Index and Nonce size >=20 > Indices and Nonces are of variable size (up to the maximum TLV size): = our > implementation selects 80-bit values, but it will handle values of up = to > 251 resp. 255 octets (as much as fits in a TLV). >=20 > While having variable-length values slightly complicates the = implementation, > I think it's a good idea: >=20 > - an implementation might want to encode a cookie in the Nonce in = order > to have stronger DoS protection, thus needing a larger Nonce; > - an implementation with a stable clock might want to use a tiny = Index > (see point 5 above). >=20 > I suggest we should limit indices and nonces to 192 octets, indices = and > nonces larger than that MUST NOT be sent. This gives enough margin to > carry a nonce or index in a sub-TLV (which we're not currently = planning to > do, but what the heck). >=20 > (This means we allow 0-octet Nonces. Haha.) Seems reasonable enough. > 9. Lack of an ANM >=20 > Since the new protocol is not vulnerable to replay, we don't use > a separate ANM, but keep all the per-peer state in the ordinary = Neighbours > Table -- if a neighbour entry expires, we'll need to challenge again. > We intend to put this in the spec, and add an implementation note to > explain that implementations that wish to avoid spurious challenges = may > use a persistent ANM to keep the neighbour state. >=20 > Does anyone see a problem with that? Not me. -Markus