From nobody Wed May 2 05:07: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 6630F120454; Wed, 2 May 2018 05:07: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 dl9x5klM-1dQ; Wed, 2 May 2018 05:07:14 -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 9DD1E126D3F; Wed, 2 May 2018 05:07:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1525262830; 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=585; bh=b9uWOwxeuBG4YcF3csyBiL/5jyikfTYUdA3xXp2tbiQ=; b=mX3/buAojGd79l3CfNygdC8wwxO63UE/U5/wDsejHSQTwfy6QKwRC7PlMNEhTxg7 hKcWkx04EsJvVeOMEiSqRN8LTDamHuOGmKAuNj+4/z77lcUA9bHd+frkpRhBJ67tmDt EOPuKNGeRSvQEQ0wILrieesL6yAcyLdHkMIk88o0= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1525262830953751.0784498225537; Wed, 2 May 2018 05:07:10 -0700 (PDT) Date: Wed, 02 May 2018 13:07:10 +0100 From: Denis Ovsienko To: "Babel at IETF" , Message-ID: <16320bfcd68.d0931e6e71274.1941219040405816150@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] Call for WG adoption of draft-ovsienko-babel-rfc7298bis (2018-03-25 to 2018-04-08) 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: Wed, 02 May 2018 12:07:16 -0000 ---- On Mon, 26 Mar 2018 19:17:06 +0100 Donald Eastlake wrote ---- >Hi, > >This message announces a two week adoption call for draft-ovsienko-babel-rfc7298bis-00.txt running for two week starting from the posting of https://www.ietf.org/mail-archive/web/babel/current/msg01079.html > > >Please comment as to whether or not you think this draft is good basis for further work by the BABEL WG. Hello all. It has been more than a month since the call so I suggest to go ahead with the adoption as intended. I would like to be able to plan this work. -- Denis Ovsienko From nobody Wed May 2 10:54:11 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 0102612D95E for ; Wed, 2 May 2018 10:54:10 -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 DsrDrvVFMfzX for ; Wed, 2 May 2018 10:54:07 -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 7CC6012D959 for ; Wed, 2 May 2018 10:54:07 -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 w42Hs5rK031584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 2 May 2018 19:54:05 +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 w42Hs7CU018616; Wed, 2 May 2018 19:54:07 +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 95FF0EB227; Wed, 2 May 2018 19:54: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 ekPw3qWQ2pIN; Wed, 2 May 2018 19:54:04 +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 E1D8BEB21E; Wed, 2 May 2018 19:54:03 +0200 (CEST) Date: Wed, 02 May 2018 19:54:03 +0200 Message-ID: <87sh7aaqpw.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko Cc: Babel at IETF In-Reply-To: <878ta1y8k0.wl-jch@irif.fr> References: <87fu4huzgj.wl-jch@irif.fr> <1628e298460.cd82970b35329.4945272877112645380@ovsienko.info> <87muyi3eqi.wl-jch@irif.fr> <16296069fec.e13616a29759.8282754479379679955@ovsienko.info> <878ta1y8k0.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]); Wed, 02 May 2018 19:54:05 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 02 May 2018 19:54:07 +0200 (CEST) X-Miltered: at korolev with ID 5AE9FB3D.005 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5AE9FB3F.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5AE9FB3D.005 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5AE9FB3F.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 : 5AE9FB3D.005 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5AE9FB3F.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] Comments about rfc7298bis 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: Wed, 02 May 2018 17:54:10 -0000 >>> What happens if the number of neighbours is so large that the complete set >>> of TC/PC echos does not fit in a full-size packet? >> The same thing happens as if there is no authentication at all and the >> number of neighbours is so large that the complete set of IHU TLVs does >> not fit. > I'm not sure I understand. The set of IHUs can be easily split across > multiple packets -- the absence of an IHU does not imply that the > neighbour has been dropped. If I understand correctly (correct me if I'm > wrong), your draft requires sneding the full set of IHU+TC/PC echo in > a single packet. If I'm right, then a mechanism is needed to deal with > overflow, no? Denis, Did I miss an e-mail? I don't see an answer to the above. -- Juliusz From nobody Wed May 2 15:31: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 E65C312DA4B for ; Wed, 2 May 2018 15:31: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, 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 a62Jbe9wsI6f for ; Wed, 2 May 2018 15:31:20 -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 54D9412DA49 for ; Wed, 2 May 2018 15:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1525300276; 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=1242; bh=pJnUnZpwbEKmzT/UHBo0WljUaSdPjGBnuipMvbhKESQ=; b=OPdIW0G1Zo6QJODmvxO7MCfVId2ICyUCyWjXiMp48EhkRFttqO6Gn8/vOx1RGSHQ hMSVlYMhLa/HaXhdbuIvecVxJNNi5Fbz8yvJYF4qjnhEL9TWVObMCyCF9gNNNr05dUh Ml4z+fqDYemCCCCoWFx5XL0wZdrcHkdQt49lh0+g= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 15253002765451013.4680357088488; Wed, 2 May 2018 15:31:16 -0700 (PDT) Date: Wed, 02 May 2018 23:31:16 +0100 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <16322fb2d40.b754c16418709.3274574589997739202@ovsienko.info> In-Reply-To: <87sh7aaqpw.wl-jch@irif.fr> References: <87fu4huzgj.wl-jch@irif.fr> <1628e298460.cd82970b35329.4945272877112645380@ovsienko.info> <87muyi3eqi.wl-jch@irif.fr> <16296069fec.e13616a29759.8282754479379679955@ovsienko.info> <878ta1y8k0.wl-jch@irif.fr> <87sh7aaqpw.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] Comments about rfc7298bis 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: Wed, 02 May 2018 22:31:22 -0000 ---- On Wed, 02 May 2018 18:54:03 +0100 Juliusz Chroboczek wrote ---- >>>> What happens if the number of neighbours is so large that the complete set >>>> of TC/PC echos does not fit in a full-size packet? > >>> The same thing happens as if there is no authentication at all and the >>> number of neighbours is so large that the complete set of IHU TLVs does >>> not fit. > >> I'm not sure I understand. The set of IHUs can be easily split across >> multiple packets -- the absence of an IHU does not imply that the >> neighbour has been dropped. If I understand correctly (correct me if I'm >> wrong), your draft requires sneding the full set of IHU+TC/PC echo in >> a single packet. If I'm right, then a mechanism is needed to deal with >> overflow, no? > >Denis, > >Did I miss an e-mail? I don't see an answer to the above. 1. Terminology: the data unit is called a TS/PC number, this has been the term since 2012. 2. Protocol encoding: the "echo" TS/PC sub-TLV is specific to an IHU TLV, the additional requirement for IHU TLVs grouping or placement you describe does not exist. If you go back a couple messages up this thread, hopefully you will see we had discussed both points before. -- Denis Ovsienko From nobody Wed May 2 15:37:42 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 9120412DA72 for ; Wed, 2 May 2018 15:37:40 -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 CxMAPYP3qNTb for ; Wed, 2 May 2018 15:37: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 5FEFD12DA4E for ; Wed, 2 May 2018 15:37:35 -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 w42MbXUO005860; Thu, 3 May 2018 00:37:33 +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 91DCFEB226; Thu, 3 May 2018 00:37:33 +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 7B938-vaktwF; Thu, 3 May 2018 00:37:32 +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 BE354EB227; Thu, 3 May 2018 00:37:32 +0200 (CEST) Date: Thu, 03 May 2018 00:37:32 +0200 Message-ID: <87po2dzntf.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko Cc: "Babel at IETF" In-Reply-To: <16322fb2d40.b754c16418709.3274574589997739202@ovsienko.info> References: <87fu4huzgj.wl-jch@irif.fr> <1628e298460.cd82970b35329.4945272877112645380@ovsienko.info> <87muyi3eqi.wl-jch@irif.fr> <16296069fec.e13616a29759.8282754479379679955@ovsienko.info> <878ta1y8k0.wl-jch@irif.fr> <87sh7aaqpw.wl-jch@irif.fr> <16322fb2d40.b754c16418709.3274574589997739202@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]); Thu, 03 May 2018 00:37:33 +0200 (CEST) X-Miltered: at korolev with ID 5AEA3DAD.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5AEA3DAD.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 : 5AEA3DAD.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] Comments about rfc7298bis 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: Wed, 02 May 2018 22:37:41 -0000 > 2. Protocol encoding: the "echo" TS/PC sub-TLV is specific to an IHU > TLV, the additional requirement for IHU TLVs grouping or placement you > describe does not exist. I'm sorry if I'm slow, Denis, please explain. Supposef that a node has 1000 neighbours on a single interface. In the original protocol, it can send a single Hello and a single Update followed with 1000 IHUs split across 50 packets. What's the encoding in 7298bis if all 1000 neighbours require auth? -- Juliusz From nobody Thu May 3 03:32: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 05E6912D877 for ; Thu, 3 May 2018 03:32:34 -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 M0JhT7tITeSu for ; Thu, 3 May 2018 03:32:32 -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 953AC12711D for ; Thu, 3 May 2018 03:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1525343549; 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=821; bh=xG1DE72AFG5PfY8A5KErfK6J2ms2E4JjAM1bUKhrNHQ=; b=fH703KaTIqmeCSuj5PZKuN0m2I+p/Cjyl2K7CpJM11vg5ja4Me/KeGfV1YdFRgew w5EZNl4qfLtlyLcWIYQcqix8w/r2cx9mTxUTNYi2pfa/LoIfqEXZzw5xA1GNdiQlJGi blSDBOa/o+tumup2CPY6/5woyMZ04fDsQRRRRsdQ= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1525343549341507.99465609291985; Thu, 3 May 2018 03:32:29 -0700 (PDT) Date: Thu, 03 May 2018 11:32:29 +0100 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <163258f779c.1272194bf35512.5113105590240148496@ovsienko.info> In-Reply-To: <87po2dzntf.wl-jch@irif.fr> References: <87fu4huzgj.wl-jch@irif.fr> <1628e298460.cd82970b35329.4945272877112645380@ovsienko.info> <87muyi3eqi.wl-jch@irif.fr> <16296069fec.e13616a29759.8282754479379679955@ovsienko.info> <878ta1y8k0.wl-jch@irif.fr> <87sh7aaqpw.wl-jch@irif.fr> <16322fb2d40.b754c16418709.3274574589997739202@ovsienko.info> <87po2dzntf.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] Comments about rfc7298bis 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: Thu, 03 May 2018 10:32:34 -0000 ---- On Wed, 02 May 2018 23:37:32 +0100 Juliusz Chroboczek wrote ---- >> 2. Protocol encoding: the "echo" TS/PC sub-TLV is specific to an IHU >> TLV, the additional requirement for IHU TLVs grouping or placement you >> describe does not exist. > >I'm sorry if I'm slow, Denis, please explain. > >Supposef that a node has 1000 neighbours on a single interface. In the >original protocol, it can send a single Hello and a single Update followed >with 1000 IHUs split across 50 packets. > >What's the encoding in 7298bis if all 1000 neighbours require auth? Per each packet: one TS/PC TLV and at least one HMAC TLV (as 7298 explains it) Per each IHU TLV: one TS/PC sub-TLV (as 7298-bis explains it) If you read the full I-D and confirm you have done that, I will appreciate that. -- Denis Ovsienko From nobody Thu May 3 13:32:50 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 7471A126CC7; Thu, 3 May 2018 13:32:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: babel-chairs@ietf.org, d3e3e3@gmail.com, martin.vigoureux@nokia.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152537956943.4375.12725134120393309404.idtracker@ietfa.amsl.com> Date: Thu, 03 May 2018 13:32:49 -0700 Archived-At: Subject: [babel] babel - New Meeting Session Request for IETF 102 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 03 May 2018 20:32:49 -0000 A new meeting session request has just been submitted by Donald E. Eastlake 3rd, a Chair of the babel working group. --------------------------------------------------------- Working Group Name: Babel routing protocol Area Name: Routing Area Session Requester: Donald Eastlake Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 42 Conflicts to Avoid: First Priority: netconf netmod rtgwg idr lpwan homenet manet bess Second Priority: dnsop 6man v6ops i2rs mptcp Third Priority: saag dnssd tsvwg lsr People who must be present: Donald E. Eastlake 3rd Russ White Alia Atlas Martin Vigoureux Resources Requested: Special Requests: Meeting toward the end of the day Thursday or in the last slot Thursday seems to work well for BABEL. --------------------------------------------------------- From nobody Thu May 3 14:55: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 4B5671204DA for ; Thu, 3 May 2018 14:55:43 -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 GcEQDVoHWPDq for ; Thu, 3 May 2018 14:55:41 -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 23EFE1267BB for ; Thu, 3 May 2018 14:55: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 w43LtcU4016439; Thu, 3 May 2018 23:55:38 +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 07013EB226; Thu, 3 May 2018 23:55: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 QU7HgI_CxztA; Thu, 3 May 2018 23:55:37 +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 32328EB21E; Thu, 3 May 2018 23:55:37 +0200 (CEST) Date: Thu, 03 May 2018 23:55:37 +0200 Message-ID: <8736z89zfq.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko Cc: "Babel at IETF" In-Reply-To: <163258f779c.1272194bf35512.5113105590240148496@ovsienko.info> References: <87fu4huzgj.wl-jch@irif.fr> <1628e298460.cd82970b35329.4945272877112645380@ovsienko.info> <87muyi3eqi.wl-jch@irif.fr> <16296069fec.e13616a29759.8282754479379679955@ovsienko.info> <878ta1y8k0.wl-jch@irif.fr> <87sh7aaqpw.wl-jch@irif.fr> <16322fb2d40.b754c16418709.3274574589997739202@ovsienko.info> <87po2dzntf.wl-jch@irif.fr> <163258f779c.1272194bf35512.5113105590240148496@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]); Thu, 03 May 2018 23:55:38 +0200 (CEST) X-Miltered: at korolev with ID 5AEB855A.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5AEB855A.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 : 5AEB855A.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] Comments about rfc7298bis 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: Thu, 03 May 2018 21:55:43 -0000 > Per each packet: one TS/PC TLV and at least one HMAC TLV (as 7298 explains it) > Per each IHU TLV: one TS/PC sub-TLV (as 7298-bis explains it) > If you read the full I-D and confirm you have done that, I will > appreciate that. I have read the I-D, although I skipped over the parts that merely restate what is in 6126. I still don't understand how you deal with more TC/PC sub-TLVs than can fit in a packet. -- Juliusz From nobody Fri May 4 07:06: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 7823912711B for ; Fri, 4 May 2018 07:06: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 KSfK9PLEPPPi for ; Fri, 4 May 2018 07:06:24 -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 A4E521205F0 for ; Fri, 4 May 2018 07:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1525442781; 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=2527; bh=MEvS+fr3V7EO/S28Yw7YTr1RzAGiYRqeFlxaRf27k70=; b=bmqwaC0WMIYguUJD1QKqdMCst50Y6WTVFS0W28eZc+okeZGHgNbrLPdWEqwmaRUh OY4xmvX8JSOBkUvMjYQpF4ay71vnNnietKa01g0jMfjZO8PcmYOqkuVxtTsvRhleOTm Cz9TMvbCgZE2klQcl73DTCql4NrOMNm0xgzLlV3Y= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1525442781864763.1266683370094; Fri, 4 May 2018 07:06:21 -0700 (PDT) Date: Fri, 04 May 2018 15:06:21 +0100 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <1632b79a2a7.d0dabacb43120.7322644504922173573@ovsienko.info> In-Reply-To: <8736z89zfq.wl-jch@irif.fr> References: <87fu4huzgj.wl-jch@irif.fr> <1628e298460.cd82970b35329.4945272877112645380@ovsienko.info> <87muyi3eqi.wl-jch@irif.fr> <16296069fec.e13616a29759.8282754479379679955@ovsienko.info> <878ta1y8k0.wl-jch@irif.fr> <87sh7aaqpw.wl-jch@irif.fr> <16322fb2d40.b754c16418709.3274574589997739202@ovsienko.info> <87po2dzntf.wl-jch@irif.fr> <163258f779c.1272194bf35512.5113105590240148496@ovsienko.info> <8736z89zfq.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] Comments about rfc7298bis 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, 04 May 2018 14:06:27 -0000 ---- On Thu, 03 May 2018 22:55:37 +0100 Juliusz Chroboczek wrote ---- >> Per each packet: one TS/PC TLV and at least one HMAC TLV (as 7298 explains it) >> Per each IHU TLV: one TS/PC sub-TLV (as 7298-bis explains it) > >> If you read the full I-D and confirm you have done that, I will >> appreciate that. > >I have read the I-D, although I skipped over the parts that merely restate >what is in 6126. I still don't understand how you deal with more TC/PC >sub-TLVs than can fit in a packet. Juliusz, the data item you are referring to is called "TS/PC", and this term has been around since 2012. I have already mentioned this before. Do you understand this leaves an impression of a conversation that is not fully two-way? Regarding your recent concerns about 7298-bis data items not fitting into output packets, the task of fitting protocol data items into a packet buffer is neither new nor really difficult. This is one of the minor tasks you had done yourself when you authored RFC 6126 and its implementation. Specifically, you managed to place IHU TLVs, which consume either 8 octets (AE 0) or 12 octets (AE 1) or 16 octets (AE 3) into a sending buffer without overflowing it. So far so good for RFC 6126 (same for 6126-bis). RFC 7298 discusses the additional buffer margin for the [per-packet] TS/PC TLV and HMAC TLV(s) in sufficient detail. Besides the margin, the buffer management remains exactly the same (and same for 7298-bis). In 7298-bis the [IHU TLV-specific] TS/PC sub-TLV consumes 8 octets, so an IHU TLV now consumes either 16 octets (AE 0), or 20 octets (AE 1) or 24 octets (AE 3). The buffer management task again remains exactly the same, it is just one of its input data items that now comes in a different size. This way, I am sorry to explain that from my point of view it reads as if you are claiming you do not understand how sending buffer management works in RFC 6126. If this is the case and your assumption is this is a fault of 7298-bis or myself, it is likely wrong. But the main point is, sending buffer management is not the only or the biggest concern here. The main goal of 7298-bis is to add a true bi-directional exchange proof to 7298. This is exactly the approach you suggested if you remember. I believe the proposed solution achieves that goal, can you prove me wrong in that? If the working group intends to deliver proper quality results, this is one of the unfinished work items on that we could (and should) spend our energy. -- Denis Ovsienko From nobody Mon May 7 07:24: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 EC9101205D3 for ; Mon, 7 May 2018 07:24:50 -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 dlM-CgQ7Jnaw for ; Mon, 7 May 2018 07:24:49 -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 A41101252BA for ; Mon, 7 May 2018 07:24:48 -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 w47EOkeD022329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 May 2018 16:24:46 +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 w47EOmRo004745; Mon, 7 May 2018 16:24:48 +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 4E142EB226; Mon, 7 May 2018 16:24:46 +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 AVWS17FsUkBg; Mon, 7 May 2018 16:24:45 +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 42D2BEB21E; Mon, 7 May 2018 16:24:45 +0200 (CEST) Date: Mon, 07 May 2018 16:24:45 +0200 Message-ID: <87sh737dci.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko Cc: "Babel at IETF" In-Reply-To: <1632b79a2a7.d0dabacb43120.7322644504922173573@ovsienko.info> References: <87fu4huzgj.wl-jch@irif.fr> <1628e298460.cd82970b35329.4945272877112645380@ovsienko.info> <87muyi3eqi.wl-jch@irif.fr> <16296069fec.e13616a29759.8282754479379679955@ovsienko.info> <878ta1y8k0.wl-jch@irif.fr> <87sh7aaqpw.wl-jch@irif.fr> <16322fb2d40.b754c16418709.3274574589997739202@ovsienko.info> <87po2dzntf.wl-jch@irif.fr> <163258f779c.1272194bf35512.5113105590240148496@ovsienko.info> <8736z89zfq.wl-jch@irif.fr> <1632b79a2a7.d0dabacb43120.7322644504922173573@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, 07 May 2018 16:24:46 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 07 May 2018 16:24:48 +0200 (CEST) X-Miltered: at korolev with ID 5AF061AE.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5AF061B0.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5AF061AE.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5AF061B0.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 : 5AF061AE.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5AF061B0.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] Comments about rfc7298bis 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, 07 May 2018 14:24:51 -0000 > Regarding your recent concerns about 7298-bis data items not fitting > into output packets, the task of fitting protocol data items into > a packet buffer is neither new nor really difficult. I think got it, sorry for being so slow. Contrary to what I believed, 7298bis only requires TS/PC sub-TLVs to be included in existing IHUs. It does not require a full set of TS/PC sub-TLVs to be included in every packet. See Section 5.4 point 4 -- it only requires rejecting packets if there's no sub-TLV in a matching IHU. On the other hand, if a packet does not include a matching IHU, then it is accepted as soon as the TS/PC TLV (not sub-TLV) is good. Is that right, Denis? If so, then I'd like to understand why this is safe. Intuitively, I'd say that by allowing packets without a matching TS/PC sub-TLV, replay attacks might still be possible. Now, the MUST in Section 3.4.3 of 6126bis should mitigate most such attacks, but I'm still a little worried. Denis, can you please point me where you explain why accepting packets with no matching TS/PC is safe? -- Juliusz From nobody Mon May 7 15: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 2F982129502 for ; Mon, 7 May 2018 15:36:53 -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 GDPmuPQXTM_N for ; Mon, 7 May 2018 15:36:51 -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 4756E124239 for ; Mon, 7 May 2018 15:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1525732607; 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=3033; bh=tHTk/SxYqsZZbCbFpgwT66bZkYYYvN/Milu9cIgssXM=; b=dnFiGJ75kWe1kTzJWpYx1tGRzKmlfkq3L6RonpvGoWYKvWQO3JiDrMGMytemkQiv 2ANHtRSehZ17MoH5eTy9yMC+j2x0uCFw+LcvBP5PCFpUManlV1/+gLBDmjS5BWVgzZR dd/IPaSKcLysbXYvxc97Kco+NPCrDe0At4IFqqXk= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1525732607412368.08734622918234; Mon, 7 May 2018 15:36:47 -0700 (PDT) Date: Mon, 07 May 2018 23:36:47 +0100 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <1633cc005b2.fb8883bc31563.5518090263169039684@ovsienko.info> In-Reply-To: <87sh737dci.wl-jch@irif.fr> References: <87fu4huzgj.wl-jch@irif.fr> <1628e298460.cd82970b35329.4945272877112645380@ovsienko.info> <87muyi3eqi.wl-jch@irif.fr> <16296069fec.e13616a29759.8282754479379679955@ovsienko.info> <878ta1y8k0.wl-jch@irif.fr> <87sh7aaqpw.wl-jch@irif.fr> <16322fb2d40.b754c16418709.3274574589997739202@ovsienko.info> <87po2dzntf.wl-jch@irif.fr> <163258f779c.1272194bf35512.5113105590240148496@ovsienko.info> <8736z89zfq.wl-jch@irif.fr> <1632b79a2a7.d0dabacb43120.7322644504922173573@ovsienko.info> <87sh737dci.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] Comments about rfc7298bis 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, 07 May 2018 22:36:53 -0000 ---- On Mon, 07 May 2018 15:24:45 +0100 Juliusz Chroboczek wrote ---- >> Regarding your recent concerns about 7298-bis data items not fitting >> into output packets, the task of fitting protocol data items into >> a packet buffer is neither new nor really difficult. > >I think got it, sorry for being so slow. Contrary to what I believed, >7298bis only requires TS/PC sub-TLVs to be included in existing IHUs. It >does not require a full set of TS/PC sub-TLVs to be included in every You get this part right. IHUs appear in outgoing packets anyway. On an interface configured for authentication all IHUs start to have a TS/PC sub-TLV because an IHU is a reaction to a Hello, and only authentic Hellos make it in, thus the ANM table has a received TS/PC number to send back in every IHU. >packet. See Section 5.4 point 4 -- it only requires rejecting packets if >there's no sub-TLV in a matching IHU. On the other hand, if a packet does Not quite. Section 5.4 item 4 means: if there are any IHU TLVs that are going to be actioned by the main protocol instance and do not quote a *fresh* *enough* TS/PC number of the incoming interface, discard the packet. >not include a matching IHU, then it is accepted as soon as the TS/PC TLV >(not sub-TLV) is good. Correct. >Is that right, Denis? Not exactly there yet, but I am glad to confirm this is much closer. Thank you for studying the details, Juliusz. >If so, then I'd like to understand why this is safe. Intuitively, I'd say >that by allowing packets without a matching TS/PC sub-TLV, replay attacks >might still be possible. Now, the MUST in Section 3.4.3 of 6126bis >should mitigate most such attacks, but I'm still a little worried. > >Denis, can you please point me where you explain why accepting packets >with no matching TS/PC is safe? Let me try to answer this as far as I understand the question. If that is not what you mean, please ask again. The new guard specifically triggers on stale (i.e. not proven fresh) IHUs and lets the timers do eventual handling of any related protocol structures. This is not completely and immediately safe, but it looks good enough. Specifically, it is still possible to intercept packets sent by a speaker, wait until it goes off the air and replay the packets soon enough for them to be accepted and processed normally (no more than once each packet). But the key difference is, in 7298-bis the time window for this spoofing is now limited and under control with TSPCMaxRTT. This is very close to MAX_HELLO_TIMESTAMP_DIFF and MAX_TC_TIMESTAMP_DIFF from RFC 7183, but without the need for all speakers to have synchronized clocks. This 2-way TS/PC check is better than 1-way but not as good as 3-way. However, my understanding is, for multicast protocol exchange 2-way is as far as it can scale (i.e. hundreds of neighbours on a single segment would have a hard time trying to maintain O(n**2) 3-way unicast exchanges). Do you see any ways for this to go wrong? -- Denis Ovsienko From nobody Wed May 9 16:41: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 D5FD9126CF9 for ; Wed, 9 May 2018 16:41:47 -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 sfVd_CxaZ9hi for ; Wed, 9 May 2018 16:41: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 7895A12DA41 for ; Wed, 9 May 2018 16:41: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 w49Nfh2U022446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 May 2018 01:41:43 +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 w49Nfj9H006058; Thu, 10 May 2018 01:41:45 +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 47EE5EB227; Thu, 10 May 2018 01:41:43 +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 Xf1yVYbR8zZ8; Thu, 10 May 2018 01:41:42 +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 4417CEB226; Thu, 10 May 2018 01:41:42 +0200 (CEST) Date: Thu, 10 May 2018 01:41:42 +0200 Message-ID: <87sh70wg5l.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko Cc: "Babel at IETF" In-Reply-To: <1633cc005b2.fb8883bc31563.5518090263169039684@ovsienko.info> References: <87fu4huzgj.wl-jch@irif.fr> <1628e298460.cd82970b35329.4945272877112645380@ovsienko.info> <87muyi3eqi.wl-jch@irif.fr> <16296069fec.e13616a29759.8282754479379679955@ovsienko.info> <878ta1y8k0.wl-jch@irif.fr> <87sh7aaqpw.wl-jch@irif.fr> <16322fb2d40.b754c16418709.3274574589997739202@ovsienko.info> <87po2dzntf.wl-jch@irif.fr> <163258f779c.1272194bf35512.5113105590240148496@ovsienko.info> <8736z89zfq.wl-jch@irif.fr> <1632b79a2a7.d0dabacb43120.7322644504922173573@ovsienko.info> <87sh737dci.wl-jch@irif.fr> <1633cc005b2.fb8883bc31563.5518090263169039684@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]); Thu, 10 May 2018 01:41:43 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 10 May 2018 01:41:45 +0200 (CEST) X-Miltered: at korolev with ID 5AF38737.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5AF38739.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5AF38737.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5AF38739.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 : 5AF38737.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5AF38739.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] Comments about rfc7298bis 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: Wed, 09 May 2018 23:41:48 -0000 Thanks for the explanation, that helps. I'm going to read 7183 when I have time. > Do you see any ways for this to go wrong? Probably not, but I'm not quite comfortable yet. Please be patient, I probably get the details wrong in the following example. Suppose that Chloe has captured a large number of packets previously sent by alice. Alice left the network, and state relevant to Alice has expired at Bob. Now Alice joins the network, and sends A: Hello, TS/PC = 42 Now Chloe sends a replayed packet: C (spoofing A): Update (::/0, 0), TS/PC = 43 Bob sees this as a route announcement from Alice, so he inserts a default route in its route table. Since Alice hasn't sent an IHU yet, the link cost is infinite, so the route doesn't get installed. Bob sends a Hello: B: Hello, TS/PC = 57 and Alice sends an IHU with the correct TS/PC echo: A: IHU(TS/PC=57), TS/PC = 43 the IHU gets ignored, due to the obsolete TS/PC (43), but then Alice resends the IHU: A: IHU(TS/PC=57), TS/PC = 44 This packet is correct, so BOB sets its txcost to something finite, and bang, the route suddenly is selectable, and Bob installs the route that was spoofed by Chloe. What am I missing? -- Juliusz From nobody Fri May 11 00:33: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 B6C3B12E867 for ; Fri, 11 May 2018 00:33: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, 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 le9YaNwlb7M1 for ; Fri, 11 May 2018 00:33:49 -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 22BE7127078 for ; Fri, 11 May 2018 00:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1526024025; 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=2681; bh=d2+ii6H9wlLQl7zRSyM5LNsxbpISZfapgz07fspUzPE=; b=aHUn1C9/uqVgqASTPlny/MRzN6BIenCkHbvk86nxeKZ3IPNaq9lJxJf8FAr3S3HN XHWNuFyIen/a1ykpy0lOyRsSq93n+VIg0BjbmMxCrU8TeGfGi1KAeLi1IBq4ITiNYAn UkUX1//hlBIydy6VnKnRRGi8JDLDKaJPd6utzTpg= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1526024025013254.99559567706024; Fri, 11 May 2018 00:33:45 -0700 (PDT) Date: Fri, 11 May 2018 08:33:45 +0100 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <1634e1eb3b4.e3d43e1a73477.1851831231495285395@ovsienko.info> In-Reply-To: <87sh70wg5l.wl-jch@irif.fr> References: <87fu4huzgj.wl-jch@irif.fr> <1628e298460.cd82970b35329.4945272877112645380@ovsienko.info> <87muyi3eqi.wl-jch@irif.fr> <16296069fec.e13616a29759.8282754479379679955@ovsienko.info> <878ta1y8k0.wl-jch@irif.fr> <87sh7aaqpw.wl-jch@irif.fr> <16322fb2d40.b754c16418709.3274574589997739202@ovsienko.info> <87po2dzntf.wl-jch@irif.fr> <163258f779c.1272194bf35512.5113105590240148496@ovsienko.info> <8736z89zfq.wl-jch@irif.fr> <1632b79a2a7.d0dabacb43120.7322644504922173573@ovsienko.info> <87sh737dci.wl-jch@irif.fr> <1633cc005b2.fb8883bc31563.5518090263169039684@ovsienko.info> <87sh70wg5l.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] Comments about rfc7298bis 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, 11 May 2018 07:33:51 -0000 ---- On Thu, 10 May 2018 00:41:42 +0100 Juliusz Chroboczek wrote ---- >Thanks for the explanation, that helps. I'm going to read 7183 when >I have time. > >> Do you see any ways for this to go wrong? > >Probably not, but I'm not quite comfortable yet. Please be patient, >I probably get the details wrong in the following example. > >Suppose that Chloe has captured a large number of packets previously sent >by alice. Alice left the network, and state relevant to Alice has expired >at Bob. (Implied: Alice reuses TS/PC numbers, Bob uses a short enough ANMTimeout.) >Now Alice joins the network, and sends > > A: Hello, TS/PC = 42 > >Now Chloe sends a replayed packet: > > C (spoofing A): Update (::/0, 0), TS/PC = 43 > >Bob sees this as a route announcement from Alice, so he inserts a default >route in its route table. Since Alice hasn't sent an IHU yet, the link >cost is infinite, so the route doesn't get installed. > >Bob sends a Hello: > > B: Hello, TS/PC = 57 > >and Alice sends an IHU with the correct TS/PC echo: > > A: IHU(TS/PC=57), TS/PC = 43 > >the IHU gets ignored, due to the obsolete TS/PC (43), but then Alice >resends the IHU: > > A: IHU(TS/PC=57), TS/PC = 44 > >This packet is correct, so BOB sets its txcost to something finite, and >bang, the route suddenly is selectable, and Bob installs the route that >was spoofed by Chloe. > >What am I missing? It looks like this attack would work they way you describe it. To spell the nuances, what 7298-bis would do on top of 7298 is detect packets with incoming IHUs that are not a fresh enough response to the local TS/PC number. Without IHUs it is only the TS/PC+HMAC check, and with reused local TS/PC number the bi-directional exchange is not actually proven. So that's a good point. Moreover, if Bob reuses his outgoing TS/PC numbers too, it will take to power-cycle A and B at the same time, then record the exchange, and then C will be able to replay a complete (Hello+IHU+Update) protocol exchange to any of those two each time they reboot. As far as I see after thinking about this new input for a day, the principal way to fix this would be to mandate that TS/PC number must be increasing across the lifetime of a speaker (7298-bis Section 5.1 item (a) goes away, item (c) becomes the recommended default, item (b) refines the requirements for the timestamp source). A secondary measure would be to have a large ANMTimeout by default (since item (a) no longer applies) and to save ANM table across reboots, this way old replayed Update TLVs will be less likely to produce inactive routes in the absence of new IHU TLVs. -- Denis Ovsienko From nobody Sun May 13 06:56: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 70760124B0A for ; Sun, 13 May 2018 06:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 9XKShI_kmDzp for ; Sun, 13 May 2018 06:56: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 08202124BAC for ; Sun, 13 May 2018 06:56: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 w4DDuLTV024299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 13 May 2018 15:56:21 +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 w4DDuMDw000429; Sun, 13 May 2018 15:56:22 +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 C8D38EB22E; Sun, 13 May 2018 15:56: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 Y61djSb25W0r; Sun, 13 May 2018 15:56: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 A2411EB22D; Sun, 13 May 2018 15:56:19 +0200 (CEST) Date: Sun, 13 May 2018 15:56:19 +0200 Message-ID: <87lgcnr75o.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko Cc: "Babel at IETF" In-Reply-To: <1634e1eb3b4.e3d43e1a73477.1851831231495285395@ovsienko.info> References: <87fu4huzgj.wl-jch@irif.fr> <1628e298460.cd82970b35329.4945272877112645380@ovsienko.info> <87muyi3eqi.wl-jch@irif.fr> <16296069fec.e13616a29759.8282754479379679955@ovsienko.info> <878ta1y8k0.wl-jch@irif.fr> <87sh7aaqpw.wl-jch@irif.fr> <16322fb2d40.b754c16418709.3274574589997739202@ovsienko.info> <87po2dzntf.wl-jch@irif.fr> <163258f779c.1272194bf35512.5113105590240148496@ovsienko.info> <8736z89zfq.wl-jch@irif.fr> <1632b79a2a7.d0dabacb43120.7322644504922173573@ovsienko.info> <87sh737dci.wl-jch@irif.fr> <1633cc005b2.fb8883bc31563.5518090263169039684@ovsienko.info> <87sh70wg5l.wl-jch@irif.fr> <1634e1eb3b4.e3d43e1a73477.1851831231495285395@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]); Sun, 13 May 2018 15:56:21 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sun, 13 May 2018 15:56:22 +0200 (CEST) X-Miltered: at korolev with ID 5AF84405.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5AF84406.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5AF84405.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5AF84406.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 : 5AF84405.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5AF84406.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] Comments about rfc7298bis 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: Sun, 13 May 2018 13:56:25 -0000 > As far as I see after thinking about this new input for a day, the > principal way to fix this would be to mandate that TS/PC number must be > increasing across the lifetime of a speaker (7298-bis Section 5.1 item > (a) goes away, item (c) becomes the recommended default, item > (b) refines the requirements for the timestamp source). A: Hello, Update(X), TS/PC=42 The packet is captured by C. At this point, A and B simultaneously reboot and loose their ANM state. C spoofing A: Hello, Update(X), TS/PC=42 Since B has lost its ANM state, it accepts this packet as authentic, and learns a spoofed route to X through A. At which point, an (authentic) Hello/IHU exchange happens: B: Hello, TS/PC=57 A: Hello, IHU(B, TS/PC=57), TS/PC=43 B's cost to A becomes finite, and the replayed route is installed. Note that I'm not sure that this is a serious attack -- C has managed to get B to route through A, it has not managed to redirect traffic through itself. > A secondary measure would be to have a large ANMTimeout by default > (since item (a) no longer applies) and to save ANM table across reboots, If we assume that the ANM table is persistent, then a lot of things become much easier. Another solution would be to assume that all nodes have real-time clocks, and require that TS/PC carries a timestamp that's no more than 20 seconds in the past. However, I think a more general fix is possible -- the attack above is due to B accepting a (spoofed) packet from A although it has no recent ANM state for A. -- Juliusz From nobody Mon May 14 16:25: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 5417512E8FA for ; Mon, 14 May 2018 16:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 abcHlmCOKi9D for ; Mon, 14 May 2018 16:25:32 -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 77A0612E8E7 for ; Mon, 14 May 2018 16:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1526340326; 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=3211; bh=o2Ct10cSS4MWhlF8SL6fSs7sanYwpVsYqh+SVNb6yLM=; b=b7Kyj+VqN+7MGZOpkxs/+qVNxAvc+uvSWCZUKZ0UIUjW4Zqo8hBcwpRsfKRozPZs d3Eu/4WFU/WqwKgM23NtVMNHHVSK7t4DDr1xAZ2c8s0sUfPgGqHolxPN7M0pZ0vrmpn mLEFLnF3cubjOxxLI2J8yyBNYmCkkPi2yxlUGNt8= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1526340326356310.90299844327694; Mon, 14 May 2018 16:25:26 -0700 (PDT) Date: Tue, 15 May 2018 00:25:26 +0100 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <16360f913d2.e0b88593159986.3607378772559997156@ovsienko.info> In-Reply-To: <87lgcnr75o.wl-jch@irif.fr> References: <87fu4huzgj.wl-jch@irif.fr> <1628e298460.cd82970b35329.4945272877112645380@ovsienko.info> <87muyi3eqi.wl-jch@irif.fr> <16296069fec.e13616a29759.8282754479379679955@ovsienko.info> <878ta1y8k0.wl-jch@irif.fr> <87sh7aaqpw.wl-jch@irif.fr> <16322fb2d40.b754c16418709.3274574589997739202@ovsienko.info> <87po2dzntf.wl-jch@irif.fr> <163258f779c.1272194bf35512.5113105590240148496@ovsienko.info> <8736z89zfq.wl-jch@irif.fr> <1632b79a2a7.d0dabacb43120.7322644504922173573@ovsienko.info> <87sh737dci.wl-jch@irif.fr> <1633cc005b2.fb8883bc31563.5518090263169039684@ovsienko.info> <87sh70wg5l.wl-jch@irif.fr> <1634e1eb3b4.e3d43e1a73477.1851831231495285395@ovsienko.info> <87lgcnr75o.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] Comments about rfc7298bis 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, 14 May 2018 23:25:34 -0000 ---- On Sun, 13 May 2018 14:56:19 +0100 Juliusz Chroboczek wrote ---- >> As far as I see after thinking about this new input for a day, the >> principal way to fix this would be to mandate that TS/PC number must be >> increasing across the lifetime of a speaker (7298-bis Section 5.1 item >> (a) goes away, item (c) becomes the recommended default, item >> (b) refines the requirements for the timestamp source). > >A: Hello, Update(X), TS/PC=42 > >The packet is captured by C. At this point, A and B simultaneously reboot >and loose their ANM state. > >C spoofing A: Hello, Update(X), TS/PC=42 > >Since B has lost its ANM state, it accepts this packet as authentic, and >learns a spoofed route to X through A. At which point, an (authentic) >Hello/IHU exchange happens: > >B: Hello, TS/PC=57 >A: Hello, IHU(B, TS/PC=57), TS/PC=43 > >B's cost to A becomes finite, and the replayed route is installed. > >Note that I'm not sure that this is a serious attack -- C has managed to >get B to route through A, it has not managed to redirect traffic through >itself. Makes sense. The root causes are the same as before -- only the packets with relevant IHU TLVs can be tested for freshness and the main protocol instance actions Update before establishing a 2-way relation with a neighbour. >> A secondary measure would be to have a large ANMTimeout by default >> (since item (a) no longer applies) and to save ANM table across reboots, > >If we assume that the ANM table is persistent, then a lot of things become >much easier. Another solution would be to assume that all nodes have It seems to me it would make sense to recommend a persistent ANM table only if the implementer can do it safely, because trying to write to disk something that changes a few times a second may actually break things on a sudden power cycle. It should do its job even as a purely run-time structure. >real-time clocks, and require that TS/PC carries a timestamp that's no >more than 20 seconds in the past. That's exactly what RFC 7183 defines, but the issue is synchronous offline clocks are either expensive, or unavailable for obvious practical reasons. 7298-bis is supposed to achieve the same effect with TSPCMaxRTT and only requires the clocks to be monotonic. The idea is roughly similar to the RTT Babel extension. >However, I think a more general fix is possible -- the attack above is due >to B accepting a (spoofed) packet from A although it has no recent ANM >state for A. Not quite, but almost there. As far as I see it, the missing design point is to let only Hello TLVs in before seeing a packet with a proven fresh IHU TLV. This way the replayed packets _before_ the IHU will not affect the main protocol instance. As a consequence, any speaker will be able to discard its ANM table on shutdown safely. Once again, for this to work the outgoing TS/PC number must be strictly increasing across the lifetime of a speaker, as explained before. This also gets rid of the replayed Updates _after_ authentic IHUs as the freshness proof will actually work. And this is doable in spite of sudden and frequent reboots. Do you see what I mean? -- Denis Ovsienko From nobody Mon May 14 19:07: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 CFC5212EA6A for ; Mon, 14 May 2018 19:07:49 -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 E7FjWsBbO3g5 for ; Mon, 14 May 2018 19:07:48 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA6E127369 for ; Mon, 14 May 2018 19:07:48 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id j186-v6so16227426ita.5 for ; Mon, 14 May 2018 19:07:47 -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=PebMvUhplrBLOJ5V2d1mrHBl7A0gKb5SI79JDROlac4=; b=BHL98/ceQVrHA/gO6SSoNf6ci9q3LmnpOtNe7cERxBGhoudSkQtFxUCkc0KnfUJfF1 P4H5Qoia/ju8uAUgY0ckUI0kY99Y86p/vONf8sxKqZsPQwz6Rqs0UMcjWyjsYZxorI2w cB/Wy1OoOjeBrIB3430O1D0wtjFLIRNnbg1tIvvmznH5/EFUy8m4METSnlQgBWdoiO8i qA+wWZpCvZIp4upISCA4EUoNDw2J6VHzSOwnEfKixqW2nrOV77dnX2jZZK7hSgHbCWnh T+bXes4fvf+4RpP3F1+aeDxe2HhQryY5G7MfBqnK/rkge2ZzmRzLYB4ZjCbADInvmSra xUOg== 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=PebMvUhplrBLOJ5V2d1mrHBl7A0gKb5SI79JDROlac4=; b=T2vobQSEpcC3BHf3j+tHLIfZ8eK/atverVf0tGiTTZNwZEQvC6QTye5wQO1kaO3/KF nxjOKpWSXK+ZTBIMxyo7OwFBC1XDeS2ZmzxwAsfL/SOYzCeyKSuxNDKEtsJkeNymEBA/ BmKtWQLDqJeq40bo6mt27t3IUGR/gr2E7hxNKKi2I60/ICoxvhBRKiHIjON04t4xLXpO FwvkHRdO6STVnZfXdCgMY9SrvfH5dDsVTIDPyZk90LzNl00WJbkiF9ymegmCoPFatLjW 9bnStqnpLc6F3pxoZOYl9ZbNOT+QNPqYjoPpMR4+82uVQpoPWDwpjWJrBhjxPo2RSgdl UpZQ== X-Gm-Message-State: ALKqPweIgmAvFPhek5RAERv3V3CV0/l3Q3XPd1OIGQq+sBPTwG2a3LMJ fSEneRmfjJTFS6qYHkINwX6t25XISB9Q4ipyXHA= X-Google-Smtp-Source: AB8JxZrdzJ/+Kp+T7iJQjjqOnf902x4x1MzST3ZaIv3QYufchi9KSNVfReVPi0fuCWJo5AtqOD+U2bAApq0J51QGqvg= X-Received: by 2002:a6b:c5a:: with SMTP id w87-v6mr13572162ioi.132.1526350067080; Mon, 14 May 2018 19:07:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.162.15 with HTTP; Mon, 14 May 2018 19:07:31 -0700 (PDT) In-Reply-To: <87woxcmh6m.wl-jch@irif.fr> References: <015101d3d275$7bff1e80$73fd5b80$@olddog.co.uk> <87woxcmh6m.wl-jch@irif.fr> From: Donald Eastlake Date: Mon, 14 May 2018 19:07:31 -0700 Message-ID: To: Juliusz Chroboczek Cc: Adrian Farrel , Babel at IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] draft-ietf-babel-applicability WG Last Call 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: Tue, 15 May 2018 02:07:50 -0000 On Thu, Apr 12, 2018 at 11:08 AM, Juliusz Chroboczek wrote: >> Isn't [RFC6126bs] really a normative reference? > > Donald, please advise. Having just re-read the applicability draft, I'm inclined to believe that this should be a normative reference. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > -- Juliusz From nobody Tue May 15 02:56: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 1BD6C12D7F9; Tue, 15 May 2018 02:56:48 -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 7KgjPbwGbiWS; Tue, 15 May 2018 02:56:46 -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 655BA12D82F; Tue, 15 May 2018 02:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1526378204; 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=757; bh=RF4n5kH6s1Ofxlr8Y+nSbFwijVYxYpOLwK0Cmsx2aoo=; b=NTttXAxDhikXOaW0PGxgR5iRvvJKP9krM8hA95/TMKnNl24xy6iW9ScYwPMdduUF ppqeKzDtYw+nqCD/Oa9l6VJjDkye5kpDBgTiU44AOiRlaJiLvBGVXhYbBsin4i4NoL2 tKm+RBt76qjWi94IxteBoOROPi7OQUZ0NNmh2A6k= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1526378204065215.838437131609; Tue, 15 May 2018 02:56:44 -0700 (PDT) Date: Tue, 15 May 2018 10:56:44 +0100 From: Denis Ovsienko To: "Babel at IETF" , Message-ID: <163633b0ba0.e5fd623a167632.8393356312068248739@ovsienko.info> In-Reply-To: <16320bfcd68.d0931e6e71274.1941219040405816150@ovsienko.info> References: <16320bfcd68.d0931e6e71274.1941219040405816150@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] Call for WG adoption of draft-ovsienko-babel-rfc7298bis (2018-03-25 to 2018-04-08) 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: Tue, 15 May 2018 09:56:48 -0000 ---- On Wed, 02 May 2018 13:07:10 +0100 Denis Ovsienko wrote ---- >---- On Mon, 26 Mar 2018 19:17:06 +0100 Donald Eastlake wrote ---- >>Hi, >> >>This message announces a two week adoption call for draft-ovsienko-babel-rfc7298bis-00.txt running for two week starting from the posting of https://www.ietf.org/mail-archive/web/babel/current/msg01079.html >> >> >>Please comment as to whether or not you think this draft is good basis for further work by the BABEL WG. > >Hello all. > >It has been more than a month since the call so I suggest to go ahead with the adoption as intended. I would like to be able to plan this work. It has been seven weeks since the call. I would like to understand its current status now. -- Denis Ovsienko From nobody Tue May 15 06:49: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 64E0512DA1C; Tue, 15 May 2018 06:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 bP7hWfMTbisb; Tue, 15 May 2018 06:49:44 -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 CDA5312D954; Tue, 15 May 2018 06:49:43 -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 w4FDnfCu002717; Tue, 15 May 2018 15:49: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 3635BEB200; Tue, 15 May 2018 15:49:41 +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 8RrUAav49HhZ; Tue, 15 May 2018 15:49:40 +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 C7716EB915; Tue, 15 May 2018 15:49:37 +0200 (CEST) Date: Tue, 15 May 2018 15:49:37 +0200 Message-ID: <87tvr9jafi.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko Cc: "Babel at IETF" , In-Reply-To: <163633b0ba0.e5fd623a167632.8393356312068248739@ovsienko.info> References: <16320bfcd68.d0931e6e71274.1941219040405816150@ovsienko.info> <163633b0ba0.e5fd623a167632.8393356312068248739@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]); Tue, 15 May 2018 15:49:41 +0200 (CEST) X-Miltered: at korolev with ID 5AFAE575.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5AFAE575.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 : 5AFAE575.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] Call for WG adoption of draft-ovsienko-babel-rfc7298bis (2018-03-25 to 2018-04-08) 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: Tue, 15 May 2018 13:49:46 -0000 > It has been seven weeks since the call. I would like to understand its > current status now. I was under the impression that we're discussing a vulnerability in your protocol. It would be good if we could convince ourselves that the vulnerability is fixable before we adopt. I don't think there's any urgency with adopting; I'd much rather we worked on fixing the protocol and getting it implemented before. On my side, two interns are starting next week. (Yes, I do have a plan for fixing the vulnerability, although I've yet to convince myself it's correct and not overly complex.) -- Juliusz From nobody Tue May 15 08: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 E10F212DA43; Tue, 15 May 2018 08:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.308 X-Spam-Level: X-Spam-Status: No, score=-4.308 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, 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=telekom.de header.b=AAITs+Xz; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=HCuYkc23 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 TgaMfp7Zr0dm; Tue, 15 May 2018 08:40:34 -0700 (PDT) Received: from mailout24.telekom.de (MAILOUT24.telekom.de [80.149.113.254]) (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 DD07D12DA45; Tue, 15 May 2018 08:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1526398834; x=1557934834; h=from:to:cc:subject:date:message-id:mime-version; bh=hqeEktXaBNwibXOvHE1XrLf/h+MFWQI/ccUR2jrbu18=; b=AAITs+XzhVknzuVW8p7FGvFtoAZy2qpB4U+vAi3ahDVGnQl5LCscLynz MRYvowUzfP+N9t6WcXjVckvrRIx/q+NtjBT9MT5dua9hmzOpxqi97caJw mIjZVZol0aKF8wimqo4t151tMz9QSAVjKxmrIqe2VGpo7c2t6c1IydaNb 3tFsRnwYW/N7To3lVTSxQf8QtrwI5/doJ3L7s0ffAyEnnG8zjXVsiL1PL XP6P9HpDpB92vEhFNvej/MDcinrDUWGMzFeRsCnqOky2XC+SNRjVOMgt5 Q1qaOFIP4CDqB+EFV23WAwSKlf5La+7XgL4SGGsdQKoYqOAJ9fgpADzNH Q==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 May 2018 17:40:29 +0200 X-IronPort-AV: E=Sophos;i="5.48,405,1517871600"; d="scan'208,217";a="171307447" Received: from he105848.emea1.cds.t-internal.com ([10.169.118.22]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 15 May 2018 17:40:29 +0200 Received: from HE105850.EMEA1.cds.t-internal.com (10.169.118.24) by HE105848.emea1.cds.t-internal.com (10.169.118.22) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 15 May 2018 17:40:28 +0200 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE105850.EMEA1.cds.t-internal.com (10.169.118.24) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Tue, 15 May 2018 17:40:28 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.15) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 15 May 2018 17:40:12 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hqeEktXaBNwibXOvHE1XrLf/h+MFWQI/ccUR2jrbu18=; b=HCuYkc23oA8V18OQAS/5EK58shIsC/VwNH9btOZnK7+D14ZNIu0IQgRBFRUrVBePmGHINccmY5zKNKkrgjfHTv92tkwp/rtd/6VMytTwKhENiK7t3+8DtBjq+YS5pIq8j/nXD2NW2GJviHyZlzaobO53qWtst6iphbA/YVu+gus= Received: from LEJPR01MB0713.DEUPRD01.PROD.OUTLOOK.DE (10.158.144.135) by LEJPR01MB0715.DEUPRD01.PROD.OUTLOOK.DE (10.158.144.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Tue, 15 May 2018 15:40:26 +0000 Received: from LEJPR01MB0713.DEUPRD01.PROD.OUTLOOK.DE ([fe80::576:6279:1daf:5629]) by LEJPR01MB0713.DEUPRD01.PROD.OUTLOOK.DE ([fe80::576:6279:1daf:5629%13]) with mapi id 15.20.0755.018; Tue, 15 May 2018 15:40:26 +0000 From: To: , , CC: , Thread-Topic: RtgDir Early review: draft-ietf-babel-rfc6126bis-04.txt Thread-Index: AdPsO09o/gCfreaCRMmyrf2Ukkqh+Q== Date: Tue, 15 May 2018 15:40:26 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=N.Leymann@telekom.de; x-originating-ip: [164.19.3.76] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LEJPR01MB0715; 7:TK5cKX1CFuoCuAcadbG1M0x74+8u2M15OMab9TlhBMob7mfwsolgSDPWNbu5Kmr/QPV+MTLGCSfL90ZyX81UBXTLmqW4WAqm6/Ltq+dPE2bBifOMnmKBv0HfDeJnfmQX07uuZQq5GVoSJqgt0NaSLU33mzMuHcCyFnfsfq5Y4gaTGVBMEeoIhvfgue0wwo9qBfRjnEuAfIr/jks7RyDxGk8KDw2/9ECpWkl5p08YKQoLlE+P/NVqm2HQCexBdB90 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(2017052603328)(7153060)(7193020); SRVR:LEJPR01MB0715; x-ms-traffictypediagnostic: LEJPR01MB0715: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(192374486261705)(21748063052155)(17755550239193); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:LEJPR01MB0715; BCL:0; PCL:0; RULEID:; SRVR:LEJPR01MB0715; x-forefront-prvs: 0673F5BE31 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39380400002)(376002)(366004)(39860400002)(469094003)(53484002)(199004)(189003)(3846002)(75402003)(316002)(110136005)(561944003)(2201001)(86362001)(54906003)(33656002)(106356001)(2906002)(14454004)(2900100001)(478600001)(3280700002)(6116002)(74482002)(102836004)(966005)(72206003)(97736004)(59450400001)(105586002)(3660700001)(7696005)(5660300001)(26005)(9686003)(8676002)(81166006)(4326008)(305945005)(6306002)(55016002)(7736002)(52396003)(66066001)(81156014)(8936002)(39060400002)(486006)(68736007)(5250100002)(476003)(186003)(53936002)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:LEJPR01MB0715; H:LEJPR01MB0713.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-microsoft-antispam-message-info: N/5bMxZ45eg9G8vZASbTP0bmR7Ms6d/ERlF81+2nZMIP6iT4gDig9WC98yI//PXj7+5D0sLaQxb1SyKjFJm81szPZ0ptQ4pgE8f8w46KMiS8j0kkWBiC8xjz/NRO4nmzDiJjYiKHPRNqWZuLvGJT0VJgZ5vhJAcmHq8k2CM0UJsLQ2OxT+tameoI70P4sVsFZWcw6MqejLc75Vo1MtGSdA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_LEJPR01MB0713BCD9A66C32A8BD776AB298930LEJPR01MB0713DEUP_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 3f3627d0-b1e8-4890-aab5-08d5ba7a2e5e X-MS-Exchange-CrossTenant-Network-Message-Id: 3f3627d0-b1e8-4890-aab5-08d5ba7a2e5e X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2018 15:40:26.8744 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEJPR01MB0715 X-OriginatorOrg: telekom.de Archived-At: Subject: [babel] RtgDir Early review: draft-ietf-babel-rfc6126bis-04.txt 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: Tue, 15 May 2018 15:40:38 -0000 --_000_LEJPR01MB0713BCD9A66C32A8BD776AB298930LEJPR01MB0713DEUP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIHRvIGRvIGEgcm91dGluZyBkaXJlY3RvcmF0 ZSDigJxlYXJseeKAnSByZXZpZXcgb2YgdGhpcyBkcmFmdC4NCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYmFiZWwtcmZjNjEyNmJpcy8NCg0KVGhlIHJvdXRpbmcg ZGlyZWN0b3JhdGUgd2lsbCwgb24gcmVxdWVzdCBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIGNoYWly LCBwZXJmb3JtIGFuIOKAnGVhcmx54oCdIHJldmlldyBvZiBhIGRyYWZ0IGJlZm9yZSBpdCBpcyBz dWJtaXR0ZWQgZm9yIHB1YmxpY2F0aW9uIHRvIHRoZSBJRVNHLiBUaGUgZWFybHkgcmV2aWV3IGNh biBiZSBwZXJmb3JtZWQgYXQgYW55IHRpbWUgZHVyaW5nIHRoZSBkcmFmdOKAmXMgbGlmZXRpbWUg YXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiBUaGUgcHVycG9zZSBvZiB0aGUgZWFybHkgcmV2 aWV3IGRlcGVuZHMgb24gdGhlIHN0YWdlIHRoYXQgdGhlIGRvY3VtZW50IGhhcyByZWFjaGVkLg0K DQpGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxl YXNlIHNlZSDigItodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kv UnRnRGlyDQoNCkRvY3VtZW50OiBkcmFmdC1pZXRmLWJhYmVsLXJmYzYxMjZiaXMtMDQudHh0DQog UmV2aWV3ZXI6IE5pY29sYWkgTGV5bWFubg0KIFJldmlldyBEYXRlOiAxNS4wNS4yMDE4DQogSW50 ZW5kZWQgU3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sNCg0KU3VtbWFyeToNCkkgaGF2ZSBzb21lIG1p bm9yIGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgdGhhdCBJIHRoaW5rIHNob3VsZCBiZSBy ZXNvbHZlZCBiZWZvcmUgaXQgaXMgc3VibWl0dGVkIHRvIHRoZSBJRVNHLg0KDQpDb21tZW50czoN CkluIGdlbmVyYWwgdGhlIGRyYWZ0IGlzIHdlbGwgd3JpdHRlbiBhbmQgdXNlcyBhIGNsZWFyIGxh bmd1YWdlLiAgRXhwbGFuYXRpb24gb2YgdGVjaG5pY2FsIGRldGFpbHMgYXJlIHN1ZmZpY2llbnQg YW5kIHVuZGVyc3RhbmRhYmxlLiBUaGUgYWJzdHJhY3QgaXMgYSBiaXQgc2hvcnQgYW5kIHNob3Vs ZCBhbHNvIGV4cGxhaW4gaW4gd2hpY2gga2luZCBvZiBlbnZpcm9ubWVudHMgYmFiZWwgaXMgZXhw ZWN0ZWQgdG8gYmUgdXNlZCAoZS5nLiBob21lIG5ldHdvcmtzLCDigKYpLiBBbiBleGFtcGxlIHdp dGggYSDigJxyZWFsIHdvcmxkIGJhYmVsIG5ldHdvcmvigJ0gaW5jbHVkZWQgaW4gdGhlIGludHJv ZHVjdGlvbiB3b3VsZCBtYWtlIHRoZSBjb250ZXh0IG1vcmUgY2xlYXIuIEl0IGlzIGFsc28gbm90 IGNsZWFyIHdoaWNoIHR5cGljYWwgbmV0d29yayBzaXplIGlzIGJlaW5nIGV4cGVjdGVkIChudW1i ZXIgb2YgZGV2aWNlcykuDQoNCkZyb20gbXkgZXhwZXJpZW5jZSBydW5uaW5nIGFuZCBtYW5hZ2lu ZyBhIHJvdXRpbmcgcHJvdG9jb2wgaW5zaWRlIGFuIHR5cGljYWwgZW5kLXVzZXJzIG5ldHdvcmsg aXMgY29tcGxleCwgZXNwZWNpYWxseSBpbiBmYWlsdXJlIHNjZW5hcmlvcyAoaWYgc29tZXRoaW5n IGdvZXMgd3Jvbmcgb3IgaWYgYW4gZGV2aWNlIGlzIG1pc2JlaGF2aW5nKS4gIEVuZCB1c2VycyBh cmUgdXN1YWxseSBub3QgZXhwZXJpZW5jZWQgcm91dGluZyBleHBlcnRzIGFuZCB0ZW5kIHRvIGNh bGwgdGhlIElTUCBpbiBtb3N0IG9mIHRoZSBjYXNlcy4gU28gZm9yIG1lIG9uZSBvZiB0aGUgbWFq b3Igb3BlbiBxdWVzdGlvbiBpcywgaG93IGlzIHRoZSBuZXR3b3JrIGlzIGJlaW5nIG1hbmFnZWQg YW5kIHdoYXQgcG9zc2liaWxpdGllcyBhcmUgb2ZmZXJlZCB0byB0cm91YmxlIHNob290IGZhaWx1 cmVzLg0KDQpTZWN0aW9uIDM6IFRoZSB1c2Ugb2Yg4oCcbXVsdGljYXN04oCdIGFuZCDigJx1bmlj YXN04oCdIGluIHRoZSBjb250ZXh0IG9mIGhlbGxvcyBpcyBhIGJpdCBtaXNsZWFkaW5nLiBUaGVy ZSBhcmUgTXVsdGljYXN0IEhlbGxvcywgVW5pY2FzdCBIZWxsb3MgYW5kIE11bHRpY2FzdCBIZWxs b3Mgb3ZlciBVbmljYXN0LiBXaGljaCBzZXFuIG51bWJlciBpcyB1c2VkIGlmIE11bHRpY2FzdCBv dmVyIFVuaWNhc3QgSGVsbG8gaXMgc2VuZD8NClNlY3Rpb24gMy4xOiBBbnkgYXNzdW1wdGlvbnMg b24gdGhlIG1heGltdW0gc2l6ZSBvZiB0aGUgVURQIGRhdGFncmFtcz8NClNlY3Rpb24gMy4yLjU6 IEhvdyBpcyB0aGUgdGltZXIgc2V0LCBpcyB0aGVyZSBhIGxpc3Qgd2l0aCBkZWZhdWx0IHZhbHVl cz8NClNlY3Rpb24gMy40LjE6IE11bHRpY2FzdCBIZWxsb3MgdG8gTXVsdGljYXN0IGFuZCBVbmlj YXN0IGFkZHJlc3Nlcy4gU2hvdWxkIGJlIGNsYXJpZmllZCBlYXJsaWVyIGluIHRoZSBkb2N1bWVu dC4gVGVybWlub2xvZ3kgaXMgYSBiaXQgY29uZnVzaW5nLg0KU2VjdGlvbiAzLjUuMzogV2hhdCBh cmUgdGhlIHVzZSBjYXNlcyBmb3IgQmFiZWw/IEhvdyBsYXJnZSBpcyBhIGxhcmdlIEJhYmVsIE5l dHdvcmsgKGhvdyBtYW55IG5vZGVzKT8NCiAgLSBMYXRlciBpbiB0aGUgZG9jdW1lbnQgKHNlY3Rp b24gNikgaXQgaXMgc3RhdGVkIHRoYXQgQmFiZWwgaXMgaW5zZWN1cmUuIEZvciBhIGxhcmdlIG5l dHdvcmsgc2VjdXJpdHkgaXMgYW4gaXNzdWUgYW5kIG5lZWRzIHRvIGJlIGFkZHJlc3NlZC4gSSBt aWdodCBiZSBvayB0byBub3QgaW1wbGVtZW50DQogICAgYW55IHNlY3VyaXR5IG1lY2hhbmlzbXMg aW4gYSByZWxhdGl2ZWx5IHNtYWxsIGhvbWUgbmV0d29yayBidXQgZm9yIGEgbGFyZ2UgbmV0d29y ayBpdOKAmXMgbWlzc2lvbiBjcml0aWNhbCB0byBoYXZlIGEgc3RhYmxlLCBzZWN1cmUgYW5kIHJl bGlhYmxlIHJvdXRpbmcgbWVjaGFuaXNtLg0KU2VjdGlvbiAzLjc6IFdoYXQgaXMgYSDigJxtdWx0 aWNhc3QgcGFja2FnZeKAnSBpbiB0aGlzIGNvbnRleHQ/IElzIHRoZSB0cmFuc3BvcnQgYWx3YXlz IHdpdGggYW4gbXVsdGljYXN0IGRlc3RpbmF0aW9uIGFkZHJlc3M/DQpQYWdlIDI5OiDigJxyZWNl bnRseSBmb3J3YXJkZWTigJ0gYW5kIOKAnHN1ZmZpY2llbnRseSBsYXJnZeKAnTsgd2hhdCB2YWx1 ZXMgZG8gSSB1c2UgaGVyZT8NClBhZ2UgMzEsIFNlY3Rpb24gNDogd2hpY2ggd2VsbC1rbm93IG11 bHRpY2FzdCBhZGRyZXNzIGlzIGJlaW5nIHVzZWQ/DQpQYWdlIDQ4LCBTZWN0aW9uIDY6IEFzIG1l bnRpb25lZCBlYXJsaWVyLCBzZWN1cml0eSBpcyBhbiBpc3N1ZSBhbmQgc2hvdWxkIGJlIGFkZHJl c3NlZCBpbiBtb3JlIGRldGFpbC4gSWYgQmFiZWwgaXMgaW5zZWN1cmUgaW4gaXRzZWxmIGFuIGF0 dGFja2VyIGJlaW5nIGNvbm5lY3RlZCB0byBhIEJhYmVsIG5ldHdvcmsgY2FuIGJyaW5nIGRvd24g dGhlIHdob2xlIG5ldHdvcmsuIFR5cGljYWwgc2VjdXJpdHkgbWVjaGFuaXNtIHVzZWQgaW4gbGFy Z2VyIG5ldHdvcmtzIG1pZ2h0IG5vdCBiZSBhcHBsaWNhYmxlIHRvIGhvbWUgbmV0d29yayAoZS5n LiBkdWUgdG8gdGhlIGNvbXBsZXhpdHksIG5lZWQgZm9yIG1hbmFnZW1lbnQsIOKApikuDQoNCk5p dHM6DQpUaGUgbWl4IG9mIOKAnFNIT1VMROKAnS/igJ1TSE9VTEQgTk9U4oCdIGFuZCDigJxSRUNP TU1FTkRFRC9OT1QgUkVDT01NRU5ERUTigJ0gaXMgYSBiaXQgY29uZnVzaW5nLiBNeSBwcm9wb3Nh bCBpcyB0byB1c2Ugb25lIG9mIHRoZSBwYWlycyBhbmQgbm90IHRvIG1peCB0aGVtLg0K4oCcUm91 dGluZyBUYWJsZeKAnSBhbmQg4oCcUm91dGUgVGFibGXigJ0gYXJlIHVzZWQuIENob29zZSBvbmUg OykNCg0KUGFnZSA1LCBTZWN0aW9uIDI6IFJlZmVyZW5jZSB0byBCZWxsbWFuLUZvcmQgcHJvdG9j b2wgd291bGQgYmUgbmljZQ0KUGFnZSA1LCBTZWN0aW9uIDIuMjogRChBKSBhbmQgTkgoQSkgYXJl IGV4cGxhaW5lZCwgYnV0IG5vdCBEKFMpICh3aGljaCBpcyB0aGUgdGhpcmQgcGllY2Ugb2YgZGF0 YSBvdXQgb2YgdHdvKQ0KUGFnZSAxMSwg4oCccm91dGVyLWlkIGNoYW5nZSBTZWN0aW9uIDMuNy4y IMK7IHNvdW5kcyBpZiBzb21ldGhpbmcgaXMgbWlzc2luZw0KUGFnZSAyOCwgU2VjdGlvbiAzLjgu MS4xOiDigJxpZiBzdWNoIGEgcm91dGUgZG9lcyBub3QgaXQgbXVzdOKAnSAoc29tZXRoaW5nIGlz IG1pc3NpbmcpDQpQYWdlIDM5OiBBRSB2YWx1ZXMgMSBhbmQgMyBzaG91bGQgYmUgZXhwbGFpbmVk IGZvciBiZXR0ZXIgcmVhZGFiaWxpdHkgKDE9SVB2NCwgMz1sbElQdjYpDQoNCkkgaG9wZSB0aGlz IGhlbHBzIHRvIGltcHJvdmUgdGhlIGRyYWZ0IGFuZCB0byBtb3ZlIGl0IGZvcndhcmQhDQoNClJl Z2FyZHMNCg0KTmljDQoNCg0K --_000_LEJPR01MB0713BCD9A66C32A8BD776AB298930LEJPR01MB0713DEUP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+SGVsbG8sPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj5JIGhhdmUgYmVlbiBzZWxlY3RlZCB0byBkbyBhIHJvdXRpbmcgZGlyZWN0b3JhdGUg 4oCcZWFybHnigJ0gcmV2aWV3IG9mIHRoaXMgZHJhZnQuPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9 IkNhbGlicmkiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtYmFiZWwtcmZjNjEyNmJpcy8iPjxmb250IGNvbG9yPSJibHVlIj48dT5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWJhYmVsLXJmYzYxMjZiaXMvPC91Pjwv Zm9udD48L2E+PC9mb250PjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+VGhlIHJvdXRp bmcgZGlyZWN0b3JhdGUgd2lsbCwgb24gcmVxdWVzdCBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIGNo YWlyLCBwZXJmb3JtIGFuIOKAnGVhcmx54oCdIHJldmlldyBvZiBhIGRyYWZ0IGJlZm9yZSBpdCBp cyBzdWJtaXR0ZWQgZm9yIHB1YmxpY2F0aW9uIHRvIHRoZSBJRVNHLiBUaGUgZWFybHkgcmV2aWV3 IGNhbiBiZSBwZXJmb3JtZWQgYXQgYW55IHRpbWUgZHVyaW5nIHRoZSBkcmFmdOKAmXMgbGlmZXRp bWUgYXMgYSB3b3JraW5nIGdyb3VwDQpkb2N1bWVudC4gVGhlIHB1cnBvc2Ugb2YgdGhlIGVhcmx5 IHJldmlldyBkZXBlbmRzIG9uIHRoZSBzdGFnZSB0aGF0IHRoZSBkb2N1bWVudCBoYXMgcmVhY2hl ZC4gPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5Gb3IgbW9yZSBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSDigItodHRwOi8vdHJhYy50 b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyIDwvZGl2Pg0KPGRpdj4mbmJz cDs8L2Rpdj4NCjxkaXY+RG9jdW1lbnQ6IGRyYWZ0LWlldGYtYmFiZWwtcmZjNjEyNmJpcy0wNC50 eHQ8L2Rpdj4NCjxkaXY+IFJldmlld2VyOiBOaWNvbGFpIExleW1hbm4gPC9kaXY+DQo8ZGl2PiBS ZXZpZXcgRGF0ZTogMTUuMDUuMjAxODwvZGl2Pg0KPGRpdj4gSW50ZW5kZWQgU3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5TdW1tYXJ5OiA8L2Rp dj4NCjxkaXY+SSBoYXZlIHNvbWUgbWlub3IgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0 aGF0IEkgdGhpbmsgc2hvdWxkIGJlIHJlc29sdmVkIGJlZm9yZSBpdCBpcyBzdWJtaXR0ZWQgdG8g dGhlIElFU0cuIDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Q29tbWVudHM6IDwvZGl2 Pg0KPGRpdj5JbiBnZW5lcmFsIHRoZSBkcmFmdCBpcyB3ZWxsIHdyaXR0ZW4gYW5kIHVzZXMgYSBj bGVhciBsYW5ndWFnZS4mbmJzcDsgRXhwbGFuYXRpb24gb2YgdGVjaG5pY2FsIGRldGFpbHMgYXJl IHN1ZmZpY2llbnQgYW5kIHVuZGVyc3RhbmRhYmxlLiBUaGUgYWJzdHJhY3QgaXMgYSBiaXQgc2hv cnQgYW5kIHNob3VsZCBhbHNvIGV4cGxhaW4gaW4gd2hpY2gga2luZCBvZiBlbnZpcm9ubWVudHMg YmFiZWwgaXMgZXhwZWN0ZWQgdG8gYmUgdXNlZCAoZS5nLiBob21lDQpuZXR3b3Jrcywg4oCmKS4g QW4gZXhhbXBsZSB3aXRoIGEg4oCccmVhbCB3b3JsZCBiYWJlbCBuZXR3b3Jr4oCdIGluY2x1ZGVk IGluIHRoZSBpbnRyb2R1Y3Rpb24gd291bGQgbWFrZSB0aGUgY29udGV4dCBtb3JlIGNsZWFyLiBJ dCBpcyBhbHNvIG5vdCBjbGVhciB3aGljaCB0eXBpY2FsIG5ldHdvcmsgc2l6ZSBpcyBiZWluZyBl eHBlY3RlZCAobnVtYmVyIG9mIGRldmljZXMpLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxk aXY+RnJvbSBteSBleHBlcmllbmNlIHJ1bm5pbmcgYW5kIG1hbmFnaW5nIGEgcm91dGluZyBwcm90 b2NvbCBpbnNpZGUgYW4gdHlwaWNhbCBlbmQtdXNlcnMgbmV0d29yayBpcyBjb21wbGV4LCBlc3Bl Y2lhbGx5IGluIGZhaWx1cmUgc2NlbmFyaW9zIChpZiBzb21ldGhpbmcgZ29lcyB3cm9uZyBvciBp ZiBhbiBkZXZpY2UgaXMgbWlzYmVoYXZpbmcpLiZuYnNwOyBFbmQgdXNlcnMgYXJlIHVzdWFsbHkg bm90IGV4cGVyaWVuY2VkIHJvdXRpbmcgZXhwZXJ0cw0KYW5kIHRlbmQgdG8gY2FsbCB0aGUgSVNQ IGluIG1vc3Qgb2YgdGhlIGNhc2VzLiBTbyBmb3IgbWUgb25lIG9mIHRoZSBtYWpvciBvcGVuIHF1 ZXN0aW9uIGlzLCBob3cgaXMgdGhlIG5ldHdvcmsgaXMgYmVpbmcgbWFuYWdlZCBhbmQgd2hhdCBw b3NzaWJpbGl0aWVzIGFyZSBvZmZlcmVkIHRvIHRyb3VibGUgc2hvb3QgZmFpbHVyZXMuIDwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+U2VjdGlvbiAzOiBUaGUgdXNlIG9mIOKAnG11bHRp Y2FzdOKAnSBhbmQg4oCcdW5pY2FzdOKAnSBpbiB0aGUgY29udGV4dCBvZiBoZWxsb3MgaXMgYSBi aXQgbWlzbGVhZGluZy4gVGhlcmUgYXJlIE11bHRpY2FzdCBIZWxsb3MsIFVuaWNhc3QgSGVsbG9z IGFuZCBNdWx0aWNhc3QgSGVsbG9zIG92ZXIgVW5pY2FzdC4gV2hpY2ggc2VxbiBudW1iZXIgaXMg dXNlZCBpZiBNdWx0aWNhc3Qgb3ZlciBVbmljYXN0IEhlbGxvIGlzIHNlbmQ/PC9kaXY+DQo8ZGl2 PlNlY3Rpb24gMy4xOiBBbnkgYXNzdW1wdGlvbnMgb24gdGhlIG1heGltdW0gc2l6ZSBvZiB0aGUg VURQIGRhdGFncmFtcz88L2Rpdj4NCjxkaXY+U2VjdGlvbiAzLjIuNTogSG93IGlzIHRoZSB0aW1l ciBzZXQsIGlzIHRoZXJlIGEgbGlzdCB3aXRoIGRlZmF1bHQgdmFsdWVzPzwvZGl2Pg0KPGRpdj5T ZWN0aW9uIDMuNC4xOiBNdWx0aWNhc3QgSGVsbG9zIHRvIE11bHRpY2FzdCBhbmQgVW5pY2FzdCBh ZGRyZXNzZXMuIFNob3VsZCBiZSBjbGFyaWZpZWQgZWFybGllciBpbiB0aGUgZG9jdW1lbnQuIFRl cm1pbm9sb2d5IGlzIGEgYml0IGNvbmZ1c2luZy48L2Rpdj4NCjxkaXY+U2VjdGlvbiAzLjUuMzog V2hhdCBhcmUgdGhlIHVzZSBjYXNlcyBmb3IgQmFiZWw/IEhvdyBsYXJnZSBpcyBhIGxhcmdlIEJh YmVsIE5ldHdvcmsgKGhvdyBtYW55IG5vZGVzKT88L2Rpdj4NCjxkaXY+Jm5ic3A7IC0gTGF0ZXIg aW4gdGhlIGRvY3VtZW50IChzZWN0aW9uIDYpIGl0IGlzIHN0YXRlZCB0aGF0IEJhYmVsIGlzIGlu c2VjdXJlLiBGb3IgYSBsYXJnZSBuZXR3b3JrIHNlY3VyaXR5IGlzIGFuIGlzc3VlIGFuZCBuZWVk cyB0byBiZSBhZGRyZXNzZWQuIEkgbWlnaHQgYmUgb2sgdG8gbm90IGltcGxlbWVudDwvZGl2Pg0K PGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsgYW55IHNlY3VyaXR5IG1lY2hhbmlzbXMgaW4gYSByZWxh dGl2ZWx5IHNtYWxsIGhvbWUgbmV0d29yayBidXQgZm9yIGEgbGFyZ2UgbmV0d29yayBpdOKAmXMg bWlzc2lvbiBjcml0aWNhbCB0byBoYXZlIGEgc3RhYmxlLCBzZWN1cmUgYW5kIHJlbGlhYmxlIHJv dXRpbmcgbWVjaGFuaXNtLjwvZGl2Pg0KPGRpdj5TZWN0aW9uIDMuNzogV2hhdCBpcyBhIOKAnG11 bHRpY2FzdCBwYWNrYWdl4oCdIGluIHRoaXMgY29udGV4dD8gSXMgdGhlIHRyYW5zcG9ydCBhbHdh eXMgd2l0aCBhbiBtdWx0aWNhc3QgZGVzdGluYXRpb24gYWRkcmVzcz88L2Rpdj4NCjxkaXY+UGFn ZSAyOTog4oCccmVjZW50bHkgZm9yd2FyZGVk4oCdIGFuZCDigJxzdWZmaWNpZW50bHkgbGFyZ2Xi gJ07IHdoYXQgdmFsdWVzIGRvIEkgdXNlIGhlcmU/PC9kaXY+DQo8ZGl2PlBhZ2UgMzEsIFNlY3Rp b24gNDogd2hpY2ggd2VsbC1rbm93IG11bHRpY2FzdCBhZGRyZXNzIGlzIGJlaW5nIHVzZWQ/PC9k aXY+DQo8ZGl2PlBhZ2UgNDgsIFNlY3Rpb24gNjogQXMgbWVudGlvbmVkIGVhcmxpZXIsIHNlY3Vy aXR5IGlzIGFuIGlzc3VlIGFuZCBzaG91bGQgYmUgYWRkcmVzc2VkIGluIG1vcmUgZGV0YWlsLiBJ ZiBCYWJlbCBpcyBpbnNlY3VyZSBpbiBpdHNlbGYgYW4gYXR0YWNrZXIgYmVpbmcgY29ubmVjdGVk IHRvIGEgQmFiZWwgbmV0d29yayBjYW4gYnJpbmcgZG93biB0aGUgd2hvbGUgbmV0d29yay4gVHlw aWNhbCBzZWN1cml0eSBtZWNoYW5pc20gdXNlZCBpbiBsYXJnZXINCm5ldHdvcmtzIG1pZ2h0IG5v dCBiZSBhcHBsaWNhYmxlIHRvIGhvbWUgbmV0d29yayAoZS5nLiBkdWUgdG8gdGhlIGNvbXBsZXhp dHksIG5lZWQgZm9yIG1hbmFnZW1lbnQsIOKApikuIDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N CjxkaXY+Tml0czogPC9kaXY+DQo8ZGl2PlRoZSBtaXggb2Yg4oCcU0hPVUxE4oCdL+KAnVNIT1VM RCBOT1TigJ0gYW5kIOKAnFJFQ09NTUVOREVEL05PVCBSRUNPTU1FTkRFROKAnSBpcyBhIGJpdCBj b25mdXNpbmcuIE15IHByb3Bvc2FsIGlzIHRvIHVzZSBvbmUgb2YgdGhlIHBhaXJzIGFuZCBub3Qg dG8gbWl4IHRoZW0uPC9kaXY+DQo8ZGl2PuKAnFJvdXRpbmcgVGFibGXigJ0gYW5kIOKAnFJvdXRl IFRhYmxl4oCdIGFyZSB1c2VkLiBDaG9vc2Ugb25lIDspPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj5QYWdlIDUsIFNlY3Rpb24gMjogUmVmZXJlbmNlIHRvIEJlbGxtYW4tRm9yZCBwcm90 b2NvbCB3b3VsZCBiZSBuaWNlPC9kaXY+DQo8ZGl2PlBhZ2UgNSwgU2VjdGlvbiAyLjI6IEQoQSkg YW5kIE5IKEEpIGFyZSBleHBsYWluZWQsIGJ1dCBub3QgRChTKSAod2hpY2ggaXMgdGhlIHRoaXJk IHBpZWNlIG9mIGRhdGEgb3V0IG9mIHR3byk8L2Rpdj4NCjxkaXY+UGFnZSAxMSwg4oCccm91dGVy LWlkIGNoYW5nZSBTZWN0aW9uIDMuNy4yJm5ic3A7wrsgc291bmRzIGlmIHNvbWV0aGluZyBpcyBt aXNzaW5nPC9kaXY+DQo8ZGl2PlBhZ2UgMjgsIFNlY3Rpb24gMy44LjEuMTog4oCcaWYgc3VjaCBh IHJvdXRlIGRvZXMgbm90IGl0IG11c3TigJ0gKHNvbWV0aGluZyBpcyBtaXNzaW5nKTwvZGl2Pg0K PGRpdj5QYWdlIDM5OiBBRSB2YWx1ZXMgMSBhbmQgMyBzaG91bGQgYmUgZXhwbGFpbmVkIGZvciBi ZXR0ZXIgcmVhZGFiaWxpdHkgKDE9SVB2NCwgMz1sbElQdjYpPC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj5JIGhvcGUgdGhpcyBoZWxwcyB0byBpbXByb3ZlIHRoZSBkcmFmdCBhbmQgdG8g bW92ZSBpdCBmb3J3YXJkITwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+UmVnYXJkczwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+TmljPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_LEJPR01MB0713BCD9A66C32A8BD776AB298930LEJPR01MB0713DEUP_-- From nobody Wed May 16 05:07: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 1A48C12946D; Wed, 16 May 2018 05:07:50 -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 utAidoooEEZo; Wed, 16 May 2018 05:07:48 -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 4312C12D873; Wed, 16 May 2018 05:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1526472463; 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=2613; bh=JgHaFXf03yQlwfEiiQgVkj92Uma48gYtCQIDg9QfipA=; b=PXNXQAxcaM9bVFa0MIxrgTNMGEi+oGBE4yJitkg10iTVmYL5fymFo62z83oDebPO YXdA7COPK3yD5Gy6aAyerOpYiaRT0on0t8tRgp2zcVUCc1zoPjaI2PItF7FH1a+gbnL JekKDooNnZ81pNyKYy3schmKA3MfU3Arq0vcEIGE= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1526472463930164.52837421047138; Wed, 16 May 2018 05:07:43 -0700 (PDT) Date: Wed, 16 May 2018 13:07:43 +0100 From: Denis Ovsienko To: "Babel at IETF" , Message-ID: <16368d95639.f2ca280824271.4678778444473383800@ovsienko.info> In-Reply-To: <87tvr9jafi.wl-jch@irif.fr> References: <16320bfcd68.d0931e6e71274.1941219040405816150@ovsienko.info> <163633b0ba0.e5fd623a167632.8393356312068248739@ovsienko.info> <87tvr9jafi.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] Call for WG adoption of draft-ovsienko-babel-rfc7298bis (2018-03-25 to 2018-04-08) 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: Wed, 16 May 2018 12:07:50 -0000 ---- On Tue, 15 May 2018 14:49:37 +0100 Juliusz Chroboczek wrote ---- > > It has been seven weeks since the call. I would like to understand its > > current status now. > > I was under the impression that we're discussing a vulnerability in your > protocol. It would be good if we could convince ourselves that the > vulnerability is fixable before we adopt. > > I don't think there's any urgency with adopting; I'd much rather we worked > on fixing the protocol and getting it implemented before. On my side, two > interns are starting next week. (Yes, I do have a plan for fixing the > vulnerability, although I've yet to convince myself it's correct and not > overly complex.) Juliusz, let me assure you that I have started this round of this work because I see ways to get it done in the first place, and I am taking the quality of my contributions at least as seriously as you have taken the quality of yours. It is correct that we (you and I, two working group members) eventually started to review a solution to the problem, which was initially stated shortly after the WG formation, I really appreciate the recent _constructive_ part of your participation and I am ready to continue until completion. Although a bit overdue, this is a normal way of things. On this note, if you want to fix outstanding issues in 6126-bis, just let me know when you are ready to discuss. At the WG formation in 2016 you did not suggest to delay the adoption of your own pre-WG work, though you wanted a hold-off on 7298-bis to provide the WG with more choices on security mechanisms. After roughly 2 years and not enough progress in this regard this handicap is over. It is correct that I have openly requested the adoption of my I-D to continue this work within the working group, consequently I am demanding the working group chairs to state their decision and act it. This is a normal and upfront agreed upon way of things again. As to "vulnerability in your protocol", let me remind that this was a joint design flaw, with reasoning duly explained on the list. So please mind the wording and try to put the blame where it belongs, not where you would prefer it to be. This is very important for producing the right solution. Your interns are welcome to work on an implementation, as discussed before. And you, like anybody else, are welcome to oppose or support me in the security mechanism work (after my last message the ball is on your side, I believe). But you would have to convince me what is right, rather than tell me what to do. -- Denis Ovsienko From nobody Thu May 17 20:38:11 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 83D51126D45; Thu, 17 May 2018 20:38:10 -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 59BPWPgK3Pju; Thu, 17 May 2018 20:38:08 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A48E51201F8; Thu, 17 May 2018 20:38:08 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id e20-v6so11524792itc.1; Thu, 17 May 2018 20:38:08 -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=RPOpxIGs1GDf0H7kCE9JOOG0cEQ8kELrH0W0/9/mScs=; b=QkCKlqhHPOnKIWbw+XT2gd6uZowVkuMPi/BJavJc0oOTfXXwuWoF5mlFZBP7FJ/aIF 255s0R2C9JhbS85wsxHjOgAu6kzGBncbOFicHHJ4coy9cFqbayqHni26oCUrTS4qvj6R 7G4cprAxy3PEMYCK2QFWWC5OtkPtjebJ5dXOEdbS6jWPF2INT9qv+jM8OSQhqTBt09AN gEH2Cg9x3Agr7y/NfZrUvWD5cP/2KoZLlWTI41SgP8vn2V/ilJ2v1qww5Zx9AZn/bZyu EZn44VWZY9xw2D1pDLOWzFaiTdKntySsajaNbT3L4SBa9xyKos3GiPIeUDa7QmV/AYBA BvQA== 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=RPOpxIGs1GDf0H7kCE9JOOG0cEQ8kELrH0W0/9/mScs=; b=kXriMfhLmMZ0rD+9HZBV5CZzRrHnbbAY8yDvFagyfeGf/dk2Wp3+gQ8hk2hKcj/w/x RqwVQ9215kCzY2htuihe64sgxsHSrya4BcTQure3Bq3hozKkEsvczkoQ3hpfqvXR6v6v JjtPYdwd6obbhWLHxKyx6xKU8e9NB3g2jkNaffCaGQQZnoneHkoZQaFAQzY+eZHBoUPI MGxdbSJxhCngjdnGfhYKYpTt1BFfNtzbaDG7I0tXcosJg6pI4++m4xJoNM7ikgll9gRW rBLOVzFdHHQid5ODYBpsznb9Ltm52Q8JuERPlXmWQ1c4XlZDw4+Af/XproY8gNEus8Nu GgvQ== X-Gm-Message-State: ALKqPwczzUBKRMNJJ6Hi7nMkxzf9ozEH/jZbMezK9uUWhvPkbAYMoA6k xIemDmYadtrZbOfZ6YhRg7+gNfcvm+VpgltNLahdxZHC X-Google-Smtp-Source: AB8JxZpIdL9/wTMEVzr0bZ0y//YFcm9d8RMCm0rH1bsRmKqUwXzocChswYpO+uLAuozf7vG5Fcy0ttRRnnH4iqLxEfw= X-Received: by 2002:a24:6b4f:: with SMTP id v76-v6mr5112154itc.59.1526614687737; Thu, 17 May 2018 20:38:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.162.15 with HTTP; Thu, 17 May 2018 20:37:52 -0700 (PDT) In-Reply-To: <163633b0ba0.e5fd623a167632.8393356312068248739@ovsienko.info> References: <16320bfcd68.d0931e6e71274.1941219040405816150@ovsienko.info> <163633b0ba0.e5fd623a167632.8393356312068248739@ovsienko.info> From: Donald Eastlake Date: Thu, 17 May 2018 23:37:52 -0400 Message-ID: To: Denis Ovsienko Cc: Babel at IETF , babel-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] Call for WG adoption of draft-ovsienko-babel-rfc7298bis (2018-03-25 to 2018-04-08) 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, 18 May 2018 03:38:11 -0000 Hi, On Tue, May 15, 2018 at 5:56 AM, Denis Ovsienko wrote: > ---- On Wed, 02 May 2018 13:07:10 +0100 Denis Ovsienko wrote ---- >>---- On Mon, 26 Mar 2018 19:17:06 +0100 Donald Eastlake wrote ---- >>>Hi, >>> >>>This message announces a two week adoption call for draft-ovsienko-babel-rfc7298bis-00.txt running for two week starting from the posting of https://www.ietf.org/mail-archive/web/babel/current/msg01079.html >>> >>> >>>Please comment as to whether or not you think this draft is good basis for further work by the BABEL WG. >> >>Hello all. >> >>It has been more than a month since the call so I suggest to go ahead with the adoption as intended. I would like to be able to plan this work. > > It has been seven weeks since the call. I would like to understand its current status now. My apologies for being slow to respond. I was on vacation in California recently and am catching up. While there is no specific rule (except in Working Groups that have adopted a rule), typically I would look for at least five non-author supporting posts to adopt a draft. So far I believe there have been three. Note that the adoption of the draft just means that its the starting point for the WG version. I'll post a specific reminder and extend the Last Call for ~10 days. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > -- > > Denis Ovsienko From nobody Thu May 17 21:17:11 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 28FAA126DED; Thu, 17 May 2018 21:17:09 -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 8zCiYjJQXieh; Thu, 17 May 2018 21:17:07 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 982EF126D73; Thu, 17 May 2018 21:17:05 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id e20-v6so4652498iof.4; Thu, 17 May 2018 21:17:05 -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=QpXUcUv2eVNAD304MHOsGbZXiEZh6ao3+fsABI4JJUo=; b=hEPkgGXH3CMm/P/TuaX2yNwHslgEEKdO+AoE408eCCMDDabul9DjtMzSz7QEzG4+vU VdY6nLMzS0vtx+unJp9abOG7j+V/LogbGkbnEam0A6Kqe/NA3xJbI+bWS4sE7KczXena uTWDqIe2vHwVG15qSzpjdDfTTltCHt6hLPhECXJlFYUrR9kAmSPiJwk2lGBV88nh/OWP idlaXtnwzJYugE6ru5Fsi7dXUtqrsUdhoDpMdiS/tmD55NvE9Su56BfSjYdi8zBpoTKT tlKE+cPbxBcyy6BKE58+mfL2lsZB8H3YVsypVdMKcDHgRnfh1YkekNZd6XMMN3k5hPa0 wBgg== 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=QpXUcUv2eVNAD304MHOsGbZXiEZh6ao3+fsABI4JJUo=; b=Upv2mdCZGC7FPRgCIV08MCrmuRtX54oGA5x4o3v0Em20PnYIfyQWI9b2YlXEkgaWsi cQWbjNSOeKrYUyOkaEjt0RjNVO9H1848f/t81KpGlUuSVSzTV/XJjDiyV3XM6VZh98/5 eOnCk5KO/pJkyVf9g6hvchYmovPl7te3+r4l8oRy5zk2L2qE6ge3s97bF7CJDxxJyJ0U zXHxAYmeZxGtAd/dAex0hLuFWhQzwUOtO8DZq7fQN1XZhLJbsLxp//YtT+V5ouql5pHp wzngYNmWgEVdy9bDR0/TMHU6e/yqp/9+3BMb55uJglt4aVIkhMPcmf2sEC5vJ0ZRguBJ 44Gw== X-Gm-Message-State: ALKqPweID4WfSDeKd/t/EnWi6Rxwehq7tiAmvag+v7PdgpwE9qiK1fPH vu9phjPu6ID3o1QhqUg9MYKjthpd24+m+/u0eTjnz9pa X-Google-Smtp-Source: AB8JxZookUkn6epAO16FUlYrCkx6MrSICM+j55lyLiURrymo+r5sMG62dbGe9UcKRmVhTlLI5q8HT7p5ZKs6T94WcAs= X-Received: by 2002:a6b:264d:: with SMTP id m74-v6mr8456257iom.154.1526617024032; Thu, 17 May 2018 21:17:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.162.15 with HTTP; Thu, 17 May 2018 21:16:48 -0700 (PDT) From: Donald Eastlake Date: Fri, 18 May 2018 00:16:48 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [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, 18 May 2018 04:17:09 -0000 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. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Fri May 18 05: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 9829C12D88A; Fri, 18 May 2018 05:55: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 E8p5EH1ZS_Iy; Fri, 18 May 2018 05:55: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 15C0D12D887; Fri, 18 May 2018 05:55:13 -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 w4ICtBCF003209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 18 May 2018 14:55:11 +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 w4ICtDaZ010925; Fri, 18 May 2018 14:55: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 228AFEB98E; Fri, 18 May 2018 14:55: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 pSh1T7ApXdQD; Fri, 18 May 2018 14:55: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 EC942EB984; Fri, 18 May 2018 14:55:09 +0200 (CEST) Date: Fri, 18 May 2018 14:55:09 +0200 Message-ID: <877eo1jf82.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]); Fri, 18 May 2018 14:55:11 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 18 May 2018 14:55:13 +0200 (CEST) X-Miltered: at korolev with ID 5AFECD2F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5AFECD31.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5AFECD2F.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5AFECD31.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 : 5AFECD2F.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5AFECD31.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] 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, 18 May 2018 12:55:17 -0000 > 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. I have mixed feelings, and therefore do not know whether I do or don't support adoption at the current time. On the one hand: - I am convinced that Babel needs a simple, comprehensible, implementable auth mechanism that introduces no heavy dependencies (possibly in addition to any heavier mechanism, such as DTLS); - Denis' draft is a good starting point for obtaining the above. On the other hand: - as described on the list, the protocol appears to be vulnerable to replay, due to an unfortunate confusion between symmetric reachability (as defined by 6126bis) and security association. I have a plan for fixing the vulnerability (by removing the confusion), but I'd like to have a chance to explain my ideas in order to see if they work; - the document (as opposed to the protocol) is very difficult to work with. Three reasons for that: (1) an almost complete lack of rationale and human-readable intuitions, (2) a tendency to repeat the same points multiple times, and (3) a tendency to repeat what is already in 6126bis. This is bad for a security document, and is especially worrying since the author has a poor track record of listening to stylistic (as opposed to technical) criticisms. Should the stylistic issues with the document be fixed, and should my ideas for fixing the vulnerability work out, I'd support adoption with no hesitation. As it currently stands, and since I do not trust the author to fix the editorial issues once the document is adopted, I'm not sure. -- Juliusz From nobody Fri May 18 08:58: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 E3B2912DA4D; Fri, 18 May 2018 08:58:56 -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 9zQN2n5hBoV8; Fri, 18 May 2018 08:58:54 -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 DFFB512D96C; Fri, 18 May 2018 08:58:54 -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 w4IFtRKH006414; Fri, 18 May 2018 11:58:52 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2j20w39j95-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 May 2018 11:58:51 -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 w4IFwoTu004929; Fri, 18 May 2018 11:58:50 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w4IFwjNV004861; Fri, 18 May 2018 11:58:45 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 144A440002BA; Fri, 18 May 2018 15:58:45 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30485.vci.att.com (Service) with ESMTPS id F1A5840006C2; Fri, 18 May 2018 15:58:44 +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.0389.001; Fri, 18 May 2018 11:58:44 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" , Donald Eastlake CC: "babel-chairs@ietf.org" , Babel at IETF Thread-Topic: [babel] Extension of Call for WG adoption of draft-ovsienko-babel-rfc7298bis through 2018-05-28 Thread-Index: AQHT7l8e0nDad8b/vkyBPu2WV7O50aQ1tTeA///q6/A= Date: Fri, 18 May 2018 15:58:44 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DDC604A@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <877eo1jf82.wl-jch@irif.fr> In-Reply-To: <877eo1jf82.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.205.47] 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-05-18_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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805180173 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, 18 May 2018 15:58:57 -0000 I wonder if it might be possible to adopt under certain conditions (in-line= below)? Barbara > From: Juliusz Chroboczek ... > I have mixed feelings, and therefore do not know whether I do or don't > support adoption at the current time. >=20 > On the one hand: >=20 > - I am convinced that Babel needs a simple, comprehensible, > implementable auth mechanism that introduces no heavy dependencies > (possibly in addition to any heavier mechanism, such as DTLS); > - Denis' draft is a good starting point for obtaining the above. I agree =20 > On the other hand: >=20 > - as described on the list, the protocol appears to be vulnerable to > replay, due to an unfortunate confusion between symmetric reachabilit= y > (as defined by 6126bis) and security association. I have a plan for > fixing the vulnerability (by removing the confusion), but I'd like to > have a chance to explain my ideas in order to see if they work; I've seen many adopted drafts die without ever being sent for publication. = I've helped kill a few myself. Admittedly, it is easier to kill prior to ad= option than prior to WGLC -- but not that much easier. Might it be possible= to agree to adopt, but with the understanding that we don't have WGLC unle= ss there are at least 2 interoperable implementations without a replay vuln= erability? That is, there exists a technical issue that *must* be resolved = before WGLC. > - the document (as opposed to the protocol) is very difficult to work > with. Three reasons for that: (1) an almost complete lack of > rationale and human-readable intuitions, (2) a tendency to repeat the > same points multiple times, and (3) a tendency to repeat what is > already in 6126bis. This is bad for a security document, and is > especially worrying since the author has a poor track record of > listening to stylistic (as opposed to technical) criticisms. Authors of WG drafts are assigned by the chairs and do not have to be the s= ame as authors of individual contributions those WG drafts evolve from. If = Denis were willing to work with a co-author, the chairs could assign such a= co-author with the specific charter of making the draft readable. I would = be willing to volunteer to do this. Alternately, the chairs could be cold-h= earted and cruel and completely remove Denis as an author (which I'm not ad= vocating, unless Denis refuses to work with a co-author or wants to complet= ely step aside from this effort). I've seen this done several times. So thi= s is not a reason that should prevent adoption, but is input the chairs sho= uld consider. =20 > Should the stylistic issues with the document be fixed, and should my ide= as > for fixing the vulnerability work out, I'd support adoption with no hesit= ation. > As it currently stands, and since I do not trust the author to fix the ed= itorial > issues once the document is adopted, I'm not sure. >=20 > -- Juliusz >=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=3DkuyFIAvd4lkAsr4xOmt0IOcVUWBjZuPVIcUKHf9RgX4&s > =3D24w8fbY1aQnxpOhJyK1zB-lnaFAfOawqOckSQeh8zUg&e=3D From nobody Fri May 18 14:37: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 42B9112E04F; Fri, 18 May 2018 14:37:31 -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 FxDmn0QJc8HG; Fri, 18 May 2018 14:37: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 19F9D12E049; Fri, 18 May 2018 14:37: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 w4ILbOcx003692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 18 May 2018 23:37:24 +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 w4ILbPOx020185; Fri, 18 May 2018 23:37:25 +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 92482EB22E; Fri, 18 May 2018 23:37:23 +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 iUBkc41eElXC; Fri, 18 May 2018 23:37: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 186DEEB200; Fri, 18 May 2018 23:37:19 +0200 (CEST) Date: Fri, 18 May 2018 23:37:19 +0200 Message-ID: <87lgcgir1s.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "babel-chairs@ietf.org" , Babel at IETF In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DDC604A@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <877eo1jf82.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DDC604A@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 [IPv6:2001:660:3301:8000::1:2]); Fri, 18 May 2018 23:37:24 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 18 May 2018 23:37:25 +0200 (CEST) X-Miltered: at korolev with ID 5AFF4794.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5AFF4795.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5AFF4794.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5AFF4795.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 : 5AFF4794.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5AFF4795.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] 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, 18 May 2018 21:37:32 -0000 > I wonder if it might be possible to adopt I think we ought to adopt at some point, but not necessarily right now. > If Denis were willing to work with a co-author, the chairs could assign > such a co-author with the specific charter of making the draft > readable. I would be willing to volunteer to do this. That's a great offer. Denis, what do you think? > Alternately, the chairs could be cold-hearted and cruel and completely > remove Denis as an author That would be unacceptable for me, we really should be giving proper credit. -- Juliusz From nobody Mon May 21 10:58: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 B3F3012EA7F; Mon, 21 May 2018 10:58:00 -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 InnWD9zOUeDu; Mon, 21 May 2018 10:57:58 -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 E3BF712EA42; Mon, 21 May 2018 10:57:57 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id z6-v6so22034002iti.4; Mon, 21 May 2018 10:57:57 -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=GM4kUf2lcJhBz/L0qMG3f8fd6F6zrqeaoXS2WwMFrY4=; b=Xpgwrb0uUYUuanMsXJ8CoLJcxzGp1HBnOgWyY1rrPLowdr4ChhQvYYoHBKw/0pZ+eO NuJFaKbgJos5eEYXMaKXMpcTMU2u9l42vtjGXp3eDjml8Zhry3etngVwYzG4V9ri8qB2 56P4DgSMxbX+SrYIL35BHQAJH6+3QKvNJAg+1LF7KSq0tle22p2QiUDYyveZpjvhV5JY Ijm4KUH2lVwYP1LcUxFBitxGKL6TYsIkBi7WDT5RoFTI/Y5OVHPqQ6gJa0A6aESuIRiY iAiHj4NkjttDcfOl8TgxbcQNt39yBt9tTmC1hH7k5fzwOjKGn64IV6Xe1ykx2XzAoJB4 phrA== 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=GM4kUf2lcJhBz/L0qMG3f8fd6F6zrqeaoXS2WwMFrY4=; b=PE0tMN4SqWx0RPBxzmOvSzM3iQKTqqAjRgVkIOFNZsBeWhhVICQUAnGiLYbQdu5Yg9 Yj75cYs69nPbSoyiEhPxhEt6w4uTLOUWh9JuT1ac5LIR8NpGoG+bJ3uAuklcakpk35+t zZK4cFIrVgdHpYnX35a7UMI/+RbsiCmaMSFXeuXJMXytmCYkktpXkETkyenU8i0+erf9 632zaZund9/f26R59QSfVatjDERd8bbnUt6z7gWzkuuTc1Wd9a7Zq2NqMzMKM/d8VM34 ppahSzD64fZDT5BDzQyRfqbIL8ZgKUuJhpcCBwpHDK88pdZyTHl5AqroD9ODFfbuT5QH /bhg== X-Gm-Message-State: ALKqPweVLbSjC7HUSGtvwc2aLLjomNacsbWISuoiUnVYc46tR1mkH70r n6xpsYs6lXdSGRbhvDYS0mulhKLyYDEiseW+cnY= X-Google-Smtp-Source: AB8JxZoTfTjipWhosRdi/WVlZfSI/zA73m0d0ABnNL3PHffoFjX5tVmfWiGdXRtXFwKAJm+ka1J/nuzQQUxr/VWBhVo= X-Received: by 2002:a24:1994:: with SMTP id b142-v6mr18513725itb.14.1526925477208; Mon, 21 May 2018 10:57:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.162.15 with HTTP; Mon, 21 May 2018 10:57:41 -0700 (PDT) In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DDC604A@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <877eo1jf82.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DDC604A@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Donald Eastlake Date: Mon, 21 May 2018 13:57:41 -0400 Message-ID: To: "STARK, BARBARA H" Cc: Juliusz Chroboczek , "babel-chairs@ietf.org" , Babel at IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Mon, 21 May 2018 17:58:05 -0000 Hi Barbara, 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, May 18, 2018 at 11:58 AM, STARK, BARBARA H wrote: > > I wonder if it might be possible to adopt under certain conditions (in-li= ne below)? > Barbara > > > From: Juliusz Chroboczek > ... > > I have mixed feelings, and therefore do not know whether I do or don't > > support adoption at the current time. > > > > On the one hand: > > > > - I am convinced that Babel needs a simple, comprehensible, > > implementable auth mechanism that introduces no heavy dependencies > > (possibly in addition to any heavier mechanism, such as DTLS); > > - Denis' draft is a good starting point for obtaining the above. > > I agree > > > On the other hand: > > > > - as described on the list, the protocol appears to be vulnerable to > > replay, due to an unfortunate confusion between symmetric reachabil= ity > > (as defined by 6126bis) and security association. I have a plan fo= r > > fixing the vulnerability (by removing the confusion), but I'd like = to > > have a chance to explain my ideas in order to see if they work; > > I've seen many adopted drafts die without ever being sent for publication= . I've helped kill a few myself. Admittedly, it is easier to kill prior to = adoption than prior to WGLC -- but not that much easier. Might it be possib= le to agree to adopt, but with the understanding that we don't have WGLC un= less there are at least 2 interoperable implementations without a replay vu= lnerability? That is, there exists a technical issue that *must* be resolve= d before WGLC. I suppose it's possible but I don't see much point. If people want 2 interoperable implementations, which is consistent with the way this WG has been thinking about drafts, and such implementations don't exist, either there won't be a WGLC or it will fail. > > - the document (as opposed to the protocol) is very difficult to work > > with. Three reasons for that: (1) an almost complete lack of > > rationale and human-readable intuitions, (2) a tendency to repeat t= he > > same points multiple times, and (3) a tendency to repeat what is > > already in 6126bis. This is bad for a security document, and is > > especially worrying since the author has a poor track record of > > listening to stylistic (as opposed to technical) criticisms. > > Authors of WG drafts are assigned by the chairs and do not have to be the= same as authors of individual contributions those WG drafts evolve from. I= f Denis were willing to work with a co-author, the chairs could assign such= a co-author with the specific charter of making the draft readable. I woul= d be willing to volunteer to do this. Alternately, the chairs could be cold= -hearted and cruel and completely remove Denis as an author (which I'm not = advocating, unless Denis refuses to work with a co-author or wants to compl= etely step aside from this effort). I've seen this done several times. So t= his is not a reason that should prevent adoption, but is input the chairs s= hould consider. It is not that common for WG chairs to exercise their authority over authorship on WG draft. Things normally work out informally. If substantial text changes are needed to the draft, my first through is that people should be proposing text changes or going through and marking up the draft and sending the result to Denis. Involuntarily removing an author of a WG draft is extreme rare and pretty much only happens if there is a clear WG consensus for specific changes and the author refuses to make those changes. I don't see any point in talking about that at this point. 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 > > Should the stylistic issues with the document be fixed, and should my i= deas > > for fixing the vulnerability work out, I'd support adoption with no hes= itation. > > As it currently stands, and since I do not trust the author to fix the = editorial > > issues once the document is adopted, I'm not sure. > > > > -- Juliusz > > > > _______________________________________________ > > 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=3DkuyFIAvd4lkAsr4xOmt0IOcVUWBjZuPVIcUKHf9RgX4&s > > =3D24w8fbY1aQnxpOhJyK1zB-lnaFAfOawqOckSQeh8zUg&e=3D From nobody Tue May 22 08:52: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 86000127275; Tue, 22 May 2018 08:52:22 -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 yNa9RefzWeXa; Tue, 22 May 2018 08:52:20 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 A4F4612741D; Tue, 22 May 2018 08:52:20 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id n202-v6so534742ita.1; Tue, 22 May 2018 08:52:20 -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=8PR/0wFenC/HGB0FvQCg3NE0HF8Z5+iNg29UVdhZ+sk=; b=a/5vS9U2XdOrIm9Z6yNHQRsMq3zHqkqiu0gbXutaePoRUQjTt4gLt92nMkGaSrgDT7 ezcq+e0JVzD/V526Jarqj7M9GK64KssEaER5W8AZ9BmWUSBy1YhDt8V5cnVxRHhFtKSB wUGZLWDJln1TXQTj63LcSYJkB6xAtsHKlj2Z4Nt/OeY2EbKivvamubgQwxd8REhCku63 tlv1acj5O22PReNLC2DF1MernHSpQiQ0s6CY5QKssmPIhgfkeCf/ZjNdYtxA1hQ5PViS PnJRk7UXg3zfzZaGi3FDrsWlozBsxyoQ7hYjBGX9OnlAyGTkOWEmvpItOCGygF04f0tq cVeA== 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=8PR/0wFenC/HGB0FvQCg3NE0HF8Z5+iNg29UVdhZ+sk=; b=Nu0ZQk7b6SOvjGC1ekbzZ4fv2yrrNcvOPev1PusXP6z5YYW9HQNQkuFZDiFTg+z16D bw5hThKKQDYWdpSTm26NYZmhbPAJqRfbjcGCw1Yuxh06lywOeCvb6zLwMsHwxajMNtEY HG6tJbQ0gG7gBvd663Hh0T6ncXp3fcb7w360kNYGrWui8k2hMLN5tH8bkUFKAXOx+Eu1 tLO0X++d/go5qjx6hCgyoGbhL5myHVCq3iwFm7RPkcyNICSrglBVMisLh/lhKq8bxPe1 Zw3lh8UA3KfF4DCMMS++8UOJgSFEoMNKcq52AwlxYPdpcjfGiSpUwclXsiCLZ8Wk9XXM HM3g== X-Gm-Message-State: ALKqPwctjJ2mJbY0Vdb9xUv9GE/HogBJmn0o9ykIaSeB/HxjXdX8k+0D AZakENxLiek/79I0BVLuvj/nSDaLc330m3zH28ySBoD5 X-Google-Smtp-Source: AB8JxZoInS7r0O4bqJyQi6LcZxbnubWlcCvLGwd3l/m58eY6NXNijzoQgeZBpwNF4r/cZ2GkU1e3CD+Gefxuq5Gd1is= X-Received: by 2002:a24:97cf:: with SMTP id k198-v6mr1798082ite.105.1527004339501; Tue, 22 May 2018 08:52:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.162.15 with HTTP; Tue, 22 May 2018 08:52:04 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Tue, 22 May 2018 11:52:04 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" 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: Tue, 22 May 2018 15:52:23 -0000 This is a reminder that https://tools.ietf.org/html/draft-ietf-babel-source-specific-03 is still in WG Last Call and should be considered to be so until the Chairs announce a consensus as to whether the document is ready or not. Thus far, in my opinion, there have been an insufficient number of responses so please indicate whether you believe the document is ready for publication or not or have any suggestions for change. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Mon, Mar 26, 2018 at 2:16 PM, Donald Eastlake wrote: > Hi, > > This message starts a two-week WG Last Call on > draft-ietf-babel-source-specific-03.txt. Please review the draft and > indicate whether you think it is ready for advancement. Comments > welcome. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com From nobody Tue May 22 16:14: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 3D26B12D87F; Tue, 22 May 2018 16:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 61shKj9RuydA; Tue, 22 May 2018 16:14:38 -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 72670129C6D; Tue, 22 May 2018 16:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1527030871; 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=2364; bh=tNHLQgh2vB6gSJupXtIF7k0qmKxh8qGfECa/KCekDg0=; b=YAe0Y2h+w0m7cDESpRcAi4SkZxgbFWEdvJgBcrKvXiFjyw/Quym2tYWZsrNrbuzg fDx1gGpyM6tQ4e6Yk8rFhHXy6/5L/DKuUS6S5tse5iOGQhLWz1sknk+nLWWrg9Lwqeu DZA393SOGmXM6ZJi9esNCoCB/kuT1bl5ZNP5IHlk= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1527030871851161.29908319198523; Tue, 22 May 2018 16:14:31 -0700 (PDT) Date: Wed, 23 May 2018 00:14:31 +0100 From: Denis Ovsienko To: "Babel at IETF" , "babel-chairs@ietf.org" Message-ID: <1638a21f72a.f115e721115322.8073557499992170629@ovsienko.info> In-Reply-To: References: <877eo1jf82.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DDC604A@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] 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: Tue, 22 May 2018 23:14:41 -0000 Hello all. Thank you for making your reasons, let me provide a digest of the main technical points of the proposed work item. HMAC result(s) prove a packet was not modified in transit and was send by a speaker that has the shared secret. This will require adding the packet destination address into the HMAC input in 7298-bis as discussed. RFC 7298 specifies a simple optional way to guarantee that the per-interface outgoing TS/PC number is strictly increasing over the lifetime of a speaker. 7298-bis will need to mandate this property. This way any speaker can tell if any other speaker's sequence of packets runs strictly uphill and never repeats itself. In addition to the above, the IHU-specific TS/PC sub-TLV and the sent TS/PC numbers table in 7298-bis make it possible to tell if an IHU proves (because the local TS/PC number also runs strictly uphill and never repeats) freshness (not just uphill but roughly at the same elevation) that does not exceed the configured threshold. This threshold is specified in real time seconds but does not require the clocks to be synchronous. The latest technical problem Juliusz had pointed out was that the main protocol instance could change its state in response to replayed/delayed [authentic, non-duplicate, in-order] packets with Update(s) but without IHU, and then a fresh IHU could activate those old routes regardless if the speaker currently intends to advertise respective prefixes. I suggested to let only Hello and IHU TLVs through before the first freshness proof occurs. Having thought about it for some time, it seems to me this attack could also work _after_ the freshness has been proved for the first time, it just requires a long enough time span and many enough topology changes to prepare the Update(s) to be sent before the next IHU. At the moment it seems to me to make the most sense to maintain an age timer in 7298-bis for every proof of freshness (i.e. to add a column to ANM table and to use it to tell what TLVs can reach the main protocol instance). Although the proposed concept has slightly moved ahead of the I-D, my understanding is the job is doable and the document is an OK work item. That said, the working group makes the decision, I just need to know what specifically it is to be able to plan my further contributions. Thanks. -- Denis Ovsienko From nobody Wed May 23 21:45: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 DF2BD1204DA; Wed, 23 May 2018 21:45:37 -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 SFk57nnrQ0pJ; Wed, 23 May 2018 21:45:36 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 5DD281200B9; Wed, 23 May 2018 21:45:36 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id t23-v6so731331ioc.10; Wed, 23 May 2018 21:45:36 -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=Sn600u5e0mJehnMeONtsQsjvYJxE0e1PeCgci8N/S6g=; b=SvAm8U7PbKm+Kk9mQj4BC1feCzUpNc9aCLv2tRua4Pls8uXt7DBS1BWTbucpKpAXgr 1PZr+NDW97oBZPb6v3d3UfEYnjFB+qec8jYvHrciGUiCdj6y5vI9zrAS3ttbisChBQUc s5FxqTnf37punQxv1ZrKJDg6XA+bgjTU2Hgd6mhReArZjC8VgJYIolpW3sI/fUuTODic fJMuUI7om3h2DRFs8Prk0BB76TY7/o8FUv2SW3eFTUbR/tkoJIABvjJj7YefSe4XV/GX lc1foJqjfPfACYPKszOaAD0Y5e+Gtkf9oM0sfadW8VaUdyGjlnEEAY1zUmYDRh7cXOxQ KBuA== 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=Sn600u5e0mJehnMeONtsQsjvYJxE0e1PeCgci8N/S6g=; b=glwK/i7iyA9fHSZaVeD6xmhhnkjbnP9D3H46D/YlhgL23EKRT8ELko4+Finu0Dv8Gh nUcNzwQ51otDXEp29jVWiUkoGnDfUxvBhSre0VJI/lYtGcBpOFMwRpyEXbui+WRG1eGI dYSxPVWpaTJ0VsaUE6s1F6t9evgawPn086nqTLc0YPUlPOaehKzzhr/sQ4xnCZ4GPRRX +5c0FnuxemEPyL31EiiXmy8Mm74tD0c3sEYYUF6VI1zKQntCoTAoPiTQrlP3rERtLsw9 ctDEjq2gEBwf8sYTXp7kxIRUrsdZGp0NdbxJMr6gM5TTkjiNip5vjh7aa5DLCdJeIqBM GdEw== X-Gm-Message-State: ALKqPwecfo6YA3cWoJQkjJkGRER6AFWRNlWB8gnPWVLWPzzab4Zi6rWd sa9O7Um4QnMoKMerRBgdlVGXxKAGOxrdcHmh7OOgwUkM X-Google-Smtp-Source: ADUXVKJE1Kg09Ymn0Ae7tRmPJhu3Ft6i9lNZDE4hu9/GcmW9YQS+4acmBgaLNjgeKuLc1pDH/M1XwpTTfltsfp1PON0= X-Received: by 2002:a6b:264d:: with SMTP id m74-v6mr5119913iom.154.1527137135514; Wed, 23 May 2018 21:45:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:a20f:0:0:0:0:0 with HTTP; Wed, 23 May 2018 21:45:19 -0700 (PDT) From: Donald Eastlake Date: Thu, 24 May 2018 00:45:19 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [babel] IPR Poll for draft-ietf-babel-applicability 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: Thu, 24 May 2018 04:45:38 -0000 Hi, This is a poll for any undisclosed IPR in this draft. The author of the draft and anyone whose contribution to the draft had such IPR must respond. Others should respond if they are aware of such IPR. Thanks, Donald PS: See 3979, 4879, 3669 and 5378 for more details on IETF IPR rules. =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Wed May 23 21:47: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 8C4B11200B9; Wed, 23 May 2018 21:47:10 -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 POda9uCGz1eq; Wed, 23 May 2018 21:47:08 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABAB71200A0; Wed, 23 May 2018 21:47:08 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id 144-v6so748050iti.5; Wed, 23 May 2018 21:47:08 -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=sUzv3QYzwS1nspkL2oXMffkeRbnbOi1QIZ5tL0XUR7k=; b=XU5vY/dpzCbVuZToak+K4W/vSjMKrQdzKRXcaWdcVWxer3wzS6v1tRlv1wRTh33lAH jJKkaCJwWH3wZLFKhoG/bhWeTcpGVfcsP1wjpv2m5G/k45nmtUECiTLWj9bx65xrzw8d RCNG+SDTy8z8M+0zE3rSD3ntXoCAJb1xE6gRlTw2x5Z0SxhXXAChjOfjr7NMSOR1McTD IY4w6uuWnOGRchocOes3D0vwiWT+9UVP5xKamwQmjQeYFAZKp02VegRLwiVWZ9cYh3B4 yKBtW2wazkRH2YQTJe890Rms0x1bET3jHmRWqSFoQumSFlwZm93p7TYziszga+amdBA8 xQBQ== 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=sUzv3QYzwS1nspkL2oXMffkeRbnbOi1QIZ5tL0XUR7k=; b=knEHFT+hAlbK44vp+mx5gmD0csnuzyWpse8JEDA3dim0XmclXHPaKy/B3YszrPsCcB SMbQALpPPT31eo5pDlvnDzSI5t5ljpxB523fL5WcZHzx7wVBE0Kxv4EshxB1Cj76WJmc RY0Gy5fQzm8r++zluQhBIW0OgJPVEAjhynVlVoeXoSHhnMUX7kW4fqeHVIomOcXxlqik NdUufOHcpFg6pX4HCsfDnh1NQmd38HPy1u7mD0NVDegU3FaJkkVRgTlXdDTDbQCkAESf of4hgHi345dFmrnaCyBK2wYJs0VxafmQGF9PRoVNDbD9wjWXcMDVmdnmOjgRjRn3mVDZ bjnA== X-Gm-Message-State: ALKqPwejeUCHp+Rp9TRoCYZMStwLRZOx3WnuMNHvMEpcdzdTNYoxe9tV iEMAbb2KnKer6JxyFMjU0IRjvs9pRmvUOLZDHKD2eA== X-Google-Smtp-Source: AB8JxZqObJc6v7lpK5/qIt/VoF5X3uVaYHqlQg1aksCCBmtEh4fymfEdIt4Aw6T0OReZkabXucp3kx1WON2Z6CcO38Y= X-Received: by 2002:a24:97cf:: with SMTP id k198-v6mr3800804ite.105.1527137227879; Wed, 23 May 2018 21:47:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:a20f:0:0:0:0:0 with HTTP; Wed, 23 May 2018 21:46:52 -0700 (PDT) From: Donald Eastlake Date: Thu, 24 May 2018 00:46:52 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [babel] IPR Poll for draft-ietf-babel-source-specific 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: Thu, 24 May 2018 04:47:11 -0000 Hi, This is a poll for any undisclosed IPR in this draft. The authors of the draft and anyone whose contribution to the draft had such IPR must respond. Others should respond if they are aware of such IPR. Thanks, Donald PS: See 3979, 4879, 3669 and 5378 for more details on IETF IPR rules. =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Thu May 24 13:30: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 0A66C12EB33; Thu, 24 May 2018 13:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 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_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 iTH3ChohP_v9; Thu, 24 May 2018 13:30:16 -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 D7FE212EB32; Thu, 24 May 2018 13:30:15 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id g1-v6so3885087iob.2; Thu, 24 May 2018 13:30:15 -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=4+pEnbgHSqTGxlmds0PD7XwxZFE4K50G3ieP0WOJ6sA=; b=kGw5zx5te0sGj6nyaayQirvDpd4f3UNPUkWocJQihXR7+k9/zCVw9eJDZcepNS7W0/ P2g5B3wxC6S6fTAqX8TD2e2VLzWklouRpAjeAYIgWZ8LzWlYcuqF5Qh5CE8uRvpk7Uxt DYThqIbKU1u9blRCfUg1U/bcqun2nvG9NjC4Vjpy9HmEcBc2/W5lTqdih2meiPbq9zdd J26Z2VY1CYQhOJ2LptHjSUskldOfKKofzwIvhBJ6fJW0JEow8FuPpjzE27w92402ePZU +Yzf0QJg6WK3o8YwcnRRkjWOcRD/nGEObay40nSZle0y5Rj1ReICdWsoLF5k47ieO1f/ lIOQ== 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=4+pEnbgHSqTGxlmds0PD7XwxZFE4K50G3ieP0WOJ6sA=; b=bzK/9yX0wmEzwFtcvqV/hWpqagXSkJrFKxFfPTHQRV4Hznkldgm9UwtGZdTeSatmAY 5fJ/0LpCRaj6AugnXdLIWaS4veETkuAXOqMBhH3ZelY/bAB/5EcU3jbtkWkR8KOX18BK Ujzoo9R/Vh6P2hg/tk2RkzCqyhtHqzMl2uXk1Y62vFb4F+9Y7lGI1q9xImxZhhiP1AuD I4K6j1QSIxw/aIJVHuJDSFxy6xXsbxUeZ3KEWTZNHqoerPH9H9ZmsglbspGaIokEAHOy iOQlRXzQOyRAnioCaTqkgugmudX+8jyItpyPRHznDYhxGeKzOErnmCu6YL3tZeWMQR6w HQpg== X-Gm-Message-State: ALKqPwf1KsUZrgfkR72z99XrsfMyi+uXvoWjUttHHx84ByKZN/gU73+v rkX11ucJjQLwA58b3PgPsAGEN7OzKk5nBtCGzYNTtQ1E X-Google-Smtp-Source: ADUXVKJ5y4WMWz9RNX5brCGgLjXmy2c93Of6htNKWH50qeiFAC0WPDsAInXtuiwdkZGceV/ukzJnPP9gYup6jBOrmyk= X-Received: by 2002:a6b:264d:: with SMTP id m74-v6mr8095931iom.154.1527193814663; Thu, 24 May 2018 13:30:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:a20f:0:0:0:0:0 with HTTP; Thu, 24 May 2018 13:29:59 -0700 (PDT) In-Reply-To: <1638a21f72a.f115e721115322.8073557499992170629@ovsienko.info> References: <877eo1jf82.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DDC604A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1638a21f72a.f115e721115322.8073557499992170629@ovsienko.info> From: Donald Eastlake Date: Thu, 24 May 2018 16:29:59 -0400 Message-ID: To: Babel at IETF Cc: "babel-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d38685056cf984bb" 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: Thu, 24 May 2018 20:30:18 -0000 --000000000000d38685056cf984bb Content-Type: text/plain; charset="UTF-8" Hi, Commenting at a slightly higher level, although it is obviously up to the WG whether or not to adopt this draft, the replay discussion seem good and is typical of discussions that happen on security draft that have been adopted. So, I would say that the current questions would not, by most WGs, be considered a bar to acceptance. I have attempted to review the draft. It seems clear that a lot of work went into but it is very wordy and also has a lot of justification and design background material that usually does not appear in an IETF protocol specification. The "bits-on-the-wire" and any necessary state / state-machine at the end points are usually the focus for an IETF protocol specification. The draft seems to provide a lot of implementation options. For example, quantities that can either be implemented as per-interface or implemented per-babel-speaker -- I would have said that if there is clear need for it sometimes being per-interface, then just specify it as always being per-interface. It's an operator interface issue, which is mostly not in scope for a typical protocol specification, whether or not to provide a command to set it for all interfaces or set a default or whatever. On cryptographic algorithms, I think it should just say what you MUST/SHOULD implement and very briefly give the necessary characteristics for the crypto algorithms. Lots of detail about algorithms considered bad by the crypto community and listing possibly good algorithms that could be used does not seem necessary. Assuming this is adopted as an IETF Proposed Standard, or whatever, any future changes will be by a document that will go through the IETF process including security review and it should just be assumed that bad algorithms won't be approved in the future. There is no need to try to give commands about future IETF actions ("MUST NOT consider hash algorithms ... meaningful attacks exist or that are commonly viewed as deprecated") since they are unnecessary and unenforceable. I have a number of other detailed suggestions that I am sending directly to Denis. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, May 22, 2018 at 7:14 PM, Denis Ovsienko wrote: > Hello all. > > Thank you for making your reasons, let me provide a digest of the main > technical points of the proposed work item. > > HMAC result(s) prove a packet was not modified in transit and was send by > a speaker that has the shared secret. This will require adding the packet > destination address into the HMAC input in 7298-bis as discussed. > > RFC 7298 specifies a simple optional way to guarantee that the > per-interface outgoing TS/PC number is strictly increasing over the > lifetime of a speaker. 7298-bis will need to mandate this property. This > way any speaker can tell if any other speaker's sequence of packets runs > strictly uphill and never repeats itself. > > In addition to the above, the IHU-specific TS/PC sub-TLV and the sent > TS/PC numbers table in 7298-bis make it possible to tell if an IHU proves > (because the local TS/PC number also runs strictly uphill and never > repeats) freshness (not just uphill but roughly at the same elevation) that > does not exceed the configured threshold. This threshold is specified in > real time seconds but does not require the clocks to be synchronous. > > The latest technical problem Juliusz had pointed out was that the main > protocol instance could change its state in response to replayed/delayed > [authentic, non-duplicate, in-order] packets with Update(s) but without > IHU, and then a fresh IHU could activate those old routes regardless if the > speaker currently intends to advertise respective prefixes. I suggested to > let only Hello and IHU TLVs through before the first freshness proof occurs. > > Having thought about it for some time, it seems to me this attack could > also work _after_ the freshness has been proved for the first time, it just > requires a long enough time span and many enough topology changes to > prepare the Update(s) to be sent before the next IHU. At the moment it > seems to me to make the most sense to maintain an age timer in 7298-bis for > every proof of freshness (i.e. to add a column to ANM table and to use it > to tell what TLVs can reach the main protocol instance). > > Although the proposed concept has slightly moved ahead of the I-D, my > understanding is the job is doable and the document is an OK work item. > That said, the working group makes the decision, I just need to know what > specifically it is to be able to plan my further contributions. > > Thanks. > > -- > Denis Ovsienko > > > --000000000000d38685056cf984bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Commenting at a slightly higher lev= el, although it is obviously up to the WG whether or not to adopt this draf= t, the replay discussion seem good and is typical of discussions that happe= n on security draft that have been adopted. So, I would say that the curren= t questions would not, by most WGs, be considered a bar to acceptance.

