From nobody Mon Aug 1 09:35:44 2016 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 8229D12D129 for ; Mon, 1 Aug 2016 09:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bknws10m9ihc for ; Mon, 1 Aug 2016 09:35:42 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 C854B12B01B for ; Mon, 1 Aug 2016 09:35:41 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id l32so110174125ual.2 for ; Mon, 01 Aug 2016 09:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=0nfpXKnwizZ6rBEqI37N90V6+IUoyscHAPNtSUjmZGo=; b=0UtJOJV6nqSIubYEWYKYfr3+8Tb0SRMXhl7NjhVu/Mc2DSovFGG0MLn1yh0cOyDAAr xSU4WhHbFFKHR0C7nA/qJtNwQ+pY77qGaby3LYNCelzn1JU8VWewfXssY871VeTk8biB Rz1cBk+5SiPbZq6M4qbq4Hv3RW32ZHxrVcuR4sPFnml96F2UDEEXsvnywuTiHeYAa+9A cGwZ43DPT8JybX9OfCUc5s2JEpFL1HuAlMCzHZNDbXvySuS4eb8gU/aBA4LYgYfL5r5X 4Bvw1U7EdhIGZdmM21aFlceJk/xBWnJ3jkoh8eI5NzetTWXz//TRB40mUF3pWAIfQexU HIRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0nfpXKnwizZ6rBEqI37N90V6+IUoyscHAPNtSUjmZGo=; b=OwSM//ANKptjxGjq8OBp9JG6tACZL4kZ4PwXEfMECdUy7ReQ7jgaGmVkyKWiaJk4xm 0l7zHpATBn2H9UNx18rl1njygpKwfct6eTxgQ2SF8nrat/7HO9tJE77vPllX0DypTrej TGkbOZbkDgh0mPfJ11dC+jwItHYtT3vjnRSti5MrYzI0rdeQVMUNDQ3wR3MgKiJJ5z/w k7LDnTmKEyo9OKnU+Z4PWBrJC42Dpz6gQncTYTKzT4FtaqufpTY+lXPA2Nhp9K8XNWWc HANLKLADhb8Kx0aufH+p4KmscHdd2kB4BLbqdIBst1PBUvHErPEvmTXxsO45Uc5QBbEI Guww== X-Gm-Message-State: AEkoouvjcR/tud02dVTxYssg7rBdGJKvKOMvBTP11b2CyBjBh7u2fS2qIP7SIREoWzHaTyVCn/tb8fuTvQSfSA== X-Received: by 10.159.37.137 with SMTP id 9mr26815762uaf.53.1470069340694; Mon, 01 Aug 2016 09:35:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.104.2 with HTTP; Mon, 1 Aug 2016 09:35:25 -0700 (PDT) From: Donald Eastlake Date: Mon, 1 Aug 2016 12:35:25 -0400 Message-ID: To: Babel at IETF Content-Type: multipart/alternative; boundary=001a113d0aa0d8ed3c0539053032 Archived-At: Subject: [babel] Draft minutes from Berlin uploaded X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 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, 01 Aug 2016 16:35:43 -0000 --001a113d0aa0d8ed3c0539053032 Content-Type: text/plain; charset=UTF-8 Hi, Draft minutes of the BABEL WG meeting in Berlin have been uploaded to https://www.ietf.org/proceedings/96/minutes/minutes-96-babel Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com --001a113d0aa0d8ed3c0539053032 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Draft minutes of the BABEL WG meeti= ng in Berlin have been uploaded to

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donal= d E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street,= Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com
--001a113d0aa0d8ed3c0539053032-- From nobody Mon Aug 1 10:28:36 2016 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 03A7212DA36; Mon, 1 Aug 2016 10:28:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160801172834.32528.13377.idtracker@ietfa.amsl.com> Date: Mon, 01 Aug 2016 10:28:34 -0700 Archived-At: Cc: babel@ietf.org Subject: [babel] I-D Action: draft-ietf-babel-rfc6126bis-00.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 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, 01 Aug 2016 17:28:35 -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 of the IETF. Title : The Babel Routing Protocol Author : Juliusz Chroboczek Filename : draft-ietf-babel-rfc6126bis-00.txt Pages : 45 Date : 2016-08-01 Abstract: Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-00 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 Sun Aug 7 10:15:39 2016 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 1336D12D0A0 for ; Sun, 7 Aug 2016 10:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 DVJuvBcPZN38 for ; Sun, 7 Aug 2016 10:15:36 -0700 (PDT) Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CD712B025 for ; Sun, 7 Aug 2016 10:15:36 -0700 (PDT) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1470590133606666.5840168416197; Sun, 7 Aug 2016 10:15:33 -0700 (PDT) Date: Sun, 07 Aug 2016 18:15:33 +0100 From: Denis Ovsienko To: "Babel at IETF" Message-ID: <1566600a52d.11082d71139924.7938100330812649620@ovsienko.info> In-Reply-To: <155e957c435.ce572f94276352.5573721139773988447@ovsienko.info> References: <155e02102cc.b9c8f25c210102.3836370527282629171@ovsienko.info> <155e957c435.ce572f94276352.5573721139773988447@ovsienko.info> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: Normal User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: Re: [babel] delay/replay attack on RFC 7298 mechanism X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2016 17:15:38 -0000 Hello group. I've been thinking about possible solutions for a while and it seems to me there is at least one particular bit that can be improved, please see below. ---- On Thu, 14 Jul 2016 13:18:11 +0100 Denis Ovsienko wrote ---- >[...] >>This behaviour depends on two current design points: >>1. The authentication mechanism is only concerned if the packets were originally produced by a legitimate router, came in order and were not modified. As long as those conditions are met, the delay between any input packets may be any amount of time. >>2. The main protocol body takes any IHU as a recent response to a recent Hello as it is currently impossible to relate an IHU to a particular Hello (Hellos do have 16-bit sequence numbers but IHUs don't). The RTT metric Babel extension seems to be close to this problem/solution space, as well as the TLVs that include a nonce number to correlate the request and response. >> > >I have considered the problem for some more time. A possible solution to this could be: >1. To add a "your last seen TS/PC" sub-TLV to each IHU TLV on sending. >2. To check that the sub-TLV stands for a reasonably recent point in time on receiving. >3. To consider if any other replayed TLVs would be actionable without the requirement of a verified two-way neighbourship. As far as my interpretations of RFC 6126 (bis) go, a Babel protocol instance makes every neighbour through the following (roughly) states: (Hello received) -> (IHU received) -> (will respond to AckReq with Ack, will process Update, will respond with Update to RouteReq and SeqnoReq) This lacks handling of timeouts, but the idea should be clear: until there is a two-way exchange with a neighbour, only Hello and IHU may be actioned. If this understanding is correct, the coupling between Hello and IHU as mentioned above should provide a protection from the described attack. This coupling may be done on the base of the existing Hello Seqno field, which at the moment looks like 16 bit worth of nonce. In this case the Seqno will have to be echoed back in an IHU. The least disruptive way of this would be a sub-TLV in the IHU TLV. The return nonce (Seqno) would then provide a proof of freshness. Alternatively, the two-way exchange of a nonce could be done using the existing AckReq+Ack TLVs. In this case an AckReq would have to accompany each Hello and an Ack would have to accompany each IHU. But it seems to me the additional TLV management would make this a worse option. In either case, having the neighbour state machine in the specification seems to be a good idea, even just as an illustration. For example, OSPF and BGP specs have FSMs as a part of the normative spec and those can be mapped into the code in a straightforward way. If we have a consensus on this, I could prepare a diagram for 6126-bis. >4. To revise Section 5.1 of RFC 7298 thoroughly to accommodate those changes. > >It would be nice to produce a simple measure of "freshness" like MAX_HELLO_TIMESTAMP_DIFF in RFC 7183 without the dependency on a pre-synchronised time, which in practice tends to depend on working routing. This chicken-and-egg situation should be avoided. > >Would anybody be interested to discuss this during the working group meeting? I could pull a couple slides together. -- Denis Ovsienko