From nobody Sun Apr 1 18:08:16 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0213C126C89; Sun, 1 Apr 2018 18:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 BjrsJ6JUi14r; Sun, 1 Apr 2018 18:08:12 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 27AF41243F3; Sun, 1 Apr 2018 18:08:10 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Forcepoint Email with ESMTPS id 6C8E8304A062971B1FA9; Mon, 2 Apr 2018 09:08:07 +0800 (CST) Received: from njxapp01.zte.com.cn ([10.41.132.200]) by mse02.zte.com.cn with SMTP id w32181xJ028321; Mon, 2 Apr 2018 09:08:01 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn) Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid203; Mon, 2 Apr 2018 09:08:02 +0800 (CST) Date: Mon, 2 Apr 2018 09:08:02 +0800 (CST) X-Zmail-TransId: 2afa5ac182722ca-2b3ad X-Mailer: Zmail v1.0 Message-ID: <201804020908024607213@zte.com.cn> In-Reply-To: References: CAF4+nEHUmjUcY7PS0eVDuPr8YHaJG4t+CyoxzMR15821X+-Vsg@mail.gmail.com Mime-Version: 1.0 From: To: Cc: , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse02.zte.com.cn w32181xJ028321 Archived-At: Subject: Re: [babel] =?utf-8?q?WG_Last_Call_for_draft-ietf-babel-source-speci?= =?utf-8?q?fic=282018-03-26_to_2018-04-09=29?= 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, 02 Apr 2018 01:08:15 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 QWZ0ZXIgYSBxdWljayByZWFkaW5nLCBJTU8gdGhpcyBkcmFmdCBpcyByZWFkeS4NCg0KDQoNCg0K DQoNCg0KQSBzbWFsbCBuaXQ6DQoNCkluIHRoZSBzZWNvbmQgcGFyYWdyYXBoLCBzZWN0aW9uIDUu MToNCg0KIldoZW4gYSBub2RlIHJlY2VpdmVzIGEgc291cmNlLXNwZWNpZmljIC4uLiAgZnJvbSBh IG5laWdoYm91ciBuZWlnaCwgaXQgYmVoYXZlcyBhcyBkZXNjcmliZWQgLi4uIg0KDQoNCkl0IHNl ZW1zIGxpa2UgIm5laWdoYm91ciIgYW5kICJuZWlnaCIgYXJlIGR1cGxpY2F0ZS4NCg0KDQoNCg0K DQoNCg0KVGhhbmtzLA0KDQoNClNhbmR5DQoNCg0KDQrljp/lp4vpgq7ku7YNCg0KDQoNCuWPkeS7 tuS6uu+8mkRvbmFsZEVhc3RsYWtlIDxkM2UzZTNAZ21haWwuY29tPg0K5pS25Lu25Lq677yaQmFi ZWwgYXQgSUVURiA8YmFiZWxAaWV0Zi5vcmc+DQrmioTpgIHkurrvvJpiYWJlbC1jaGFpcnNAaWV0 Zi5vcmcgPGJhYmVsLWNoYWlyc0BpZXRmLm9yZz4NCuaXpSDmnJ8g77yaMjAxOOW5tDAz5pyIMjfm l6UgMDI6MTcNCuS4uyDpopgg77yaW2JhYmVsXSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYt YmFiZWwtc291cmNlLXNwZWNpZmljKDIwMTgtMDMtMjYgdG8gMjAxOC0wNC0wOSkNCg0KDQpIaSwN Cg0KVGhpcyBtZXNzYWdlIHN0YXJ0cyBhIHR3by13ZWVrIFdHIExhc3QgQ2FsbCBvbg0KZHJhZnQt aWV0Zi1iYWJlbC1zb3VyY2Utc3BlY2lmaWMtMDMudHh0LiBQbGVhc2UgcmV2aWV3IHRoZSBkcmFm dCBhbmQNCmluZGljYXRlIHdoZXRoZXIgeW91IHRoaW5rIGl0IGlzIHJlYWR5IGZvciBhZHZhbmNl bWVudC4gQ29tbWVudHMNCndlbGNvbWUuDQoNClRoYW5rcywNCkRvbmFsZA0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KIERvbmFsZCBFLiBFYXN0bGFrZSAzcmQgICArMS01MDgtMzMz LTIyNzAgKGNlbGwpDQogMTU1IEJlYXZlciBTdHJlZXQsIE1pbGZvcmQsIE1BIDAxNzU3IFVTQQ0K IGQzZTNlM0BnbWFpbC5jb20NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCmJhYmVsIG1haWxpbmcgbGlzdA0KYmFiZWxAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmFiZWw= --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTphcmlhbDsiPkFmdGVyIGEgcXVpY2sgcmVhZGluZywgSU1PIHRoaXMgZHJhZnQgaXMgcmVh ZHkuPGJyPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48 YnI+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZhbWlseTphcmlhbDsiPkEgc21h bGwgbml0OjwvcD48cD5JbiB0aGUgc2Vjb25kIHBhcmFncmFwaCwgc2VjdGlvbiA1LjE6PC9wPjxw PiJXaGVuIGEgbm9kZSByZWNlaXZlcyBhIHNvdXJjZS1zcGVjaWZpYyAuLi4gJm5ic3A7ZnJvbSBh IG5laWdoYm91ciBuZWlnaCwgaXQgYmVoYXZlcyBhcyBkZXNjcmliZWQgLi4uIjxicj48L3A+PHA+ SXQgc2VlbXMgbGlrZSAibmVpZ2hib3VyIiBhbmQgIm5laWdoIiBhcmUgZHVwbGljYXRlLjxicj48 L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+PGJyPjwvcD48 cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij5UaGFua3MsPC9wPjxw IHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZhbWlseTphcmlhbDsiPlNhbmR5PC9wPjxkaXY+ PGRpdiBjbGFzcz0iemhpc3RvcnlSb3ciIHN0eWxlPSJkaXNwbGF5OmJsb2NrIj48ZGl2IGNsYXNz PSJ6aGlzdG9yeURlcyIgc3R5bGU9IndpZHRoOiAxMDAlOyBoZWlnaHQ6IDI4cHg7IGxpbmUtaGVp Z2h0OiAyOHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiAjRTBFNUU5OyBjb2xvcjogIzEzODhGRjsgdGV4 dC1hbGlnbjogY2VudGVyOyIgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeU9yZ1R4dCI+5Y6f5aeL6YKu 5Lu2PC9kaXY+PGRpdiBpZD0iendyaXRlSGlzdG9yeUNvbnRhaW5lciI+PGRpdiBjbGFzcz0iY29u dHJvbC1ncm91cCB6aGlzdG9yeVBhbmVsIj48ZGl2IGNsYXNzPSJ6aGlzdG9yeUhlYWRlciIgc3R5 bGU9InBhZGRpbmc6IDhweDsgYmFja2dyb3VuZC1jb2xvcjogI0Y1RjZGODsiPjxkaXY+PHN0cm9u ZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5U2VuZGVyVHh0Ij7lj5Hku7bkurrvvJo8L3N0cm9uZz48 c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSI+RG9uYWxkRWFzdGxha2UgJmx0O2QzZTNlM0BnbWFp bC5jb20mZ3Q7PC9zcGFuPjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5 VE9UeHQiPuaUtuS7tuS6uu+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBz dHlsZT0iZGlzcGxheTogaW5saW5lOyI+QmFiZWwgYXQgSUVURiAmbHQ7YmFiZWxAaWV0Zi5vcmcm Z3Q7PC9zcGFuPjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5Q0NUeHQi PuaKhOmAgeS6uu+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0i ZGlzcGxheTogaW5saW5lOyI+YmFiZWwtY2hhaXJzQGlldGYub3JnICZsdDtiYWJlbC1jaGFpcnNA aWV0Zi5vcmcmZ3Q7PC9zcGFuPjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0 b3J5RGF0ZVR4dCI+5pelIOacnyDvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0iIj4yMDE45bm0MDPm nIgyN+aXpSAwMjoxNzwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlz dG9yeVN1YmplY3RUeHQiPuS4uyDpopgg77yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVGl0 bGUiPjxzdHJvbmc+W2JhYmVsXSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtYmFiZWwtc291 cmNlLXNwZWNpZmljKDIwMTgtMDMtMjYgdG8gMjAxOC0wNC0wOSk8L3N0cm9uZz48L3NwYW4+PC9k aXY+PC9kaXY+PGRpdiBjbGFzcz0iemhpc3RvcnlDb250ZW50Ij48ZGl2PkhpLDxicj48YnI+VGhp cyZuYnNwO21lc3NhZ2UmbmJzcDtzdGFydHMmbmJzcDthJm5ic3A7dHdvLXdlZWsmbmJzcDtXRyZu YnNwO0xhc3QmbmJzcDtDYWxsJm5ic3A7b248YnI+ZHJhZnQtaWV0Zi1iYWJlbC1zb3VyY2Utc3Bl Y2lmaWMtMDMudHh0LiZuYnNwO1BsZWFzZSZuYnNwO3JldmlldyZuYnNwO3RoZSZuYnNwO2RyYWZ0 Jm5ic3A7YW5kPGJyPmluZGljYXRlJm5ic3A7d2hldGhlciZuYnNwO3lvdSZuYnNwO3RoaW5rJm5i c3A7aXQmbmJzcDtpcyZuYnNwO3JlYWR5Jm5ic3A7Zm9yJm5ic3A7YWR2YW5jZW1lbnQuJm5ic3A7 Q29tbWVudHM8YnI+d2VsY29tZS48YnI+PGJyPlRoYW5rcyw8YnI+RG9uYWxkPGJyPj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT08YnI+Jm5ic3A7RG9uYWxkJm5ic3A7RS4mbmJzcDtFYXN0 bGFrZSZuYnNwOzNyZCZuYnNwOyZuYnNwOyZuYnNwOysxLTUwOC0zMzMtMjI3MCZuYnNwOyhjZWxs KTxicj4mbmJzcDsxNTUmbmJzcDtCZWF2ZXImbmJzcDtTdHJlZXQsJm5ic3A7TWlsZm9yZCwmbmJz cDtNQSZuYnNwOzAxNzU3Jm5ic3A7VVNBPGJyPiZuYnNwO2QzZTNlM0BnbWFpbC5jb208YnI+PGJy Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPmJhYmVs Jm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8YnI+YmFiZWxAaWV0Zi5vcmc8YnI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iYWJlbDwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pjwv ZGl2PjwvZGl2PjxwPjxicj48L3A+PC9kaXY+ --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Tue Apr 3 17:20: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 C506D12D9FF for ; Tue, 3 Apr 2018 17:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 aU-b7EIKWsuC for ; Tue, 3 Apr 2018 17:20:26 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E055412D946 for ; Tue, 3 Apr 2018 17:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1522801221; 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=2944; bh=X1xxhwKxztrD1X/BSrn6kju6RbeRgAnC3SAzNvSGDNA=; b=No7RA2H2CM5QGLT2ljLi5tCOwITU9ZyANzFjh6d4rz2m/Wrbkyn3kCHzgovytT3G 9dEVpo6nBNj2lQajGOIgDS9069FYq7KC5LepudTasE1pLuFuaUhIpUH8CcPRdv5FcRT vBdK9gNQomHIAcF9NbFEWiqKGKKlxNzCL0rwr7tM= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 152280122112893.14602084910325; Tue, 3 Apr 2018 17:20:21 -0700 (PDT) Date: Wed, 04 Apr 2018 01:20:21 +0100 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <1628e069e06.104b4b60634736.7031234626202321408@ovsienko.info> In-Reply-To: <9E3DBF48-F991-43BA-AD12-F4433A2CEF30@apple.com> References: <87k1u1uekt.wl-jch@irif.fr> <16263df4d35.c134482a130573.7360272675488949721@ovsienko.info> <87r2o6k2jm.wl-jch@irif.fr> <162642bbd2f.1266904f2130878.513114391174006256@ovsienko.info> <87po3qech1.fsf@toke.dk> <1626c14d206.11a73a01135842.5517559371574417385@ovsienko.info> <871sg4jybq.fsf@toke.dk> <87h8p01ias.wl-jch@irif.fr> <87bmf8icvc.fsf@toke.dk> <87efk41h6z.wl-jch@irif.fr> <878tacibum.fsf@toke.dk> <87bmf81fy1.wl-jch@irif.fr> <87sh8kgvvv.fsf@toke.dk> <87muysgvtt.fsf@toke.dk> <9E3DBF48-F991-43BA-AD12-F4433A2CEF30@apple.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] Work to do (IHU TLV AE 0) 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, 04 Apr 2018 00:20:30 -0000 Hello all. ---- On Fri, 30 Mar 2018 15:59:09 +0100 David Schinazi wrote ---- > Taking a step back and thinking about the security properties here, > I don't see a security issue with the text "A Unicast Hello carrying a given seqno should normally be sent to just one neighbour". > The conceptual property of unicast hellos is that the seqno is from a different pool as the multicast seqno. > That means that I MUST treat them separately when I receive them to avoid mixing up cost estimations, > however as a sender I can very well send the same unicast seqno to all my neighbors if I so choose. > As such it is not a problem to send Unicast Hellos to the multicast address (even though I don't see a reason to do so). > The attack that Juliusz described was where Eve takes an unicast Hello from Alice destined for Bob and sends it to Damian, > in that case the problem arises because Damian will check the timestamp/packet counter from the Alice-Damian relationship > and get a seqno from the Alice-Bob relationship. Yes, that's what I meant. One minor detail does not look correct at the end: authenticity relation is one-way (from Alice to whom it may concern). The good news is that "belt and braces" approach does not require a 100% exact problem statement so it should be fine (you are welcome to prove this wrong) both to cover the destination address by the integrity check _and_ to make the Address field in the IHU TLV mandatory. As a side comment, one thing that your description makes easier to notice is as follows. Given a [strictly increasing, per-interface] TS/PC number with no gaps between the values, some of the values may be spent on Tx multicast and the others -- on Tx unicast. From the point of view of a multicast-only or unicast-only receiving speaker, the number will remain strictly increasing but there will be gaps between the values. Which is going to work as originally intended in both the old and the new sections of 7298-bis -- the added complexity of Hello seqno tracking does not spill into the TS/PC number tracking. Right? > The attack stems from the fact that packets can be replayed with a falsified destination address. > The simplest fix is to have the destination address as part of the inputs to the HMAC function. Yes. > Here is a proposal: we replace the current construct where the IPv6 source address is written into the HMAC field before HMAC > with a different construct akin to the TCP pseudo-header: we set the HMAC field to all zeroes and prepend the source and > destination IP addresses to the Babel payload before computing the HMAC. This is simpler and does not require us to place requirements > on the size of the HMAC output. Yes. RFC 7298 specifies the overlay construct for consistency reasons (i.e. the intent was to do things differently only if there was a good reason for that). -- Denis Ovsienko From nobody Tue Apr 3 17:29: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 8C5FC12704A for ; Tue, 3 Apr 2018 17:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fjjOKgFQ3tx for ; Tue, 3 Apr 2018 17:29:19 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA69D12DA04 for ; Tue, 3 Apr 2018 17:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1522801757; x=2386715357; 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=Ndap6VyBjMLCbmuJzv1G9gcNLquYPx1Voug4MyeMfK8=; b=IUjm8jSaKbbuul5M4Pk8GBWp3+2z/F36NfCAXjUPN+eFIPQjYQADsm3OVpxY1Oi0 ZZ38u0o+g5Egfeq2o4OkpRGzTJ1X7cQ35BaovsIaxxbtEESnphg31idXsDU6z6c9 QveEZ3pVVeKo+aMB0VSO1HNCpb+Q/Jaij+O8aLp/2KNlo8EZjmKdqOJ0L1b1So+a pXWsBiKLB/Y51TGxqQsvqxMBCLVwR1a4c7+JUpfm3jF0efUQmHDCI1Y7YsYtmUd7 KyTbeu6bxVHIBci6tYP8MCCdzFPsTQ333/lOlYirNT5rjvnKUQZDUBLVRGXrid03 Rbx16mZZoAp5+7hSG55ovg==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id A0.C2.07147.D5C14CA5; Tue, 3 Apr 2018 17:29:17 -0700 (PDT) X-AuditID: 11973e12-d46b29e000001beb-9f-5ac41c5d36bc Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id B9.5B.10701.D5C14CA5; Tue, 3 Apr 2018 17:29:17 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_zlKnq1/u/nEGVjMaBRN+XQ)" Received: from [17.192.155.180] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P6M00FVBXCSK1C0@nwk-mmpp-sz09.apple.com>; Tue, 03 Apr 2018 17:29:17 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi X-Priority: Medium In-reply-to: <1628e069e06.104b4b60634736.7031234626202321408@ovsienko.info> Date: Tue, 03 Apr 2018 17:29:15 -0700 Cc: Babel at IETF Message-id: References: <87k1u1uekt.wl-jch@irif.fr> <16263df4d35.c134482a130573.7360272675488949721@ovsienko.info> <87r2o6k2jm.wl-jch@irif.fr> <162642bbd2f.1266904f2130878.513114391174006256@ovsienko.info> <87po3qech1.fsf@toke.dk> <1626c14d206.11a73a01135842.5517559371574417385@ovsienko.info> <871sg4jybq.fsf@toke.dk> <87h8p01ias.wl-jch@irif.fr> <87bmf8icvc.fsf@toke.dk> <87efk41h6z.wl-jch@irif.fr> <878tacibum.fsf@toke.dk> <87bmf81fy1.wl-jch@irif.fr> <87sh8kgvvv.fsf@toke.dk> <87muysgvtt.fsf@toke.dk> <9E3DBF48-F991-43BA-AD12-F4433A2CEF30@apple.com> <1628e069e06.104b4b60634736.7031234626202321408@ovsienko.info> To: Denis Ovsienko X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUi2FCYphsrcyTKYPMzKYsti7pZLObc+s7i wOSxZMlPJo8VJzeyBTBFcdmkpOZklqUW6dslcGV0X3nFVrBcp2LDlKfsDYwPVbsYOTkkBEwk lr/4yNbFyMUhJLCGSWJ/10w2mMTmLStYIBLrmSS2LTjCDJLgFRCU+DH5HguIzSwQJtHQ2MME YgsJfGOUuNTCD2ILC0hLdF24ywph60k8eNMLZHNwsAloSRxYYwQxX0hiy465jCA2p4C3xL7u +WBjWARUJeZeP8AEMV5JYvW3O1BrbSQeXF0Edeg7Fokzy9+CJUQENCS+bJnHDDFUSWL699tg RRICK9gkDt5bxjKBUXgWkrtnIbkbwtaS+P6oFSjOAWTLSxw8LwsR1pR4du8TO4StLfHk3QXW BYxsqxiFchMzc3Qz80z0EgsKclL1kvNzNzGCYmS6ndAOxlOrrA4xCnAwKvHwBiw4HCXEmlhW XJl7iFGag0VJnFf2AVBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo3H8932aiw2sVTbMedly qvygUGvOqj29khr8mqeypE8aGTo67G1/Vz7nxZvrtcxyH8uYTfKnLnB99WGd3gPxkD8vdF14 nbbb2fefm3Sgc89W6cXXbIyjNJnzb3tteCWkcf0Xw6y4+rs/m2fw2dhfEPm++GQ9Z/X//CUb n7gsUGvL6Lrduf1qqxJLcUaioRZzUXEiAJ1UMWJyAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUi2FAcoBsrcyTK4NMXcYsti7pZLObc+s7i wOSxZMlPJo8VJzeyBTBFcdmkpOZklqUW6dslcGV0X3nFVrBcp2LDlKfsDYwPVbsYOTkkBEwk Nm9ZwdLFyMUhJLCeSWLbgiPMIAleAUGJH5PvsYDYzAJhEg2NPUwgtpDAN0aJSy38ILawgLRE 14W7rBC2nsSDN71ANgcHm4CWxIE1RhDzhSS27JjLCGJzCnhL7OueDzaGRUBVYu71A0wQ45Uk Vn+7A7XWRuLB1UVsEPe8Y5E4s/wtWEJEQEPiy5Z5zBBDlSSmf7/NNoFRYBaSU2chORXC1pL4 /qgVKM4BZMtLHDwvCxHWlHh27xM7hK0t8eTdBdYFjGyrGAWKUnMSKy30EgsKclL1kvNzNzGC Q7owbQdj03KrQ4wCHIxKPLwBCw5HCbEmlhVX5h5ilOBgVhLhVdgMFOJNSaysSi3Kjy8qzUkt PsQozcGiJM7bybUzSkggPbEkNTs1tSC1CCbLxMEp1cAoOSlW99b8y+n/fz1I95PYtWPq9Ake RmyfG+YujTb4tpH/4axDV1cx81ZuX5323oDlbdnuvdJip/OaK4yOXTpU2bj88lmvyhOznxX0 /uOJvRldM11pYdwyqbCT3nYz9OaqHri5X+THqZpr+3SVWnUOPloivNvvmNx7yU3uj7N9PyTn 9G59Z6nyWYmlOCPRUIu5qDgRALEa8FhlAgAA Archived-At: Subject: Re: [babel] Work to do (IHU TLV AE 0) 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, 04 Apr 2018 00:29:21 -0000 --Boundary_(ID_zlKnq1/u/nEGVjMaBRN+XQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > On Apr 3, 2018, at 17:20, Denis Ovsienko wrote: > > Yes, that's what I meant. One minor detail does not look correct at the end: authenticity relation is one-way (from Alice to whom it may concern). The good news is that "belt and braces" approach does not require a 100% exact problem statement so it should be fine (you are welcome to prove this wrong) both to cover the destination address by the integrity check _and_ to make the Address field in the IHU TLV mandatory. I am opposed to making the IHU TLV address mandatory, as it increases packet size. Adding the destination address to the inputs to the HMAC does not increase the number of bytes transmitted. > As a side comment, one thing that your description makes easier to notice is as follows. Given a [strictly increasing, per-interface] TS/PC number with no gaps between the values, some of the values may be spent on Tx multicast and the others -- on Tx unicast. From the point of view of a multicast-only or unicast-only receiving speaker, the number will remain strictly increasing but there will be gaps between the values. Which is going to work as originally intended in both the old and the new sections of 7298-bis -- the added complexity of Hello seqno tracking does not spill into the TS/PC number tracking. Right? Gaps are expected in the presence of packet loss, as long as TS/PC doesn't wrap around too quickly we should be fine. Hello seqno gaps impact the cost computation, TS/PC gaps should not impact anything. David --Boundary_(ID_zlKnq1/u/nEGVjMaBRN+XQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
On = Apr 3, 2018, at 17:20, Denis Ovsienko <denis@ovsienko.info>= wrote:

Yes, that's what I meant. One = minor detail does not look correct at the end: authenticity relation is = one-way (from Alice to whom it may concern). The good news is that "belt = and braces" approach does not require a 100% exact problem statement so = it should be fine (you are welcome to prove this wrong) both to cover = the destination address by the integrity check _and_ to make the Address = field in the IHU TLV mandatory.

I am = opposed to making the IHU TLV address mandatory, as it increases packet = size.
Adding the destination address to the inputs to the HMAC = does not increase the number of bytes transmitted.

As a side comment, one thing = that your description makes easier to notice is as follows. Given a = [strictly increasing, per-interface] TS/PC number with no gaps between = the values, some of the values may be spent on Tx multicast and the = others -- on Tx unicast. =46rom the point of view of a multicast-only or = unicast-only receiving speaker, the number will remain strictly = increasing but there will be gaps between the values. Which is going to = work as originally intended in both the old and the new sections of = 7298-bis -- the added complexity of Hello seqno tracking does not spill = into the TS/PC number tracking. Right?

Gaps are = expected in the presence of packet loss, as long as TS/PC doesn't wrap = around too quickly we should be fine.
Hello seqno gaps impact = the cost computation, TS/PC gaps should not impact = anything.

David
= --Boundary_(ID_zlKnq1/u/nEGVjMaBRN+XQ)-- From nobody Tue Apr 3 17:58: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 A86A812D93E for ; Tue, 3 Apr 2018 17:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 7kOkOP4y0NO9 for ; Tue, 3 Apr 2018 17:58:35 -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 D1795127775 for ; Tue, 3 Apr 2018 17:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1522803508; 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=/rp8ncro64HWmzImJwfBj9QHalWzApFNq831C8JGVg0=; b=YJr9swFhiaNhCGQyBiMjesFnY5MiXeiMPC6REb9yAgXf5Gy1B6TXFxN9TVxdpQ9t jjZP4DqTqaL5K/cyt1gcXig7O3UdDEoVRWp97klCVA2GgBl+wgOE2rihhq1AvMdIUu9 Z4fgTabbQhbqbiYafakFwJn6PIiBuGST6AutIwzg= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1522803508321165.23286416457688; Tue, 3 Apr 2018 17:58:28 -0700 (PDT) Date: Wed, 04 Apr 2018 01:58:28 +0100 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <1628e298460.cd82970b35329.4945272877112645380@ovsienko.info> In-Reply-To: <87fu4huzgj.wl-jch@irif.fr> References: <87fu4huzgj.wl-jch@irif.fr> 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] 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, 04 Apr 2018 00:58:37 -0000 ---- On Fri, 30 Mar 2018 20:37:32 +0100 Juliusz Chroboczek wro= te ----=20 > Dear all,=20 > =20 > The following is a summary of discussions that I've had with David=20 > Schinazi, Clara D=C3=B4, and Weronika Ko=C5=82odziejak. I'm no longer s= ure who made=20 > which comment, so I'll just summarise the discussion.=20 > =20 > 1. We still don't have a clear and concise description of the attack=20 > against 7298. That would be helpful, especially if we are meant to work= =20 > together.=20 Let me remind, the most illustrated description so far is in the IETF 97 wo= rking group meeting materials. > 2. The procedure that consists in putting the source IP into the HMAC=20 > field before hashing is bizarre. A more straightforward solution would = be=20 > to prepend the source IP to the whole Babel packet, similarly to the TCP= =20 > pseudo-header. Note that this does not break the ability to have multip= le=20 > HMACs.=20 Yes, fine. > 3. I think it is necessary to protect the destination IP in addition to= =20 > the source IP. This prevents some pretty obvious attacks against IHU, A= ck=20 > and Unicast Hello TLVs, and might in the future prevent attacks against= =20 > extensions.=20 Yes, fine. > 4. For clarity, the TC/PC sub-TLV should be renamed to TC/PC Echo.=20 Clarity is important. Could also be "My TS/PC" for the TLV and "Your TS/PC"= for the sub-TLV if that reads better. > 5. It's not clear to me what happens when a diskless clock-less node=20 > reboots and loses its sequence number. I'm sure it's described somewher= e=20 > in the document, please point me at the right place.=20 Section 5.1 describes it, you are referring to item (a), which is the worst= implementation case. The 2nd paragraph of Section 3.7 clarifies the conseq= uences. (All references for the -00 revision of the 7298bis I-D.) > 6. I'm not sure that the IHU TLV is the right place to put the TC/PC=20 > echo -- what about putting it in a sub-TLV of TC/PC itself?=20 IHU is the right place as it means: "I have heard you, X, and _your_ last v= alid TS/PC from my point of view was Y". Y is specific to X, and a Babel pa= cket can contain IHUs for more than one X. > 7. What's the fragmentation procedure when the whole set of TC/PC echos= =20 > exceeds the size of a packet?=20 As far as I understand it, the behaviour should be the same as it is withou= t the security mechanism, except the additional margin discussed in Section= 6.2 (which now has to upgrade the formula to account for the new sub-TLV).= Does this look right? --=20 Denis Ovsienko From nobody Wed Apr 4 13:21: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 1A70A12E046 for ; Wed, 4 Apr 2018 13:21:05 -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 w8UO__sry2tL for ; Wed, 4 Apr 2018 13:21:03 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE49112E03D for ; Wed, 4 Apr 2018 13:20: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 w34KKuYL027517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Apr 2018 22:20:56 +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 w34KKvwO019067; Wed, 4 Apr 2018 22:20:57 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 57AADEB276; Wed, 4 Apr 2018 22:20:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id QWwtUnc37R6K; Wed, 4 Apr 2018 22:20:53 +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 D9DE8EB275; Wed, 4 Apr 2018 22:20:53 +0200 (CEST) Date: Wed, 04 Apr 2018 22:20:53 +0200 Message-ID: <87muyi3eqi.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko Cc: "Babel at IETF" In-Reply-To: <1628e298460.cd82970b35329.4945272877112645380@ovsienko.info> References: <87fu4huzgj.wl-jch@irif.fr> <1628e298460.cd82970b35329.4945272877112645380@ovsienko.info> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 04 Apr 2018 22:20:56 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 04 Apr 2018 22:20:57 +0200 (CEST) X-Miltered: at korolev with ID 5AC533A8.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5AC533A9.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5AC533A8.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5AC533A9.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 : 5AC533A8.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5AC533A9.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, 04 Apr 2018 20:21:05 -0000 >> 1. We still don't have a clear and concise description of the attack >> against 7298. That would be helpful, especially if we are meant to work >> together. > Let me remind, the most illustrated description so far is in the IETF 97 > working group meeting materials. Denis, we'd really need something concise. Do you think you could write it up in one page (60 lines)? >> 7. What's the fragmentation procedure when the whole set of TC/PC echos >> exceeds the size of a packet? > As far as I understand it, the behaviour should be the same as it is > without the security mechanism, except the additional margin discussed > in Section 6.2 (which now has to upgrade the formula to account for the > new sub-TLV). Does this look right? 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? -- Juliusz From nobody Thu Apr 5 06:37: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 367F01275FD for ; Thu, 5 Apr 2018 06:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 8EOo5-ESJh4L for ; Thu, 5 Apr 2018 06:37:21 -0700 (PDT) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF003127444 for ; Thu, 5 Apr 2018 06:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1522935439; 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=1584; bh=I9hxJEn3wiHyHssWkarEi1r/3xiPi/e1bNQDw9mUU08=; b=C5a2S5nBvTn2QkgCcnRiIFhx+qBrSklkLR0IZVe9iT0Yp14LVX8oE+stoI5NMXYT JmIMmJJbXX+6JTtMu7JhVPJ/RX/uGpwlM9CUaoW4q4Z6gxPWpncHNkOfhlQqoqncUnp V5C0kJRQIQMgWtg55GwkIL0xeWc5/l8izyPDtOb4= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1522935439341893.3966832909998; Thu, 5 Apr 2018 06:37:19 -0700 (PDT) Date: Thu, 05 Apr 2018 14:37:19 +0100 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <16296069fec.e13616a29759.8282754479379679955@ovsienko.info> In-Reply-To: <87muyi3eqi.wl-jch@irif.fr> References: <87fu4huzgj.wl-jch@irif.fr> <1628e298460.cd82970b35329.4945272877112645380@ovsienko.info> <87muyi3eqi.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, 05 Apr 2018 13:37:23 -0000 ---- On Wed, 04 Apr 2018 21:20:53 +0100 Juliusz Chroboczek wrote ---- >>> 1. We still don't have a clear and concise description of the attack >>> against 7298. That would be helpful, especially if we are meant to work >>> together. > >> Let me remind, the most illustrated description so far is in the IETF 97 >> working group meeting materials. > >Denis, we'd really need something concise. Do you think you could write >it up in one page (60 lines)? The matter is, you have already seen a few versions of the problem statement, of assorted brevity. That did not work and I would like to understand why. Which ones have you read and tried to understand? What specifically did you understand? What specifically you did not understand and why? >>> 7. What's the fragmentation procedure when the whole set of TC/PC echos >>> exceeds the size of a packet? > >> As far as I understand it, the behaviour should be the same as it is >> without the security mechanism, except the additional margin discussed >> in Section 6.2 (which now has to upgrade the formula to account for the >> new sub-TLV). Does this look right? > >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. The existence and handling of the threshold are not specific to 7298bis, which only amends its exact value. And the term is "TS/PC". -- Denis Ovsienko From nobody Thu Apr 5 08:31: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 5E3B912D7F5 for ; Thu, 5 Apr 2018 08:31:05 -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 Ku49IiM-YkRG for ; Thu, 5 Apr 2018 08:30:58 -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 193F012D574 for ; Thu, 5 Apr 2018 08:30:57 -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 w35FUu1V005288; Thu, 5 Apr 2018 17:30:56 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5D3E0EB5CC; Thu, 5 Apr 2018 17:30:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id KleMiKZhCZhZ; Thu, 5 Apr 2018 17:30:55 +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 84CACEB5C9; Thu, 5 Apr 2018 17:30:55 +0200 (CEST) Date: Thu, 05 Apr 2018 17:30:55 +0200 Message-ID: <878ta1y8k0.wl-jch@irif.fr> From: Juliusz Chroboczek To: Denis Ovsienko Cc: "Babel at IETF" In-Reply-To: <16296069fec.e13616a29759.8282754479379679955@ovsienko.info> References: <87fu4huzgj.wl-jch@irif.fr> <1628e298460.cd82970b35329.4945272877112645380@ovsienko.info> <87muyi3eqi.wl-jch@irif.fr> <16296069fec.e13616a29759.8282754479379679955@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, 05 Apr 2018 17:30:56 +0200 (CEST) X-Miltered: at korolev with ID 5AC64130.005 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5AC64130.005 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5AC64130.005 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] 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, 05 Apr 2018 15:31:05 -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? -- Juliusz From nobody Thu Apr 5 08: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 25EFD12D872 for ; Thu, 5 Apr 2018 08:38:38 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyDJ6nXscjv8 for ; Thu, 5 Apr 2018 08:38:36 -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 B6015126CBF for ; Thu, 5 Apr 2018 08:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1522942716; x=2386856316; 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=/pL+jXlrui08LBUsLG1uruYLAiG26P8aDKHutNGokfU=; b=x+GJvPa3EJ8rV3tTbtavRw2Q4dzsLnvFtwCFRdMedtri/wF2xE5C5i4XCUU6xThJ Bgtu8xG0nwJ4G2SJl0rrRdJjrEb8pyAC0os9MfAx3i72jwXcOkhG8rzVdc3Mze5X IcgURQvsewXhX8qzJft3D+qzOUlS3a6MvJBVm9SvESRlx+jhL5uEOvsASFjOECaN NLKJldlUAZqJd0B23VGtKSOMif91q9V5Bfmlhqa0t4/Cjqr8s4h1uL36Henk8ghm 6YOOaDDYtB+F4AJ/EA85ZoL/JTm8zVYJAIbWm/Sbp4oRDiE9KcAt2NWIkCt241PW zJ6/AcuET9qS6thWwavYag==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in23.apple.com (Apple Secure Mail Relay) with SMTP id CB.A4.16187.BF246CA5; Thu, 5 Apr 2018 08:38:36 -0700 (PDT) X-AuditID: 11ab0217-fe1ff70000003f3b-4d-5ac642fb7edc Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 4F.61.23499.BF246CA5; Thu, 5 Apr 2018 08:38:35 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.234.98.44] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P6P00AOJY3UJZ60@nwk-mmpp-sz10.apple.com>; Thu, 05 Apr 2018 08:38:35 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi X-Priority: Medium In-reply-to: <16296069fec.e13616a29759.8282754479379679955@ovsienko.info> Date: Thu, 05 Apr 2018 08:38:18 -0700 Cc: Babel at IETF Message-id: References: <87fu4huzgj.wl-jch@irif.fr> <1628e298460.cd82970b35329.4945272877112645380@ovsienko.info> <87muyi3eqi.wl-jch@irif.fr> <16296069fec.e13616a29759.8282754479379679955@ovsienko.info> To: Denis Ovsienko X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUi2FAYofvH6ViUwdIrTBZbFnWzWMy59Z3F gcljyZKfTB4rTm5kC2CK4rJJSc3JLEst0rdL4Mp4Mdep4Bh7xcLXPxgbGP+ydjFyckgImEi8 6/oGZHNxCAmsYZJYN/cDG0xiztwJLBCJDUwS508tZQJJ8AoISvyYfA8owcHBLCAvcfC8LEiY WUBL4vujVqj6L4wS7QfWMYIkhAWkJbou3GWFsPUk3m49zAzSywbUcGCNEcQuIYktO+YygoQ5 BTwlTj03AwmzCKhKbHz2gRVivJLE6m93mCEusJFo+T8LatURRok9N3aD3SwioCHxZcs8ZoiZ ShLTv99mAymSEOhhk5j37QXrBEaRWUhemIXwwiwkLyxgZF7FKJybmJmjm5lnZKyXWFCQk6qX nJ+7iREU8KuZxHcwfn5teIhRgINRiYe34++RKCHWxLLiytxDjNIcLErivNeeN0YJCaQnlqRm p6YWpBbFF5XmpBYfYmTi4JRqYJyTH3KZ16ojRjIvZo3I3JT5ho/vqZ9Q+D1rSviKtL+T2+fI yildMhTcNflAtunjh6sK4w/k8zTb8/l88WqcrPNTT+T+DLZNCx+Vlc0458J7/4Tqh25Bb4u/ jq++zAzelJe4i1e+4/sfo74Gvw8vIrrF/F6dz1JR8AjebClWsdPl66Y1avb3tyixFGckGmox FxUnAgDzw0gcWQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUi2FBcpfvb6ViUwb59PBZbFnWzWMy59Z3F gcljyZKfTB4rTm5kC2CK4rJJSc3JLEst0rdL4Mp4Mdep4Bh7xcLXPxgbGP+ydjFyckgImEjM mTuBpYuRi0NIYAOTxPlTS5lAErwCghI/Jt8DSnBwMAvISxw8LwsSZhbQkvj+qBWq/gujRPuB dYwgCWEBaYmuC3dZIWw9ibdbDzOD9LIBNRxYYwSxS0hiy465jCBhTgFPiVPPzUDCLAKqEhuf fWCFGK8ksfrbHWaIC2wkWv7Pglp1hFFiz43dbCAJEQENiS9b5jFDzFSSmP79NtsERsFZSK6e hXD1LCRXL2BkXsUoUJSak1hpqpdYUJCTqpecn7uJERyehRE7GP8vszrEKMDBqMTD2/DtSJQQ a2JZcWXuIUYJDmYlEd4IrWNRQrwpiZVVqUX58UWlOanFhxilOViUxHlnrT4aJSSQnliSmp2a WpBaBJNl4uCUamCsDLJK7sgIP32HsSep8qX8x+xdXTv4+R/xJa9a8uH5zbIDYr9q8v5c4f53 UkBD+XrEpJOfP54R5N71btGklBenP2RvDVK5s9Jw1q3UWU8row61/ngWL8Wx8wkvU9nZa1NN 1ZQYdz6pn7F0z4//vxZbTDohV8m0b2uXR9qn6qMl23LElk+/MTPfWImlOCPRUIu5qDgRAOV+ U7pLAgAA 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, 05 Apr 2018 15:38:38 -0000 > On Apr 5, 2018, at 06:37, Denis Ovsienko wrote: > > ---- On Wed, 04 Apr 2018 21:20:53 +0100 Juliusz Chroboczek wrote ---- >> >> Denis, we'd really need something concise. Do you think you could write >> it up in one page (60 lines)? > > The matter is, you have already seen a few versions of the problem statement, of assorted brevity. That did not work and I would like to understand why. Which ones have you read and tried to understand? What specifically did you understand? What specifically you did not understand and why? Hi Denis, I was trying to refresh my memory on this attack and was not able to find a concise description. I have read everything I could find on the topic and I have understood everything I read, but having a short summary would be very helpful to the community. Maybe that already exists and I have just failed to find it, in which case could you point me to it please? Thanks, David From nobody Thu Apr 5 10:43:45 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 4681E12DDD2; Thu, 5 Apr 2018 10:43:43 -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.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152295022323.25892.6195454881367215295@ietfa.amsl.com> Date: Thu, 05 Apr 2018 10:43:43 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-applicability-02.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: Thu, 05 Apr 2018 17:43:43 -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 : Applicability of the Babel routing protocol Author : Juliusz Chroboczek Filename : draft-ietf-babel-applicability-02.txt Pages : 9 Date : 2018-04-05 Abstract: Where we argue that although OSPF and IS-IS are fine protocols, there exists a space where the Babel routing protocol (RFC 6126bis) can be useful. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-applicability/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-applicability-02 https://datatracker.ietf.org/doc/html/draft-ietf-babel-applicability-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-applicability-02 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 Thu Apr 5 10:46: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 AD24A12DB72 for ; Thu, 5 Apr 2018 10:46:19 -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 QWh-AwK9c9Jd for ; Thu, 5 Apr 2018 10:46: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 F0547129C5D for ; Thu, 5 Apr 2018 10:46:17 -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 w35HkG32021339 for ; Thu, 5 Apr 2018 19:46: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 5C3C8EB35E for ; Thu, 5 Apr 2018 19:46: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 J8DjPqX6rQKY for ; Thu, 5 Apr 2018 19:46: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 7CDA6EB33C for ; Thu, 5 Apr 2018 19:46:15 +0200 (CEST) Date: Thu, 05 Apr 2018 19:46:15 +0200 Message-ID: <87zi2hwnq0.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org In-Reply-To: <152295022323.25892.6195454881367215295@ietfa.amsl.com> References: <152295022323.25892.6195454881367215295@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 05 Apr 2018 19:46:16 +0200 (CEST) X-Miltered: at korolev with ID 5AC660E8.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5AC660E8.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 : 5AC660E8.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-applicability-02.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: Thu, 05 Apr 2018 17:46:20 -0000 > Filename : draft-ietf-babel-applicability-02.txt Expanded the introduction (it's now four pages long, half the document), removed Section 3 (now redundant). It's been barely read, I'll sleep over it then work on -03. Please read it in your copious free time, and let me know if the tone is right, and whether I forgot anything. -- Juliusz From nobody Thu Apr 5 16:00:27 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 BEB251267BB; Thu, 5 Apr 2018 16:00:20 -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.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152296922074.3735.16897081899496814064@ietfa.amsl.com> Date: Thu, 05 Apr 2018 16:00:20 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-information-model-02.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: Thu, 05 Apr 2018 23:00:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : Babel Information Model Author : Barbara Stark Filename : draft-ietf-babel-information-model-02.txt Pages : 16 Date : 2018-04-05 Abstract: This Babel Information Model can be used to create data models under various data modeling regimes (e.g., YANG). It allows a Babel implementation (via a management protocol such as netconf) to report on its current state and may allow some limited configuration of protocol constants. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-information-model-02 https://datatracker.ietf.org/doc/html/draft-ietf-babel-information-model-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-information-model-02 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 Thu Apr 5 16:05: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 627E212706D for ; Thu, 5 Apr 2018 16:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLXxMXQn7487 for ; Thu, 5 Apr 2018 16:05:28 -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 29B011267BB for ; Thu, 5 Apr 2018 16:05:28 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w35MjVc5037031 for ; Thu, 5 Apr 2018 19:05:27 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 2h5ucpj4b0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 05 Apr 2018 19:05:27 -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 w35N5Pxq005621 for ; Thu, 5 Apr 2018 19:05:26 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w35N5LAW005423 for ; Thu, 5 Apr 2018 19:05:21 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 0D05640002AA for ; Thu, 5 Apr 2018 23:05:21 +0000 (GMT) Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (unknown [130.8.218.153]) by zlp30487.vci.att.com (Service) with ESMTPS id ECD5D40002C0 for ; Thu, 5 Apr 2018 23:05:20 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.71]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0361.001; Thu, 5 Apr 2018 19:05:20 -0400 From: "STARK, BARBARA H" To: "babel@ietf.org" Thread-Topic: [babel] I-D Action: draft-ietf-babel-information-model-02.txt Thread-Index: AQHTzTHqUGLPde4vy02uVWpeD+EO3qPyyfng Date: Thu, 5 Apr 2018 23:05:19 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DD686A8@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <152296922074.3735.16897081899496814064@ietfa.amsl.com> In-Reply-To: <152296922074.3735.16897081899496814064@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.141.136] 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.10432:, , definitions=2018-04-05_11:, , 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=451 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050230 Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-02.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.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, 05 Apr 2018 23:05:29 -0000 I think this information model is ready to be reviewed by Those Who Volunte= ered. I have quite a collection of items to think about at the end of the d= raft. Barbara > -----Original Message----- > Subject: [babel] I-D Action: draft-ietf-babel-information-model-02.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Babel routing protocol WG of the IETF. >=20 > Title : Babel Information Model > Author : Barbara Stark > Filename : draft-ietf-babel-information-model-02.txt > Pages : 16 > Date : 2018-04-05 >=20 > Abstract: > This Babel Information Model can be used to create data models under > various data modeling regimes (e.g., YANG). It allows a Babel > implementation (via a management protocol such as netconf) to report > on its current state and may allow some limited configuration of > protocol constants. From nobody Thu Apr 5 17:23: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 C64F912E055 for ; Thu, 5 Apr 2018 17:23: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 iZHZO3Y_c8_q for ; Thu, 5 Apr 2018 17:23:30 -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 B952112E04B for ; Thu, 5 Apr 2018 17:23:29 -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 w360NQDk031692; Fri, 6 Apr 2018 02:23:26 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C6F78EB275; Fri, 6 Apr 2018 02:23:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id ALx7rqxRugtN; Fri, 6 Apr 2018 02:23:24 +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 6C456EB274; Fri, 6 Apr 2018 02:23:22 +0200 (CEST) Date: Fri, 06 Apr 2018 02:23:22 +0200 Message-ID: <87zi2huqrp.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "babel@ietf.org" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DD686A8@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <152296922074.3735.16897081899496814064@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114DD686A8@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 06 Apr 2018 02:23:26 +0200 (CEST) X-Miltered: at korolev with ID 5AC6BDFE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5AC6BDFE.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 : 5AC6BDFE.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-02.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.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, 06 Apr 2018 00:23:35 -0000 Thanks, Barbara. I haven't checked the security bits, but the rest looks fine to me. A few minor nits. Due to the simplicity of the Babel protocol and the fact that it is designed to be used in non-professionally administered environments (such as home networks) Please don't say that -- Babel is a general-purpose routing protocol that is designed to survive where other protocols die. In particular, it can survive in the hostile Home Network environment, but I'd like to avoid restricting it to that case. I suggest removing the bit from "and the fact" up to the closing paranthesis. babel-supported-link-types: set of values of supported link types where the following enumeration values MUST be supported: 1 = wireless, 2 = physical-layer ethernet, 99 = other I'd prefer this to be a list of strings, with possible values "wired", "wireless", "tunnel" and "other". > 3.2. Definition of babel-constants-obj I don't see a way to find out if this Babel instance is speaking IPv6, IPv4, or both. (Toke suggested we dump the IPv4 support, I'm half inclined to agree.) > 3.3. Definition of babel-interfaces-obj babel-link-type: indicates the type of link; integer values Same as above -- I'd prefer this to be a string. babel-external-cost: external input to cost of link of this interface (need to determine how to express this);MUST be configurable if implemented I suggest "if supported, this is a value that is added to the metrics of routes learned over this interface". There's a space missing after the semicolon. babel-neighbors: a set of babel-neighbors objects There's a "u" missing ;-) > 3.4. Definition of babel-neighbors-obj babel-hello-mcast-history: the multicast Hello history of whether or not each of the 16 multicast Hello messages prior to babel- hello-seqno was received; represented as a 16 bit (4 hex digits) value where 1 = Hello received and 0 = Hello not received; see draft-ietf-babel-rfc6126bis [rfc6126bis] section A.1 You need to specify the endiannness of this bitstring. The reference implementation puts the most recent bits at the big-endian end, and shifts right. On a related note, shouldn't this be a bit string of an implementation-defined length? babel-hello-seqno: expected Hello sequence number This needs to be split into "babel-expected-ucast-hello-seqno" and "babel-expected-mcast-hello-seqno". > 3.6. Definition of babel-routes-obj I think there's a field missing -- the interface over which this route has been learned. Alternatively, you could put a reference to the neighbour from which this route has been learned. babel-route-next-hop: the next-hop address of this route; this will be empty if this route has no next-hop address I suggest "if this is empty, the next hop is the address of the neighbour from which the route has been learnt." babel-route-metric: the metric with which this route was advertised by the neighbor, or maximum value (infinity) to [...] babel-route-announced-metric: a calculated metric for this route; how the metric is calculated is implementation-specific; either Have you inverted the two? Please add "if this is the value 65535, then this route has been retracted and is temporarily unreachable (see Section 3.5.5 of [RFC6126bis])". babel-route-feasible: a boolean flag indicating whether this route is known to work; a route that is not feasible will never be selected A boolean flag indicating whether this route is feasible, as defined in Section 3.5.1 of [RFC6126bis]. 5. Do we need a registry for the supported security mechanisms? No. -- Juliusz From nobody Sat Apr 7 07:57:28 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 D7123124217; Sat, 7 Apr 2018 07:57:20 -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.77.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152311304083.29986.295214642269872621@ietfa.amsl.com> Date: Sat, 07 Apr 2018 07:57:20 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-applicability-03.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: Sat, 07 Apr 2018 14:57:21 -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 : Applicability of the Babel routing protocol Author : Juliusz Chroboczek Filename : draft-ietf-babel-applicability-03.txt Pages : 10 Date : 2018-04-07 Abstract: Where we argue that, although OSPF and IS-IS are fine protocols, there exists a space where the Babel routing protocol (RFC 6126bis) is useful. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-applicability/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-applicability-03 https://datatracker.ietf.org/doc/html/draft-ietf-babel-applicability-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-applicability-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Apr 7 11:47:26 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A69124D37 for ; Sat, 7 Apr 2018 11:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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=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 bV4BJSkUh6R8 for ; Sat, 7 Apr 2018 11:47:23 -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 0C7161200C5 for ; Sat, 7 Apr 2018 11:47:22 -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=1523126840; bh=MY+xSt6FvOJkhXUlhBVOu17jnzVIGFnEpeFWCESiUDU=; h=From:To:Subject:In-Reply-To:References:Date:From; b=xlFG6vGHHXcfhvQaKY8IB8L2hH8L/K9dYW/Z6VDtV2AdaSZzWWKjYOOGKcSluREyr ezLmgTZqZ7af74g03x7PV+psZbz7KDGtiqgBLXy1C+EoHmvQsztRrdOkdxKfOOIr1F xL0Jljxhw8eLS18qzOeMwGOXIeeZ6aA1c2DWDwuxX1BqWoH2C/Ihv+fvEpQrGhBvMb kzgNGZeG8kbEdujCwMEIu4o6H/r1en+Q/Q3f1i/8UK9bK+xvQuaMmsJy7c8OVLuphG +7XqGxHBzq6G06hIeXbh7oUYT3rRvMXBJgBXSIMAMiY00k9br7VoOlCI3uF11xK7Y0 5z0svywdLoBJw== To: "STARK\, BARBARA H" , "babel\@ietf.org" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DD686A8@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <152296922074.3735.16897081899496814064@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114DD686A8@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Sat, 07 Apr 2018 20:47:18 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87y3hyam6h.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-02.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.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, 07 Apr 2018 18:47:25 -0000 "STARK, BARBARA H" writes: > I think this information model is ready to be reviewed by Those Who > Volunteered. I have quite a collection of items to think about at the > end of the draft. Generally looks good! A few comments: > babel-ucast-hello-interval: the current unicast hello interval in > use for this interface Shouldn't this be per-neighbour? > babel-message-log: log entries that have timestamp of a received > Babel message and the entire received Babel message, including > Ethernet frame and IP headers; an implementation must restrict the > size of this log, but how and what size is implementation-specific A userspace implementation doesn't necessarily have access to the Ethernet and IP headers. > babel-neighbor-ihu-interval: current IHU interval for this > neighbor The IHU interval (i.e. the value put into an IHU TLV) is not necessarily available; it is perfectly sensible to just store the expiry time. > babel-security-supported: list of supported security mechanisms So every security object contains the entire list of supported security mechanisms? Until this point I was under the impression that the logic was one security object per mechanism... > 1. babel-interfaces-obj: Juliusz:"This needs further discussion, I > fear some of these are implementation details." [In the absence > of discussion, the current model stands. Note that all but > link-type and the neighbors sub-object are optional; if an > implementation does not have any of the optional elements then > it simply doesn't have them and that's fine.] The information currently in the draft (apart from the message log), I also added as debug output in Bird, so I think it makes sense to include it. I also output current v4/v6 nexthop addresses used for routes announced over each interface; may be useful to include, since the mapping from addresses assigned to the interface is not always obvious, so may be useful to see what a particular implementation picked? -Toke From nobody Tue Apr 10 07:25:34 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D36512D7EA; Tue, 10 Apr 2018 07:25:33 -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 HkYKdTLGGf-b; Tue, 10 Apr 2018 07:25:31 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A7C12D864; Tue, 10 Apr 2018 07:25:25 -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 w3AEPNGm004149; Tue, 10 Apr 2018 16:25:23 +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 2A3B5EB275; Tue, 10 Apr 2018 16:25: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 2eYpQiwlnjYO; Tue, 10 Apr 2018 16:25:22 +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 5623BEB273; Tue, 10 Apr 2018 16:25:19 +0200 (CEST) Date: Tue, 10 Apr 2018 16:25:19 +0200 Message-ID: <87zi2bjfzk.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org CC: babel-chairs@ietf.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 10 Apr 2018 16:25:23 +0200 (CEST) X-Miltered: at korolev with ID 5ACCC953.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5ACCC953.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 : 5ACCC953.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] Please last call 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: Tue, 10 Apr 2018 14:25:33 -0000 Dear all, I hereby most humbly request Last Call for draft-ietf-babel-applicability. -- Juliusz From nobody Tue Apr 10 16:04:19 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6251712D7F7 for ; Tue, 10 Apr 2018 16:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwf6YTqL0v7l for ; Tue, 10 Apr 2018 16:04:16 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (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 7BC901201F2 for ; Tue, 10 Apr 2018 16:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1523401456; x=2387315056; 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=6p1tou6Is1MgVzk7m5cYIOFh+ArNTcsaOekHo8kBoF0=; b=dIc+cM7IaQYSAdGns0uLQx960mN8xlCgIFkZPegcGwInRkHGIHdME6TTuv4JdoLT ImeN+3LHOH0hAwc45ovno1FfMhJOSKO498F/lKFTHXe6mFPWrbZHy2ZpOQzG6RUg icCAES7OQPLiOGQAbRQfA7cFkR3OxZ+UOvqx3JArzCrG+E4Q3z9DyhLMrhaHh9+5 SKZfZPq4JmuxSrowT4smgrJujY1IsWHDRjM9DNfQNBB7fQBD+JngmM7quyw0PHIG PvzRHuzP0XVP4MMgz20IwC+EhcPnebuXAH7q+YX6Ah2zPVdxf3EstwtuUClu/ttH 8DeabPOjKfQ5JGi3xeMpOg==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 04.A8.28259.0F24DCA5; Tue, 10 Apr 2018 16:04:16 -0700 (PDT) X-AuditID: 11973e15-f06549e000006e63-99-5acd42f0e669 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 1F.D7.23861.0F24DCA5; Tue, 10 Apr 2018 16:04:16 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.234.29.161] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P6Z00CJ1S339A40@nwk-mmpp-sz09.apple.com>; Tue, 10 Apr 2018 16:04:15 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87y3hyam6h.fsf@toke.dk> Date: Tue, 10 Apr 2018 16:04:15 -0700 Cc: "STARK, BARBARA H" , "babel@ietf.org" Content-transfer-encoding: quoted-printable Message-id: References: <152296922074.3735.16897081899496814064@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114DD686A8@GAALPA1MSGUSRBF.ITServices.sbc.com> <87y3hyam6h.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+NgFjrELMWRmVeSWpSXmKPExsUi2FAYpfvB6WyUwfZHXBZbFnWzWEz6+5PR Yuv7FewOzB4v++cweixZ8pPJY8uhi2wBzFFcNimpOZllqUX6dglcGfc+nmYv+CZW0TJrNXsD 41ShLkZODgkBE4nOh22MILaQwGomidd/amHi7x9/goqvZ5K42sIMYvMKCEr8mHyPpYuRg4NZ QF1iypTcLkYuoJKvjBLzjn1iB6kRFpCW6LpwlxXC9pJ49mYSK0g9m4CWxIE1RiBhTgFViWfL eplAbBYge9HuHrDxzEDlh1dsZoewtSWevLvACrHWRuLytB42iHPWMUoc/6UFYosI2Es0fr3A AnGyksT077fZQO6REJjAJtH4ZhLTBEbhWUjOnoVw9iwkKxYwMq9iFMpNzMzRzcwz00ssKMhJ 1UvOz93ECAr06XaiOxjPrLI6xCjAwajEw3vh1pkoIdbEsuLK3EOM0hwsSuK8R5lPRAkJpCeW pGanphakFsUXleakFh9iZOLglGpgFH7yb1bBbI0z5n/6D64SO6Cb4Bn0yk4l4rhZ3dn1wl9f pLBV9h1aHBVU0DRTK6FSK0H6p9JNaV3T2T8ndR2M9978+LLH4Y3tXvfbRdPvsN0JzpdbYhPc tk6932/6mdSb194/fp2uY/v76dd1mge3OVenXJ8wUXjjmcwjh2zsmRUqSvQEL1fqKrEUZyQa ajEXFScCANqT8AVVAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUi2FAcoPvB6WyUwe69HBZbFnWzWEz6+5PR Yuv7FewOzB4v++cweixZ8pPJY8uhi2wBzFFcNimpOZllqUX6dglcGfc+nmYv+CZW0TJrNXsD 41ShLkZODgkBE4n3jz8xgthCAuuZJK62MIPYvAKCEj8m32PpYuTgYBZQl5gyJbeLkQuo5Cuj xLxjn9hBaoQFpCW6LtxlhbC9JJ69mcQKUs8moCVxYI0RSJhTQFXi2bJeJhCbBchetLsHbDwz UPnhFZvZIWxtiSfvLrBCrLWRuDythw3inHWMEsd/aYHYIgL2Eo1fL7BAnKwkMf37bbYJjAKz kFw6C+HSWUimLmBkXsUoUJSak1hpppdYUJCTqpecn7uJERyahVE7GBuWWx1iFOBgVOLhvXDr TJQQa2JZcWXuIUYJDmYlEd5eprNRQrwpiZVVqUX58UWlOanFhxilOViUxHlnrj4aJSSQnliS mp2aWpBaBJNl4uCUamD0ZuHj35rvW2DQ57V6Tss8DTPRu1pTLGU2/zijwjjRKqRzi+6z0xWZ 8i1mJ7OyLKdZ7LjQ4HOe7egj7e3eIWcbXmr+P5MgF+OulyZvcXKxtqvNjXKzJ6LZXQ82PXH/ INBa+2K2ytfCV5F8conW1rzuqiKz29ZN6cl7ctsp92HI2iP5d9f1PVBiKc5INNRiLipOBACU 2aQNSQIAAA== Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-02.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.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, 10 Apr 2018 23:04:18 -0000 Thanks for writing this, Barbara! I read -02, and it looks good to me, it reads well. Also I agree with = Juliusz's and Toke's comments. Two minor comments: 1) babel-hello-[mu]cast-history is an implementation detail documented = in an appendix, should it be exposed? Isn't rxcost/txcost/cost sufficient? 2) Regarding security, should it be possible to pull the private key = from a router? Is that common practice? Thanks, David > On Apr 7, 2018, at 11:47, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > "STARK, BARBARA H" writes: >=20 >> I think this information model is ready to be reviewed by Those Who >> Volunteered. I have quite a collection of items to think about at the >> end of the draft. >=20 > Generally looks good! A few comments: >=20 >> babel-ucast-hello-interval: the current unicast hello interval in >> use for this interface >=20 > Shouldn't this be per-neighbour? >=20 >> babel-message-log: log entries that have timestamp of a received >> Babel message and the entire received Babel message, including >> Ethernet frame and IP headers; an implementation must restrict = the >> size of this log, but how and what size is = implementation-specific >=20 > A userspace implementation doesn't necessarily have access to the > Ethernet and IP headers. >=20 >> babel-neighbor-ihu-interval: current IHU interval for this >> neighbor >=20 > The IHU interval (i.e. the value put into an IHU TLV) is not = necessarily > available; it is perfectly sensible to just store the expiry time. >=20 >> babel-security-supported: list of supported security mechanisms >=20 > So every security object contains the entire list of supported = security > mechanisms? Until this point I was under the impression that the logic > was one security object per mechanism... >=20 >> 1. babel-interfaces-obj: Juliusz:"This needs further discussion, = I >> fear some of these are implementation details." [In the = absence >> of discussion, the current model stands. Note that all but >> link-type and the neighbors sub-object are optional; if an >> implementation does not have any of the optional elements then >> it simply doesn't have them and that's fine.] >=20 > The information currently in the draft (apart from the message log), I > also added as debug output in Bird, so I think it makes sense to = include > it. I also output current v4/v6 nexthop addresses used for routes > announced over each interface; may be useful to include, since the > mapping from addresses assigned to the interface is not always = obvious, > so may be useful to see what a particular implementation picked? >=20 > -Toke >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Tue Apr 10 17:12: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 3E66712D959 for ; Tue, 10 Apr 2018 17:12:02 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAveh5G7D3Wo for ; Tue, 10 Apr 2018 17:12:00 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E988112D944 for ; Tue, 10 Apr 2018 17:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1523405519; x=2387319119; 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=mzzGO2QQyFID1Z/Wg2GbUJ/m31IVrYuKGvq2mNadeYE=; b=sfeZp+k/kLUx2mMHOHeM4uXDjrT0ogg4tYmLsl1mcb602EERThhCeMu55IQmkwiu AnwOrfTBIbG1bPVkgM5VCai9pChC3UIjq8oga/uOn6LvUkZZ8lZ2tLLl0G/3Jo6o vnH71SS17wIWVVnop9N5bUDeAsYTirro744y/1/tdsKOSJ0Q1LXCRXCCyqqgvbs8 zwZi+RSXZoXy1FBJSFZ5g2NdRuQ+/ebKtSKIq8qgHz5C63fDuynK/WcGkcSYR1fw Yl4AWd2Ot7YEBxtPx8ys9dB1eQ53t1yB7gNgdjsP9R8DJPA5855Jz3fW2HJBySao mkGml4JipTX46fMWwoANJg==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 48.29.04908.FC25DCA5; Tue, 10 Apr 2018 17:11:59 -0700 (PDT) X-AuditID: 11973e16-446529e00000132c-5c-5acd52cf68c5 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id B4.FE.23861.FC25DCA5; Tue, 10 Apr 2018 17:11:59 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.234.29.161] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P6Z004W3V7ZSZ30@nwk-mmpp-sz09.apple.com>; Tue, 10 Apr 2018 17:11:59 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87zi2bjfzk.wl-jch@irif.fr> Date: Tue, 10 Apr 2018 17:11:58 -0700 Cc: babel@ietf.org, babel-chairs@ietf.org Message-id: References: <87zi2bjfzk.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUi2FAYpXs+6GyUwYOPRhane2+xWGxZ1M1i Mb91GZsDs8eSJT+ZPBZvecsYwBTFZZOSmpNZllqkb5fAlTGtu5W14CZzxck9p5kbGBuYuxg5 OSQETCS+L5/D1sXIxSEksJpJYt/UbiaYRNeE3WBFQgLrmSQOT5ICsXkFBCV+TL7H0sXIwcEs IC9x8LwsSJhZQEvi+6NWFojyr4wSj+f5g9jCAtISXRfuskLYLhJTr69iBGllA6o/sMYIJMwp oCFxZfkMsBIWAVWJhyc+M0OM1JR4vfMNK8RWG4n1/ZOgrlGXePLpBdiVIgIqEsunPWOHuFhJ Yvr322CvSAg0skm0vHzNPoFReBaSq2chXD0LydULGJlXMQrlJmbm6GbmmeslFhTkpOol5+du YgSF93Q7sR2MD1dZHWIU4GBU4uG9cOtMlBBrYllxZe4hRmkOFiVx3mPMJ6KEBNITS1KzU1ML Uovii0pzUosPMTJxcEo1MOqE2q5PzLO+2Rpu8ffhvh9WdSY3Z6Y+cjQJ33HL/99Jpju/P1x8 oDaLQejffFHuC8s/B+5dcfYE+7qC5j2h3AeETZb8t+KMXvmovqJobca3CaumRjF68l9x0a5e vOJ4yLL16VdmbS6ukK0rUPx4YiWX3VfHLMOnErv+qcun2wloFSl+337QVluJpTgj0VCLuag4 EQDddX6GUAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUi2FAcoHs+6GyUwfSv+hane2+xWGxZ1M1i Mb91GZsDs8eSJT+ZPBZvecsYwBTFZZOSmpNZllqkb5fAlTGtu5W14CZzxck9p5kbGBuYuxg5 OSQETCS6JuwGs4UE1jNJHJ4kBWLzCghK/Jh8j6WLkYODWUBe4uB5WZAws4CWxPdHrSwQ5V8Z JR7P8wexhQWkJbou3GWFsF0kpl5fxQjSygZUf2CNEUiYU0BD4sryGWAlLAKqEg9PfGaGGKkp 8XrnG1aIrTYS6/snQV2jLvHk0wsmEFtEQEVi+bRn7BAXK0lM/36bbQKjwCwkh85COHQWkkMX MDKvYhQoSs1JrDTTSywoyEnVS87P3cQIDsfCqB2MDcutDjEKcDAq8fBeuHUmSog1say4MvcQ owQHs5IIby/T2Sgh3pTEyqrUovz4otKc1OJDjNIcLErivDNXH40SEkhPLEnNTk0tSC2CyTJx cEo1MJqtWGJ3+aDy588TJHp+3dm9cVbfvq8/K2wS+Btm3wwr4E/aEll9z+hP0tf3k0ym5+/j CS3pzrFYezP80ls5fr6FsgoMdStzLkenz33zc/8N7w+sefsZ9fr3pvnp9cm91/gYYuCTP+nP /lweMc3woEcn2WdePfIzXubWi6+3Kucm5b++ejaw9YMSS3FGoqEWc1FxIgDTE8y3QwIAAA== Archived-At: Subject: Re: [babel] Please last call 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: Wed, 11 Apr 2018 00:12:02 -0000 I just read draft-ietf-babel-applicability-03 and I think the document is ready to move forward. I found it clear and concise. David > On Apr 10, 2018, at 07:25, Juliusz Chroboczek wrote: > > Dear all, > > I hereby most humbly request Last Call for draft-ietf-babel-applicability. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Tue Apr 10 21:06: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 AFF97127023 for ; Tue, 10 Apr 2018 21:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kapsi.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id By7gQwGzGqPI for ; Tue, 10 Apr 2018 21:06:08 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA621201F8 for ; Tue, 10 Apr 2018 21:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=zVq7uNzbMtGjhdLVWcHC+skHkx5tSHnKBttB3pE3TBI=; b=wl4K+GMW2gMzO42qC0IucKSDLywuIXXfRiHDfVc2u5CbDOdsFgOo5zYTnfxGe+aCYGTzEP6SsUJTb4c2/6jRxBA5qMRDRS8lFd+HZkLvIT9yY8umxfM/RrF/wxakLjXTTqZBJ9RE0UQ6knL+Nn1qEPo0NTL2su3G/0ut6UWRfYn9YDFYTWH90pALbxMi5PO8kqpyI+r0cod4LKxEcuwCFiJExJ78eL5bEvV9/OoV28xjTjX7QVufz7yAbtBjGqEyUv2KyISkTkqA018fsS9Gr8V22rAWyRTEqJKhyIOliWfMGiO947jI/LLhkyeCq0ZaSzOuB1k/sSZANA3hCObIXg==; Received: from 91-155-68-157.elisa-laajakaista.fi ([91.155.68.157] helo=poro.lan) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1f671A-0006dE-3n; Wed, 11 Apr 2018 07:05:56 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Markus Stenberg In-Reply-To: Date: Wed, 11 Apr 2018 07:05:55 +0300 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , BARBARA H STARK , "babel@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2524EF75-E323-4B72-A516-E671BF3A08AB@iki.fi> References: <152296922074.3735.16897081899496814064@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114DD686A8@GAALPA1MSGUSRBF.ITServices.sbc.com> <87y3hyam6h.fsf@toke.dk> To: David Schinazi X-Mailer: Apple Mail (2.3445.5.20) X-SA-Exim-Connect-IP: 91.155.68.157 X-SA-Exim-Mail-From: markus.stenberg@iki.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-02.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: Wed, 11 Apr 2018 04:06:11 -0000 On 11 Apr 2018, at 2.04, David Schinazi wrote: > 2) Regarding security, should it be possible to pull the private key = from a router? Is that common practice? No. I think what is written in the spec now is good. In general only public keys should ever go anywhere from a device. Any = scheme that involves private key distribution is quite a bit less = secure. That=E2=80=99s why e.g. certificate (=3D glorified public key) = enrollment practises involve device making requests with the public key, = and getting signed one back in return. Similarly, why HSMs and such are = all the rage (keep your private key on a box you don=E2=80=99t have even = access to the actual private key, just encryption and decryption = functions and public key). As a matter of fact, if one were to use HSM with routing protocol (not = impossible although I guess it is mostly done nowadays with = https/ipsec/ssh keys), providing private key would not be possible as = only public key (and-or certificate) would even be available. Cheers, -Markus= From nobody Wed Apr 11 05:50:55 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C31126D0C for ; Wed, 11 Apr 2018 05:50:53 -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 2gEhWcvX2oyy for ; Wed, 11 Apr 2018 05:50:51 -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 F02BB126CE8 for ; Wed, 11 Apr 2018 05:50:49 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w3BCoeip020567; Wed, 11 Apr 2018 14:50:40 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 7051DEB332; Wed, 11 Apr 2018 14:50:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 3znH_lXaw3uG; Wed, 11 Apr 2018 14:50:39 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id DEF06EB33C; Wed, 11 Apr 2018 14:50:36 +0200 (CEST) Date: Wed, 11 Apr 2018 14:50:36 +0200 Message-ID: <87in8xc3fn.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: "STARK, BARBARA H" , "babel@ietf.org" In-Reply-To: References: <152296922074.3735.16897081899496814064@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114DD686A8@GAALPA1MSGUSRBF.ITServices.sbc.com> <87y3hyam6h.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, 11 Apr 2018 14:50:41 +0200 (CEST) X-Miltered: at korolev with ID 5ACE04A0.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5ACE04A0.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 : 5ACE04A0.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] I-D Action: draft-ietf-babel-information-model-02.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: Wed, 11 Apr 2018 12:50:53 -0000 > 1) babel-hello-[mu]cast-history is an implementation detail documented > in an appendix, should it be exposed? It's a useful piece of data when debugging issues with wireless links -- it's easier to understand than the xxcost values. It's optional in Barbara's model, so implementations can ignore it if they don't use a Hello history. I argue for keeping it (as optional). -- Juliusz From nobody Wed Apr 11 06:10:15 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84931126D74; Wed, 11 Apr 2018 06:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8qzR5XTbu9h; Wed, 11 Apr 2018 06:10:11 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 31D9C126D0C; Wed, 11 Apr 2018 06:10:11 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id z73so1727236wrb.0; Wed, 11 Apr 2018 06:10:11 -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=H/ZFQKNwd3Fk7NC4a8juesFba5btKOJK9Y6wUij/4AU=; b=Km4V0N6Gl3gyc15OQYDzZ0l4C54vhDjyCemI+CZjn3pQPO9aMoMwDoxn6t1fUx1rr0 GMYP9qoK1LSFXsO0mQERyMpIKSfCIy+SNLgtqZJMOwblKokKD4vlBI+7rdJKHvIir4xX BGN561D59Tvwl9JAHi0rwbefIjoCPFppAYg8IE5k/uWvV48oIRUTjzhzJVIuG+xZq/Fk O1uHg5dRSIRYxNR+5P1F3grinAqvQ1vsmaRhKAtaA4REeb0AprsOIsW0EhZ1N+0hvjcG LuOsA/5a3nih9qeD7q2nrHm8dr9wyxzdCdGfFMjv60e9x6hKoSRh4fEjq4AIDDNVQoYp x6zQ== 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=H/ZFQKNwd3Fk7NC4a8juesFba5btKOJK9Y6wUij/4AU=; b=CfwT3USLy8Bwf8r+xmtLqVNcfKXL37AYB0wWkRlaX6umc6in60zAWms1w+aci4H+Hm i1qGs4sCLvDuYUKH9NzOCzsQt/3KaYy9aCQxMFWYAlyE3idJc07dFV39Z4jHz/VZjezl zFjQmnxrpqmY7Z/MawAb4q4CHC1sFMO7eHJyb3vFoboOP/uxuLUsQmoQu48Ci72LIuyN Oa5mZGL6cx2nVvEbCOd9vDrpih+l37elYIL/ZK1S1aXga+309QP0dsjbVhPsyPZF7002 xNcEX3oYGjyAQi2y+Xyj2ZQ7CTSises4EuI5ZTAAFocHNYDEWAZJA1wTMN7hdkCltKbS sv3g== X-Gm-Message-State: ALQs6tAKwELtsj5BbdZkbekYySVw2i+gbyDdoR/zrsxUJjluVVFSI8Vj cv/wywoI8ghWSTw4F4M++358xHSXKh3NOCOhJkJ5UQ== X-Google-Smtp-Source: AIpwx4/gX22B9zWb0k0WJGnro63I0VsgkkBOzMsGsHPm0wp9tl80lwo0GeuGif5b/pMy1jJOeK/tgt+nL3h7fIZmBRk= X-Received: by 10.223.129.17 with SMTP id 17mr3545157wrm.109.1523452209603; Wed, 11 Apr 2018 06:10:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.154.52 with HTTP; Wed, 11 Apr 2018 06:10:09 -0700 (PDT) In-Reply-To: <87zi2bjfzk.wl-jch@irif.fr> References: <87zi2bjfzk.wl-jch@irif.fr> From: tjw ietf Date: Wed, 11 Apr 2018 09:10:09 -0400 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF , babel-chairs@ietf.org Content-Type: multipart/alternative; boundary="94eb2c098db0c92afc0569925be6" Archived-At: Subject: Re: [babel] Please last call 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: Wed, 11 Apr 2018 13:10:14 -0000 --94eb2c098db0c92afc0569925be6 Content-Type: text/plain; charset="UTF-8" I went back over draft-ietf-babel-applicability-03 and it's simple and straightforward. The documentation of where it will not succeed is well stated and useful. If the chairs are doing a WGLC, count me in as a +1 Tim On Tue, Apr 10, 2018 at 10:25 AM, Juliusz Chroboczek wrote: > Dear all, > > I hereby most humbly request Last Call for draft-ietf-babel-applicability. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --94eb2c098db0c92afc0569925be6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I went back over=C2=A0draft-ietf-babel-applicability-03 an= d it's simple and straightforward.=C2=A0 The documentation of where it = will not succeed is well stated=C2=A0
and useful. =C2=A0=C2=A0