I have attempted to review the draft. It seems clear t= hat a lot of work went into but it is very wordy and also has a lot of just= ification and design background material that usually does not appear in an= IETF protocol specification. The "bits-on-the-wire" and any nece= ssary state / state-machine at the end points are usually the focus for an = IETF protocol specification.
=C2=A0 =C2=A0 =C2=A0The draft seems = to provide a lot of implementation options. For example, quantities that ca= n either be implemented as per-interface or implemented per-babel-speaker -= - I would have said that if there is clear need for it sometimes being per-= interface, then just specify it as always being per-interface. It's an = operator interface issue, which is mostly not in scope for a typical protoc= ol specification, whether or not to provide a command to set it for all int= erfaces or set a default or whatever.
=C2=A0 =C2=A0 =C2=A0On cryp= tographic algorithms, I think it should just say what you MUST/SHOULD imple= ment and very briefly give the necessary characteristics for the crypto alg= orithms. Lots of detail about algorithms considered bad by the crypto commu= nity and listing possibly good algorithms that could be used does not seem necessary. Assuming this is ado= pted as an IETF Proposed Standard, or whatever, any future changes will be = by a document that will go through the IETF process including security revi= ew and it should just be assumed that bad algorithms won't be approved = in the future. There is no need to try to give commands about future IETF a= ctions ("MUST NOT consider hash algorithms ...=C2=A0meaningful attacks exist or that are=C2=A0= commonly viewed as deprecated") since they are unnecessary and = unenforceable.
=C2=A0 =C2=A0 =C2=A0I have a number of other detailed suggestions t= hat I am sending directly to Denis.

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 (cell)
=C2=A0155 Beaver Street, Mi= lford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

On Tue, May 22, 2018 at 7:14 PM, Denis Ovsie= nko <denis@ovsienko.info> wrote:
Hello all.

Thank you for making your reasons, let me provide a digest of the main tech= nical points of the proposed work item.

HMAC result(s) prove a packet was not modified in transit and was send by a= speaker that has the shared secret. This will require adding the packet de= stination address into the HMAC input in 7298-bis as discussed.

RFC 7298 specifies a simple optional way to guarantee that the per-interfac= e outgoing TS/PC number is strictly increasing over the lifetime of a speak= er. 7298-bis will need to mandate this property. This way any speaker can t= ell if any other speaker's sequence of packets runs strictly uphill and= never repeats itself.

In addition to the above, the IHU-specific TS/PC sub-TLV and the sent TS/PC= numbers table in 7298-bis make it possible to tell if an IHU proves (becau= se the local TS/PC number also runs strictly uphill and never repeats) fres= hness (not just uphill but roughly at the same elevation) that does not exc= eed the configured threshold. This threshold is specified in real time seco= nds but does not require the clocks to be synchronous.

The latest technical problem Juliusz had pointed out was that the main prot= ocol instance could change its state in response to replayed/delayed [authe= ntic, non-duplicate, in-order] packets with Update(s) but without IHU, and = then a fresh IHU could activate those old routes regardless if the speaker = currently intends to advertise respective prefixes. I suggested to let only= Hello and IHU TLVs through before the first freshness proof occurs.