If the chairs are doing a WGLC, count me in as a +1
<= div>
Tim
=C2=A0

On Tue, Apr 10, 2018 at 10:25 AM, Juliusz= Chroboczek <jch@irif.fr> wrote:
Dear all,

I hereby most humbly request Last Call for draft-ietf-babel-applicabil= ity.

-- Juliusz

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

--94eb2c098db0c92afc0569925be6-- From nobody Wed Apr 11 06:22: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 6E379127444; Wed, 11 Apr 2018 06:22: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, 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 O0iacfeu36AW; Wed, 11 Apr 2018 06:22:50 -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 7C868127419; Wed, 11 Apr 2018 06:22:29 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1523452947; bh=kFUGmPUZHpLMWnqQ0Yt0OCMadREgnjD2sd+UydYnd1A=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Q3/dYUicyO1UtKNqXVPydmF1XLr2BeMmbPSuhFRD1aoIXV0p8fyOPWAG7DBhV7XG1 1ppMj5kRu6LGYYjdLgDGaQl1zm4JCW6+R76TKm826p91hA0acsIqOpEtd6n+cenUS+ cFuWcEx9ul+cMzC+YR1bgJ+f/BwBVLugUD2OY6o1JvbwM6l5WyRmUEc5I2yUrNFBQt QmqV1TiX4XNiQ3DO5Gg3QrJn0/CD0dYust4g6X5nCZvzxuOwR7qLMJmhz1mBYtnydk 3UtefnXb9joZX9ZBqEMuo+/x4dfiWUupnHQg1HbPXtqqpgFmWXDjp/8ZGtKaqEFyjb tnDx2fwI4+oJg== To: tjw ietf , Juliusz Chroboczek Cc: babel-chairs@ietf.org, Babel at IETF In-Reply-To: References: <87zi2bjfzk.wl-jch@irif.fr> Date: Wed, 11 Apr 2018 15:22:26 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87lgdt7u99.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Please last call 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: Wed, 11 Apr 2018 13:22:53 -0000 tjw ietf writes: > I went back over draft-ietf-babel-applicability-03 and it's simple and > straightforward. The documentation of where it will not succeed is > well stated and useful. > > If the chairs are doing a WGLC, count me in as a +1 And now I finally got around to re-reading it as well. I agree, and will add another +1 -Toke From nobody Wed Apr 11 06:42: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 2FB6E126DCA; Wed, 11 Apr 2018 06:42:19 -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 vja_GW-g72zf; Wed, 11 Apr 2018 06:42:18 -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 DDE99126D74; Wed, 11 Apr 2018 06:42:17 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id 142-v6so2748787itl.5; Wed, 11 Apr 2018 06:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZPeWR9jUye7Kp20s2MTb2jc2py1OO9MU3M7efiJWD7M=; b=lTo+HUQXgVA3GE8BAwiQBqe54WWt/bAF3jhwgeAJGs+ciUPOSYObIV+h+aqcqrCS/6 pRY4JHDQLtFlEQc3Sw7sjAgo7DVe5gl0/p7ycuUaM0FUsIQzkV9TG+/RfOXUUHdYfQQ4 Xj9m5YjFT5+yEgrTNSqAsMTuztoLLzOgHrubHnLsmIh6QqUQQcCNqlhz1cavJSHyzwhh AMDKRkwRwtutFwE7SiCDolPrKbajk5WFi3wLOTZRj/asiZ6dX5EX8hU9IqMhArzOw34/ nDMExTHE0X2tQ61Q6+HrbzcYD2NDi8f/AKACW4ubxEkySDUQUBm8Cg7PfTK9HPEKU1Si 5vyQ== 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=ZPeWR9jUye7Kp20s2MTb2jc2py1OO9MU3M7efiJWD7M=; b=j3r8noLrci2lV/gllGnaF6bx/tyZWSyrXxcFpQLUrnG4pTDbQqpMz2OduvmY2kh+bU Z5WDsq1+a9f1xVWEfr3/irTQASSmOt2jKlU+qWKsS0xJrDSwqhgn6zCB6BEenGiJwjmd w7q4i2dX6ISd5oLBd0UjB39Su9ln3p/LTDeXLMIntRdpCJOwq+/Zeo6U/COx5EoS4vIq S/3ZFjMGuLRT76hHXyKJeOVPRk8UJ56ja3fV9wZ79hklDWXvBW7kJv+h7JTYUYGFQYF6 lb1CYk4QIHH4gVYW60yorm7rEfHwnaPiUBv11mCbZFg1n6IZm/CAc9y12zyU6XAwO/IU qekg== X-Gm-Message-State: ALQs6tD/hTEmTFTnCCIRJI1zPSEKteh1SnCJ5zMwa6hrXew1mR/vmcZg V4wh4Pw4NIyv0r/5VqMV+Y9oX6zJMy26frc7JBo= X-Google-Smtp-Source: AIpwx48trsHuuY7Akiu6MyXcX6oJGH6+nmJciXZZvi4KTvEMYj4+y2JYOJN8qY7iZsWm6Y60S49CFdsUWLKfwNemvL8= X-Received: by 2002:a24:c88:: with SMTP id 130-v6mr4005371itn.14.1523454137266; Wed, 11 Apr 2018 06:42:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.90.13 with HTTP; Wed, 11 Apr 2018 06:42:01 -0700 (PDT) In-Reply-To: <87zi2bjfzk.wl-jch@irif.fr> References: <87zi2bjfzk.wl-jch@irif.fr> From: Donald Eastlake Date: Wed, 11 Apr 2018 09:42:01 -0400 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF , babel-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] Please last call 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: Wed, 11 Apr 2018 13:42:19 -0000 OK, I'll do that. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Apr 10, 2018 at 10:25 AM, Juliusz Chroboczek wrote: > Dear all, > > I hereby most humbly request Last Call for draft-ietf-babel-applicability. > > -- Juliusz From nobody Wed Apr 11 07:09: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 3CE8E127201; Wed, 11 Apr 2018 07:09:49 -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 Mg1rVqr1HtbF; Wed, 11 Apr 2018 07:09:47 -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 77E2C1201FA; Wed, 11 Apr 2018 07:09:47 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id 19-v6so2788203itw.3; Wed, 11 Apr 2018 07:09:47 -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=cFVKSv/lgF3V0H/+C7OLkmAbRhsoDIH3Y614Ay4Ps10=; b=GKl81DyZorrk0Lrav84D/Oa6/dcTVNBe+qysZarIu0z/4ONa3ntJOHZSD0nrMDIbH5 /kuaExFrmKua24IcLTJ7kMv4aZznk1tFLW55S+FUSl+56QLILaP6UwnUH+fl3lC3ewi2 G11Dz0nuScjQHRNnKJtuHddc5gqxqwRIqvGDQEoeSINqm4SvmojlKRYstBXk9er88giM Fc18UcphozgOU6kkHn0bTuUhg5WbyzanaukINkuc5d2NFLylNAFXO0oCPE53xOmeVTSd XC2vq32CpiDhy4XyaA2XW6afSt831NPNz3M9lgyg270ppe+kZ8u87OjR98MXEZU6RwlH paqA== 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=cFVKSv/lgF3V0H/+C7OLkmAbRhsoDIH3Y614Ay4Ps10=; b=AUhHw1nzLqtojO9vM45F3+xlQpBxgnhuzbN9LTUlg1TYplL67FTn6vKhH9CuYKG9bl 1O/7u3bCeaJ2rkpr0F7g/6loZM7evWE7CgFBapf8G8IV924dukzeSgJW3E9d5C7dV2rh YlZFhwDULt93L0RLV4rB8fXyGNt2G8fwR+BD3pTpGM1nBm294C0tJ6tEPKjiT4Dv9Zq5 5prUreIrhxhuT45z1g0kXGGscLewL36Y3H99DIhBlu1hS97M4iZeA60TZVa3x4O9TBYM Ulc6pPfCgAvBlGQxNmgQfLZWOrwKEijZ9kd+aSaypp69/CkYBF4gILhl4PUAaJjuv6hb qaiw== X-Gm-Message-State: ALQs6tCFnPMwqbIGmC4c9iHrPPtR6E1VEGWieD/qpi1MmPwfwzcf01K/ Yi/lVs409eYwcWpvtPxUQrPzFDhgIHzbD5gpT/9vcg== X-Google-Smtp-Source: AIpwx4/HlsicbQNGDjuqsSa/uSgWjMuNtClbJa6eZ43MbcZ+NCqJzSkWhHcgXxsZrJ74CY4PAP/irEFySttD/EAofJA= X-Received: by 2002:a24:c88:: with SMTP id 130-v6mr4138468itn.14.1523455786248; Wed, 11 Apr 2018 07:09:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.90.13 with HTTP; Wed, 11 Apr 2018 07:09:30 -0700 (PDT) From: Donald Eastlake Date: Wed, 11 Apr 2018 10:09:30 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [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: Wed, 11 Apr 2018 14:09:49 -0000 This message starts a two week Working Group Last Call on draft-ietf-babel-applicability-03.txt. The several endorsements posted in the last 24 hours will also be considered responses to this call. :-) Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Wed Apr 11 09:19: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 0C28D1275F4 for ; Wed, 11 Apr 2018 09:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.312 X-Spam-Level: X-Spam-Status: No, score=-4.312 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, RCVD_IN_MSPIKE_H2=-0.001, 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 vvvgk9WQIpem for ; Wed, 11 Apr 2018 09:19:14 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1BE8127241 for ; Wed, 11 Apr 2018 09:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1523463554; x=2387377154; 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=vmipHUYCUXDnj06xz/O4s99D3fOEOi9d15Y8A6OwRKM=; b=dAlmeSBcMBWUG+cyTPm+WIbVeEgpr8fJrUWYSFVQsV4+8aRA1aNgyihm3/IqsCxc CRZeUxz50aKGj/JFyVE7J4H2895qa/xfoGWnOb5PJqLuoGUtEr7BAxN+IifyFyqW fu2nTGQRrat2XVGlQEiAV1igHuyggIMwMqEsNfHuDxEfJ+n683jJUvg84s+laktL 7YNsGelJsyBNgEJPVEBgrOdKTHk8QDXrkzPxvEpnvrqW7axd7itERAgDDZax6Hem eP/BUuDqKFKe0oiYI0GJ7uyMcPlVP0LZRAAHfYL5spJuxnnfFeLIl0rWKXAMiax7 DG9uRUZcqQT/8MpAxA+xTQ==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 8F.15.04908.2853ECA5; Wed, 11 Apr 2018 09:19:14 -0700 (PDT) X-AuditID: 11973e16-446529e00000132c-14-5ace35829444 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 41.EA.21982.2853ECA5; Wed, 11 Apr 2018 09:19:14 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.234.117.4] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P71001DM3ZVHM50@nwk-mmpp-sz13.apple.com>; Wed, 11 Apr 2018 09:19:14 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <2524EF75-E323-4B72-A516-E671BF3A08AB@iki.fi> Date: Wed, 11 Apr 2018 09:19:05 -0700 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , BARBARA H STARK , "babel@ietf.org" Content-transfer-encoding: quoted-printable Message-id: <3B3269F9-6B16-4781-88DE-F643A6765FC6@apple.com> References: <152296922074.3735.16897081899496814064@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114DD686A8@GAALPA1MSGUSRBF.ITServices.sbc.com> <87y3hyam6h.fsf@toke.dk> <2524EF75-E323-4B72-A516-E671BF3A08AB@iki.fi> To: Markus Stenberg X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUi2FCYqttkei7K4FyvtMWWRd0sFpP+/mS0 2Dt3BYvF1vcr2B1YPF72z2H0WLLkJ5PH4a8LWTy2HLrIFsASxWWTkpqTWZZapG+XwJXx8PhV loLV3BXL28oaGHs4uxg5OSQETCT+LV3B0sXIxSEksIZJ4l/XVHaYxMbbL9khEhuYJA617mMB SfAKCEr8mHwPyObgYBZQl5gyJRei5gujxPqzf8GahQWkJbou3GWFsL0knr2ZxApSzyagJXFg jRFImFPASmLpnt+MIDaLgKrEjR0LmUBsZoE2RokJu3ggbG2JJ+8ugLXyCthInL3JB7Gqn0mi f+FcsF4RAR2JC58OskLcrCQx/fttNgh7AZtE+xSpCYzCs5BcPQvh6llINixgZF7FKJSbmJmj m5lnrpdYUJCTqpecn7uJERT80+3EdjA+XGV1iFGAg1GJh/fCrTNRQqyJZcWVuYcYpTlYlMR5 jzGfiBISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAaPc75dojlS0H3qsdTSk9tLX0qKQY49t7 m7b79Lle3mD2dqd0TofFrJxzPKdFIti67dtKjO4evW/pcu7pUpFrkzV+sTVI+bvJhPcrprzm 3rnS+Ma6yiMbY5oOT//Q1Vqw+uerMrlwFYvoKzwLfl2bOGXhhbItTavX7zBNyRXnezSdV/Pm ZA8xRyWW4oxEQy3mouJEAKJM1bFfAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUi2FB8Q7fJ9FyUwZ7rEhZbFnWzWEz6+5PR Yu/cFSwWW9+vYHdg8XjZP4fRY8mSn0weh78uZPHYcugiWwBLFJdNSmpOZllqkb5dAlfGw+NX WQpWc1csbytrYOzh7GLk5JAQMJHYePslexcjF4eQwAYmiUOt+1hAErwCghI/Jt8Dsjk4mAXU JaZMyYWo+cIosf7sX3aQGmEBaYmuC3dZIWwviWdvJrGC1LMJaEkcWGMEEuYUsJJYuuc3I4jN IqAqcWPHQiYQm1mgjVFiwi4eCFtb4sm7C2CtvAI2Emdv8kGs6meS6F84F6xXREBH4sKng6wQ NytJTP9+m20Co8AsJJfOQrh0FpKpCxiZVzEKFKXmJFaa6yUWFOSk6iXn525iBIdrYeoOxsbl VocYBTgYlXh4L9w6EyXEmlhWXJl7iFGCg1lJhPfo77NRQrwpiZVVqUX58UWlOanFhxilOViU xHlnrj4aJSSQnliSmp2aWpBaBJNl4uCUamCc3v/T+N1cz8nz0q/Ilb361XHmWrfm0T1H98o7 H9qj9jWzeHmqiWKJopFKYocD88G3JT/t2w0ZQ5Z76B/Osp28IOdo0+Qlbu37IuIzsjUqFkr9 eLM6dI3Le/4TZodF9AI/Bl+YdKtQNDenrWrqlsXnFvtdrXixi9FRWU56PYvjozZnvrtONZOU WIozEg21mIuKEwHn8/s/UwIAAA== Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-02.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.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, 11 Apr 2018 16:19:16 -0000 > On Apr 10, 2018, at 21:05, Markus Stenberg = wrote: >=20 > On 11 Apr 2018, at 2.04, David Schinazi wrote: >> 2) Regarding security, should it be possible to pull the private key = from a router? Is that common practice? >=20 > No. I think what is written in the spec now is good. >=20 > In general only public keys should ever go anywhere from a device. Any = scheme that involves private key distribution is quite a bit less = secure. >=20 > That=E2=80=99s why e.g. certificate (=3D glorified public key) = enrollment practises involve device making requests with the public key, = and getting signed one back in return. Similarly, why HSMs and such are = all the rage (keep your private key on a box you don=E2=80=99t have even = access to the actual private key, just encryption and decryption = functions and public key). >=20 > As a matter of fact, if one were to use HSM with routing protocol (not = impossible although I guess it is mostly done nowadays with = https/ipsec/ssh keys), providing private key would not be possible as = only public key (and-or certificate) would even be available. To clarify, I entirely agree with you - I think we should NOT allow = extracting the private key. But my incorrect understanding of the doc = was that it allowed grabbing them. I just reread it and agree that I = does not allow it, only addition and deletion. David= From nobody Wed Apr 11 09:19: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 17782127444 for ; Wed, 11 Apr 2018 09:19: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 2P7t0yZVnv97 for ; Wed, 11 Apr 2018 09:19:42 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B91E127419 for ; Wed, 11 Apr 2018 09:19: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=1523463582; x=2387377182; 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=8CKJFucgNc6QQOEmwYdcKaHIWunsBSrDShs2H5k0gp4=; b=zAZ2M3opCyUqgsTQHD7xj49flthwkciqi9H6qbWiBRnFGcO82yP/hpcfRtVJJjSH BQuhhYWHiGKmzEURK7En7Fsc6RDvEGKaI+JAdMdTPqljKKGhSEaCmkX4TKLGSLGr njyedsEgKqgmssT79uUXkmeyUIwaBw8RXAC4H6FLxZUAmVQn9v65Y8H6loX5TSHS dUpmF/ll/Vlsw9V3XcMMOt8YMWBiLBKrvvn7DTny0rIgMH3RKvhxR6mYCuuClHRI vx8uzVHNpeuH+TkmPebSUIkHiEP08ARk62B4ayVi685GGS5H+IhhuyPMh1NFqXkW 3cQgxW0zMkPSnZRCPTIJSA==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id B1.5D.07147.E953ECA5; Wed, 11 Apr 2018 09:19:42 -0700 (PDT) X-AuditID: 11973e12-833ff70000001beb-80-5ace359e9975 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 82.2B.21982.C953ECA5; Wed, 11 Apr 2018 09:19:40 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.234.117.4] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P71001DM3ZVHM50@nwk-mmpp-sz13.apple.com>; Wed, 11 Apr 2018 09:19:40 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <87in8xc3fn.wl-jch@irif.fr> Date: Wed, 11 Apr 2018 09:19:38 -0700 Cc: "STARK, BARBARA H" , "babel@ietf.org" Message-id: <465529F4-55B7-439D-8022-C61864D3320C@apple.com> References: <152296922074.3735.16897081899496814064@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114DD686A8@GAALPA1MSGUSRBF.ITServices.sbc.com> <87y3hyam6h.fsf@toke.dk> <87in8xc3fn.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUi2FCYqjvP9FyUwYz1UhZbFnWzWEz6+5PR Yn7rMjYHZo+X/XMYPZYs+cnksXjLW8YA5igum5TUnMyy1CJ9uwSujCeffAq6WCoutu9gbWCc x9zFyMkhIWAi8e7UOyCbi0NIYA2TRNvMG2wwibZ/b5kgEhuYJC5uv80CkuAVEJT4MfkekM3B wSwgL3HwvCxImFlAS+L7o1YWiPovjBJLu96xgySEBaQlui7cZYWwvSSevZnECtLLBtRwYI0R SJhTQEOi8/15sJEsAqoSB+5ZQoz0kji8YjM7xFYbiY0XVkHd+ZdR4tKxi2AJEQEVieXTnrFD 3KwkMf37baj7J7BJvLkYP4FReBaSq2chXD0LydULGJlXMQrlJmbm6GbmmeglFhTkpOol5+du YgQF+nQ7oR2Mp1ZZHWIU4GBU4uGNMD4XJcSaWFZcmXuIUZqDRUmc9xjziSghgfTEktTs1NSC 1KL4otKc1OJDjEwcnFINjLGx37ICrmw9e+vXKY0/enfPuvarduxm4dD/veDrErE3WtOarcyT mvfdV9QV0jD8+ysv2rTv8ZMvN7du8nj6ti9cUXjOuYVav34Xfk0NfHoqe3mU4lbXDVo2N+cz 7HT5mbApVqLW57FebYb1brXNViWzpb0mbuhMTWi8l9ki0spt/qiX8WCqpBJLcUaioRZzUXEi ADqL5X9VAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUi2FB8Q3eO6bkog2s7DSy2LOpmsZj09yej xfzWZWwOzB4v++cweixZ8pPJY/GWt4wBzFFcNimpOZllqUX6dglcGU8++RR0sVRcbN/B2sA4 j7mLkZNDQsBEou3fW6YuRi4OIYENTBIXt99mAUnwCghK/Jh8D8jm4GAWkJc4eF4WJMwsoCXx /VErC0T9F0aJpV3v2EESwgLSEl0X7rJC2F4Sz95MYgXpZQNqOLDGCCTMKaAh0fn+PNhIFgFV iQP3LCFGekkcXrGZHWKrjcTGC6uYIcb/ZZS4dOwiWEJEQEVi+bRn7BA3K0lM/36bbQKjwCwk l85CuHQWkksXMDKvYhQoSs1JrDTXSywoyEnVS87P3cQIDs3C1B2MjcutDjEKcDAq8fBeuHUm Sog1say4MvcQowQHs5II79HfZ6OEeFMSK6tSi/Lji0pzUosPMUpzsCiJ885cfTRKSCA9sSQ1 OzW1ILUIJsvEwSnVwKjoMHmR0j+/TZcqOMMDN8wwXFV8cNu7/NmfbwRYJplrzpr/IzTK+UZ5 muBn3T+fRBU/OHLfeyXuNnu2bkTiv0MRSce7Dl3/8efsCpPS96qlqbU7+D5W/Nx41TjzAmd5 qDp/4sRtq2IXzDhy9IOwKEv6hI07LHl0tmQsn6ai0eYXVfdr49n/K/yUWIozEg21mIuKEwFz 3LeRSQIAAA== Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-02.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.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, 11 Apr 2018 16:19:44 -0000 > On Apr 11, 2018, at 05:50, Juliusz Chroboczek wrote: > >> 1) babel-hello-[mu]cast-history is an implementation detail documented >> in an appendix, should it be exposed? > > It's a useful piece of data when debugging issues with wireless links -- > it's easier to understand than the xxcost values. It's optional in > Barbara's model, so implementations can ignore it if they don't use > a Hello history. > > I argue for keeping it (as optional). Fair enough. That works for me. David From nobody Thu Apr 12 08:47:08 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C70B126DC2 for ; Thu, 12 Apr 2018 08:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5bofvJWd5MJ for ; Thu, 12 Apr 2018 08:47:03 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 1257E120725 for ; Thu, 12 Apr 2018 08:47:01 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id w3CFkxRb001614; Thu, 12 Apr 2018 16:46:59 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3F9D622054; Thu, 12 Apr 2018 16:46:58 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id 342D32204C; Thu, 12 Apr 2018 16:46:58 +0100 (BST) Received: from 950129200 (111.98.114.87.dyn.plus.net [87.114.98.111]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id w3CFkuTx008163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2018 16:46:57 +0100 Reply-To: From: "Adrian Farrel" To: "'Babel at IETF'" Cc: "'Donald Eastlake'" References: In-Reply-To: Date: Thu, 12 Apr 2018 16:46:54 +0100 Message-ID: <015101d3d275$7bff1e80$73fd5b80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJehzEg2hnZ0hTai0NwaVj1BNnRA6Ln2dzg Content-Language: en-gb X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23780.000 X-TM-AS-Result: No--10.526-10.0-31-10 X-imss-scan-details: No--10.526-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23780.000 X-TMASE-Result: 10--10.525600-10.000000 X-TMASE-MatchedRID: X4bcv0S75KlfsB4HYR80ZuYAh37ZsBDCUG8t0WtghCAn+p552csI1YYx goTDHmwZbwLamxo/eoJ2RsuknD8OT+boTa4PnlISA9lly13c/gFM6Axy3Z2WhLKeTtOdjMy6xf6 vD0EkW+TI8DCic88xMojmc/qsuKonuyXwa/V5eQozw5Ejs3g1lp7wR6/2hZzOclfXI71B+39R/8 wLhm7apKrR2gMZYZVdzsYj9wGekCkwH8qwXC+TQYbBPrt55wnwOUgDgpLqlbe0Vg+MnSE2GOyLQ G9V/UV4eIOFFrlESlAMoVYXIfvgRIEdzT5hCcIKEdFsavUQKAe3dp6DuD+6wCIWzbRXGr/CuZEt 0lV0Sb/v7KQvOHjFKGcuTf8BqjnO/u0XY/jqmEyeAiCmPx4NwLTrdaH1ZWqCHOI0tZ7A+B36C0e Ps7A07fk39LXMSri6L7jjTRsbnQtojdD02QznYRLsE63KmoxfKtwXgqLO3Q4= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 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: Thu, 12 Apr 2018 15:47:05 -0000 Hi, Thanks for a balanced assessment of Babel. I have a few minor comments on the current revision. Cheers, Adrian === The Abstract could usefully say what this document is and does. The first paragraph of the introduction might serve. --- The use of the first person plural is not usual in RFCs largely because it begs the question of who "we" are. Better to use "This document..." --- 1.1 s/traditional distance-vector protocol/distance-vector protocol/ --- 1.1 s/two obvious extensions/two extensions/ --- 2.1 Suggest to strike the following. Given a sufficiently friendly audience, the principles behind Babel can be explained in 15 minutes, and a full description of the protocol can be done in 52 minutes (one microcentury). --- 2.1 While Babel is a young protocol, there exist four independent implementations, including one that was reportedly written and debugged in just two nights. While an RFC is in some sense a snapshot in time, people will read this document for years to come. You need to reword this accordingly. It might also benefit from a citation or two. --- 2.2. o strict monotonicity of the metric: M < C + M; o left-distributivity of the metric: if M <= M', then C + M <= C + M'. These may be true statements, but what are M and C and M' ? --- 2.2 OLD in contrast to traditional link-state routing protocols NEW in contrast to link-state routing protocols --- 2.2 This is in contrast to traditional link-state routing protocols such as OSPF [RFC5340] or IS-IS [RFC1195], which are layered over a reliable flooding algorithm and make stronger requirements on the underlying network and metric. Are OSPF and IS-IS really layered over a flooding algorithm or do they incorporate the flooding algorithm? --- The three examples in 2.2 all say "does most probably not". In principle this is a reasonable thing to say, but it is subjective. It would be nice to scope "probably" in some way. I'm personally a little sceptical about the first example because my experience suggests that coders are fiendishly capable of constructing bugs that do all manner of unexpected things. --- 2.3 Remarkably enough, all of the extensions designed to date interoperate with the base protocol and with each other. This, again, is a consequence of the protocol design Then it is not remarkable, then, is it? :-) --- 2.4.1 a protocol that relies a reliable transport (such as OSPF, IS-IS I don't think that either OSPF or IS-IS rely on a reliable transport. Rather, I think they incorporate mechanisms to mitigate or overcome the effects of an unreliable network. --- It might be good to discuss the manageability of the protocol --- Isn't [RFC6126bs] really a normative reference? > -----Original Message----- > From: babel [mailto:babel-bounces@ietf.org] On Behalf Of Donald Eastlake > Sent: 11 April 2018 15:10 > To: Babel at IETF > Cc: babel-chairs@ietf.org > Subject: [babel] draft-ietf-babel-applicability WG Last Call > > This message starts a two week Working Group Last Call on > draft-ietf-babel-applicability-03.txt. The several endorsements posted > in the last 24 hours will also be considered responses to this call. > :-) > > Thanks, > Donald From nobody Thu Apr 12 11:01:45 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFAA126DED for ; Thu, 12 Apr 2018 11:01: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 8poFSoT_H1ae for ; Thu, 12 Apr 2018 11:01:40 -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 913E312762F for ; Thu, 12 Apr 2018 11:01:40 -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 w3CI1dFM004698; Thu, 12 Apr 2018 20:01:39 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id E1C8FEB273; Thu, 12 Apr 2018 20:01: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 P4ClOD2P-EIe; Thu, 12 Apr 2018 20:01:38 +0200 (CEST) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3F309EB276; Thu, 12 Apr 2018 20:01:36 +0200 (CEST) Date: Thu, 12 Apr 2018 20:01:36 +0200 Message-ID: <87zi28mhhb.wl-jch@irif.fr> From: Juliusz Chroboczek To: adrian@olddog.co.uk Cc: "'Babel at IETF'" In-Reply-To: <015101d3d275$7bff1e80$73fd5b80$@olddog.co.uk> References: <015101d3d275$7bff1e80$73fd5b80$@olddog.co.uk> 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, 12 Apr 2018 20:01:39 +0200 (CEST) X-Miltered: at korolev with ID 5ACF9F03.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5ACF9F03.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 : 5ACF9F03.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] 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: Thu, 12 Apr 2018 18:01:43 -0000 Thanks for your comments, Adrian. I'll give myself a few days to think them over. > Suggest to strike the following. > Given a sufficiently friendly audience, the principles > behind Babel can be explained in 15 minutes, and a full description > of the protocol can be done in 52 minutes (one microcentury). Strongly disagree. Comprehensibility and implementability are important properties of Babel (second only to the fact that it works). I'm open to rewording if you find the current wording overly whimsical. > I'm personally a little sceptical about the first example [in Section > 2.2] because my experience suggests that coders are fiendishly capable > of constructing bugs that do all manner of unexpected things. This is based on actual experience. I'll try to reword it, but I stand by my claim. For example, an early version of babeld had a bug that randomly corrupted buffers; with high probability, the corruption happened within an IPv6 address, so nodes would simply learn spurious host routes that would time out after a few seconds. (It took us ages to find the bug, in the meantime we were running with a network populated with occasional "martians".) Another example: I've recently introduced a bug in the sending of triggered updates (fixed in 1.8.1). The effect was that convergence was slowed down in some cases, until the next periodic update, but the loop-avoidance mechanisms were still functional, so not much harm happened. I'll think about how to reword it, perhaps summarising the two examples above might be useful. -- Juliusz From nobody Thu Apr 12 11:08: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 CC89812762F for ; Thu, 12 Apr 2018 11:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cf0c3Ek4QsdC for ; Thu, 12 Apr 2018 11:08:10 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E4F4126DED for ; Thu, 12 Apr 2018 11:08: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 w3CI82xi008034; Thu, 12 Apr 2018 20:08:02 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 1BB21EB273; Thu, 12 Apr 2018 20:08:02 +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 DLGyabszpQ0L; Thu, 12 Apr 2018 20:08:01 +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 3AEB9EB276; Thu, 12 Apr 2018 20:08:01 +0200 (CEST) Date: Thu, 12 Apr 2018 20:08:01 +0200 Message-ID: <87woxcmh6m.wl-jch@irif.fr> From: Juliusz Chroboczek To: adrian@olddog.co.uk Cc: "'Babel at IETF'" , "'Donald Eastlake'" In-Reply-To: <015101d3d275$7bff1e80$73fd5b80$@olddog.co.uk> References: <015101d3d275$7bff1e80$73fd5b80$@olddog.co.uk> 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, 12 Apr 2018 20:08:02 +0200 (CEST) X-Miltered: at korolev with ID 5ACFA082.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5ACFA082.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 : 5ACFA082.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] 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: Thu, 12 Apr 2018 18:08:12 -0000 > Isn't [RFC6126bs] really a normative reference? Donald, please advise. -- Juliusz From nobody Thu Apr 12 14:10: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 5C37212D941 for ; Thu, 12 Apr 2018 14:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 W41Zcqe9wnjP for ; Thu, 12 Apr 2018 14:10:13 -0700 (PDT) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 308A912D779 for ; Thu, 12 Apr 2018 14:10:13 -0700 (PDT) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id w3CLABjK028905; Thu, 12 Apr 2018 22:10:11 +0100 Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 25B912204A; Thu, 12 Apr 2018 22:10:11 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id 107E322048; Thu, 12 Apr 2018 22:10:11 +0100 (BST) Received: from 950129200 (111.98.114.87.dyn.plus.net [87.114.98.111]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id w3CLA9oN001875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2018 22:10:10 +0100 Reply-To: From: "Adrian Farrel" To: "'Juliusz Chroboczek'" Cc: "'Babel at IETF'" References: <015101d3d275$7bff1e80$73fd5b80$@olddog.co.uk> <87zi28mhhb.wl-jch@irif.fr> In-Reply-To: <87zi28mhhb.wl-jch@irif.fr> Date: Thu, 12 Apr 2018 22:10:07 +0100 Message-ID: <006401d3d2a2$a2d3f0d0$e87bd270$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJehzEg2hnZ0hTai0NwaVj1BNnRAwFy6qEtAoTBx8+iyHbmUA== Content-Language: en-gb X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23780.003 X-TM-AS-Result: No--20.364-10.0-31-10 X-imss-scan-details: No--20.364-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23780.003 X-TMASE-Result: 10--20.364200-10.000000 X-TMASE-MatchedRID: hls5oAVArl9fsB4HYR80ZppWgCLYjjT9/pYFEe4K6UmqvcIF1TcLYJjI dgnN0BwO1vNKGjIONd2OviVq/5wUPB2P280ZiGmRa0aUozXm0Db8d3gJRYhL8aWGUq5UQVeCOOx U2OT3WMAYumjInKeCWIaDCmcc7/bpPOvhMkqO6QrFlCgYxEaGEwOWx6MQC8CDPZRah3AKPkeEad LlemMdYxYePKokeL53T8bMOOFT8grtt0HEL3BUV4Dqq/69HfgsYQXxsZnRwoI2lCztgMwyoP+I4 5Q8H+H+kKaVbA4S4D15OPD8XJFfpE1+zyfzlN7y/sToY2qzpx6x5amWK2anSPoLR4+zsDTtAqYB E3k9Mpw= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 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: Thu, 12 Apr 2018 21:10:15 -0000 > > Suggest to strike the following. > > > Given a sufficiently friendly audience, the principles > > behind Babel can be explained in 15 minutes, and a full description > > of the protocol can be done in 52 minutes (one microcentury). > > Strongly disagree. Comprehensibility and implementability are important > properties of Babel (second only to the fact that it works). I'm open to > rewording if you find the current wording overly whimsical. How about... Babel is easily comprehensible and implementable. The principles behind Babel can be quickly explained, and a full description of the protocol takes just 48 pages in [RFC6126bis]. > > I'm personally a little sceptical about the first example [in Section > > 2.2] because my experience suggests that coders are fiendishly capable > > of constructing bugs that do all manner of unexpected things. > > This is based on actual experience. I'll try to reword it, but I stand by > my claim. > > For example, an early version of babeld had a bug that randomly corrupted > buffers; with high probability, the corruption happened within an IPv6 > address, so nodes would simply learn spurious host routes that would time > out after a few seconds. (It took us ages to find the bug, in the > meantime we were running with a network populated with occasional > "martians".) > > Another example: I've recently introduced a bug in the sending of > triggered updates (fixed in 1.8.1). The effect was that convergence was > slowed down in some cases, until the next periodic update, but the > loop-avoidance mechanisms were still functional, so not much harm happened. > > I'll think about how to reword it, perhaps summarising the two examples > above might be useful. OK. Maybe saying that "The protocol is robust against bugs such as buffer corruption, message loss, and timer disruption" would cover it? Cheers, Adrian From nobody Fri Apr 13 01:28: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 C58A41274D2 for ; Fri, 13 Apr 2018 01:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 MxIR7Q9gnYYS for ; Fri, 13 Apr 2018 01:28:19 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186A7126FDC for ; Fri, 13 Apr 2018 01:28:19 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id e2so1617633pgv.8 for ; Fri, 13 Apr 2018 01:28:19 -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=82WumCI8CdNLLnj7nim2qyCipJJX+DuAq5J/0xhLM9g=; b=cPt0DvxqNeY33mS0xYVWm+j6nQx3q3kVLQZV/WoPtfORPu+pS98/OMJuBkO64yP0QI hmucUqGv21kIN+tSALpbkXExgCA7cp+blRJ8lLoirUXsbcDFZS87JqA4wzu/2VpNteTM nRvbfcNEUfNDP+4iC+uyyrJQJwYM7uzzIXNy2OqQgki7WmQTdPKRq3kNPmx6uVcy4J30 KQX6zCEuplXlA1we2Nj6AXCREmX1tiAo4cNNnOd1j8g87aDy/0Xc/hDrgVhwv6/7ie6X /k4bSGVDFfFE6e0UfRHnvlfwA8DU1++7Jp8lC9oanjtk11p3wRnBW97lDwy24L3g7I3k 5RPA== 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=82WumCI8CdNLLnj7nim2qyCipJJX+DuAq5J/0xhLM9g=; b=E0wSJ1a4n+XuZfXCcAcvdYUSfy+aazralFksbcmX7obNHd6GSWUj5zDUvCu0aXohC7 tZ3Qrdi/X0ZZemcd16+GhhRN6Cp2MUOxZbf2G5sw4gF+8l8E0v4Y9H5kaVNi4m8Psdyw ZcKUpiWYhFn3G0AzUKvU6UJLafpLoQ8nhk4V3wkmUMNsQ+DMVioP6PAuWYhv0jn/PEa3 +vxDrcQskO1iaBOvIjKIdlFQS4zXK2kdOcA8k2MpxIkM5NDLhPxypPzpxlkXtcsT7fpe 5kutdWNOkQHYYj31Rf2jy9zAA68DrVagrd4jHNaPdN4rSBA9fXM8aa/y59hsZbkYmECT YOYg== X-Gm-Message-State: ALQs6tAzopmeoyuTYYb248YaoRvmzvXBxjg7bu7b6aX014q6qZNZd3ns EReXxy8xJApoObdBZSlPb3mXQfQwa8fyKlB4bFykjrB4FNo= X-Google-Smtp-Source: AIpwx49ajnquFRZBHyzPRXV4AEb5i+XmwUUq4PtOE/k6hlr6OCRHYbP7zI4PU6DfszyF0RfmMd9VmdFtW3ZoZWA4jCQ= X-Received: by 10.98.152.17 with SMTP id q17mr10630583pfd.67.1523608098157; Fri, 13 Apr 2018 01:28:18 -0700 (PDT) MIME-Version: 1.0 References: <015101d3d275$7bff1e80$73fd5b80$@olddog.co.uk> <87zi28mhhb.wl-jch@irif.fr> <006401d3d2a2$a2d3f0d0$e87bd270$@olddog.co.uk> In-Reply-To: <006401d3d2a2$a2d3f0d0$e87bd270$@olddog.co.uk> From: Gabriel Kerneis Date: Fri, 13 Apr 2018 08:27:41 +0000 Message-ID: To: adrian@olddog.co.uk Cc: Juliusz Chroboczek , Babel at IETF Content-Type: multipart/alternative; boundary="94eb2c115f607862090569b6a732" 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: Fri, 13 Apr 2018 08:28:21 -0000 --94eb2c115f607862090569b6a732 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 12, 2018 at 11:10 PM Adrian Farrel wrote: > > > Suggest to strike the following. > > > > > Given a sufficiently friendly audience, the principles > > > behind Babel can be explained in 15 minutes, and a full description > > > of the protocol can be done in 52 minutes (one microcentury). > > > > Strongly disagree. Comprehensibility and implementability are important > > properties of Babel (second only to the fact that it works). I'm open to > > rewording if you find the current wording overly whimsical. > > How about... > > Babel is easily comprehensible and implementable. The principles behind > Babel > can be quickly explained, and a full description of the protocol takes > just 48 > pages in [RFC6126bis]. > This is less whimsical (which is good) but it loses the important aspect of being precise (that you advocate for in other comments). I'd suggest something along the lines of: Babel is easily comprehensible and implementable. The principles behind Babel have been explained in under-an-hour talks to varied audiences, and a full description of the protocol takes just 48 pages in [RFC6126bis]. Gabriel --94eb2c115f607862090569b6a732 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 12= , 2018 at 11:10 PM Adrian Farrel <adrian@olddog.co.uk> wrote:
> > Suggest to strike the following.
>
> >=C2=A0 =C2=A0 Given a sufficiently friendly audience, the principl= es
> >=C2=A0 =C2=A0 behind Babel can be explained in 15 minutes, and a f= ull description
> >=C2=A0 =C2=A0 of the protocol can be done in 52 minutes (one micro= century).
>
> Strongly disagree.=C2=A0 Comprehensibility and implementability are im= portant
> properties of Babel (second only to the fact that it works).=C2=A0 I&#= 39;m open to
> rewording if you find the current wording overly whimsical.