Having thought about it for some time, it seems to me this attack could als= o work _after_ the freshness has been proved for the first time, it just re= quires a long enough time span and many enough topology changes to prepare = the Update(s) to be sent before the next IHU. At the moment it seems to me = to make the most sense to maintain an age timer in 7298-bis for every proof= of freshness (i.e. to add a column to ANM table and to use it to tell what= TLVs can reach the main protocol instance).

Although the proposed concept has slightly moved ahead of the I-D, my under= standing is the job is doable and the document is an OK work item. That sai= d, the working group makes the decision, I just need to know what specifica= lly it is to be able to plan my further contributions.

Thanks.

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



--000000000000d38685056cf984bb-- From nobody Thu May 24 14:07: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 AADEC12D77B; Thu, 24 May 2018 14:07:34 -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 yJzk2IKETG1b; Thu, 24 May 2018 14:07:32 -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 F016912D77D; Thu, 24 May 2018 14:07:31 -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 w4OL7TM7005864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 May 2018 23:07:29 +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 w4OL7VUq020538; Thu, 24 May 2018 23:07: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 9261CEB200; Thu, 24 May 2018 23:07:29 +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 Edo_tBd7YxKk; Thu, 24 May 2018 23:07:28 +0200 (CEST) Received: from mac-matthieu.lan (AAubervilliers-652-1-303-39.w83-112.abo.wanadoo.fr [83.112.4.39]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6792FEB27A; Thu, 24 May 2018 23:07:28 +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 In-Reply-To: Date: Thu, 24 May 2018 23:07:27 +0200 Cc: Babel at IETF , babel-chairs@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <62DE54A5-1540-494F-8D32-C584A6688216@irif.fr> References: To: Donald Eastlake 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]); Thu, 24 May 2018 23:07:30 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 24 May 2018 23:07:31 +0200 (CEST) X-Miltered: at korolev with ID 5B072991.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B072993.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B072991.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B072993.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 : 5B072991.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B072993.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] IPR Poll for draft-ietf-babel-source-specific 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: Thu, 24 May 2018 21:07:35 -0000 Hi ! I'm not aware of any IPR. Thanks, Matthieu From nobody Sat May 26 12:15: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 51D8212762F; Sat, 26 May 2018 12:15: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 aNKsTIz8fzd8; Sat, 26 May 2018 12:15: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 D1F4F127337; Sat, 26 May 2018 12:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1527362125; 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=5579; bh=2WQUBToriTeKq9RU1AycZyL3b7ccimmZ+UO+fgw7SWE=; b=pR98SanAA7yqGOgt/WIz/orCOLhmPD6y3m0yWCRfKP2ODIc8UbwXKq2m9E1uN2ym riYl4tMNH2eFVTUkjwGIzw4kWXfrsgxKwSi+C9Rlb6ZVefN6KhVLxOT4B5k1h8tDRmO KHOkWqhX+YEUtYYaz++JPvlR/JUzrW4oZFG66Jz0= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1527362124977118.88947248532656; Sat, 26 May 2018 12:15:24 -0700 (PDT) Date: Sat, 26 May 2018 20:15:24 +0100 From: Denis Ovsienko To: "Babel at IETF" , "babel-chairs@ietf.org" Message-ID: <1639de07cb0.102e9f95e202547.643578535261439543@ovsienko.info> In-Reply-To: References: <877eo1jf82.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DDC604A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1638a21f72a.f115e721115322.8073557499992170629@ovsienko.info> 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] 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: Sat, 26 May 2018 19:15:31 -0000 ---- On Thu, 24 May 2018 21:29:59 +0100 Donald Eastlake = wrote ---- =20 > Hi, =20 > Commenting at a slightly higher level, although it is obviously up to th= e WG whether or not to adopt this draft, the replay discussion seem good an= d is typical of discussions that happen on security draft that have been ad= opted. So, I would say that the current questions would not, by most WGs, b= e considered a bar to acceptance. =20 > I have attempted to review the draft. It seems clear that a lot of work = went into but it is very wordy and also has a lot of justification and desi= gn background material that usually does not appear in an IETF protocol spe= cification. The "bits-on-the-wire" and any necessary state / state-machine = at the end points are usually the focus for an IETF protocol specification.= The draft seems to provide a lot of implementation options. For exampl= e, quantities that can either be implemented as per-interface or implemente= d per-babel-speaker -- I would have said that if there is clear need for it= sometimes being per-interface, then just specify it as always being per-in= terface. It's an operator interface issue, which is mostly not in scope for= a typical protocol specification, whether or not to provide a command to s= et it for all interfaces or set a default or whatever. On cryptographic= algorithms, I think it should just say what you MUST/SHOULD implement and = very briefly give the necessary characteristics for the crypto algorithms. = Lots of detail about algorithms considered bad by the crypto community and = listing possibly good algorithms that could be used does not seem necessary= . Assuming this is adopted as an IETF Proposed Standard, or whatever, any f= uture changes will be by a document that will go through the IETF process i= ncluding security review and it should just be assumed that bad algorithms = won't be approved in the future. There is no need to try to give commands a= bout future IETF actions ("MUST NOT consider hash algorithms ... meaningful= attacks exist or that are commonly viewed as deprecated") since they are u= nnecessary and unenforceable. I have a number of other detailed suggest= ions that I am sending directly to Denis. =20 > =20 =20 Hello Donald and all. =20 =20 Thank you for the thorough review. There is indeed space for improvements i= n this document, which I am willing to discuss. Before responding on partic= ular points let me clarify upfront that the -00 I-D of 7298-bis was derived= from the -09 (last before the RFC) 7298 I-D, and my goal was to identify a= nd try to fix problems in the core design first. The supporting text around= it right now remains mostly inherited, consequently what was good in an Ex= perimental document in 2014 in several cases is not yet good enough in a St= andards Track I-D in 2018. But it all looks workable to me. For the points you have made above:=20 * Yes, 7298-bis does not need to have all the prose from RFC 7298, which en= ded up in the document due to a number of reasons, some of which no longer = apply. That said, from my experience on the implementation side of this fen= ce it looks like extra reasoning/background in the right place helps to get= things right in the field. It would be nice eventually to have a document = that strikes the right balance, I suggest to look at this again after remov= ing some text. * Leaving some implementation options out may be an improvement. In particu= lar, for the outgoing TS/PC numbers this is a necessity, other points may b= e considered, you are welcome to make particular suggestions. * For Section 2.1 (MTI and optional crypto hash algorithms), if the appropr= iateness considerations can be left up to the IETF, that would make the job= a bit easier. For the points you have made inline in the I-D text: * Most of the I-D front page was automatically generated by the xml2rfc too= l, the user has only limited control over the output, sorry. * I appreciate general English proof-reading, RFC 7298 I-Ds incorporated as= much of it as I could get from the reviewers, and still the RFC Editor tea= m made one more round before the publication (that round is not in the 7298= -bis I-D yet). * Section 2.4 (HMAC definition) had to appear in RFC 7298 to identify and s= top a technical error that was introduced in RFC 4822 and kept propagating = into other RFCs. Now that it had served its intended purpose, in 7298-bis i= t should be OK to have just a reference to RFC 2104. * Section 4.1 (updates to protocol encoding -> justification) had to appear= in RFC 7298 to review the options and explain the design choice. Subsequen= t publication of RFC 7557 (now incorporated into 6126-bis) indeed made this= section less useful and this is one of the things to fix (reduce/move/remo= ve) in 7298-bis. * The notes on byte order conversion (sections 5.3 and 5.4 and elsewhere) c= an be reduced in 7298-bis without impacting the document's normative qualit= y. They were in RFC 7298 purely because of my experience with software deve= lopers that kept getting byte order wrong. That said, it should be good eno= ugh for 7298-bis to say about byte order about as much as a typical Standar= ds Track document. * RFC 7298 had Table 1 because the Babel protocol registry did not exist at= that time. I agree that at the current time a document like this should re= fer to the existing registry. Thanks. -- =20 Denis Ovsienko =20 From nobody Sun May 27 16: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 2344A12EAE9; Sun, 27 May 2018 16:29: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 jw3vjFZgJZ-7; Sun, 27 May 2018 16:29:02 -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 A18AD127775; Sun, 27 May 2018 16:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1527463738; 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=5915; bh=JFdAYYYocL7daa2YYdNuPvxTOntNg07pKm5R6begONg=; b=DDJ02kLqnmQCvQ7AEE1IwEdEV14ledukilyDQhRz+mYVy2TpxAyOc3Ae/Y9yI9Ga TlJftd2thEXh+23BVG334Za4WWrAZFMscsoNrmAO02+BJLiTaCHtMsL2wkAzeWdeLtN sz5TIcJe3aVB+tZcSbgwTmzyTwqVDzMW+7oj9TT8= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1527463738548348.0912074331462; Sun, 27 May 2018 16:28:58 -0700 (PDT) Date: Mon, 28 May 2018 00:28:58 +0100 From: Denis Ovsienko To: "Babel at IETF" , Message-ID: <163a3eefcb3.105e54392539813.8869059599002671510@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] 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: Sun, 27 May 2018 23:29:04 -0000 ---- On Tue, 22 May 2018 16:52:04 +0100 Donald Eastlake wrote ---- > This is a reminder that > https://tools.ietf.org/html/draft-ietf-babel-source-specific-03 > is still in WG Last Call and should be considered to be so until the > Chairs announce a consensus as to whether the document is ready or > not. Thus far, in my opinion, there have been an insufficient number > of responses so please indicate whether you believe the document is > ready for publication or not or have any suggestions for change. I have studied the latest revision of the document and would like to provide some feedback on its editorial merits. My lack of experience with the implementation of this extension does not let me do a thorough proof-reading of the technical concept. Note that the route entry contains a source which itself contains a source prefix. These are two very different concepts that should not be confused. (Here it could be helpful to provide a reference that helps the reader get the difference right.) 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?) Fields: Type Set to 128 to indicate a Source Prefix sub-TLV. Length The length of the body, exclusive of the Type and Length fields. Source Plen The length of the advertised source prefix. This MUST NOT be 0. Source Prefix The source prefix being advertised. This field's size is (Source Plen)/8 rounded upwards. (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.) Please find below a patch for the XML source file with some trivial corrections. --- draft-ietf-babel-source-specific-03.xml.orig 2018-05-27 23:21:17.055373767 +0100 +++ draft-ietf-babel-source-specific-03.xml 2018-05-27 23:58:33.402935740 +0100 @@ -55,7 +55,7 @@ The Babel routing protocol is a distance vector routing protocol for next-hop routing. In next-hop routing, each node -maintains a forwarding table which maps destination prefixes to next hops. +maintains a forwarding table, which maps destination prefixes to next hops. The forwarding decision is a per-packet operation which depends on the destination address of the packets and on the entries of the forwarding table. When a packet is about to be routed, its destination address is @@ -102,9 +102,10 @@
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", -"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this -document are to be interpreted as described in . +"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and +"OPTIONAL" in this document are to be interpreted as described in +BCP 14 when, and +only when, they appear in all capitals, as shown here.
@@ -229,7 +230,7 @@ these messages to optionally carry a source prefix sub-TLV, as described in below. The sub-TLV is marked as mandatory, so that an unextended implementation will silently ignore the -whole enclising TLV. A node obeying this specification MUST NOT send +whole enclosing TLV. A node obeying this specification MUST NOT send a TLV with a zero-length source prefix: instead, it sends a TLV with no source prefix sub-TLV. Conversely, an extended implementation MUST interpret an unextended TLV as carrying a source prefix of zero length. @@ -288,7 +289,7 @@ to 0 (a wildcard route request) SHOULD send a full routing table dump, including routes with a non-zero-length source prefix. A node MUST NOT send a wildcard request that carries a source prefix, and a node receiving -a wildcard request with a with a source prefix MUST silently ignore +a wildcard request with a source prefix MUST silently ignore it. @@ -377,7 +378,7 @@ ]]> Fields: - + Set to 128 to indicate a Source Prefix sub-TLV. The length of the body, exclusive of the Type and @@ -392,7 +393,7 @@ The contents of the source prefix sub-TLV are interpreted according to the AE of the enclosing TLV. -Note that this sub-TLV is a mandatory sub-TLV. Threfore, as described +Note that this sub-TLV is a mandatory sub-TLV. Therefore, as described in Section 4.4 of , the whole TLV MUST be ignored if that sub-TLV is not understood (or malformed). Otherwise, routing loops may occur (see ). @@ -439,7 +440,7 @@
IANA has allocated sub-TLV number 128 for the Source Prefix sub-TLV in -the Babel Sub-TLV Numbers registry. +the Babel Sub-TLV Types registry.
@@ -475,6 +476,8 @@ + + The Babel Routing Protocol -- Denis Ovsienko From nobody Mon May 28 14:38:38 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 30367128C0A; Mon, 28 May 2018 14:38:36 -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 Af6Ft2OH7V5Y; Mon, 28 May 2018 14:38:34 -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 44F7A126C0F; Mon, 28 May 2018 14:38:34 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id j186-v6so16170517ita.5; Mon, 28 May 2018 14:38:34 -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=pNYOk0fBwDetb+zQtEUyssqnmVtzczuFQOWux93+EBY=; b=gG+5l0GsYfJB7kpYtiNlVDCZsjw/IgemWVB4LdPRWpwifrxDKtZjMTyqh5R0CRWu30 wQnOzmvX6R3RHOFMmRL9SjbVyZY1bxptB/cMHFS2FSoyg0PYKo+qBkrBa3HsEDxssmzQ cChzoABa0XEiqSnWE7JvCeZxyLTyx5K/q0Jwz8YyjoReYcQiFczOa/MZK5GOg0iwe3XR JF493VPNZXMgHpl5c9UDeo38qSTxiaTvBdS2mM6+0BHV1eKUx3CYsx7TjTFj4CElG5x4 DxYn6PaPUzikYoGMLDsaq2u9x8QmuCQIyT+s19LpLUtIn17QdcQxBpNzCjbzXQ0gTmQB gqkg== 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=pNYOk0fBwDetb+zQtEUyssqnmVtzczuFQOWux93+EBY=; b=mqwRVzqQRm1Ubals/Ytj4vfB8Z+PDldYDl+wHbJkmX3xBVRiEAf0wHqgh1o9SLVl5L mk1gpctTbOb6Vcr062/LwZMkg1OMM155lSmJEx0kXXfREOQ96oVblSGxZVnc++8u0xQE HFYgqLqQJGsFq2JT3W3XVgqJ4UGOenV9NXkAGFLwhPfoPAe50SKpnZENOeOr9Z4YD2xr khpMd79yPXWsOLraDm+ndGf528wkirYEQ6Ao31dAVLFjZXebWINjk89dM+g1ecXgZk7B 2YPODOKR/Soi7tP5ulKmP8hU5lo/BMJ8LZjLKrJQkoSMD38SrEHKNkIGX9lo96GiyNjz gwVw== X-Gm-Message-State: ALKqPwdVQwXr8Ws9kZSjWggkM0qnjIUFsYVgMA7MYR8zgO9f7a2sOTJ4 6P1goNG0Stsfc2qWJrFoiXjyIGx0WKYhmxYXNEVuUiZG X-Google-Smtp-Source: AB8JxZqh/VI3GGXACvodX3z+Z+qLDHLfbJQ1ZrqysIcpt/t++itzs3GGVsT7h+7Q1un9issgknGv/u2wCBuUjFBNt+I= X-Received: by 2002:a24:d651:: with SMTP id o78-v6mr11487403itg.94.1527543513452; Mon, 28 May 2018 14:38:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:a210:0:0:0:0:0 with HTTP; Mon, 28 May 2018 14:38:18 -0700 (PDT) In-Reply-To: <1639de07cb0.102e9f95e202547.643578535261439543@ovsienko.info> References: <877eo1jf82.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DDC604A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1638a21f72a.f115e721115322.8073557499992170629@ovsienko.info> <1639de07cb0.102e9f95e202547.643578535261439543@ovsienko.info> From: Donald Eastlake Date: Mon, 28 May 2018 17:38:18 -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] 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, 28 May 2018 21:38:36 -0000 Hi Denis On Sat, May 26, 2018 at 3:15 PM, Denis Ovsienko wrote= : > ---- On Thu, 24 May 2018 21:29:59 +0100 Donald Eastlake wrote ---- > ... > > Hello Donald and all. > > Thank you for the thorough review. There is indeed space for improvements= in this document, which I am willing to discuss. Before responding on part= icular points let me clarify upfront that the -00 I-D of 7298-bis was deriv= ed from the -09 (last before the RFC) 7298 I-D, and my goal was to identify= and try to fix problems in the core design first. The supporting text arou= nd it right now remains mostly inherited, consequently what was good in an = Experimental document in 2014 in several cases is not yet good enough in a = Standards Track I-D in 2018. But it all looks workable to me. > > For the points you have made above: > > * Yes, 7298-bis does not need to have all the prose from RFC 7298, which = ended up in the document due to a number of reasons, some of which no longe= r apply. That said, from my experience on the implementation side of this f= ence it looks like extra reasoning/background in the right place helps to g= et things right in the field. It would be nice eventually to have a documen= t that strikes the right balance, I suggest to look at this again after rem= oving some text. OK. > * Leaving some implementation options out may be an improvement. In parti= cular, for the outgoing TS/PC numbers this is a necessity, other points may= be considered, you are welcome to make particular suggestions. I think the different suggestions/options for generating TS/PC at transmission are fine because they are handled in a uniform way on receipt. It seems particularly problematic to have configuration variables that can be per-interface or per-babel-speaker. This will make any OAM scheme significantly more complex. > * For Section 2.1 (MTI and optional crypto hash algorithms), if the appro= priateness considerations can be left up to the IETF, that would make the j= ob a bit easier. I think they can in general. It's fine to have a sentence or two or three about the characteristics of suitable algorithms and you certainly need to indicate the initial mandatory or recommended to implement algorithms. But lots of text and lists of good/bad algorithms are not a good idea in my opinion. Such material can never really be complete, will get out of date, etc... > For the points you have made inline in the I-D text: > > * Most of the I-D front page was automatically generated by the xml2rfc t= ool, the user has only limited control over the output, sorry. OK. (I do my drafts in nroff so I am used to having, perhaps, too much control...) > * I appreciate general English proof-reading, RFC 7298 I-Ds incorporated = as much of it as I could get from the reviewers, and still the RFC Editor t= eam made one more round before the publication (that round is not in the 72= 98-bis I-D yet). You're welcome. I actually found very few English errors and none, that I can recall, that was likely to mislead anyone. Mostly there just seem to be extra words and phrases thrown in, use of passive voice, and the like. To some extent this is a matter of taste: it gives the document more of a conversational tone but make it more verbose and is something the RFC Editor staff is likely to want to change anyway. > * Section 2.4 (HMAC definition) had to appear in RFC 7298 to identify and= stop a technical error that was introduced in RFC 4822 and kept propagatin= g into other RFCs. Now that it had served its intended purpose, in 7298-bis= it should be OK to have just a reference to RFC 2104. OK -- But I don't see how RFC 4822 could be a problem. Except maybe for Errata, RFCs are immutable documents, like books a shelf. Even if RFC 4822 updated RFC 2104, which it does not, that would only affect a document referencing RFC 4822 or referencing RFC 4822 and RFC 2014. If you just reference RFC 2104, they you just do what is in RFC 2104 and even later updating RFCs that you do not reference are, at least in principle, irrelevant. > * Section 4.1 (updates to protocol encoding -> justification) had to appe= ar in RFC 7298 to review the options and explain the design choice. Subsequ= ent publication of RFC 7557 (now incorporated into 6126-bis) indeed made th= is section less useful and this is one of the things to fix (reduce/move/re= move) in 7298-bis. OK. > * The notes on byte order conversion (sections 5.3 and 5.4 and elsewhere)= can be reduced in 7298-bis without impacting the document's normative qual= ity. They were in RFC 7298 purely because of my experience with software de= velopers that kept getting byte order wrong. That said, it should be good e= nough for 7298-bis to say about byte order about as much as a typical Stand= ards Track document. OK. As I say, mentioning this just a couple of times and having a worked example that developers can check against should be enough. > * RFC 7298 had Table 1 because the Babel protocol registry did not exist = at that time. I agree that at the current time a document like this should = refer to the existing registry. Ah, OK, guess I wasn't quite aware of the timing with respect to the regist= ry. 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 > Thanks. > > -- > Denis Ovsienko From nobody Tue May 29 09:02: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 846841200C5; Tue, 29 May 2018 09:02:09 -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 j8g-QbYnBkAH; Tue, 29 May 2018 09:02:06 -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 55ABE1275FD; Tue, 29 May 2018 09:02:06 -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 w4TG24Me011445; Tue, 29 May 2018 18:02:04 +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 3CC59EB912; Tue, 29 May 2018 18:02:04 +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 moexkWuj6rMS; Tue, 29 May 2018 18:02:03 +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 C1956EB915; Tue, 29 May 2018 18:02:02 +0200 (CEST) Date: Tue, 29 May 2018 18:02:02 +0200 Message-ID: <87sh6aqwlh.wl-jch@irif.fr> From: Juliusz Chroboczek To: Cc: , , , , 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=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, 29 May 2018 18:02:04 +0200 (CEST) X-Miltered: at korolev with ID 5B0D797C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B0D797C.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 : 5B0D797C.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] RtgDir Early review: draft-ietf-babel-rfc6126bis-04.txt 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: Tue, 29 May 2018 16:02:10 -0000 Dear Nic, Thank you very much for your review, and sorry for the delay replying -- it's exam time here at Babel Towers. > Section 3: The use of “multicast†and “unicast†in the context of hellos is a bit > misleading. I agree. We've puzzled over that for a while, and couldn't find a better terminology. > There are Multicast Hellos, Unicast Hellos and Multicast Hellos over > Unicast. Which seqn number is used if Multicast over Unicast Hello is > send? I've clarified this. > Section 3.1: Any assumptions on the maximum size of the UDP datagrams? Beginning of Section 4. I've added a forward-reference. > Section 3.2.5: How is the timer set, is there a list with default values? It doesn't matter -- "on the order of minutes" is good enough in this case. The (informative) Appendix B gives sample values (3 minutes in this case). > Section 3.4.1: Multicast Hellos to Multicast and Unicast addresses. Should be clarified > earlier in the document. Terminology is a bit confusing. Yeah, the terminology is confusing, but as mentioned before, we couldn't agree on a better one. > Section 3.5.3: What are the use cases for Babel? How large is a large Babel Network (how > many nodes)? That's draft-ietf-babel-applicability, I'd rather not give any figures in this docuemnt. > - Later in the document (section 6) it is stated that Babel is insecure. For a large network > security is an issue and needs to be addressed. I might be ok to not implement > any security mechanisms in a relatively small home network but for a large network it’s > mission critical to have a stable, secure and reliable routing mechanism. We agree, and we're currently working on defining security mechanisms for Babel. The plan is to refer to the security document once it's finalised. > Section 3.7: What is a “multicast package†in this context? Is the > transport always with an multicast destination address? I'm not sure I understand. "Multicast packet" is shorthand for "an IP packet with a multicast destination address". The choice of multicast vs. unicast is described in the second paragraph of Section 3.1. > Page 29: “recently forwarded†and “sufficiently largeâ€; what values do I use here? I've clarified. > Page 31, Section 4: which well-know multicast address is being used? I'm not sure I understand. The "well-known Babel multicast address" is the address assigned by IANA for Babel. > Page 48, Section 6: As mentioned earlier, security is an issue and should be addressed in > more detail. If Babel is insecure in itself an attacker being connected to a Babel network > can bring down the whole network. Typical security mechanism used in larger networks might > not be applicable to home network (e.g. due to the complexity, need for management, …). Yes, we're working on that. > The mix of “SHOULDâ€/â€SHOULD NOT†and “RECOMMENDED/NOT RECOMMENDED†is a bit confusing. My > proposal is to use one of the pairs and not to mix them. I most humbly disagree. > “Routing Table†and “Route Table†are used. Choose one ;) This is deliberate. The "route table" is the data structure described in Section 3.2.6. "Routing table" is a generic term. > Page 5, Section 2: Reference to Bellman-Ford protocol would be nice What do you suggest? > Page 5, Section 2.2: D(A) and NH(A) are explained, but not D(S) (which > is the third piece of data out of two) Disagree. A ranges over all routers, including S. ("Every node A maintains ... D(A)") > Page 11, “router-id change Section 3.7.2 » sounds if something is missing Reworded, thanks. > Page 28, Section 3.8.1.1: “if such a route does not it must†(something is missing) Reworded, thanks. > Page 39: AE values 1 and 3 should be explained for better readability (1=IPv4, 3=llIPv6) Done. Thanks for your help, -- Juliusz From nobody Tue May 29 09:03: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 A2B98126BFD; Tue, 29 May 2018 09:03:09 -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 YKxUX1VKXzPT; Tue, 29 May 2018 09:03:08 -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 B52441274D2; Tue, 29 May 2018 09:03:06 -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 w4TG35De012198; Tue, 29 May 2018 18:03:05 +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 B6E22EB913; Tue, 29 May 2018 18:03:04 +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 teDqnxK_X4ht; Tue, 29 May 2018 18:03:03 +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 B8DC5EB920; Tue, 29 May 2018 18:03:03 +0200 (CEST) Date: Tue, 29 May 2018 18:03:03 +0200 Message-ID: <87r2luqwjs.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 [194.254.61.138]); Tue, 29 May 2018 18:03:05 +0200 (CEST) X-Miltered: at korolev with ID 5B0D79B9.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B0D79B9.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 : 5B0D79B9.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] IPR Poll for draft-ietf-babel-source-specific 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: Tue, 29 May 2018 16:03:10 -0000 None on my side. From nobody Tue May 29 10:19:52 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 98C1012EB04; Tue, 29 May 2018 10:19:44 -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: <152761438457.29529.9159262235017186871@ietfa.amsl.com> Date: Tue, 29 May 2018 10:19:44 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-rfc6126bis-05.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.22 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, 29 May 2018 17:19:45 -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 : The Babel Routing Protocol Authors : Juliusz Chroboczek David Schinazi Filename : draft-ietf-babel-rfc6126bis-05.txt Pages : 59 Date : 2018-05-29 Abstract: Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol, and obsoletes RFCs 6126 and 7557 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-05 https://datatracker.ietf.org/doc/html/draft-ietf-babel-rfc6126bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-rfc6126bis-05 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 May 29 15:38: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 EE9AF12EAEF; Tue, 29 May 2018 15:38: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 lBaEH6NM-XpO; Tue, 29 May 2018 15:38: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 C3A6E12DA47; Tue, 29 May 2018 15:38: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 w4TMchYG000919; Wed, 30 May 2018 00:38:43 +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 F3B59EB22E; Wed, 30 May 2018 00:38: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 GVpjw3wrzWY7; Wed, 30 May 2018 00:38:42 +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 E3FC8EB22D; Wed, 30 May 2018 00:38:41 +0200 (CEST) Date: Wed, 30 May 2018 00:38:41 +0200 Message-ID: <87a7siozny.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko Cc: "Babel at IETF" , "babel-chairs@ietf.org" In-Reply-To: <1638a21f72a.f115e721115322.8073557499992170629@ovsienko.info> References: <877eo1jf82.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114DDC604A@GAALPA1MSGUSRBF.ITServices.sbc.com> <1638a21f72a.f115e721115322.8073557499992170629@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, 30 May 2018 00:38:43 +0200 (CEST) X-Miltered: at korolev with ID 5B0DD673.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B0DD673.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 : 5B0DD673.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] 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: Tue, 29 May 2018 22:38:47 -0000 > Having thought about it for some time, it seems to me this attack could > also work _after_ the freshness has been proved for the first time, it > just requires a long enough time span and many enough topology changes > to prepare the Update(s) to be sent before the next IHU. At the moment > it seems to me to make the most sense to maintain an age timer in > 7298-bis for every proof of freshness (i.e. to add a column to ANM table > and to use it to tell what TLVs can reach the main protocol instance). Yes. From nobody Wed May 30 09:18:23 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 EC0E8124E15 for ; Wed, 30 May 2018 09:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 sLBpvU1ASqys for ; Wed, 30 May 2018 09:18: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 85298124207 for ; Wed, 30 May 2018 09:18: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 w4UGIGvx003755; Wed, 30 May 2018 18:18:16 +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 63B72EB22E; Wed, 30 May 2018 18:18: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 5zuxyuleoyoL; Wed, 30 May 2018 18:18:15 +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 350F6EB22D; Wed, 30 May 2018 18:18:15 +0200 (CEST) Date: Wed, 30 May 2018 18:18:14 +0200 Message-ID: <87sh6915ix.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-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]); Wed, 30 May 2018 18:18:16 +0200 (CEST) X-Miltered: at korolev with ID 5B0ECEC8.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B0ECEC8.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 : 5B0ECEC8.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: [babel] Rethinking HMAC authentication 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: Wed, 30 May 2018 16:18:21 -0000 Dear all, As I mentioned previously, Clara Dô, Weronika Ko³odziejak (in copy of this mail) and myself are currently working on implementing HMAC authentication in babeld roughly based on RFC 7298 and rfc7298bis. Right now, we're not strictly following Denis's spec, but rather enjoying ourselves and experimenting with various approaches, in order to gain experience in a view to defining a common specification by the end of the summer. The work is in its very early stages, so all of the choices below are open to discussion. 1. We're using a pseudo-header, as suggested by David. The exact structure of the pseudo-header is not fixed yet, but it's clearly going to include the source and destination link-local IPs. 2. In addition to the pseudo-header, we're hashing the packet header and the packet body. 3. Contrary to what Denis did, we're not inserting the HMAC TLV into the packet body, but instead appending it in the packet trailer (the part of the UDP datagram that's beyond the packet length). This has two pleasant consequences: - we don't need to insert the HMAC TLVs before hashing; - when receiving a packet, we don't need to do a first parse of the whole packet before checking the HMAC, we jump directly to the packet trailer. We still need to ensure that there is enough space left in the buffer to append all HMAC TLVs (the restrictions on packet length in Section 4 of rfc6126bis apply to the whole packet, not just the packet body). Any non-HMAC TLV present in the packet trailer is silently ignored, for future extensibility (in case somebody finds a use for a TLV that's not protected by HMAC). 4. The TS/PC TLV and the TS/PC echo sub-TLVs are still in the packet body (and hence protected by HMAC). 5. We're not checking TS/PC echos yet. The approach suggested in 7298bis revision 00 has been shown to be unsafe, therefore, as suggested by Denis in a maling list posting, we're going to use a recent proof of liveliness approach. The exact details are still unclear, but I'm thinking about: - a packet is accepted if (1) the TS/PC is higher than the previous value and (2) a correct TS/PC echo has been received from that peer in the last 3 minutes. This implies that the protocol will require capping the IHU interval to 3 minutes (or less, in presence of packet loss). I believe that's acceptable. As mentioned above, all of this is still open to discussion. Please speak up. -- Juliusz From nobody Wed May 30 10:58: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 862F4124BE8 for ; Wed, 30 May 2018 10:58:03 -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 zYpB1VTAJRfa for ; Wed, 30 May 2018 10:58:01 -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 B7652128C0A for ; Wed, 30 May 2018 10:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1527703081; x=2391616681; 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=9L/hdvtQq7OlXvpxCQJcpXfTixQ5excSTJa206LwE6k=; b=LcPxdJ5+XnJanVvoTSehi2Uoy7ZO3kjV9iZLYGRR4UwgL02MEVwRreF2+vpMt65U 3dTT3EMp8S2VTBA1PH4X4bB0iqDsDsZwWao+/OSVbhjNrTvldiXYeKCeyS6sEV8W BAR2dMNJkqIUBnp9V+aVAaBx9HgLQZtRumVt+dkCjSuGX2bqPY7AkO5dQenOLx9G YtpxDYtABooA1C+gxpd6jaHrM45I4Ou+7PCkRY7WcGTzP2qED30UyAYH/mrZrI1C nnghQLK1qvVHGAUy9onwjzRorl7esyoxXVn7gyUnFdWRn4PwdKkUN3l0XBq/YPSw gIOBUC8fygRay3XV3+Q5Iw==; X-AuditID: 11ab0217-24b109e000003e90-0f-5b0ee62865df 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 4C.D5.16016.826EE0B5; Wed, 30 May 2018 10:58:01 -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 <0P9J007L2Z8ODK10@ma1-mtap-s02.corp.apple.com>; Wed, 30 May 2018 10:58:00 -0700 (PDT) Received: from [17.192.155.180] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P9J002ZVZ8O0T20@nwk-mmpp-sz10.apple.com>; Wed, 30 May 2018 10:58:00 -0700 (PDT) X-Va-A: X-Va-T-CD: d59661a006d810078864a2b5ec0f053f X-Va-E-CD: 364ba9793b3bbfb9221b229b541cb094 X-Va-R-CD: 27f632e87b0ecd4c43e83a63c73bf407 X-Va-CD: 0 X-Va-ID: 647d4418-96cf-4342-97a4-4c252f462b9f X-V-A: X-V-T-CD: 7d6566e1ce32e60bd701207e1252a9a5 X-V-E-CD: 364ba9793b3bbfb9221b229b541cb094 X-V-R-CD: 27f632e87b0ecd4c43e83a63c73bf407 X-V-CD: 0 X-V-ID: 941ee6c2-7662-4fe4-aaec-13ff68ca9985 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-30_08:,, signatures=0 Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87sh6915ix.wl-jch@irif.fr> Date: Wed, 30 May 2018 10:57:59 -0700 Cc: Babel at IETF , =?utf-8?Q?Weronika_Ko=C5=82odziejak?= , =?utf-8?B?Q2xhcmEgRMO0?= Message-id: References: <87sh6915ix.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEIsWRmVeSWpSXmKPExsUiqOHDpqv5jC/a4MpcRosti7pZLDZcXsds Mb91GZvFh093WB1YPHbOusvusWTJTyaPxVveMnq8mv6QPYAlissmJTUnsyy1SN8ugStj/dL3 LAULmCuebN/D0sC4k6mLkZNDQsBE4tLsXvYuRi4OIYH9TBLNm1cygiR4BQQlfky+x9LFyMHB LCAvcfC8LEiYWUBL4vujVhaI+o1MEg1v3zBDON8YJS69vAs1lV3iz68dLBC2tsTBO8tYYeyL T5Yxw9iTn/1ghLC5JBZsPc0KskxCQFdi/n8NiDCbxPoTS6BGakk83f6cFcZe0NTLCGMvu30a ahWnxPkvE9khbB2JQ3tnQ9VkS/ydfRQsLiwgLdF14S4rhG0sMffJPiaQtWxAcw6sMQIJcwpo SGzY2cYGYrMIqEq8+f8T7EVmgYWMEi8fNLJDwsdGYvKjI2BzhATUJW6fOg72loiAisTyac+g blCSmP79NtsERrlZSEE6CxGks5CCdAEj8ypG4dzEzBzdzDwjY73EgoKcVL3k/NxNjKBEsJpJ fAfj59eGhxgFOBiVeHg3rOSLFmJNLCuuzD3EKM3BoiTOuzCII1pIID2xJDU7NbUgtSi+qDQn tfgQIxMHp1QDI4v6Y7UK+aXSFw1UnkTd7q/e73HL6YWwT2yE/+XV+qofrsxhcn2Q+758RW4w g3KSR9BfJbHtEaF1d2QVj7vwtFxYy5HbtFbTbvOlmUEKrFu8Jx3t4TqeumtfbL5L4gKhgvLl POvTFs6a7ttelHqOa9teRakWi9uF8vOvFmdWnRO41fl08ncfJZbijERDLeai4kQA4I7nD+UC AAA= Archived-At: Subject: Re: [babel] Rethinking HMAC authentication 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: Wed, 30 May 2018 17:58:04 -0000 Thanks for sharing Juliusz, this is interesting! > On May 30, 2018, at 09:18, Juliusz Chroboczek wrote: > > - when receiving a packet, we don't need to do a first parse of the > whole packet before checking the HMAC, we jump directly to the > packet trailer. Don't you still need to do a first parse of the whole packet to extract the TS/PC for replay protection? David From nobody Wed May 30 11:12: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 2804312D95A for ; Wed, 30 May 2018 11:12:54 -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 sa80l8OHa5aH for ; Wed, 30 May 2018 11:12:52 -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 40DD9126CC4 for ; Wed, 30 May 2018 11:12: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=1527703970; bh=It0Rnmw/XsTmP3tyqLPfsjNzHXAu0qCFRSPHLzgLqAQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=dDCSz21sc8Yuaf4efl9rYP931LbI3/Jf7yKlN06J0/ZMY8LR/uERY1evdYNArP0VR zHM8+pTfCr69QTfDixgROmetL/Z4YcpwUvSmmperKixuP4jLcHhC67vIVQD2c+LYjH AUdupWbxIQsnnf/8Xn69R/YlqevjJcOq/IfUy8qOXCTQPucDiaLTO9DU1pyTxD2V/p RCSXx4th9TmOD6xKg2qMSJauQVaCt+KsVitM6owA3tC1kFmZJESXHvbOIHfz8UXz6v lTuwrvB/pGEKSPJ/2AzMKrBavAeO1lJq2A4EWtsELrImRgcfW92yX2Fe2tOtjHbHvr CwD4wPNPCAHnA== To: David Schinazi , Juliusz Chroboczek Cc: Clara =?utf-8?Q?D=C3=B4?= , Weronika =?utf-8?Q?Ko=C5=82odziejak?= , Babel at IETF In-Reply-To: References: <87sh6915ix.wl-jch@irif.fr> Date: Wed, 30 May 2018 20:12:53 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <876035c8re.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Rethinking HMAC authentication 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: Wed, 30 May 2018 18:12:54 -0000 David Schinazi writes: > Thanks for sharing Juliusz, this is interesting! > >> On May 30, 2018, at 09:18, Juliusz Chroboczek wrote: >> >> - when receiving a packet, we don't need to do a first parse of the >> whole packet before checking the HMAC, we jump directly to the >> packet trailer. > > Don't you still need to do a first parse of the whole packet to > extract the TS/PC for replay protection? Presumably you could check the signature first, then just look for possible replays while parsing the rest? -Toke From nobody Wed May 30 11:16: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 A0D8612EAF5 for ; Wed, 30 May 2018 11:16:19 -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 EKGirzdbv1X4 for ; Wed, 30 May 2018 11:16: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 ED49412EACD for ; Wed, 30 May 2018 11:16:17 -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=1527704176; bh=/W+Nf2sHt7O+GIuDFObN7PYxeX4pLW6xDfAyAGXN2Qs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=WiBADom2ui89+fhdcYuPPC8qbWE9zQvdJMgxoBDuuofrAxaNzK3HGz3HuFBzXw0QT zjpLCHb87KQegLiVSWhZx/SiGLwG87CwsVtesGhpoEjPyfPSrkJCjyappT0fAVGCPU /V+mBw86r1ghJjb217K5FrRb3pVO+KmdWONGyZCNPqivO+qnWgjzu3IIvHlPYe2K1B 1XP9X6UqME18B6B7V7oHyjK/WKjkcPpfKWuO6MIlWfmFa2SfacXx2Gpl4HSWbRCdDz WerxAhNROCNvLTWAgucn/fZAFEbENrmbwkqC4K/ak+aSFHrNeCTEIZoUy85KgGHw+B cvIWPOqDWwH5w== To: Juliusz Chroboczek , babel@ietf.org Cc: Weronika =?utf-8?Q?Ko=C5=82odziejak?= , Clara =?utf-8?Q?D=C3=B4?= In-Reply-To: <87sh6915ix.wl-jch@irif.fr> References: <87sh6915ix.wl-jch@irif.fr> Date: Wed, 30 May 2018 20:16:19 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <8736y9c8lo.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Rethinking HMAC authentication 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: Wed, 30 May 2018 18:16:20 -0000 Juliusz Chroboczek writes: > 2. In addition to the pseudo-header, we're hashing the packet header and > the packet body. What does packet header mean here? Babel header? UDP header? IP header? I assume the former, right? > 3. Contrary to what Denis did, we're not inserting the HMAC TLV into the > packet body, but instead appending it in the packet trailer (the part > of the UDP datagram that's beyond the packet length). This has two > pleasant consequences: > > - we don't need to insert the HMAC TLVs before hashing; I like this. The zeroing and rewriting bits in 7298 always struck me as annoyingly complicated... > As mentioned above, all of this is still open to discussion. Please > speak up. Most of the rest seems sensible. What hashing algorithms are you implementing? For small routers, blake2s might be good to have as MTI (http://blake2.net/). I asked the crypto guy at my department what he would recommend in this day and age, and he basically said "just do SHA256; and blake2s if you want to be fast on small devices"... -Toke From nobody Wed May 30 11:21: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 50A0412EB6F for ; Wed, 30 May 2018 11:21: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 9F9VcL1d8f1x for ; Wed, 30 May 2018 11:21:45 -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 D85E412EB5C for ; Wed, 30 May 2018 11:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1527704505; x=2391618105; 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=I6JFxxdtQH1BAwdqx2+buTqPQm6xOwRGTH2MhE4ILWg=; b=S7J1e/qd4wdZ1mUm8ArFKtVCuWJr/dfo6ylGNwNZyQVkFOP1p2ASWwMN52OVe5Ic mT9Nead6YAJXhdbOYMkI3Cs2GYURAj60TlfgpieXRP94Jd1xOyGoOcj3bA96NTF3 zEsExxxu2XzXN3bv2KbmQ/PEdWL8mRhES7qKrbKZo7zpAGEt/O3Yd31UlvDcbFfz IB33Rn3Hkgs0JLYtYU2OpQcrUB6PBU7E6iVp81S+kIRG81eV3L1EkrReTFu8BZXf /0kQAgW/ypCdL7ycnnELXN5blACdEjHRfPyQYRc6qUj8hIki09KAut6O87k6DANX Fn1oSqdDON6RQH9jXRck0A==; X-AuditID: 11973e13-62dff7000000242c-c4-5b0eebb9b6cc Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) (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 C4.26.09260.9BBEE0B5; Wed, 30 May 2018 11:21:45 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0P9K003GS0C89IE0@ma1-mtap-s01.corp.apple.com>; Wed, 30 May 2018 11:21:44 -0700 (PDT) Received: from [17.192.155.180] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P9K00KY00C8RQB0@nwk-mmpp-sz10.apple.com>; Wed, 30 May 2018 11:21:44 -0700 (PDT) X-Va-A: X-Va-T-CD: c5a7321f76d9a4ca2e93bf28536377c1 X-Va-E-CD: 364ba9793b3bbfb9221b229b541cb094 X-Va-R-CD: 27f632e87b0ecd4c43e83a63c73bf407 X-Va-CD: 0 X-Va-ID: 4b8b97d7-9469-4857-805f-ea5e49d996ee X-V-A: X-V-T-CD: 319a1c775657bc6582695a36a4aadeb6 X-V-E-CD: 364ba9793b3bbfb9221b229b541cb094 X-V-R-CD: 27f632e87b0ecd4c43e83a63c73bf407 X-V-CD: 0 X-V-ID: f5419de7-9c28-4220-a6df-a2ba31ba1e2b X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-30_09:,, signatures=0 Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <876035c8re.fsf@toke.dk> Date: Wed, 30 May 2018 11:21:43 -0700 Cc: Juliusz Chroboczek , =?utf-8?Q?Weronika_Ko=C5=82odziejak?= , =?utf-8?B?Q2xhcmEgRMO0?= , Babel at IETF Content-transfer-encoding: quoted-printable Message-id: <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> References: <87sh6915ix.wl-jch@irif.fr> <876035c8re.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+NgFrrJIsWRmVeSWpSXmKPExsUiqOHDqrvzNV+0wY6nKhZbFnWzWGy4vI7Z Yn7rMjaLre9XsFt8+HSH1YHVY+esu+weS5b8ZPJYvOUto8eWQxfZPF5Nf8gewBrFZZOSmpNZ llqkb5fAldG68w9jwVv2ivuTZrI3MM5k62Lk5JAQMJH4ceQscxcjF4eQwD4miWkr9oAleAUE JX5MvsfSxcjBwSygLjFlSi5EzUYmic0b9rFCON8YJe6eX8sOMYld4s+vHSwQtrbE49Wv2GDs i0+WMcPYk5/9YISwuSQWbD3NCmHrSnxrXgNls0msP7GECWSxhICWxMLbhhBhLYkFTb2MMPay 26ehVnFKnP8ykR2iXEfi+VNZiHC2xIcne8BKhAWkJbou3GWFsI0l5j7ZBzadDWjMgTVGICan gKpETwPYvSxAZv/djYwgDzILHGWUWNlzDOxBZqDjn7y7wAoJHRuJRTt/gDUICRRLPLj5AaxG RMBeovHrBajLlCSmf7/NNoFRbhZSgM5CBOgsJFMXMDKvYhTKTczM0c3MM9VLLCjISdVLzs/d xAhKC9PthHcwnl5ldYhRgINRiYd3w0q+aCHWxLLiytxDjNIcLErivDWTOaKFBNITS1KzU1ML Uovii0pzUosPMTJxcEo1MFaXOZzdbO/n9evEoWyuG7WHOZxuOrJ/UV7/8Y/wB/XMkhWrpAo2 HTy8p990R2uT4iQfx3VfSifO2X13rfbV3I3bu8MPHOor3erbfLhDlvmjx7lV7UKev6+8e1R+ MabDWKrfWPh5UGSk5Ymj9i9uLEm6tJXxzqvHCgvez6rK73wU/njrr86EKbeUWIozEg21mIuK EwEyvPcJ7AIAAA== Archived-At: Subject: Re: [babel] Rethinking HMAC authentication 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: Wed, 30 May 2018 18:21:48 -0000 > On May 30, 2018, at 11:12, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > David Schinazi writes: >=20 >> Thanks for sharing Juliusz, this is interesting! >>=20 >>> On May 30, 2018, at 09:18, Juliusz Chroboczek wrote: >>>=20 >>> - when receiving a packet, we don't need to do a first parse of = the >>> whole packet before checking the HMAC, we jump directly to the >>> packet trailer. >>=20 >> Don't you still need to do a first parse of the whole packet to >> extract the TS/PC for replay protection? >=20 > Presumably you could check the signature first, then just look for > possible replays while parsing the rest? The problem is that if there are TLVs before the TS/PC, you don't want = to act on them until you've validated the TS/PC and MAC. This could be solved by mandating that the TS/PC TLVs MUST come before any other TLVs, but adding ordering requirements to Babel TLVs makes me cringe. David From nobody Wed May 30 11:57: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 110F212DB70 for ; Wed, 30 May 2018 11:57:05 -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 EFI5CV3fHdEy for ; Wed, 30 May 2018 11:57:03 -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 117AB127867 for ; Wed, 30 May 2018 11:57:03 -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=1527706620; bh=Z/6bIq+ztnFuK35eJsPbejoL+XxpfY0dj13oP9UA0So=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=SEIroG/Eu6Sc3y9X/0+OWs8t6ou4RKtwgq2OuoduXzSq8o1WwpuZb1lIKaPztBRcZ yZpCARY+65wYxf2GMLeVd2PHyfXrBtQCB2qE8z2C7Cy1CyYGRK7OPTqm2Q2iTZH7/H r00PPDQM1UnjFVgW8YxoO8+eHsnqxhYFg2bq0rMMgtOj5Fibf6nhy2MitalwIIAknp ZtVhuvEUmkf0in7Zz/xOwgMPeQXlouEUwsubQ9JpdXsPmdFi8ZwNTwz+gYCCSxapDg Zy4zGufXkYSisO5Xmp9Yy8kUCX3lLyQCmXz8U/fF+NCuCROcqgiS/LjX1rkTzY7wib Kd7RWkFxw8Ejg== To: David Schinazi Cc: Juliusz Chroboczek , Weronika =?utf-8?Q?Ko=C5=82odziejak?= , Clara =?utf-8?Q?D=C3=B4?= , Babel at IETF In-Reply-To: <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> References: <87sh6915ix.wl-jch@irif.fr> <876035c8re.fsf@toke.dk> <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> Date: Wed, 30 May 2018 20:57:03 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87zi0has5c.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Rethinking HMAC authentication 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: Wed, 30 May 2018 18:57:05 -0000 David Schinazi writes: >> On May 30, 2018, at 11:12, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >> David Schinazi writes: >>=20 >>> Thanks for sharing Juliusz, this is interesting! >>>=20 >>>> On May 30, 2018, at 09:18, Juliusz Chroboczek wrote: >>>>=20 >>>> - when receiving a packet, we don't need to do a first parse of the >>>> whole packet before checking the HMAC, we jump directly to the >>>> packet trailer. >>>=20 >>> Don't you still need to do a first parse of the whole packet to >>> extract the TS/PC for replay protection? >>=20 >> Presumably you could check the signature first, then just look for >> possible replays while parsing the rest? > > The problem is that if there are TLVs before the TS/PC, you don't want > to act on them until you've validated the TS/PC and MAC. This could be > solved by mandating that the TS/PC TLVs MUST come before any other > TLVs, but adding ordering requirements to Babel TLVs makes me cringe. Or you could just build a parser that is robust against that sort of thing? ;) Arguably, a malformed packet should be discarded without acting on any TLVs anyway, HMAC or not... -Toke From nobody Wed May 30 12:03: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 D5AFB12EA7F for ; Wed, 30 May 2018 12:02: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 7KJAxD3Lm-XJ for ; Wed, 30 May 2018 12:02: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 0660B12EB9D for ; Wed, 30 May 2018 12:02:47 -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 w4UJ2kds012620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 May 2018 21:02:46 +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 w4UJ2mmi010827; Wed, 30 May 2018 21:02:48 +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 1AA09EB913; Wed, 30 May 2018 21:02:46 +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 wWLzCqzxLEly; Wed, 30 May 2018 21:02:44 +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 C4381EB912; Wed, 30 May 2018 21:02:44 +0200 (CEST) Date: Wed, 30 May 2018 21:02:44 +0200 Message-ID: <878t81ge5n.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: babel@ietf.org, Weronika =?ISO-8859-2?Q?Ko=B3odziejak?= , Clara =?ISO-8859-1?Q?D=F4?= In-Reply-To: <8736y9c8lo.fsf@toke.dk> References: <87sh6915ix.wl-jch@irif.fr> <8736y9c8lo.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]); Wed, 30 May 2018 21:02:46 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 30 May 2018 21:02:48 +0200 (CEST) X-Miltered: at korolev with ID 5B0EF556.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B0EF558.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B0EF556.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B0EF558.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 : 5B0EF556.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B0EF558.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] Rethinking HMAC authentication 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: Wed, 30 May 2018 19:03:09 -0000 >> 2. In addition to the pseudo-header, we're hashing the packet header and >> the packet body. > What does packet header mean here? Babel header? UDP header? IP header? > I assume the former, right? Yes. The relevant data from the IP and UDP headers is in the pseudo-header (which is open to discussion). > What hashing algorithms are you implementing? For small routers, blake2s > might be good to have as MTI (http://blake2.net/). We're using SHA1 right now, but Denis's protocol is agile, so it's a minor detail at this stage. > I asked the crypto guy at my department what he would recommend in this > day and age, and he basically said "just do SHA256; and blake2s if you > want to be fast on small devices"... Noted. Denis? -- Juliusz From nobody Wed May 30 12:11: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 54FD912EACD for ; Wed, 30 May 2018 12:11: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 IXqP-bex_wKK for ; Wed, 30 May 2018 12:11: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 AFAA412E87B for ; Wed, 30 May 2018 12:11:07 -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 w4UJ6148013422; Wed, 30 May 2018 21:06:01 +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 684D0EB22E; Wed, 30 May 2018 21:06:01 +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 6EsNFBjDwopg; Wed, 30 May 2018 21:06:00 +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 554D9EB200; Wed, 30 May 2018 21:06:00 +0200 (CEST) Date: Wed, 30 May 2018 21:06:00 +0200 Message-ID: <877enlge07.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: David Schinazi , Weronika =?ISO-8859-2?Q?Ko=B3odz?= =?ISO-8859-2?Q?iejak?= , Clara =?ISO-8859-1?Q?D=F4?= , Babel at IETF In-Reply-To: <87zi0has5c.fsf@toke.dk> References: <87sh6915ix.wl-jch@irif.fr> <876035c8re.fsf@toke.dk> <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> <87zi0has5c.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]); Wed, 30 May 2018 21:06:01 +0200 (CEST) X-Miltered: at korolev with ID 5B0EF619.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B0EF619.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 : 5B0EF619.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] Rethinking HMAC authentication 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: Wed, 30 May 2018 19:11:17 -0000 >>> Presumably you could check the signature first, then just look for >>> possible replays while parsing the rest? >> The problem is that if there are TLVs before the TS/PC, you don't want >> to act on them until you've validated the TS/PC and MAC. Right. >> This could be solved by mandating that the TS/PC TLVs MUST come before >> any other TLVs, but adding ordering requirements to Babel TLVs makes me >> cringe. Me too. > Arguably, a malformed packet should be discarded without acting on any > TLVs anyway, HMAC or not... Hmm, I want to preserve the ability to interleave parsing and acting. That's not what your implementation does, Toke, but I want to preserve the other implementation choice. It looks like something needs to give. Let's keep implementing and thinking (interleaving the two, of course). -- Juliusz From nobody Wed May 30 13:35: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 0A81E12EABE for ; Wed, 30 May 2018 13:35:43 -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 p94g69C4sLDq for ; Wed, 30 May 2018 13:35:40 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9265E12E89A for ; Wed, 30 May 2018 13:35:40 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id e9-v6so9594800pfi.4 for ; Wed, 30 May 2018 13:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VtPC4qqsxQqF1V1awMnTMGc63ghy30JU+5K8Qj1iDfo=; b=eLJZGPY2XcYAb34Aw8aLub/FkXZqS8fK1X8H37gywl4i/b95aGPaIiSNPo1iweV1uk DcKvvr7BtuEIjjunHidEkdnPQfU+6fdmqu8jj9bzy83HcP9yllzEiPGLI9i1XFEDbQ73 eMnAEYKP6W6ghBQsUbASl1UDBxF510ej0EWRNstF6EAPhqnL+I7rPOqvxpXBVaXayK7n ugrTls6PrLX2eQhumD8uIXim2Qab107+l/Be8szHvmKx5rdSO+4+Q30UCeA4kN2Yg/JR 4xhVRwNXzUfjqIffaVpNWhfiBcS+WALMQOaIGwwkkK/hhG59h3sBMPDPQoqn9gWRAGHF aJaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VtPC4qqsxQqF1V1awMnTMGc63ghy30JU+5K8Qj1iDfo=; b=BTRwxFsnoiFDnx7OWY2hyLA2+YU5FgYM2ps/7w15SXPXjmvtJMaNozdDRO6rOveYKI Ego6GLcC4IoUZASodzeZa9hqtPBWTv0YINMgma9Wbc+F5QGKCOamsCWVpNydz0FACYlU ntdTWnPxIQUhfZe+LeSDVkRgR3i4uPz7+H41P+Tlph+FslrglukHeN/P2Eoz7NaTvB21 REVBePjoZ0iZmWso6sXJBJ3T3/GxGBdhKVlsjOTvFMqN29f/gy2xlfzTBB66AnGrzKmy LK59viyuGXI/CvCbH0QSqWcxp9FC7CdHHhHpPre+/ilap2aytv/ZYfD7ZRp9+Shmc1vk Ac/g== X-Gm-Message-State: ALKqPwfx/qEXcLkpScgcFPP0hDGo1xK090FNyiTQikJz/iE98LmKxsio 0B9Z6Y0Pq2+5c1ZHtaThy5rzIg== X-Google-Smtp-Source: ADUXVKIRoORxk+sZJ21gBDK9SeEnt6RoOe3G0sTqRIAdTxR821dd6bBVASAXdhwsMsD6HXaItK+kMA== X-Received: by 2002:a65:5883:: with SMTP id d3-v6mr3328720pgu.131.1527712539838; Wed, 30 May 2018 13:35:39 -0700 (PDT) Received: from cavall.scim-upper-hall-ap ([65.153.119.10]) by smtp.gmail.com with ESMTPSA id w14-v6sm11432409pfn.40.2018.05.30.13.35.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 May 2018 13:35:39 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3FEBAE38-9218-4E5C-BE24-5B5F50612DA0" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 30 May 2018 13:35:36 -0700 In-Reply-To: <877enlge07.wl-jch@irif.fr> Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , =?utf-8?B?Q2xhcmEgRMO0?= , =?utf-8?Q?Weronika_Ko=C5=82odziejak?= , David Schinazi , Babel at IETF To: Juliusz Chroboczek References: <87sh6915ix.wl-jch@irif.fr> <876035c8re.fsf@toke.dk> <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> <87zi0has5c.fsf@toke.dk> <877enlge07.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [babel] Rethinking HMAC authentication 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: Wed, 30 May 2018 20:35:43 -0000 --Apple-Mail=_3FEBAE38-9218-4E5C-BE24-5B5F50612DA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 30, 2018, at 12:06 PM, Juliusz Chroboczek wrote: > Hmm, I want to preserve the ability to interleave parsing and acting. > That's not what your implementation does, Toke, but I want to preserve = the > other implementation choice. This is a well-known way to create security problems: if you interleave = in this way, it's very easy to take some action based on an incomplete = parse that turns out to have been valid, but too late. TLS = implementations have been hacked this way multiple times (I say this = based on hearsay that I don't have time to go look up again, so I may be = pointing my finger at the wrong thing, but this is definitely a serious = problem). So on the one hand, I would argue that you just shouldn't do = this, and it's okay. But if you insist on doing this, then you have to = treat the signature specially. --Apple-Mail=_3FEBAE38-9218-4E5C-BE24-5B5F50612DA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = May 30, 2018, at 12:06 PM, Juliusz Chroboczek <jch@irif.fr> = wrote:
Hmm, I want = to preserve the ability to interleave parsing and acting.
That's not = what your implementation does, Toke, but I want to preserve = the
other = implementation choice.