How about...

Babel is easily comprehensible and implementable. The principles behind Bab= el
can be quickly explained, and a full description of the protocol takes just= 48
pages in [RFC6126bis].

This is less whi= msical (which is good) but it loses the important aspect of being precise (= that you advocate for in other comments). I'd suggest something along t= he lines of:

Babel is easily comprehensible a= nd implementable. The principles behind Babel have been explained in under-= an-hour talks to varied audiences, and a full description of the protocol t= akes just 48 pages in [RFC6126bis].

Gabriel<= /div>
--94eb2c115f607862090569b6a732-- From nobody Fri Apr 20 06:27:47 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 1D8D612D7E4; Fri, 20 Apr 2018 06:27:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Mehmet Ersue To: Cc: draft-ietf-babel-rfc6126bis.all@ietf.org, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.78.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152423086508.3257.3447827631091630217@ietfa.amsl.com> Date: Fri, 20 Apr 2018 06:27:45 -0700 Archived-At: Subject: [babel] Opsdir early review of draft-ietf-babel-rfc6126bis-04 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: Fri, 20 Apr 2018 13:27:45 -0000 Reviewer: Mehmet Ersue Review result: Has Nits I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Intended status: Standards Track Current IESG state: ID exists Obsoletes: 6126,7557 Summary: The document defines the Babel Routing Protocol originally defined in experimental RFCs 6116 and 7557. The abstract in this draft is a copy from the abstract of RFC 6116 and is a generic statement on "Babel". IMO the abstract should state explicitly that this draft defines the "Babel Routing Protocol" and replaces/obsoletes the RFCs 6116 and 7557. There are following additional nits in the document: == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) IANA Considerations have to be reviewwed from IANA. Security Considerations should refer to the discussion in RFC 6126. The document does not cause any issues related to operations and management. Regards, Mehmet From nobody Fri Apr 20 10:35: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 EA08912785F; Fri, 20 Apr 2018 10:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxpBqLHE6zZG; Fri, 20 Apr 2018 10:35:09 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85556127077; Fri, 20 Apr 2018 10:35: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 w3KHZ4un031658; Fri, 20 Apr 2018 19:35: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 E4047EB21E; Fri, 20 Apr 2018 19:35:03 +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 7iv7k14wwJsu; Fri, 20 Apr 2018 19:35:03 +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 0B51BEB226; Fri, 20 Apr 2018 19:35:03 +0200 (CEST) Date: Fri, 20 Apr 2018 19:35:02 +0200 Message-ID: <87r2n9u6gp.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mehmet Ersue Cc: , draft-ietf-babel-rfc6126bis.all@ietf.org, babel@ietf.org In-Reply-To: <152423086508.3257.3447827631091630217@ietfa.amsl.com> References: <152423086508.3257.3447827631091630217@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 20 Apr 2018 19:35:04 +0200 (CEST) X-Miltered: at korolev with ID 5ADA24C8.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5ADA24C8.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 : 5ADA24C8.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] Opsdir early review of draft-ietf-babel-rfc6126bis-04 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, 20 Apr 2018 17:35:12 -0000 Dear Mehmet, > Reviewer: Mehmet Ersue > Review result: Has Nits Thanks for your review. It will take me a few days to find the time to produce a new revision. > == There are 1 instance of lines with multicast IPv4 addresses in the document. > If these are generic example addresses, they should be changed to use the > 233.252.0.x range defined in RFC 5771 If you are referring to Section 5, then this is the address assigned by IANA to the protocol. If you are referring to something else, I'd appreciate a clarification. Thanks, -- Juliusz Chroboczek From nobody Fri Apr 20 11:32: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 DA16712D86A; Fri, 20 Apr 2018 11:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzrzudVhoVQ1; Fri, 20 Apr 2018 11:32:10 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 588A51200F1; Fri, 20 Apr 2018 11:32:10 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id m26-v6so7458945wrb.3; Fri, 20 Apr 2018 11:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=Sy5+HgziYK/Nd3ssa5OkBcDJU2lqaLGn67uGKRiYHyw=; b=c0tN69xSnLhfxvTlxLy8M5QCRC2i74hAFYjWPAYOXqYhEYdCU95jCxb7Sre8tJ1Jnr GTcqF6HphvJSM3tsJU2cFgF+Qi9vW7UnVlcaeEpxhz9fFc9xEHxmuAYLeZRwbpGviLhS gLP53U+t953mvY+a8/rbawG+yr2+J5pj2/cDNQTgJIxI81wffjAsrmD+k3wJu5yV9dT5 arKjMkWzDn04DC+vC/p2rxLrs+EGxmvfB4wyiys3+/QOHvA3I5j/i/pJyGuRKCe3/amg UidEhCeX8p8c/Qp22JtMoIKo8RyqHKBFbqDfyHsQwxVnpOMVPlIn1rS6xaGZJxBk+3va hwKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Sy5+HgziYK/Nd3ssa5OkBcDJU2lqaLGn67uGKRiYHyw=; b=RW/6vk/mRhQAQ1RGarYnX1QPqXlZBbxZgEcVUwVj/JmbIuYgB+2Ud+Yexk5EsGUSzu xE9BBmCdZacI51fUeqA5sMRh0sOsdxXBx3tLbpohzzQAtjapKON4/GBA/57cS7XJIc4K iZtgYPK0qZsqiVsbzjyl1boAPh5NVaGt0hAXjbBR3lPmh+Y6rCEkVw7CxORzqvk3+qgx DQemDrWFEO2DSraeoGqY3+ehAj4Zg4ABULawtLh4tPcSa8UrvoG/CKVNmhZcPZszIAqY 3R8/vPFP6HZ/ezenSgrHmlCcfAVcqI4b0Pq0IdAHaTx8W9GQZu8SZGFAYxztu3V7Wff3 uEWQ== X-Gm-Message-State: ALQs6tD3nbpDWsCjBvns3MDdwrHoUsSsVDJUp5Rtg+N81CAf49tVqlCU 8Vo/VvvdGFLY/zS9zPwgz3R/bA== X-Google-Smtp-Source: AIpwx4/3xMt7fLdOcTCxxgQYmkrrjTbOoJEqF1h3UNZ7sjBoejErwVnIzw/tyNqcuXIITOc+C7KIXw== X-Received: by 10.80.182.44 with SMTP id b41mr9587616ede.255.1524249128669; Fri, 20 Apr 2018 11:32:08 -0700 (PDT) Received: from DESKTOPFLHJVQJ ([2001:16b8:2d9d:1f00:f51b:8e45:31f6:c8c2]) by smtp.gmail.com with ESMTPSA id i15sm4037834edb.56.2018.04.20.11.32.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Apr 2018 11:32:08 -0700 (PDT) From: "Mehmet Ersue" To: "'Juliusz Chroboczek'" Cc: , , References: <152423086508.3257.3447827631091630217@ietfa.amsl.com> <87r2n9u6gp.wl-jch@irif.fr> In-Reply-To: <87r2n9u6gp.wl-jch@irif.fr> Date: Fri, 20 Apr 2018 20:32:15 +0100 Message-ID: <013901d3d8de$4a4cc1c0$dee64540$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQDTg8EpC9q6KGOLgHHuLU0/iHXqBwJljwcjpfeIFSA= Content-Language: de Archived-At: Subject: Re: [babel] Opsdir early review of draft-ietf-babel-rfc6126bis-04 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, 20 Apr 2018 18:32:13 -0000 Hi Juliusz, I just reflected what the nit checker lists. As I understand this is no issue. Cheers, Mehmet > -----Original Message----- > From: Juliusz Chroboczek > Sent: Friday, April 20, 2018 6:35 PM > To: Mehmet Ersue > Cc: ops-dir@ietf.org; draft-ietf-babel-rfc6126bis.all@ietf.org; babel@ietf.org > Subject: Re: Opsdir early review of draft-ietf-babel-rfc6126bis-04 > > Dear Mehmet, > > > Reviewer: Mehmet Ersue > > Review result: Has Nits > > Thanks for your review. It will take me a few days to find the time to > produce a new revision. > > > == There are 1 instance of lines with multicast IPv4 addresses in the > document. > > If these are generic example addresses, they should be changed to use > > the 233.252.0.x range defined in RFC 5771 > > If you are referring to Section 5, then this is the address assigned by IANA to > the protocol. If you are referring to something else, I'd appreciate a > clarification. > > Thanks, > > -- Juliusz Chroboczek From nobody Mon Apr 30 04:22: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 3D0CE127077 for ; Mon, 30 Apr 2018 04:22:17 -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 edlxVsW3Gm8I for ; Mon, 30 Apr 2018 04:22:15 -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 3E135126DCA for ; Mon, 30 Apr 2018 04:22:15 -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=1525087331; bh=OA03CE5cgn1yfrdyv/ghLPGB/6VrUlsdbhiGRiNKwM8=; h=From:To:Subject:Date:From; b=SEQeFhiPxXhN9tyFIwIf1JZ/Iq+rP4mA4lhA8NFFe6BK9Fwk2YylE42Koq6Dl3qqD ULwR+bE9KLIDZT0MFzEHsOVXUekqn28TZZ3AEdNCNp3g98CovGVuqOHto3UlzY1/ON Naiav6n9jkqXcfU/Wi+e6nkh0zQV5D2jxP8AZmy1YQR4CKUfB1TMqkWX7Y8or2w8f0 jDfxweYbYoe+2n2Z5Yds+PQ142GmWEHPR2WjAZRnbjQSQ7dYSaWAulg3bgVQPh6d/5 C5BkxsM/vEnTVLrGtymZbzWX2HRmyt4xDbYyBnGJBN0ZtLOLGK2qHlta7rc3nLC+xS q07iOw1KijM8A== To: babel@ietf.org Date: Mon, 30 Apr 2018 13:22:10 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87po2h2b31.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [babel] Restarting nodes and seqno requests 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, 30 Apr 2018 11:22:17 -0000 I was debugging an issue with routes staying unreachable for a long time after a node reboots; and decided I wasn't actually sure what the right behaviour is, so I thought I'd ask. So, the simple scenario is this: - Babel nodes A and B have established a neighbour relationship, and node B announces prefix P with seqno S. - Node B restarts (i.e. shuts down, loses its transient state such as seqnos and comes back up either immediately or after a relatively short time). It will then start announcing prefix P again, but now with seqno S' < S. - Node A sees the new announcements from node B with a lower seqno. Since the hold time for P has not expired, these updates are unfeasible, so node A sends a seqno request. - Node B updates its seqno to S'' = S' + 1 and resends the update. - In many cases, S'' < S, so the update is still unfeasible from A's point of view. The question is, how is this supposed to be resolved? Should A keep resending the seqno requests each time it gets a new unfeasible update - and if so, is there any limit to the frequency? Or should A immediately consider the update with seqno S' as feasible because its selected route has metric infinity? I *think* the answer is the former (and that no rate limit is needed), but I may be missing a reason why it is safe to accept the unfeasible update during hold time... So what does everyone else think? :) -Toke From nobody Mon Apr 30 04:56:15 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB7512762F for ; Mon, 30 Apr 2018 04:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.099 X-Spam-Level: *** X-Spam-Status: No, score=3.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 WR6cP7-_iKUW for ; Mon, 30 Apr 2018 04:56:12 -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 522A0126D85 for ; Mon, 30 Apr 2018 04:56:12 -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 w3UBu8NF031187; Mon, 30 Apr 2018 13:56: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 A7720EB21E; Mon, 30 Apr 2018 13:56:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 3_Jwn2pZPXsL; Mon, 30 Apr 2018 13:56:07 +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 A6D57EB227; Mon, 30 Apr 2018 13:56:07 +0200 (CEST) Date: Mon, 30 Apr 2018 13:56:07 +0200 Message-ID: <874ljszz54.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: babel@ietf.org In-Reply-To: <87po2h2b31.fsf@toke.dk> References: <87po2h2b31.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]); Mon, 30 Apr 2018 13:56:10 +0200 (CEST) X-Miltered: at korolev with ID 5AE70458.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5AE70458.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 : 5AE70458.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] Restarting nodes and seqno requests 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, 30 Apr 2018 11:56:15 -0000 > - Node B restarts (i.e. shuts down, loses its transient state such as > seqnos and comes back up either immediately or after a relatively > short time). It will then start announcing prefix P again, but now > with seqno S' < S [which is unfeasible for A]. Yes. The loop avoidance mechanism in Babel is stateful (the source table contains the state), and if you loose your state, you're in trouble. That is why babeld saves its seqno into persistent storage at shutdown and restores it at startup. If the seqno is lost (either because a node has crashed or because you have no persistent storage), then you need to timeout the source table entry: - first, the route times out, so its metric becomes infinite; - you start sending retractions, and retractions don't update the source table; - at some point, the source table GC timer triggers, and the source entry gets updated. Note that the total time you wait for the route to become feasible again is the sum of the route hold time and the source GC time, so its on the order of a few minutes -- Babel is optimised for the case where links go up and down, but routers do not reboot often. If that's not acceptable, you can work around the issue by changing router ids at every boot, so that the old and new state don't interact. Babeld implements this with the "random-id" option, and it is useful in environments where routers reboot oftent without saving their seqno. > The question is, how is this supposed to be resolved? There's no good solution. The loop avoidance mechanism is stateful, and that's a fact of nature. (BGP avoids the statefulness by putting the whole state into each update, which causes updates to have an unbounded size.) If you have an idea for a good mechanism to avoid the issue, I'm listening. > Should A keep resending the seqno requests each time it gets a new > unfeasible update - and if so, is there any limit to the frequency? Only the usual delay on sending out updates (Section 4, "a Babel node SHOULD buffer every TLV and delay sending a packet by a small, randomly chosen delay"). Is that a problem in practice? > Or should A immediately consider the update with seqno S' as feasible > because its selected route has metric infinity? As you mentioned, that would be unsafe. Consider the following topology: ::0 --- A --- B A loses its Internet connection, so it sets the metric of its selected route to infinity. Before it sends a retraction, it receives an unfeasible update from B (with router-id A) -- routing loop. -- Juliusz From nobody Mon Apr 30 06:08:15 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C6E12DA17 for ; Mon, 30 Apr 2018 06:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.999 X-Spam-Level: ** X-Spam-Status: No, score=2.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, SPF_PASS=-0.001] autolearn=no 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 ms0R3NL19yEb for ; Mon, 30 Apr 2018 06:08:12 -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 A2E5C12DA14 for ; Mon, 30 Apr 2018 06:08: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=1525093687; bh=dBPD3Kwh0qP3Tf/MVWnNGNLxYIGQrICPn68s/9zEtcU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=LJGltU/yQuetF8N+GCU9V0+67EXDbo+QitdQmKYjFpouBYJNHP0/JYucHcPtqkaa1 THJix6ckCTWgGrug4Srqnsbh99bmcGj2AkN0vY5mqqdzWtARBIg+GH8yJF5S9B+7/V krqFik55/bJEVCnv1v4+AAL/T0yPmEiY6lPQ2beLTu0v3jQuB7SUSslTYzcdQ1iPDU w2uf7LBgF5KW9OVItzbrSP8K2x9DU94OTgPGBRBbLVt2RHWit9ZZj8h4TtO2IgjgZy tVDW3v3eYJ9qp8f4q+NxpdaJqA1sR+iAgT7tBVkM0wuFkx9TdoZGF2LFQbgbST4qLL 23eGK4fPK/6lQ== To: Juliusz Chroboczek Cc: babel@ietf.org In-Reply-To: <874ljszz54.wl-jch@irif.fr> References: <87po2h2b31.fsf@toke.dk> <874ljszz54.wl-jch@irif.fr> Date: Mon, 30 Apr 2018 15:08:07 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87k1so3kqw.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Restarting nodes and seqno requests 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, 30 Apr 2018 13:08:14 -0000 Juliusz Chroboczek writes: >> - Node B restarts (i.e. shuts down, loses its transient state such as >> seqnos and comes back up either immediately or after a relatively >> short time). It will then start announcing prefix P again, but now >> with seqno S' < S [which is unfeasible for A]. > > Yes. The loop avoidance mechanism in Babel is stateful (the source table > contains the state), and if you loose your state, you're in trouble. That > is why babeld saves its seqno into persistent storage at shutdown and > restores it at startup. > > If the seqno is lost (either because a node has crashed or because you > have no persistent storage), then you need to timeout the source table entry: > > - first, the route times out, so its metric becomes infinite; > - you start sending retractions, and retractions don't update the source > table; > - at some point, the source table GC timer triggers, and the source > entry gets updated. > > Note that the total time you wait for the route to become feasible again > is the sum of the route hold time and the source GC time, so its on the > order of a few minutes -- Babel is optimised for the case where links go > up and down, but routers do not reboot often. If that's not acceptable, > you can work around the issue by changing router ids at every boot, so > that the old and new state don't interact. Babeld implements this with > the "random-id" option, and it is useful in environments where routers > reboot oftent without saving their seqno. Right, that's what I thought. I don't think there's a good way to store persistent state in Bird, but it may be possible to try harder to do graceful restarts... I'll look into the options. >> The question is, how is this supposed to be resolved? > > There's no good solution. The loop avoidance mechanism is stateful, and > that's a fact of nature. (BGP avoids the statefulness by putting the > whole state into each update, which causes updates to have an unbounded > size.) > > If you have an idea for a good mechanism to avoid the issue, I'm > listening. Not off the top off my head.. >> Should A keep resending the seqno requests each time it gets a new >> unfeasible update - and if so, is there any limit to the frequency? > > Only the usual delay on sending out updates (Section 4, "a Babel node > SHOULD buffer every TLV and delay sending a packet by a small, > randomly chosen delay"). Is that a problem in practice? No, don't think so, it's just an implementation issue: Bird currently won't resend the same request until it expires after two seconds. So when the triggered update arrives with S'' (that is still too low), it won't ask for another seqno increase. But that is a straight-forward fix, and with that it converges reasonably quickly (as long as the seqno is not too high I guess...) >> Or should A immediately consider the update with seqno S' as feasible >> because its selected route has metric infinity? > > As you mentioned, that would be unsafe. Consider the following topology: > > ::0 --- A --- B > > A loses its Internet connection, so it sets the metric of its selected > route to infinity. Before it sends a retraction, it receives an > unfeasible update from B (with router-id A) -- routing loop. Right, thought so :) -Toke From nobody Mon Apr 30 06:36:16 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB30512025C for ; Mon, 30 Apr 2018 06:36:14 -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 7hjoAOh7AgYq for ; Mon, 30 Apr 2018 06:36:13 -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 09C5B12420B for ; Mon, 30 Apr 2018 06:36:12 -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 w3UDaBQV019795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Apr 2018 15:36: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 w3UDaD7B029779; Mon, 30 Apr 2018 15:36: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 22C89EB21E; Mon, 30 Apr 2018 15:36: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 ffeCNgvDih37; Mon, 30 Apr 2018 15:36: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 2B673EB227; Mon, 30 Apr 2018 15:36:10 +0200 (CEST) Date: Mon, 30 Apr 2018 15:36:10 +0200 Message-ID: <87wowoyfxx.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: babel@ietf.org In-Reply-To: <87k1so3kqw.fsf@toke.dk> References: <87po2h2b31.fsf@toke.dk> <874ljszz54.wl-jch@irif.fr> <87k1so3kqw.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]); Mon, 30 Apr 2018 15:36:11 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 30 Apr 2018 15:36:13 +0200 (CEST) X-Miltered: at korolev with ID 5AE71BCB.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5AE71BCD.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5AE71BCB.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5AE71BCD.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 : 5AE71BCB.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5AE71BCD.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] Restarting nodes and seqno requests 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, 30 Apr 2018 13:36:15 -0000 > No, don't think so, it's just an implementation issue: Bird currently > won't resend the same request until it expires after two seconds. So > when the triggered update arrives with S'' (that is still too low), it > won't ask for another seqno increase. But that is a straight-forward > fix, and with that it converges reasonably quickly (as long as the seqno > is not too high I guess...) Not sure about that -- it will cause extra background traffic, which may have unintended consequences. Note that seqnos are 16 bits, so converging to a feasible seqno takes 16384 packets on average, 32767 worst case. I'd recommend: - add an option for picking a different router-id each time (but don't make it the default, since it makes management more difficult without stable router-ids); - document the issue; - bug the BIRD guys about implementing persistent storage; two octets is all we're asking for. Should I document the issue in 6126bis? I'll definitely add a paragraph in applicability-statement. -- Juliusz From nobody Mon Apr 30 08:09:34 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EC5126BFD for ; Mon, 30 Apr 2018 08:09:33 -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 X8Uh-WPXv77i for ; Mon, 30 Apr 2018 08:09:32 -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 DC8AA126B7E for ; Mon, 30 Apr 2018 08:09:31 -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=1525100967; bh=7c4s/HbdqcmOClwDSvOKIE1a9TaZzYINjMRVSDsD+kw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=vykeY+4l0iDUxAZOSCqxIHfPdYCFxwKL1IB6MSn9jRntN3frgvtg0kzviGX+T6hib cnNiWPmtcL68PmXJHqDVm/s0G8+1Ptzgw1PAHKyV8bfDiC4wxd1CcTDaLKL5sfuV/l Eyz24jlgHdTau6PjpQf9xngXiAq+Awu1qBeixw7TlbEBWolmP2e4Q+meP4PnBL3J5E KqOTbBrxt68nAil9VboHjBaR6XF/hGyfcDbxXiQ0zlk7n4W1iAf3LnU2egJDwn4X0M ShB4kzHb96Jj8zxPn5o/pwuYp8rB+HY4CxTAMbzB4ISJ7qFKPtaASBgd89oR2pvRL5 Q7mWgbYSwKFUw== To: Juliusz Chroboczek Cc: babel@ietf.org In-Reply-To: <87wowoyfxx.wl-jch@irif.fr> References: <87po2h2b31.fsf@toke.dk> <874ljszz54.wl-jch@irif.fr> <87k1so3kqw.fsf@toke.dk> <87wowoyfxx.wl-jch@irif.fr> Date: Mon, 30 Apr 2018 17:09:26 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87efiw3f4p.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Restarting nodes and seqno requests 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, 30 Apr 2018 15:09:34 -0000 Juliusz Chroboczek writes: >> No, don't think so, it's just an implementation issue: Bird currently >> won't resend the same request until it expires after two seconds. So >> when the triggered update arrives with S'' (that is still too low), it >> won't ask for another seqno increase. But that is a straight-forward >> fix, and with that it converges reasonably quickly (as long as the seqno >> is not too high I guess...) > > Not sure about that -- it will cause extra background traffic, which may > have unintended consequences. Note that seqnos are 16 bits, so converging > to a feasible seqno takes 16384 packets on average, 32767 worst case. Yeah, suppose that would be quite a bit of traffic... > I'd recommend: > > - add an option for picking a different router-id each time (but > don't make it the default, since it makes management more difficult > without stable router-ids); Hmm, actually, since Bird sets its router ID from an IPv4 address, the top 32 bits are always zero (for compatibility with the notion of router ID that Bird uses for other protocols). My implementation of the randomisation only randomises the top 32 bits, so there's still a stable identifier. Maybe it would make sense to default to this behaviour? > - document the issue; > - bug the BIRD guys about implementing persistent storage; two octets is > all we're asking for. Yeah, 16 bits should be enough for everyone, right? ;) > Should I document the issue in 6126bis? I'll definitely add a paragraph > in applicability-statement. Hmm, documenting it *somewhere* is needed, certainly. Maybe putting it into 6126bis is a good idea, since I have a nagging suspicion that not everyone will read the applicability statement before implementing it... ;) -Toke From nobody Mon Apr 30 10:49: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 3FD40126C22 for ; Mon, 30 Apr 2018 10:49:13 -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 Bwi3dkBOMc6L for ; Mon, 30 Apr 2018 10:49:10 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7186124239 for ; Mon, 30 Apr 2018 10:49:09 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id w3UHn73p025220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Apr 2018 19:49:08 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id w3UHn97k011868; Mon, 30 Apr 2018 19:49:09 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 7A066EB227; Mon, 30 Apr 2018 19:49: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 4ridutqZqtS6; Mon, 30 Apr 2018 19:49:02 +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 93125EB21E; Mon, 30 Apr 2018 19:48:59 +0200 (CEST) Date: Mon, 30 Apr 2018 19:48:59 +0200 Message-ID: <87po2gy48k.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: babel@ietf.org In-Reply-To: <87efiw3f4p.fsf@toke.dk> References: <87po2h2b31.fsf@toke.dk> <874ljszz54.wl-jch@irif.fr> <87k1so3kqw.fsf@toke.dk> <87wowoyfxx.wl-jch@irif.fr> <87efiw3f4p.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]); Mon, 30 Apr 2018 19:49:08 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 30 Apr 2018 19:49:09 +0200 (CEST) X-Miltered: at korolev with ID 5AE75713.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5AE75715.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5AE75713.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5AE75715.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 : 5AE75713.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5AE75715.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] Restarting nodes and seqno requests 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, 30 Apr 2018 17:49:13 -0000 >> - add an option for picking a different router-id each time (but >> don't make it the default, since it makes management more difficult >> without stable router-ids); > Hmm, actually, since Bird sets its router ID from an IPv4 address, What if there's no IPv4 address? What if two IPv6 routers have the same IPv4 address (because they're in different NAT domains)? (FYI, babeld uses the first MAC address if finds that has the local bit unset, and falls back to random if no such address is found.) > My implementation of the randomisation only randomises the top 32 bits, > so there's still a stable identifier. Maybe it would make sense to > default to this behaviour? That would break the optimisation of using the low bits of the IPv6 address to encode the router-id. Probably not a big deal, except in pure mesh networks. I'm not sure how you'd avoid router-id collisions, though. >> - bug the BIRD guys about implementing persistent storage; two octets is >> all we're asking for. > Yeah, 16 bits should be enough for everyone, right? ;) You could always encode it in JSON if you want to use more space. >> Should I document the issue in 6126bis? I'll definitely add a paragraph >> in applicability-statement. > Hmm, documenting it *somewhere* is needed, certainly. Maybe putting it > into 6126bis is a good idea, Yeah. I'll try to find some time to make a new revision tomorrow, if you'd like to send me a patch, I'd be grateful. (No promise to keep your wording, though.) -- Juliusz From nobody Mon Apr 30 12:21:12 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EEA12708C for ; Mon, 30 Apr 2018 12:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 cj0t6Ml4RGfe for ; Mon, 30 Apr 2018 12:21:08 -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 0B9841200B9 for ; Mon, 30 Apr 2018 12:21:08 -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=1525116060; bh=DFnAIw7dMuuxuQ10lTL3UIk5cWetjHkkDnA1ybOrSsc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=b+BYpKzsPavZExc928BEO98EWLpIuTGFK215a5iZvZdGAc8Pxiy50WCuHXcXLujxK qp7AglJymU9dhGy1qFFmiAhrzhHOPYEF9+Ocd4SDKDXy0ANkcgw1jD98cuDsB5F9Ud pxczORy+d60FM1rKniE9wMFF6o2eKCw3q+yBktJZ+uMk4kKwCaojntGiIQvCs1a0z+ /mij5pbg0LXFBBxBcD+g0i76UlSY26pXJAO9kKtBXQ3OqhsP+VSO+/oAOS8+QCJfc6 uX/4lS+gSPVGjQiH1sGoO1akAwKrU1UUNUF9pBB/0wL4yP1ey6Lsh75Noe95llf9im hAaS13Io44xEQ== To: Juliusz Chroboczek Cc: babel@ietf.org In-Reply-To: <87po2gy48k.wl-jch@irif.fr> References: <87po2h2b31.fsf@toke.dk> <874ljszz54.wl-jch@irif.fr> <87k1so3kqw.fsf@toke.dk> <87wowoyfxx.wl-jch@irif.fr> <87efiw3f4p.fsf@toke.dk> <87po2gy48k.wl-jch@irif.fr> Date: Mon, 30 Apr 2018 21:20:51 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87tvrs33ho.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Restarting nodes and seqno requests 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, 30 Apr 2018 19:21:10 -0000 Juliusz Chroboczek writes: >>> - add an option for picking a different router-id each time (but >>> don't make it the default, since it makes management more difficult >>> without stable router-ids); > >> Hmm, actually, since Bird sets its router ID from an IPv4 address, > > What if there's no IPv4 address? What if two IPv6 routers have the > same IPv4 address (because they're in different NAT domains)? (FYI, > babeld uses the first MAC address if finds that has the local bit > unset, and falls back to random if no such address is found.) Well, usually the router ID is manually configured. If not, it'll be the lowest IP on a non-loopback interface. I have no idea what happens if there are none... There is quite a bit more configuration needed to get a basic babel node running with bird than with babeld in general; you'll need a couple dozen lines of config... >> My implementation of the randomisation only randomises the top 32 bits, >> so there's still a stable identifier. Maybe it would make sense to >> default to this behaviour? > > That would break the optimisation of using the low bits of the IPv6 > address to encode the router-id. Bird doesn't do that anyway. > I'm not sure how you'd avoid router-id collisions, though. By chance? With 32 bits of randomness, even in a moderately sized network the chance of collision is quite low (which means that it will not happen until it is the most inconvenient, of course...) :) >>> - bug the BIRD guys about implementing persistent storage; two octets is >>> all we're asking for. > >> Yeah, 16 bits should be enough for everyone, right? ;) > > You could always encode it in JSON if you want to use more space. I was actually thinking I should add JSON support to Bird :D >>> Should I document the issue in 6126bis? I'll definitely add a paragraph >>> in applicability-statement. > >> Hmm, documenting it *somewhere* is needed, certainly. Maybe putting it >> into 6126bis is a good idea, > > Yeah. I'll try to find some time to make a new revision tomorrow, if > you'd like to send me a patch, I'd be grateful. (No promise to keep > your wording, though.) No promises to send any either ;) -Toke From nobody Mon Apr 30 12:42: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 4F0D41200B9 for ; Mon, 30 Apr 2018 12:42: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 Zr2LM6D3PLRL for ; Mon, 30 Apr 2018 12:42: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 A8B7B127010 for ; Mon, 30 Apr 2018 12:42: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 w3UJgCk0019142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Apr 2018 21:42:12 +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 w3UJgDdC032724; Mon, 30 Apr 2018 21:42: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 BECCEEB226; Mon, 30 Apr 2018 21:42: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 16MEb03ZHcZQ; Mon, 30 Apr 2018 21:42: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 D076EEB21E; Mon, 30 Apr 2018 21:42:10 +0200 (CEST) Date: Mon, 30 Apr 2018 21:42:10 +0200 Message-ID: <87h8nsxyzx.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: babel@ietf.org In-Reply-To: <87tvrs33ho.fsf@toke.dk> References: <87po2h2b31.fsf@toke.dk> <874ljszz54.wl-jch@irif.fr> <87k1so3kqw.fsf@toke.dk> <87wowoyfxx.wl-jch@irif.fr> <87efiw3f4p.fsf@toke.dk> <87po2gy48k.wl-jch@irif.fr> <87tvrs33ho.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]); Mon, 30 Apr 2018 21:42:12 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 30 Apr 2018 21:42:13 +0200 (CEST) X-Miltered: at korolev with ID 5AE77194.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5AE77195.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5AE77194.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5AE77195.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 : 5AE77194.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5AE77195.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] Restarting nodes and seqno requests 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, 30 Apr 2018 19:42:16 -0000 >>> My implementation of the randomisation only randomises the top 32 bits, >>> so there's still a stable identifier. Maybe it would make sense to >>> default to this behaviour? >> >> That would break the optimisation of using the low bits of the IPv6 >> address to encode the router-id. > Bird doesn't do that anyway. That's five lines of code, and saves almost half the traffic in pure IPv6 meshes. >> I'm not sure how you'd avoid router-id collisions, though. > By chance? With 32 bits of randomness, even in a moderately sized > network the chance of collision is quite low (which means that it will > not happen until it is the most inconvenient, of course...) :) With 100 nodes, probability of collision is 10^-6. With 1000 nodes, it's 10^-4. With 2000 nodes, it's 5*10^-4. With 5000 nodes, it's 3*10^-3. I think we're at the very edge of comfort, which is why I chose 64 bits in the first place. >> I'll try to find some time to make a new revision tomorrow, if you'd >> like to send me a patch, I'd be grateful. (No promise to keep your >> wording, though.) > No promises to send any either ;) We have a deal. -- Juliusz From nobody Mon Apr 30 12:56:01 2018 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2CB126D0C for ; Mon, 30 Apr 2018 12:56:00 -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 iEhYIVVSw1PW for ; Mon, 30 Apr 2018 12:55:58 -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 531AA1200B9 for ; Mon, 30 Apr 2018 12:55:58 -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=1525118156; bh=0op/s0uSBQVzR6I9fwkLNToT6wiP6G1M0iDVd2eesC8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=aAX0YR2PIYKUO4MwWtw9BZWWtbX0lFW71JAfUmLNn+XkV6cMBw+y+qrO+8sNx3PHn mzmpXNUwBMwQlo8FmaSU9jY+mVAs4pN9vDec8C1hKHtIk/momqK+s1KqxP/L9f55Dy xcVgNyo6UhYRij/xjVAEuEiicWTtzukznadnsXPG0XWsCNPeF/dm3fQHZBaiRf0UHW /oecVK3xyKQBFcPPekeqEZf5fUYYFnYdkPDlyEkS19US0Aks8Msu9lM4Gbv48luXzX 96AZiRwzpC7rX5QYM9PwLfaVQlJdU/8ezo6vHjmKKX4rX6fIDPJfCqGalGxST4LI3G 1SP2uSbMlngew== To: Juliusz Chroboczek Cc: babel@ietf.org In-Reply-To: <87h8nsxyzx.wl-jch@irif.fr> References: <87po2h2b31.fsf@toke.dk> <874ljszz54.wl-jch@irif.fr> <87k1so3kqw.fsf@toke.dk> <87wowoyfxx.wl-jch@irif.fr> <87efiw3f4p.fsf@toke.dk> <87po2gy48k.wl-jch@irif.fr> <87tvrs33ho.fsf@toke.dk> <87h8nsxyzx.wl-jch@irif.fr> Date: Mon, 30 Apr 2018 21:55:57 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87h8ns31v6.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Restarting nodes and seqno requests 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, 30 Apr 2018 19:56:00 -0000 Juliusz Chroboczek writes: >>>> My implementation of the randomisation only randomises the top 32 bits, >>>> so there's still a stable identifier. Maybe it would make sense to >>>> default to this behaviour? >>> >>> That would break the optimisation of using the low bits of the IPv6 >>> address to encode the router-id. > >> Bird doesn't do that anyway. > > That's five lines of code, and saves almost half the traffic in pure > IPv6 meshes. Right, well the reason I didn't include it was that Bird already has a notion of a router ID (from BGP), which is 32 bits and based on v4 addresses. And it would be breaking assumptions to just override that. It could conceivably be a switch, though... >>> I'm not sure how you'd avoid router-id collisions, though. > >> By chance? With 32 bits of randomness, even in a moderately sized >> network the chance of collision is quite low (which means that it will >> not happen until it is the most inconvenient, of course...) :) > > With 100 nodes, probability of collision is 10^-6. With 1000 nodes, it's > 10^-4. With 2000 nodes, it's 5*10^-4. With 5000 nodes, it's 3*10^-3. > > I think we're at the very edge of comfort, which is why I chose 64 > bits in the first place. Well, the collision domain would not be all nodes, only those with the same configured router ID (or v4 address absent any configuration). But yeah, you're not wrong :) BTW, in the case where there *is* a stable identifier (whether its EUI-64 or a v4 address), randomising only parts of the router ID would be a way to keep the stable identifier? For the v4/32 bit case, randomising the 32 bits is the obvious solution; for EUI-64 you could just randomise the FFFE part? That way you could gain the reboot support but still have stable(-ish) identifiers so you could find your node? -Toke -Toke