This is a well-known way to create security problems: if you = interleave in this way, it's very easy to take some action based on an = incomplete parse that turns out to have been valid, but too late.   = TLS implementations have been hacked this way multiple times (I say this = based on hearsay that I don't have time to go look up again, so I may be = pointing my finger at the wrong thing, but this is definitely a serious = problem).  So on the one hand, I would argue that you just = shouldn't do this, and it's okay.   But if you insist on doing = this, then you have to treat the signature specially.

= --Apple-Mail=_3FEBAE38-9218-4E5C-BE24-5B5F50612DA0-- From nobody Wed May 30 14:01: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 2A93E12EABC; Wed, 30 May 2018 14:01:15 -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 dxZDWuOz40cV; Wed, 30 May 2018 14:01:13 -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 68A9712E855; Wed, 30 May 2018 14:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1527714066; 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=474; bh=nyZ3Bb8eAgAaZBv9F+86EFZfcMb5eJGfxniqutm/qUA=; b=ceCUe2jNwX/TYapLPNBfsK1YsvQAK673FTCfRyGn7YnewUuvxRHrkxhN1QGvyqaY 7HVBSUE4THTOHB/D+9eF4tKEPFYM5I/G6HzH4WDH3+5e0hwEzWoBYLfZwPxEI6Bj0Pi KDZyj8UEX7lhF9YIcd4SQJ2MLk6wn+nnmYVyC6Gk= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1527714066856404.24421722738975; Wed, 30 May 2018 14:01:06 -0700 (PDT) Date: Wed, 30 May 2018 22:01:06 +0100 From: Denis Ovsienko To: "Babel at IETF" , Message-ID: <163b2dab1a7.b9ca30aa119717.1733400857314939856@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] 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: Wed, 30 May 2018 21:01:16 -0000 ---- 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. -- Denis Ovsienko From nobody Wed May 30 14:06: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 5150912EB46 for ; Wed, 30 May 2018 14:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 hCvsv8oHpqno for ; Wed, 30 May 2018 14:06:25 -0700 (PDT) Received: from mail-in2.euro.apple.com (mail-in2.euro.apple.com [17.72.148.12]) (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 5D9AB12EB29 for ; Wed, 30 May 2018 14:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1527714383; x=2391627983; 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=xvo0vmbWaX8hS94rne8jS+vZ4EKPA5Wvy5F4x+zg878=; b=QxrIQI9HL/jOm5Pv4PZe4gqvTN8M5ZiEvpplAfeX7PxnOh0EwNM5OjymQ5/XC7W6 L4Y7SNG2fdZEUh9LDxNbe2VVHWkzixIQ0KJ/a8YI0x0TJSYud1fNWmHX6pD7vHbC XiVRgNsAmEvGcMnl2LRjj3GZzJTyxN2jUKtSSOjeq1OcdjLL+9Br+1MPtAcDXY9m 8SV78fVBxvs9soxiWMju80cJqfAB5mHi8DYAAuwCNusLBNEAfW9TOBJCUhdO18Tt r7BEVHlIJLYQZhN4YuHCyI2PdPVFQJipD6AA/48kxBU/VtiPfiFsiFWrQD4PPOHR w/BL86eR8EOlH09Nq6ivtA==; 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-in2.euro.apple.com (Apple Secure Mail Relay) with SMTP id B1.6A.28874.F421F0B5; Wed, 30 May 2018 22:06:23 +0100 (BST) X-AuditID: 1148940c-8adff700000070ca-2d-5b0f124f5401 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 5B.90.26930.F421F0B5; Wed, 30 May 2018 22:06:23 +0100 (BST) Received: from [17.192.155.180] by crk-mmpp-sz03.euro.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P9K00CS97YKRA30@crk-mmpp-sz03.euro.apple.com>; Wed, 30 May 2018 22:06:23 +0100 (IST) Sender: dschinazi@apple.com From: David Schinazi Message-id: <551BD811-DC02-4DF0-A508-610F66296BFB@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_2C4C8E05-9E2E-4FA8-8866-EAEF852FAC5B" MIME-version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 30 May 2018 14:06:19 -0700 In-reply-to: Cc: Juliusz Chroboczek , =?utf-8?Q?Weronika_Ko=C5=82odziejak?= , =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , =?utf-8?B?Q2xhcmEgRMO0?= , Babel at IETF To: Ted Lemon References: <87sh6915ix.wl-jch@irif.fr> <876035c8re.fsf@toke.dk> <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> <87zi0has5c.fsf@toke.dk> <877enlge07.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUi6GTOo+svxB9t8O20isWWRd0sFhsur2O2 mN+6jM3izZojTBZb369gt/jw6Q6rA5tH04Vl7B47Z91l91iy5CeTx+Itbxk9thy6yObxavpD 9gC2KC6blNSczLLUIn27BK6Mx43NbAWPHSo+TbzE0sA427yLkZNDQsBEouHkReYuRi4OIYEd TBLbH85ghEl8PjeRHcQWEljBJPHgljpEUQOTxN5XHWAJYQFpia4Ld1m7GDk42AS0JA6sMQIJ 8wrYSKy4/pEFxGYWSJJY9aGRGSJuInH72g+oVmOJuU/2MYHYLAKqEtv/HWEFsTkFbCU2vL0B dhCzQAuTxIS9C8AOEhFQkJh7Zg0TxBF9TBKL+1axQ1yqJDH9+202kISEwG02idZpDewTGIVm Idk+C8l2iLi2xLKFr4HiHEC2jsTkhYyowhD2x/NHmBYwsq1iFM9NzMzRzcwz0kstLcrXSywo yEnVS87P3cQIijOPKTw7GC8eNDzEKMDBqMTDu2ElX7QQa2JZcWXuIUYJDmYlEd7orUAh3pTE yqrUovz4otKc1OJDjNIcLErivC8COaKFBNITS1KzU1MLUotgskwcnFINjFvn7fm18czl2mfd WwRvdnrf75u3XlduxfPjgrwv7R7w1UjE+GZvusTWsPLyIUHpqCm2zlEen+SD+h1OaU+uKp3n 8mHj9d5A9quRKgtdhSMdNT/5G4a/989d1i967h3H2/s3LO7210QJM7ewV919pMj89l/R1QMC UwJmavVPST7VduX2by2FQiWW4oxEQy3mouJEAGPw/DKvAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUi6MSzVNdfiD/a4F+PvMWWRd0sFhsur2O2 mN+6jM3izZojTBZb369gt/jw6Q6rA5tH04Vl7B47Z91l91iy5CeTx+Itbxk9thy6yObxavpD 9gC2KC6blNSczLLUIn27BK6Mx43NbAWPHSo+TbzE0sA427yLkZNDQsBE4vO5iewgtpDACiaJ B7fUuxi5gOwGJom9rzrAEsIC0hJdF+6ydjFycLAJaEkcWGMEEuYVsJFYcf0jC4jNLJAksepD IzNE3ETi9rUfUK3GEnOf7GMCsVkEVCW2/zvCCmJzCthKbHh7gxlkF7NAC5PEhL0LGEESIgIK EnPPrGGCOKKPSWJx3yp2iEuVJKZ/v802gZF/FpKFs5AshIhrSyxb+BoozgFk60hMXsiIKgxh fzx/hGkBI9sqRtGi1JzESiO91NKifL3EgoKcVL3k/NxNjOC4MOfZwfjqoOEhRgEORiUe3slM /NFCrIllxZW5hxglOJiVRHijt/JFC/GmJFZWpRblxxeV5qQWH2KU5mBREuedrMQcLSSQnliS mp2aWpBaBJNl4uCUamAUed/9W3CGkspV1/ltLu4fwplbzqfpP8wsq/7uPdFJM+JhcjZ/z2yL sGjG6azd0ROeMbXMCWv69IZ3Y3iOxrtbt76sYmNq+pwkKtIWohrx+dv5yP9BO/SDHVeVp/+q Orz6ndHqN42NGXYTl0q7TvPY+PRX592GraGRM/Z+WfPepO6P8wS1lp1KLMUZiYZazEXFiQD9 NSdjhwIAAA== Archived-At: Subject: Re: [babel] Rethinking HMAC authentication 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: Wed, 30 May 2018 21:06:28 -0000 --Apple-Mail=_2C4C8E05-9E2E-4FA8-8866-EAEF852FAC5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ted, While I agree with your statement for some specific protocols, I'm not = sure I follow you in the case of Babel. Babel TLVs can be parsed and acted on as they come, because future TLVs = do not impact previous ones. That's how my implementation currently works, as that is simpler and = therefore more robust. If we want to add security to that, we want to establish the security of = a Babel datagram first, then parse-act. For example, when running babel over DTLS, the parser-actor will only = see the first TLV when the entire datagram has been decrypted and integrity-checked, so there's no risk of = needing to roll back anything. This becomes trickier when it comes to HMAC, because the TS/PC TLVs are = inside the datagram. Therefore, one option is to perform two passes, one that only parses = TS/PC+HMAC, and if that succeeds, a second pass that parse-acts. What we're investigating here is the = ability of simplifying this. What caused the TLS vulnerabilities you described was the complexity of = the state machine, and if I understand the spirit of Babel correctly we won't allow that here = because the working group hates complexity. David > On May 30, 2018, at 13:35, Ted Lemon wrote: >=20 > On May 30, 2018, at 12:06 PM, Juliusz Chroboczek > wrote: >> Hmm, I want to preserve the ability to interleave parsing and acting. >> That's not what your implementation does, Toke, but I want to = preserve the >> other implementation choice. >=20 > This is a well-known way to create security problems: if you = interleave in this way, it's very easy to take some action based on an = incomplete parse that turns out to have been valid, but too late. TLS = implementations have been hacked this way multiple times (I say this = based on hearsay that I don't have time to go look up again, so I may be = pointing my finger at the wrong thing, but this is definitely a serious = problem). So on the one hand, I would argue that you just shouldn't do = this, and it's okay. But if you insist on doing this, then you have to = treat the signature specially. >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --Apple-Mail=_2C4C8E05-9E2E-4FA8-8866-EAEF852FAC5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Ted,

While I agree = with your statement for some specific protocols, I'm not sure I follow = you in the case of Babel.
Babel TLVs can be parsed = and acted on as they come, because future TLVs do not impact previous = ones.
That's how my implementation currently works, = as that is simpler and therefore more robust.
If we = want to add security to that, we want to establish the security of a = Babel datagram first, then parse-act.
For example, = when running babel over DTLS, the parser-actor will only see the first = TLV when the entire
datagram has been decrypted and = integrity-checked, so there's no risk of needing to roll back = anything.
This becomes trickier when it comes to = HMAC, because the TS/PC TLVs are inside the datagram.
Therefore, one option is to perform two passes, one that only = parses TS/PC+HMAC, and if that succeeds,
a second = pass that parse-acts. What we're investigating here is the ability of = simplifying this.
What caused the TLS = vulnerabilities you described was the complexity of the state machine, = and if I
understand the spirit of Babel correctly = we won't allow that here because the working group hates = complexity.

David


On May = 30, 2018, at 13:35, Ted Lemon <mellon@fugue.com> wrote:

On May 30, 2018, at = 12:06 PM, Juliusz Chroboczek <jch@irif.fr> wrote:
Hmm, I want to preserve the ability to interleave parsing and = acting.
That's not = what your implementation does, Toke, but I want to preserve = the
other = implementation choice.

This is a well-known way to create security problems: if you = interleave in this way, it's very easy to take some action based on an = incomplete parse that turns out to have been valid, but too late.   = TLS implementations have been hacked this way multiple times (I say this = based on hearsay that I don't have time to go look up again, so I may be = pointing my finger at the wrong thing, but this is definitely a serious = problem).  So on the one hand, I would argue that you just = shouldn't do this, and it's okay.   But if you insist on doing = this, then you have to treat the signature specially.

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

= --Apple-Mail=_2C4C8E05-9E2E-4FA8-8866-EAEF852FAC5B-- From nobody Wed May 30 14:24: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 2F6FF12D876 for ; Wed, 30 May 2018 14:24:20 -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 rS5TxUEecsTa for ; Wed, 30 May 2018 14:24:18 -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 A730712D7E2 for ; Wed, 30 May 2018 14:24: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=1527715456; bh=rH/qV7FxvYT3ypySl/t3246CyxLZACUWGtD8/FMTQGQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=yLuDqb4flczbsnnGnk2AbM+qSG5xDnCP30jDtOmL3e/UHY9TYLcGEpN21ZEBrdsoK TguBCJruQNwyulJLWcqJn4taksh5j+8gpPSKRzqKRYptI2A89ZD2tMggy9zQ0RHfuh 7TZwRKqhd1Zt5FLFz0R8Ti3rFhEOf4P3HuKLc7IoYqcaaVHt4U1ZAd7O9kHT5890yJ bpetR0OODF23yfiUtNUroHwfFC09y6LlvAKd6hMYnysSmcg7yB6C0AqXDbGPzfo7c0 ahE+q/OzgXEr+Hv5dGs4eH+RcRAWlvQhjBEb7HElVX9ICNkOcfopWz/DwEmGi/gXuf XtttrWnWq6Jew== To: David Schinazi , Ted Lemon Cc: Juliusz Chroboczek , Weronika =?utf-8?Q?Ko=C5=82odziejak?= , Clara =?utf-8?Q?D=C3=B4?= , Babel at IETF In-Reply-To: <551BD811-DC02-4DF0-A508-610F66296BFB@apple.com> References: <87sh6915ix.wl-jch@irif.fr> <876035c8re.fsf@toke.dk> <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> <87zi0has5c.fsf@toke.dk> <877enlge07.wl-jch@irif.fr> <551BD811-DC02-4DF0-A508-610F66296BFB@apple.com> Date: Wed, 30 May 2018 23:24:20 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <8736y8bzwb.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Rethinking HMAC authentication 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: Wed, 30 May 2018 21:24:20 -0000 David Schinazi writes: > Hi Ted, > > While I agree with your statement for some specific protocols, I'm not > sure I follow you in the case of Babel. Uh, I'm going to put that up on my 'famous last words' quote wall ;) > Babel TLVs can be parsed and acted on as they come, because future > TLVs do not impact previous ones. That's how my implementation > currently works, as that is simpler and therefore more robust. Except we're discussing a case where it breaks down because it is not, well, robust enough ;) Snide comments aside, I'm completely fine with finding a way to preserve this property, BTW, as long as that doesn't just move complexity from the parser to the protocol spec. -Toke From nobody Wed May 30 14:26: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 E858512EB4C for ; Wed, 30 May 2018 14:26:51 -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 X9OO1bTCBYi9 for ; Wed, 30 May 2018 14:26:50 -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 6A9F012EB8F for ; Wed, 30 May 2018 14:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1527715609; x=2391629209; 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=MxBipAl680Ez/3EywCwNsl19NBe5jxYbr+WFm98SIGs=; b=AaxEAGP//84c8cpyrRyAHqU+7akjEo1oLLH3REm5Q3LFFB+2WeH1aQqpFDxq3ytU sz27G85Krz8kWG8vQ9ufSm4X9x9NF3OLLxSbMx2ioYLW/6n9SO5WzPyvsc5AaXqC 3xrmg6XoHcdXUh2QH+TPB+LxpqfzfeThHaF6QG2sLDFQAk+Ba4Spr29vMO31sPEf JKXsCyI3YW16Ni4os/ykMk+mKmxM/dpcwrmp/QW30C9U1zWVAHSrXHZxysNLqye6 24kE+OqXU8Pxxe0F2WTI5kqOMlLRVOC+WJXRx94muHpujq+iriJfc1D5UvMcUoJk S0so0zCV9sDKdvnjQifwSA==; X-AuditID: 11ab0217-d27ff70000003e90-28-5b0f1719b094 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 26.70.16016.9171F0B5; Wed, 30 May 2018 14:26:49 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from ma1-mmpp-sz09.apple.com (ma1-mmpp-sz09.apple.com [17.171.128.183]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0P9K000OW8WPHM50@ma1-mtap-s02.corp.apple.com>; Wed, 30 May 2018 14:26:49 -0700 (PDT) Received: from [17.192.155.180] by ma1-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P9K008WX8WOCK40@ma1-mmpp-sz09.apple.com>; Wed, 30 May 2018 14:26:49 -0700 (PDT) X-Va-A: X-Va-T-CD: c5a7321f76d9a4ca2e93bf28536377c1 X-Va-E-CD: 364ba9793b3bbfb9221b229b541cb094 X-Va-R-CD: 27f632e87b0ecd4c43e83a63c73bf407 X-Va-CD: 0 X-Va-ID: 3ad85be8-7782-4381-9780-9599e64927fe X-V-A: X-V-T-CD: 319a1c775657bc6582695a36a4aadeb6 X-V-E-CD: 364ba9793b3bbfb9221b229b541cb094 X-V-R-CD: 27f632e87b0ecd4c43e83a63c73bf407 X-V-CD: 0 X-V-ID: 32a3b174-b1f3-4c7c-b536-f631536314a0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-30_09:,, signatures=0 Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <8736y8bzwb.fsf@toke.dk> Date: Wed, 30 May 2018 14:26:47 -0700 Cc: Ted Lemon , Juliusz Chroboczek , =?utf-8?Q?Weronika_Ko=C5=82odziejak?= , =?utf-8?B?Q2xhcmEgRMO0?= , Babel at IETF Content-transfer-encoding: quoted-printable Message-id: References: <87sh6915ix.wl-jch@irif.fr> <876035c8re.fsf@toke.dk> <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> <87zi0has5c.fsf@toke.dk> <877enlge07.wl-jch@irif.fr> <551BD811-DC02-4DF0-A508-610F66296BFB@apple.com> <8736y8bzwb.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+NgFnrCIsWRmVeSWpSXmKPExsUiqOHDpispzh9tsG2uisWWRd0sFhsur2O2 mN+6jM3izZojTBZb369gt/jw6Q6rA5tH04Vl7B47Z91l91iy5CeTx+Itbxk9thy6yObxavpD 9gC2KC6blNSczLLUIn27BK6MjZvXsxWs4qjY1inUwHiErYuRk0NCwETiQsM+xi5GLg4hgf1M Et2fb7ODJHgFBCV+TL7H0sXIwcEsoC4xZUouRM1GJokJhx6wQTjfGCWev77ADDGJXeLPrx0s ELa2xOPVr9hg7ItPljHD2JOf/WCEsLkkFmw9zQqyQEJAV2Lx/QKIMJvE+hNLmCDCWhILbxtC hLUkFjT1MsLYy26fhtrEKXH+y0R2CFtHov3fBait2RIfnuwBqxEWkJbounCXFcI2lpj7ZB/Y eDagOQfWGIGYnAKqEq9mlIFUsACZ/1/+ZgZ5kFngMaPE3eNXwVqZgY5/8u4CKyR0bCS+tE6C hsItJoknxw6BJUQE7CUav16Auk1JYvr322wTGOVmIYXoLESIzkIydgEj8ypG4dzEzBzdzDwj Y73EgoKcVL3k/NxNjKBksZpJfAfj59eGhxgFOBiVeHg3rOSLFmJNLCuuzD3EKM3BoiTOuzCI I1pIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo13NtscPLv+zPmc+eQXDabUrvH84b+yV3LNX aNdClwNPTu8M1c24JjHXbocm09xZIo2lLi0L+n+u6V6i+bPJ/qdmfMH2PxxKCXlXfdafE7j3 OdtpNv/2yQ+OvHZif61695jordaj+4JZZhpdmrh+1VQm6YDY2eev2VRPZOus0Y0IPSZYonrU +7USS3FGoqEWc1FxIgBeFMAB9wIAAA== Archived-At: Subject: Re: [babel] Rethinking HMAC authentication 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: Wed, 30 May 2018 21:26:52 -0000 Hi Toke, I absolutely agree, so far a two-pass parse system is safe and = relatively simple. Any other proposal would need to be as safe and simpler :) David > On May 30, 2018, at 14:24, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > David Schinazi writes: >=20 >> Hi Ted, >>=20 >> While I agree with your statement for some specific protocols, I'm = not >> sure I follow you in the case of Babel. >=20 > Uh, I'm going to put that up on my 'famous last words' quote wall ;) >=20 >> Babel TLVs can be parsed and acted on as they come, because future >> TLVs do not impact previous ones. That's how my implementation >> currently works, as that is simpler and therefore more robust. >=20 > Except we're discussing a case where it breaks down because it is not, > well, robust enough ;) >=20 > Snide comments aside, I'm completely fine with finding a way to = preserve > this property, BTW, as long as that doesn't just move complexity from > the parser to the protocol spec. >=20 > -Toke From nobody Thu May 31 01:08: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 BB5A7126CD6 for ; Thu, 31 May 2018 01:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 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, URIBL_BLOCKED=0.001, 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 VNVdj0078FqE for ; Thu, 31 May 2018 01:08:43 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1FBB1205F0 for ; Thu, 31 May 2018 01:08:43 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id z1-v6so2436232pgv.12 for ; Thu, 31 May 2018 01:08:43 -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=JGFAn1bzRwQUUF3TrNjsnF7+h97Ltee1138brr+ECTk=; b=cH7BgX699sEyHUB6kmv9rptATg129sL36Ob3+EkQo5J246bbVkVomNqSnapm0BtOxa 6cRs+/XezcZU7GLPPAu8K9JRuzImkse1MzcX2nabaOsWUodRu6cSjJ628Td3Ec1VxwYI D1F6kEhwASSEsb9mMhivnV//N3RRubLKQCHEeMz44bQOszxa1J8h/ccqzOu2QB8Uoe6G v1y0MRKufzio/RLAKqIozJJOq1QAeYfHjfpYhWroDs+Jua+ZGGcEwKdaw/320NfDsf4q GN7bBUvyJycx6cg5VVPDCs4dsgvXqSmRfoyYSpSi6Swsr+S1OhfF9pUc0oOdOtkl2EFz x4Ow== 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=JGFAn1bzRwQUUF3TrNjsnF7+h97Ltee1138brr+ECTk=; b=Af09JyAapy+JGNupFX10gwCfaDCUWv719plgLkqUlqfL7VdWtVbAQi1Eym3IVVpbv6 HX+YRv1YDO6L3Cn8BqWciwPf3hMhQUjyT9nEllApscHtRGmDP1nNwZxydGFDB6RFMApi SLt8hCFHSQSZbzm/s1jlBl9DfWFteuNmU/swIJviwLdIDvun1aw2tsZKES5/TKW+5zIX +ghZKLdB8VOtD+qdsZcDqJOK/fclT55cuqlB5RrHlzynzkc1ty9QuKX/JME5qNTCsl31 9KV1ac5kwYA78EYFDrjJoCi60q23DxeqdJkwZ2gDGfLegAZ3MdcpzPkxVla8ahMU04Ki ymnQ== X-Gm-Message-State: ALKqPwfpZv1nz4vGf+ghv4u3GMMnUOtCDVT13EEuOuyVvX8cX+q1RWu0 c1a9dvgjEM0WO9tBrLNkP0Qr6XCOrpcp5P81EeP2pA== X-Google-Smtp-Source: ADUXVKLAPDBpMND48wnXiFaw/jygHCpKreP8v1AAL7E9xvRlomnN4qcqWpAkURpR1mZWQgdlC127M0f2LYinaIqNY4c= X-Received: by 2002:a62:c00e:: with SMTP id x14-v6mr5878290pff.67.1527754122881; Thu, 31 May 2018 01:08:42 -0700 (PDT) MIME-Version: 1.0 References: <87sh6915ix.wl-jch@irif.fr> <876035c8re.fsf@toke.dk> <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> <87zi0has5c.fsf@toke.dk> <877enlge07.wl-jch@irif.fr> In-Reply-To: From: Gabriel Kerneis Date: Thu, 31 May 2018 10:08:06 +0200 Message-ID: To: Ted Lemon Cc: Juliusz Chroboczek , weronika.kolodziejak@gmail.com, =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , clarado_perso@yahoo.fr, David Schinazi , Babel at IETF Content-Type: multipart/alternative; boundary="000000000000cd058e056d7bf9e9" Archived-At: Subject: Re: [babel] Rethinking HMAC authentication 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: Thu, 31 May 2018 08:08:46 -0000 --000000000000cd058e056d7bf9e9 Content-Type: text/plain; charset="UTF-8" On Wed, May 30, 2018 at 10:35 PM Ted Lemon wrote: > On May 30, 2018, at 12:06 PM, Juliusz Chroboczek wrote: > > Hmm, I want to preserve the ability to interleave parsing and acting. > That's not what your implementation does, Toke, but I want to preserve the > other implementation choice. > > > This is a well-known way to create security problems: if you interleave in > this way, it's very easy to take some action based on an incomplete parse > that turns out to have been valid, but too late. TLS implementations have > been hacked this way multiple times (I say this based on hearsay that I > don't have time to go look up again, so I may be pointing my finger at the > wrong thing, but this is definitely a serious problem). So on the one > hand, I would argue that you just shouldn't do this, and it's okay. But > if you insist on doing this, then you have to treat the signature specially. > On a related note, I've looked into fuzzing the packet parsing logic of babeld recently, and gave up because this interleaving made it too hard. (Arguably, you could interleave and fuzz with some incremental parsing and callback, or another kind of inversion of control, but that's not what the current code does.) Gabriel --000000000000cd058e056d7bf9e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, May 30= , 2018 at 10:35 PM Ted Lemon <mellon= @fugue.com> wrote:
On May 30, 2018, a= t 12:06 PM, Juliusz Chroboczek <jch@irif.fr> wrote:
Hmm, I want to pr= eserve the ability to interleave parsing and acting.
That&= #39;s not what your implementation does, Toke, but I want to preserve the
other implementation choice.

This is a well-known way to create security problems: if you inte= rleave in this way, it's very easy to take some action based on an inco= mplete parse that turns out to have been valid, but too late. =C2=A0 TLS im= plementations have been hacked this way multiple times (I say this based on= hearsay that I don't have time to go look up again, so I may be pointi= ng my finger at the wrong thing, but this is definitely a serious problem).= =C2=A0 So on the one hand, I would argue that you just shouldn't do thi= s, and it's okay. =C2=A0 But if you insist on doing this, then you have= to treat the signature specially.

<= div>On a related note, I've looked into fuzzing the packet parsing logi= c of babeld recently, and gave up because this interleaving made it too har= d. (Arguably, you could interleave and fuzz with some incremental parsing a= nd callback, or another kind of inversion of control, but that's not wh= at the current code does.)

Gabriel
--000000000000cd058e056d7bf9e9-- From nobody Thu May 31 03: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 53ED112EB8F for ; Thu, 31 May 2018 03:50:56 -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 KMXufqzUPIks for ; Thu, 31 May 2018 03: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 C6EEE12EA52 for ; Thu, 31 May 2018 03:50: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 w4VAhAuG027524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 31 May 2018 12:43:10 +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 w4VAh8G3020844; Thu, 31 May 2018 12:43: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 0BCBBEB279; Thu, 31 May 2018 12:43: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 DSRFe0bIXwzN; Thu, 31 May 2018 12:43: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 7EEABEB200; Thu, 31 May 2018 12:43:03 +0200 (CEST) Date: Thu, 31 May 2018 12:43:03 +0200 Message-ID: <87a7sgw1fs.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: David Schinazi , Ted Lemon , Weronika =?ISO-8859-2?Q?Ko=B3odziejak?= , Clara =?ISO-8859-1?Q?D=F4?= , Babel at IETF In-Reply-To: <8736y8bzwb.fsf@toke.dk> References: <87sh6915ix.wl-jch@irif.fr> <876035c8re.fsf@toke.dk> <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> <87zi0has5c.fsf@toke.dk> <877enlge07.wl-jch@irif.fr> <551BD811-DC02-4DF0-A508-610F66296BFB@apple.com> <8736y8bzwb.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]); Thu, 31 May 2018 12:43:10 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 31 May 2018 12:43:11 +0200 (CEST) X-Miltered: at korolev with ID 5B0FD1BE.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B0FD1BC.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B0FD1BE.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B0FD1BC.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 : 5B0FD1BE.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B0FD1BC.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] Rethinking HMAC authentication 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: Thu, 31 May 2018 10:50:57 -0000 > Snide comments aside, I'm completely fine with finding a way to preserve > this property, BTW, as long as that doesn't just move complexity from > the parser to the protocol spec. Uh-huh. So with the HMAC in the trailer but TS/PC and TS/PC echo in the body, the parsing looks as following: 1. jump to the trailer, check HMAC; reject packet early if no matching HMAC. 2. walk packet a first time to check for increasing TS/PC and refresh freshness information; reject at this point if not fresh enough. 3. walk packet a second time and act on the rest of the information. That sounds reasonable enough to me. The obvious alternative is to move both TS/PC and TS/PC echo to the packet trailer (the latter would therefore no longer be a sub-TLV of IHU). I'm not sure what are the security consequences of no longer covering TS/PC by the HMAC. We'll keep hacking. -- Juliusz From nobody Thu May 31 04:12: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 5DFC012D86B for ; Thu, 31 May 2018 04:12:49 -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 Cz2MbjnhJmqG for ; Thu, 31 May 2018 04:12:47 -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 6F33012E6D7 for ; Thu, 31 May 2018 04:12:47 -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=1527765165; bh=Muazs028obf8WV78VLqDynZdqL59XwymJ2fVx+SPcys=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=CtIToBJWf31AqqoIO76z4M7hMqnXSbp7fUzhityh+FREKIIoayvMM09myl97DomVo B3aQltEe4UJJEYiyQZIEazcx6Tu+6u6yoNeZqiwUYGEUWedehXAkxZcw4D+JEd4D1O C7AzH6PntLFTxOpopAx6ofm19N47GIXCxT2D52WSGb1V+wmZ9wM/B28XmaFf0bIw4S LtOTc0/i3hPruuuDfEG92RdvEDKYek8a6O2fNSSnEqZ5eRUjbUZxTa7Q149mx4vtO/ PkP15ppFeAN4FLZnmK2ckGjiLnkunqRiS+CJq0/VilSs0pi8uX4wPThpUGjRQVzImD SDHJPE7JvXSLQ== To: Juliusz Chroboczek Cc: David Schinazi , Ted Lemon , Weronika =?utf-8?Q?Ko=C5=82odziejak?= , Clara =?utf-8?Q?D=C3=B4?= , Babel at IETF In-Reply-To: <87a7sgw1fs.wl-jch@irif.fr> References: <87sh6915ix.wl-jch@irif.fr> <876035c8re.fsf@toke.dk> <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> <87zi0has5c.fsf@toke.dk> <877enlge07.wl-jch@irif.fr> <551BD811-DC02-4DF0-A508-610F66296BFB@apple.com> <8736y8bzwb.fsf@toke.dk> <87a7sgw1fs.wl-jch@irif.fr> Date: Thu, 31 May 2018 13:12:44 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87y3g0axjn.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Rethinking HMAC authentication 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: Thu, 31 May 2018 11:12:50 -0000 Juliusz Chroboczek writes: >> Snide comments aside, I'm completely fine with finding a way to preserve >> this property, BTW, as long as that doesn't just move complexity from >> the parser to the protocol spec. > > Uh-huh. > > So with the HMAC in the trailer but TS/PC and TS/PC echo in the body, the > parsing looks as following: > > 1. jump to the trailer, check HMAC; reject packet early if no > matching HMAC. > 2. walk packet a first time to check for increasing TS/PC and refresh > freshness information; reject at this point if not fresh enough. > 3. walk packet a second time and act on the rest of the information. Yeah, so this is basically a two-step parsing, except in the first step you pretend you don't understand any of the normal TLVs... > That sounds reasonable enough to me. The obvious alternative is to > move both TS/PC and TS/PC echo to the packet trailer (the latter would > therefore no longer be a sub-TLV of IHU). I'm not sure what are the > security consequences of no longer covering TS/PC by the HMAC. Erm, that they are trivially forgeable? You just take any valid HMACed packet, stick a new TS/PC in it, and presto, you now have a valid packet to replay? -Toke From nobody Thu May 31 11:53: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 A80E512F26D for ; Thu, 31 May 2018 11:53: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 2e4ezBSpuFJd for ; Thu, 31 May 2018 11:53: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 1832C126B6D for ; Thu, 31 May 2018 11:53:03 -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 w4VIqxX0016350; Thu, 31 May 2018 20:52:59 +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 91BDCEB22D; Thu, 31 May 2018 20:52:59 +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 52YnHaAyExBO; Thu, 31 May 2018 20:52:58 +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 467D1EB200; Thu, 31 May 2018 20:52:58 +0200 (CEST) Date: Thu, 31 May 2018 20:52:58 +0200 Message-ID: <878t7z1wtx.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: David Schinazi , Weronika =?ISO-8859-2?Q?Ko=B3odz?= =?ISO-8859-2?Q?iejak?= , Clara =?ISO-8859-1?Q?D=F4?= , Babel at IETF In-Reply-To: <87y3g0axjn.fsf@toke.dk> References: <87sh6915ix.wl-jch@irif.fr> <876035c8re.fsf@toke.dk> <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> <87zi0has5c.fsf@toke.dk> <877enlge07.wl-jch@irif.fr> <551BD811-DC02-4DF0-A508-610F66296BFB@apple.com> <8736y8bzwb.fsf@toke.dk> <87a7sgw1fs.wl-jch@irif.fr> <87y3g0axjn.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, 31 May 2018 20:52:59 +0200 (CEST) X-Miltered: at korolev with ID 5B10448B.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B10448B.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 : 5B10448B.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] Rethinking HMAC authentication 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: Thu, 31 May 2018 18:53:07 -0000 >> That sounds reasonable enough to me. The obvious alternative is to >> move both TS/PC and TS/PC echo to the packet trailer (the latter would >> therefore no longer be a sub-TLV of IHU). I'm not sure what are the >> security consequences of no longer covering TS/PC by the HMAC. > Erm, that they are trivially forgeable? You just take any valid HMACed > packet, stick a new TS/PC in it, and presto, you now have a valid packet > to replay? Of course. So now that I have a more realistic assessment of my level of competence (fairly low), let's do some more exploring of the design space. The use of the trailer gives a clear separation between what is being hashed and what is not: pseudo-header: hashed packet body: hashed trailer: not hashed The advantage is that it's trivial to verify the hash; however, it does not remove the need to either do two passes of parsing (my implementation) or build a parse tree (Toke's implementation). Either implementation technique is valid, and if implemented carefully, they should be roughly equally secure. What are the disadvantages? One is that now we need to distinguish between packet body and trailer, and be careful to ignore any TLVs that are in the trailer except those that are explicitly allowed there; this doesn't seem like much of a burden. The other is that we now create a difference between DTLS and HMAC, since they don't protect exactly the same data (DTLS protects the whole packet, while HMAC protects the packet body only). I don't see that as a significant flaw, perhaps David or Denis can comment. -- Juliusz From nobody Thu May 31 12:02: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 31DD612F4C0 for ; Thu, 31 May 2018 12:02: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 NlLvevGI8f2h for ; Thu, 31 May 2018 12:02:12 -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 DBC1C130F27 for ; Thu, 31 May 2018 12:02:11 -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=1527793330; bh=O9cebU/x5fh5/fDpYskV1InnNnaE/o0vCQNVO/jJSyU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Dg4jlCBzSXt1P8hpbgZBouxap1Kl4S+aDgaWEOF3F9AvTICzwbI98wjkjMUmAdu6q ElTRdrgCFFNLSxrGZnyCJFEOinhSU5DBbdaw63X83O0wy/XN0taAaxF00nCSxmVyxL YlLknJBenya8mKMz7hEMeFCDoBnS8adtra/KcnPu9d7AOJdQ0ZjWtejW88RZQ4O1rl YhygjCtQVMBTc5X+izfsVYpitUke0IT3RKdc6h84sbaeVq/Rm4N6GkPFXvdgDGhI2J vp12p0vQlpxvpw+Q9OQyuwhWS16lI/wG6bAI+HahTcJAHWKTRLTsGp+ZlN2VFYNuok c2bJoJ4RRNlwA== To: Juliusz Chroboczek Cc: David Schinazi , Weronika =?utf-8?Q?Ko=C5=82odzie?= =?utf-8?Q?jak?= , Clara =?utf-8?Q?D=C3=B4?= , Babel at IETF In-Reply-To: <878t7z1wtx.wl-jch@irif.fr> References: <87sh6915ix.wl-jch@irif.fr> <876035c8re.fsf@toke.dk> <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> <87zi0has5c.fsf@toke.dk> <877enlge07.wl-jch@irif.fr> <551BD811-DC02-4DF0-A508-610F66296BFB@apple.com> <8736y8bzwb.fsf@toke.dk> <87a7sgw1fs.wl-jch@irif.fr> <87y3g0axjn.fsf@toke.dk> <878t7z1wtx.wl-jch@irif.fr> Date: Thu, 31 May 2018 21:02:15 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87efhrvebs.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Rethinking HMAC authentication 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: Thu, 31 May 2018 19:02:23 -0000 Juliusz Chroboczek writes: >>> That sounds reasonable enough to me. The obvious alternative is to >>> move both TS/PC and TS/PC echo to the packet trailer (the latter would >>> therefore no longer be a sub-TLV of IHU). I'm not sure what are the >>> security consequences of no longer covering TS/PC by the HMAC. > >> Erm, that they are trivially forgeable? You just take any valid HMACed >> packet, stick a new TS/PC in it, and presto, you now have a valid packet >> to replay? > > Of course. > > So now that I have a more realistic assessment of my level of competence > (fairly low), let's do some more exploring of the design space. The use > of the trailer gives a clear separation between what is being hashed and > what is not: > > pseudo-header: hashed > packet body: hashed > trailer: not hashed > > The advantage is that it's trivial to verify the hash; however, it does > not remove the need to either do two passes of parsing (my implementation) > or build a parse tree (Toke's implementation). Either implementation > technique is valid, and if implemented carefully, they should be roughly > equally secure. > > What are the disadvantages? One is that now we need to distinguish > between packet body and trailer, and be careful to ignore any TLVs that > are in the trailer except those that are explicitly allowed there; this > doesn't seem like much of a burden. The other is that we now create > a difference between DTLS and HMAC, since they don't protect exactly the > same data (DTLS protects the whole packet, while HMAC protects the packet > body only). I don't see that as a significant flaw, perhaps David or > Denis can comment. I generally agree with the above. One think you haven't mentioned is that sticking things in the packet trailer actually requires a specification of how the data in there is going to be interpreted, which the spec doesn't currently say. Just having it use the same TLV format is obvious, of course; but it should be specified I guess? Also, do we risk someone building a stupid parser that doesn't look at the length in the Babel header and just keeps parsing into the trailer without noticing? If so, then maybe wrapping the whole trailer in a single TLV and making everything else subtlvs of that might be a good idea? -Toke From nobody Thu May 31 14:01: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 A4E29131E9D for ; Thu, 31 May 2018 14:01: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 FwrfzAU8hJGS for ; Thu, 31 May 2018 14:01:48 -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 E4A8C12D87B for ; Thu, 31 May 2018 14:01:47 -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 w4VKwY2w002886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 31 May 2018 22:58:34 +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 w4VKwZwl006320; Thu, 31 May 2018 22:58:35 +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 429C1EB200; Thu, 31 May 2018 22:58:33 +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 0KOiAdZiig0l; Thu, 31 May 2018 22:58:32 +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 382E8EB279; Thu, 31 May 2018 22:58:32 +0200 (CEST) Date: Thu, 31 May 2018 22:58:32 +0200 Message-ID: <87y3fzzgnb.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: David Schinazi , Weronika =?ISO-8859-2?Q?Ko=B3odz?= =?ISO-8859-2?Q?iejak?= , Clara =?ISO-8859-1?Q?D=F4?= , Babel at IETF In-Reply-To: <87efhrvebs.fsf@toke.dk> References: <87sh6915ix.wl-jch@irif.fr> <876035c8re.fsf@toke.dk> <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> <87zi0has5c.fsf@toke.dk> <877enlge07.wl-jch@irif.fr> <551BD811-DC02-4DF0-A508-610F66296BFB@apple.com> <8736y8bzwb.fsf@toke.dk> <87a7sgw1fs.wl-jch@irif.fr> <87y3g0axjn.fsf@toke.dk> <878t7z1wtx.wl-jch@irif.fr> <87efhrvebs.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]); Thu, 31 May 2018 22:58:34 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 31 May 2018 22:58:36 +0200 (CEST) X-Miltered: at korolev with ID 5B1061FA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B1061FB.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B1061FA.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B1061FB.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 : 5B1061FA.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B1061FB.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] Rethinking HMAC authentication 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: Thu, 31 May 2018 21:01:50 -0000 > Also, do we risk someone building a stupid parser that doesn't look at > the length in the Babel header and just keeps parsing into the trailer > without noticing? If so, then maybe wrapping the whole trailer in a > single TLV and making everything else subtlvs of that might be a good > idea? Isn't it enough to have the trailer TLV space disjoint from the body TLV space? From nobody Thu May 31 14:09: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 AC454131D50 for ; Thu, 31 May 2018 14:09:47 -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 1YtY-icPPLsv for ; Thu, 31 May 2018 14:09: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 D5359132850 for ; Thu, 31 May 2018 14:09: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=1527800981; bh=+Mt3eH1EmUZiWBMW7N2d8bl6AJ6dQ62OunvsYAadOVE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=u/2xF6DFY5OSXusUCzCnzF5NCT8xuUd3bNHj2jbn8SI/WI6duhL8KTG/YV18vekeA qqcSQ0k7VxaUiLB3IpP4GKp35jC0j+SfbX8XjUWWiPK0L6n3HgltDRAe4uHp+BJ5iK E0/yw4H5P25kam6Ce9fygEILinpW6At7mTgGCQMmrOuMhYMI4qzOY22xpwg1jHnn0n zjMhVhKtqQog7o+MkzrKFRQGdPFJigPYTn9J5CpwWrQUOrR9N4yhbZHYYre8FTjzsQ gSdoehCj1L+HCM5PQkRw0Yh+7MJZTYq5w1g7KyDWKQ5AUY7Igng0Wyx9kPnnagzfEf Z8R9foyk5Jg9Q== To: Juliusz Chroboczek Cc: David Schinazi , Weronika =?utf-8?Q?Ko=C5=82odzie?= =?utf-8?Q?jak?= , Clara =?utf-8?Q?D=C3=B4?= , Babel at IETF In-Reply-To: <87y3fzzgnb.wl-jch@irif.fr> References: <87sh6915ix.wl-jch@irif.fr> <876035c8re.fsf@toke.dk> <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> <87zi0has5c.fsf@toke.dk> <877enlge07.wl-jch@irif.fr> <551BD811-DC02-4DF0-A508-610F66296BFB@apple.com> <8736y8bzwb.fsf@toke.dk> <87a7sgw1fs.wl-jch@irif.fr> <87y3g0axjn.fsf@toke.dk> <878t7z1wtx.wl-jch@irif.fr> <87efhrvebs.fsf@toke.dk> <87y3fzzgnb.wl-jch@irif.fr> Date: Thu, 31 May 2018 23:09:45 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87fu27mt0m.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Rethinking HMAC authentication 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: Thu, 31 May 2018 21:09:48 -0000 Juliusz Chroboczek writes: >> Also, do we risk someone building a stupid parser that doesn't look at >> the length in the Babel header and just keeps parsing into the trailer >> without noticing? If so, then maybe wrapping the whole trailer in a >> single TLV and making everything else subtlvs of that might be a good >> idea? > > Isn't it enough to have the trailer TLV space disjoint from the body TLV > space? Hmm, guess so. Or use the same space (assign the HMAC TLV from the existing registry), and add a flag specifying which ones are allowed to be in the trailer? Or I guess that was what you were already planning to do? -Toke From nobody Thu May 31 15:10: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 D503B12EBD2 for ; Thu, 31 May 2018 15:10:41 -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 0PwihVcirY4u for ; Thu, 31 May 2018 15:10: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 438A512D0C3 for ; Thu, 31 May 2018 15:10:39 -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 w4VMAXlZ022486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 Jun 2018 00: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 w4VMAYR2021441; Fri, 1 Jun 2018 00:10:34 +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 0B0DFEB22D; Fri, 1 Jun 2018 00:10:33 +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 CHjWNZ2h0eqH; Fri, 1 Jun 2018 00:10:32 +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 F1E84EB200; Fri, 1 Jun 2018 00:10:31 +0200 (CEST) Date: Fri, 01 Jun 2018 00:10:32 +0200 Message-ID: <87r2lrlbmv.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: David Schinazi , Weronika =?ISO-8859-2?Q?Ko=B3odz?= =?ISO-8859-2?Q?iejak?= , Clara =?ISO-8859-1?Q?D=F4?= , Babel at IETF In-Reply-To: <87fu27mt0m.fsf@toke.dk> References: <87sh6915ix.wl-jch@irif.fr> <876035c8re.fsf@toke.dk> <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> <87zi0has5c.fsf@toke.dk> <877enlge07.wl-jch@irif.fr> <551BD811-DC02-4DF0-A508-610F66296BFB@apple.com> <8736y8bzwb.fsf@toke.dk> <87a7sgw1fs.wl-jch@irif.fr> <87y3g0axjn.fsf@toke.dk> <878t7z1wtx.wl-jch@irif.fr> <87efhrvebs.fsf@toke.dk> <87y3fzzgnb.wl-jch@irif.fr> <87fu27mt0m.fsf@toke.dk> User-Agent: Wanderlust/2.15.9p 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, 01 Jun 2018 00: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]); Fri, 01 Jun 2018 00:10:35 +0200 (CEST) X-Miltered: at korolev with ID 5B1072D9.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B1072DA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B1072D9.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B1072DA.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 : 5B1072D9.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B1072DA.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] Rethinking HMAC authentication 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: Thu, 31 May 2018 22:10:42 -0000 > Hmm, guess so. Or use the same space (assign the HMAC TLV from the > existing registry), and add a flag specifying which ones are allowed to > be in the trailer? Or I guess that was what you were already planning to > do? Yes. The meaning of a TLV is determined entirely by the TLV itself, where it lives only determines whether it's dropped or not. Semantics of the mandatory bit in trailer unclear at the moment, I guess I should send a summary of the discussion to Gwendoline and ask her opinion. We've got plenty of TLV space (we can switch to 16-bit TLV numbers at any time, without breaking compatibility or mandatory bits). -- Juliusz From nobody Thu May 31 17:00: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 646901200C1 for ; Thu, 31 May 2018 16:59: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 CBGHzie9tyqk for ; Thu, 31 May 2018 16:59: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 4DF3E1200A0 for ; Thu, 31 May 2018 16:59:57 -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 w4VNsn5a009390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 Jun 2018 01:54:49 +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 w4VNsotJ003828; Fri, 1 Jun 2018 01:54: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 CB5D3EB22D; Fri, 1 Jun 2018 01:54:48 +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 h52fGKJ9eMy4; Fri, 1 Jun 2018 01:54:47 +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 ABBC0EB200; Fri, 1 Jun 2018 01:54:47 +0200 (CEST) Date: Fri, 01 Jun 2018 01:54:47 +0200 Message-ID: <87lgbzl6t4.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: David Schinazi , Weronika =?ISO-8859-2?Q?Ko=B3odz?= =?ISO-8859-2?Q?iejak?= , Clara =?ISO-8859-1?Q?D=F4?= , Babel at IETF , Gwendoline Chouasne-Guillon In-Reply-To: <87r2lrlbmv.wl-jch@irif.fr> References: <87sh6915ix.wl-jch@irif.fr> <876035c8re.fsf@toke.dk> <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> <87zi0has5c.fsf@toke.dk> <877enlge07.wl-jch@irif.fr> <551BD811-DC02-4DF0-A508-610F66296BFB@apple.com> <8736y8bzwb.fsf@toke.dk> <87a7sgw1fs.wl-jch@irif.fr> <87y3g0axjn.fsf@toke.dk> <878t7z1wtx.wl-jch@irif.fr> <87efhrvebs.fsf@toke.dk> <87y3fzzgnb.wl-jch@irif.fr> <87fu27mt0m.fsf@toke.dk> <87r2lrlbmv.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, 01 Jun 2018 01:54:50 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 01 Jun 2018 01:54:50 +0200 (CEST) X-Miltered: at korolev with ID 5B108B49.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B108B4A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B108B49.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B108B4A.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 : 5B108B49.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B108B4A.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] Rethinking HMAC authentication 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 00:00:00 -0000 > Yes. The meaning of a TLV is determined entirely by the TLV itself, where > it lives only determines whether it's dropped or not. Semantics of the > mandatory bit in trailer unclear at the moment, Strawman proposal, in early 21st century RFCese: - the trailer is a sequence of TLVs, just like the body; - a TLV MUST NOT appear in the trailer unless its specification explicitly allows it; if a TLV that is not allowed in the trailer appears there, it MUST be silently ignored (but the rest of the packet SHOULD still be processed); - a mandatory TLV MUST NOT be allowed in the trailer; if a mandatory TLV appears in the trailer, the TLV MUST be silently ignored, but the mandatory bit SHOULD NOT be acted upon (i.e. the rest of the packet SHOULD still be processed); - designers of extensions using the trailer should be aware that, since - the trailer is processed before cryptographic validation of the packet, the format of TLVs in the trailer should be as simple as possible; achieving this simplicity may involve using formats that are not self-terminating and not allowing sub-TLVs within trailer TLVs. -- Juliusz From nobody Thu May 31 17:34: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 45F5312421A for ; Thu, 31 May 2018 17:34:29 -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 TVjaXfyePMBG for ; Thu, 31 May 2018 17:34:26 -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 946061241F5 for ; Thu, 31 May 2018 17:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1527813265; x=2391726865; 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=mXYDvX6RYj2vt2LlgPlOOLGGWbHSXLpiPuW0nGUBDcA=; b=jxG+s0JP5F9rgjKpWCZJi4Q7p+iyJzJOhpBo2BLBBN2N6HMK/tK5XZMY9g9Lr+zH SkaTn0aGsxmO3IvwaoflpI3djsMyD/xR2Jfv8bIWbXwPlrsW6Z0oPvYD88BqD62C O2dZl5jckLB1Hyatui3FJIM0qGN/QL5XO3DoKybC5QKhbE0xJ8CfKSvl5sGnp6IJ eP9XHK+2lvrJNHEL1p4XB/rg+SfQkmrCr2Km7n1wvunSfC7wy/s0MnxlhT+3i3fh IA0SfeBVu7yuq/5sJrilXXiU6PsNKtHR75IvOfWM2dprUFrMHos9WindHiqcuwnO 63v+NVT+KLRATKWF+Kl+Xw==; X-AuditID: 11973e11-a13ff70000003aca-19-5b109490f494 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-in2.apple.com (Apple Secure Mail Relay) with SMTP id 70.66.15050.194901B5; Thu, 31 May 2018 17:34:25 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0P9M00IITC9CQK40@ma1-mtap-s03.corp.apple.com>; Thu, 31 May 2018 17:34:24 -0700 (PDT) Received: from [17.234.31.28] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P9M00MZIC9BQU70@nwk-mmpp-sz12.apple.com>; Thu, 31 May 2018 17:34:24 -0700 (PDT) X-Va-A: X-Va-T-CD: d59661a006d810078864a2b5ec0f053f X-Va-E-CD: 364ba9793b3bbfb9221b229b541cb094 X-Va-R-CD: 27f632e87b0ecd4c43e83a63c73bf407 X-Va-CD: 0 X-Va-ID: a579deae-a916-46ff-bc79-a0c042da7294 X-V-A: X-V-T-CD: 7d6566e1ce32e60bd701207e1252a9a5 X-V-E-CD: 364ba9793b3bbfb9221b229b541cb094 X-V-R-CD: 27f632e87b0ecd4c43e83a63c73bf407 X-V-CD: 0 X-V-ID: 629d19bb-48dd-428d-b057-2bdca86fa53b X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-31_13:,, signatures=0 Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87lgbzl6t4.wl-jch@irif.fr> Date: Thu, 31 May 2018 17:34:22 -0700 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , =?utf-8?Q?Weronika_Ko=C5=82odziejak?= , =?utf-8?B?Q2xhcmEgRMO0?= , Babel at IETF , Gwendoline Chouasne-Guillon Message-id: References: <87sh6915ix.wl-jch@irif.fr> <876035c8re.fsf@toke.dk> <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> <87zi0has5c.fsf@toke.dk> <877enlge07.wl-jch@irif.fr> <551BD811-DC02-4DF0-A508-610F66296BFB@apple.com> <8736y8bzwb.fsf@toke.dk> <87a7sgw1fs.wl-jch@irif.fr> <87y3g0axjn.fsf@toke.dk> <878t7z1wtx.wl-jch@irif.fr> <87efhrvebs.fsf@toke.dk> <87y3fzzgnb.wl-jch@irif.fr> <87fu27mt0m.fsf@toke.dk> <87r2lrlbmv.wl-jch@irif.fr> <87lgbzl6t4.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGIsWRmVeSWpSXmKPExsUiqOHDrjtxikC0wZ0maYsti7pZLDZcXsds 8av5C6PF/NZlbBZb369gt/jw6Q6rA5vHhr0tzB47Z91l91iy5CeTx+Itbxk9thy6yObxavpD 9gC2KC6blNSczLLUIn27BK6MtavfMRbM5ak4tvM9awPjTs4uRk4OCQETida5k5i6GLk4hAT2 MUlsfP6LCSTBKyAo8WPyPZYuRg4OZgF5iYPnZUHCzAJaEt8ftbJA1G8Eqj/Yzw7hfGGUaF37 iAViKrvEn187oGxtiYN3lrHC2BefLGOGsSc/+8EIYXNJLNh6GqpGV+LbzC1MEDabxPoTS6Bs LYmn25+zwtgLmnoZYexlt09D7eKUOP9lIjvI0RICOhJH9thAhLMljt1azQZiCwtIS3RduMsK YRtLzH2yjwmknA1ozIE1RiBhTgENifPPm8GmswioSvRsmsEM8iKzwBImiWcLIM7nFbCRONz5 DxoQO1kkDn+eD3aniICKxPJpz9ghFitJTP9+m20Co9wspDCdhQjTWUhhuoCReRWjUG5iZo5u Zp6RXmJBQU6qXnJ+7iZGUMKYbie4g/H4KqtDjAIcjEo8vBc+8kcLsSaWFVfmHmKU5mBREufl 9heIFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cAY/vXwpV6BlrI1Wm3tuX6TY9cG7FQSYsmc Mi897GLtLCs7x/51l7hS3/x95DvffP9067+Rcz0LLEtn3rf903zVxrFCay2T5F6b4yedlBar 7Lwz8c0jq+2P+5/47p2V0XJQoCZ5+oFVB60ZXVMZys/9D13ax6X8TWbyb495xyfyVs6osjW7 vbJCiaU4I9FQi7moOBEAFIPeIvkCAAA= Archived-At: Subject: Re: [babel] Rethinking HMAC authentication 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 00:34:29 -0000 That doesn't sound unreasonable to me, but I was fine with the HMAC TLV in the packet. Setting the MAC to zero before computing the MAC sounds simpler to explain than these 5 bullet points. (So far I have no strong opinion either way though) David > On May 31, 2018, at 16:54, Juliusz Chroboczek wrote: > >> Yes. The meaning of a TLV is determined entirely by the TLV itself, where >> it lives only determines whether it's dropped or not. Semantics of the >> mandatory bit in trailer unclear at the moment, > > Strawman proposal, in early 21st century RFCese: > > - the trailer is a sequence of TLVs, just like the body; > - a TLV MUST NOT appear in the trailer unless its specification > explicitly allows it; if a TLV that is not allowed in the trailer > appears there, it MUST be silently ignored (but the rest of the packet > SHOULD still be processed); > - a mandatory TLV MUST NOT be allowed in the trailer; if a mandatory TLV > appears in the trailer, the TLV MUST be silently ignored, but the > mandatory bit SHOULD NOT be acted upon (i.e. the rest of the packet > SHOULD still be processed); > - designers of extensions using the trailer should be aware that, since > - the trailer is processed before cryptographic validation of the > packet, the format of TLVs in the trailer should be as simple as > possible; achieving this simplicity may involve using formats that are > not self-terminating and not allowing sub-TLVs within trailer TLVs. > > -- Juliusz > > From nobody Thu May 31 18:17: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 EFB441241F5 for ; Thu, 31 May 2018 18:17:22 -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 ViZ7zAk0yety for ; Thu, 31 May 2018 18:17: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 9B3BC1200E5 for ; Thu, 31 May 2018 18:17:20 -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 w511HBf7024644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 Jun 2018 03:17:11 +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 w511HCNo016542; Fri, 1 Jun 2018 03:17:12 +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 AD60BEB22E; Fri, 1 Jun 2018 03:17:10 +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 0ejX61kyHw3h; Fri, 1 Jun 2018 03:17:09 +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 9CD8AEB22D; Fri, 1 Jun 2018 03:17:09 +0200 (CEST) Date: Fri, 01 Jun 2018 03:17:08 +0200 Message-ID: <87efhrl2zv.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , Weronika =?ISO-8859-2?Q?Ko=B3odziejak?= , Clara =?ISO-8859-1?Q?D=F4?= , Babel at IETF , Gwendoline Chouasne-Guillon In-Reply-To: References: <87sh6915ix.wl-jch@irif.fr> <876035c8re.fsf@toke.dk> <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> <87zi0has5c.fsf@toke.dk> <877enlge07.wl-jch@irif.fr> <551BD811-DC02-4DF0-A508-610F66296BFB@apple.com> <8736y8bzwb.fsf@toke.dk> <87a7sgw1fs.wl-jch@irif.fr> <87y3g0axjn.fsf@toke.dk> <878t7z1wtx.wl-jch@irif.fr> <87efhrvebs.fsf@toke.dk> <87y3fzzgnb.wl-jch@irif.fr> <87fu27mt0m.fsf@toke.dk> <87r2lrlbmv.wl-jch@irif.fr> <87lgbzl6t4.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, 01 Jun 2018 03:17:12 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 01 Jun 2018 03:17:12 +0200 (CEST) X-Miltered: at korolev with ID 5B109E97.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5B109E98.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5B109E97.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5B109E98.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 : 5B109E97.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5B109E98.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] Rethinking HMAC authentication 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 01:17:23 -0000 > That doesn't sound unreasonable to me, but I was fine with the HMAC TLV > in the packet. Setting the MAC to zero before computing the MAC sounds > simpler to explain than these 5 bullet points. Uh-huh. Since we walk the packet twice anyway, the main advantage of using the trailer is gone. There's still a minor advantage in avoiding walking the whole packet before validating HMAC -- only authentic and replayed packets can possibly reach the parser, not spoofed packets, which should make it more difficult to exploit a flaw in the parser. At this stage, I feel it's pretty much a wash (assuming I'm using the idiom correctly), it'll hopefully become clearer as we continue implementing. -- Juliusz From nobody Thu May 31 20:03:46 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 5E7F9126C0F for ; Thu, 31 May 2018 20:03: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 73TLPOJTCGRF for ; Thu, 31 May 2018 20:03:42 -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 BFB991250B8 for ; Thu, 31 May 2018 20:03: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=1527822222; x=2391735822; 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=6KbWz/nV6W6O2734bfoJQWsTDSnLB/O1EdkfjkwG9DA=; b=SAvpKz1K9CuchwSOktnDQ7gjYQXsOwkxLxOigXexVMzd1kZgtbtHFOFA9XbGBkJM AsGaDSQVLmzHcBcH9Fo3iPg4ApK8zlFqZ1gOqVn31zK6w5M2voPbLCDfvMCC1HK6 f8UZXwghHixqU2fpond63z0hmEvCK8nzrhXZySPMngVwCCCK1s71jz1m7LXGL3Uq RDKLHPjTskqRVH8t8HuAqDMevkWQfQAlT3lDcjqzGmj5Zi2SFIgtJ2RCb7SqnoOw zNhjFa88bII7XOv5kQI9wrbMc7WJ9beiuMxc2UPHhWtF2fG6PZxnpFwdlkfqi7fD mCP0iXUVQRO5ELnk8mescg==; X-AuditID: 11ab0216-c7fff70000002f11-6d-5b10b78d1aab 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 85.D5.12049.D87B01B5; Thu, 31 May 2018 20:03:42 -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.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0P9M002Y1J65NC30@mr2-mtap-s03.rno.apple.com>; Thu, 31 May 2018 20:03:41 -0700 (PDT) Received: from [17.234.31.28] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P9M00IH2J63GK20@nwk-mmpp-sz10.apple.com>; Thu, 31 May 2018 20:03:41 -0700 (PDT) X-Va-A: X-Va-T-CD: d59661a006d810078864a2b5ec0f053f X-Va-E-CD: 364ba9793b3bbfb9221b229b541cb094 X-Va-R-CD: 27f632e87b0ecd4c43e83a63c73bf407 X-Va-CD: 0 X-Va-ID: 070243ea-8a08-4568-bc95-0384d5ea5a68 X-V-A: X-V-T-CD: 7d6566e1ce32e60bd701207e1252a9a5 X-V-E-CD: 364ba9793b3bbfb9221b229b541cb094 X-V-R-CD: 27f632e87b0ecd4c43e83a63c73bf407 X-V-CD: 0 X-V-ID: 700436d0-0f6d-48c7-b84a-fa9290ddfb71 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-01_01:,, signatures=0 Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87efhrl2zv.wl-jch@irif.fr> Date: Thu, 31 May 2018 20:03:38 -0700 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , =?utf-8?Q?Weronika_Ko=C5=82odziejak?= , =?utf-8?B?Q2xhcmEgRMO0?= , Babel at IETF , Gwendoline Chouasne-Guillon Message-id: References: <87sh6915ix.wl-jch@irif.fr> <876035c8re.fsf@toke.dk> <744F5308-CC2F-4061-B6BC-84FB405789F6@apple.com> <87zi0has5c.fsf@toke.dk> <877enlge07.wl-jch@irif.fr> <551BD811-DC02-4DF0-A508-610F66296BFB@apple.com> <8736y8bzwb.fsf@toke.dk> <87a7sgw1fs.wl-jch@irif.fr> <87y3g0axjn.fsf@toke.dk> <878t7z1wtx.wl-jch@irif.fr> <87efhrvebs.fsf@toke.dk> <87y3fzzgnb.wl-jch@irif.fr> <87fu27mt0m.fsf@toke.dk> <87r2lrlbmv.wl-jch@irif.fr> <87lgbzl6t4.wl-jch@irif.fr> <87efhrl2zv.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOIsWRmVeSWpSXmKPExsUiuPlRu27fdoFogw0nGC22LOpmsdhweR2z xa/mL4wW81uXsVlsfb+C3eLDpzusDmweG/a2MHvsnHWX3WPJkp9MHou3vGX02HLoIpvHq+kP 2QPYorhsUlJzMstSi/TtErgy9vTeZypoZK+4uXMnYwPjQdYuRk4OCQETiY8tL1m6GLk4hAQO Mkms/TGZBSTBKyAo8WPyPSCbg4NZQF7i4HlZkDCzgJbE90etUPXrmSQenznHDpIQEvjCKPFg rwXEUHaJP792sEDY2hIH7yxjhbEvPlnGDGNPfvaDEcLmkliw9TRUja7EnXPboOJsEutPLGGC sLUknm5/zgpjL2jqZYSxl90+DbWLU+L8l4nsELaOxORXS6F2ZUucObiDDcQWFpCW6LpwlxXC NpaY+2QfE8iPbEBzDqwxAglzCmhI/PyyH2wMi4CqxMMnDWwg/zILLGGSeLYA4n5eARuJzn0b mSAB0cEqMff3LLAjRARUJJZPewZ1hJLE9O+32SYwys1CCtNZiDCdhRSmCxiZVzEK5yZm5uhm 5hkZ6SUWFOSk6iXn525iBKWM1UxiOxjvvTY8xCjAwajEw3vhI3+0EGtiWXFl7iFGaQ4WJXHe xUEc0UIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYzfrT6uQ2XO/qts5O5lov+z33VFtI7c4c 5vtfHjoeODiH+Vtc0Nor++M0J1TuW/NL7KWv4tv73eH3dGQUd622Dert05qgqub83ufVszUh 78oWl99heWPwvOr0yW0WeZfb160UmDlNde2es7c9JonudJHZXWPkJiDwdLNz79GUsPxVZ2e1 GyybrMRSnJFoqMVcVJwIADZitqP6AgAA Archived-At: Subject: Re: [babel] Rethinking HMAC authentication 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 03:03:45 -0000 That's a good argument though, might tip the scales. David > On May 31, 2018, at 18:17, Juliusz Chroboczek wrote: > >> That doesn't sound unreasonable to me, but I was fine with the HMAC TLV >> in the packet. Setting the MAC to zero before computing the MAC sounds >> simpler to explain than these 5 bullet points. > > Uh-huh. > > Since we walk the packet twice anyway, the main advantage of using the > trailer is gone. There's still a minor advantage in avoiding walking the > whole packet before validating HMAC -- only authentic and replayed packets > can possibly reach the parser, not spoofed packets, which should make it > more difficult to exploit a flaw in the parser. > > At this stage, I feel it's pretty much a wash (assuming I'm using the > idiom correctly), it'll hopefully become clearer as we continue implementing. > > -- Juliusz