From nobody Sun Jun 2 13:45:05 2019 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 70CE11200F1 for ; Sun, 2 Jun 2019 13:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, 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 jUnuj4rMmV_3 for ; Sun, 2 Jun 2019 13:45:01 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [IPv6:2a00:7660:6da:2001::664]) (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 DA02012008C for ; Sun, 2 Jun 2019 13:45:00 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1559508296; bh=jR6X4ydOrEb8cTuBsLHlWp3cGcVE67W0j4klGy+oF/8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=tdcP62QolGAi3TG9S+F5xkGpUh7fw2BrOZZm4fi+v2SVdbRgmWf+yIXchg3T3ULhx KJLcFc2+0Gz9reUmIm2jPOIAYB4Stzo7egHEooBMUaTuGQ5iAuXJacWBQWMl6LHjkZ l+jcrXdr3aX0E9xewpPjjmS9FisI+p5/TmZvwRvS5+f1KF4jnEYcOqHf5xiJlpOi7p 442iS3m+o2cVZXpsbmDslLskIVpZu00WLtSY/Nae1DKaZcT60pyrg6Wzrp02gUF5OA qlsrsGGtBTXlJDIbRpYLOStJw+GOCuy8SGk7YwdDi7kenNS4vj0jxMFbOjs1gT9/qw tHdZ8yLPQ2Xig== To: David Schinazi , Juliusz Chroboczek Cc: Babel at IETF In-Reply-To: References: <87tvda7omc.wl-jch@irif.fr> Date: Sun, 02 Jun 2019 22:44:56 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <877ea3iunr.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Babel over DTLS and UDP ports X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 02 Jun 2019 20:45:04 -0000 David Schinazi writes: > Now, speaking as implementor of Babel (as opposed to draft author), I > strongly believe that a new port will make a difference in the success > of this protocol. Juliusz phrased the reasons why quite well. +1 (even though I currently have no plans to implement the DTLS extension)... -Toke From nobody Thu Jun 6 06:08:10 2019 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 D722512011F; Thu, 6 Jun 2019 06:07:57 -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.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <155982647776.11574.13246675300583379482@ietfa.amsl.com> Date: Thu, 06 Jun 2019 06:07:57 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-dtls-05.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-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, 06 Jun 2019 13:07:59 -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 Routing Protocol over Datagram Transport Layer Security Authors : Antonin Decimo David Schinazi Juliusz Chroboczek Filename : draft-ietf-babel-dtls-05.txt Pages : 9 Date : 2019-06-06 Abstract: The Babel Routing Protocol does not contain any means to authenticate neighbours or protect messages sent between them. This document specifies a mechanism to ensure these properties, using Datagram Transport Layer Security (DTLS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-dtls-05 https://datatracker.ietf.org/doc/html/draft-ietf-babel-dtls-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-dtls-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 7 12:20:40 2019 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 D8419120119; Fri, 7 Jun 2019 12:20:37 -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.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <155993523783.27361.8559016189071866177@ietfa.amsl.com> Date: Fri, 07 Jun 2019 12:20:37 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-rfc6126bis-10.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-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, 07 Jun 2019 19:20:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : The Babel Routing Protocol Authors : Juliusz Chroboczek David Schinazi Filename : draft-ietf-babel-rfc6126bis-10.txt Pages : 61 Date : 2019-06-07 Abstract: Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol, and obsoletes RFCs 6126 and 7557. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-10 https://datatracker.ietf.org/doc/html/draft-ietf-babel-rfc6126bis-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-rfc6126bis-10 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 Fri Jun 7 12:36:01 2019 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 A1ED3120058 for ; Fri, 7 Jun 2019 12:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9ZQ8QrsCCvl for ; Fri, 7 Jun 2019 12:35:57 -0700 (PDT) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 9F8CD1200F3 for ; Fri, 7 Jun 2019 12:35:57 -0700 (PDT) Received: by mail-it1-x132.google.com with SMTP id x22so4505578itl.2 for ; Fri, 07 Jun 2019 12:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+Gvj0IcT5tADYSRqscrTbQ9azxH33jmIcf8Z86dFcL4=; b=rJZaPyiwMIR1/WSfxAn3v2AYY+Zy3OSZQkPbwcURJf4Ci4qAZkwr9W05nGFIBJgCBS WQF55w/rHFhXQEcXhK5XCoAKpc3yyUJ2/aitVi3N3s3D/wNjo0ULfcIfLAQOfwXurA7Y LKoZw53vXm00JibDhIi78J990hSla7m89hvgCmssdARJxC0xBrilA4BegOYbid0F542b y/KSo/MIriRf6PyOB6xkuPYRHC5Qao7/bHeFW9gXyDDi+HMNe+N5rz1qJG7xI99qlkx4 FB6pp4cb69SkrCKEY+e0THUSzKINMTt9+qlfegjIolbsHapk/LFPKSHyecdsGYqS5WIJ Ufyg== 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=+Gvj0IcT5tADYSRqscrTbQ9azxH33jmIcf8Z86dFcL4=; b=Jjix30BaL7n0R0UtBfCBoG4xhLrYXSWU5AYXHAFuYZzljuwq/fvvcSclFq6XkabzBe 3eHw9reLT7WvQ//K8K9zTzwlrUFWuwQ9CXdKZjuTjCCS530rStB7R8tz8HKhMqE/1q34 lv4FPKtezhf4Rb+183UgkPjBSRA/TzuG+MOtYbyNugjQ0CzCL4lkl3w8fMuUClkGOSvx 0VzMULlSU1kGHKBIHM37XyerNQkcs3sVxiQdEF89tohf48Lr86jy3CXm1qCPzgJ1PhuZ cuOMNwNBbH8a2lh9uYCgOGw3r+tJc1HDhAUEZGVfwr9YPdvlrubL1Oln3bWjYSPB3of0 Mn/Q== X-Gm-Message-State: APjAAAU+iaBjW9kSHa8+P1iNCl+X+etzUuqkzfSM9u4kvjpFErvpw1PX OQT/OabAXSc4CsRnldNcxReOkwOBK0HOj1eVC3o= X-Google-Smtp-Source: APXvYqxp/lrtohKHo6YKorfPEEpe6g+RQHijOn1TltHnkoYfdhdkn3fB8hYcwxC3tJBhLpgqSDupSGschK8MmkE7k7M= X-Received: by 2002:a24:2792:: with SMTP id g140mr5881760ita.81.1559936156791; Fri, 07 Jun 2019 12:35:56 -0700 (PDT) MIME-Version: 1.0 References: <87tvda7omc.wl-jch@irif.fr> In-Reply-To: <87tvda7omc.wl-jch@irif.fr> From: Donald Eastlake Date: Fri, 7 Jun 2019 15:35:45 -0400 Message-ID: To: Juliusz Chroboczek Cc: David Schinazi , Babel at IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] Babel over DTLS and UDP ports X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 07 Jun 2019 19:36:00 -0000 Hi, It seems to me that we have good reason to go for two ports. I don't think the IANA expert is trying to be bureaucratic; people's judgement can differ as to how hard we should be trying to conserve port number code points for future protocols and as to how good our reasons are. I think we should forge ahead with a TBD in the draft for the DTLS secure port if we can't get one with expert approval and, assuming the draft is approved by the IESG, we will get a port then. Thanks, Donald PS: I'm not sure I would say it is "usual" for protocols to have two ports, one for secure usage and one for insecure usage, but it is "common". =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com On Fri, May 31, 2019 at 9:14 AM Juliusz Chroboczek wrote: > > > When the authors requested the new port from IANA, we received some pushback. > > The position of the IANA port expert was that UDP ports are a scarce resource > > and they strongly prefer to not allocate them unless it is necessary. > > In a healthy technical organisation, the administration helps the > technical folks get their stuff done. An organisation is ossified if the > bureaucacy feels they have the right to dictate the technical solutions. > > If there are technical reasons to use a single port, we should state them. > Under no circumstances should we agree to change our protocol in order to > make the bureaucrats happy. > > > So the question for the Babel WG is: is the separate port necessary? > > Antonin's original implementation implementation used a single port: > > https://datatracker.ietf.org/meeting/101/materials/slides-101-babel-babel-over-dtls-00 > > > One possible solution could be for us to have unencrypted packets and DTLS > > packets share the same port. For that we can leverage the fact that all Babel > > packets start with a first byte set to 42, and say that DTLS packets use the > > same port, prefixed with 43 instead of 42. > > Yes, that's what I was arguing for back in 2018. However, I was put in > the minority by a number of wise people: > > - David argued that the whole point of DTLS is to use a standard DTLS > stack, and some DTLS stacks don't support using a single port for both > encrypted an cleartext traffic; > - David pointed out that Apple's DTLS implementation doesn't support > this mode of operation; > - Donald added that it is usual for IETF protocols to use separate ports. > > If the above points no longer stand, then please explain what has changed > since 2018. > > If these points still stand, then it is our duty to make the right > technical decision, IANA's impotence notwithstanding. We have a number of > options: > > - go speak with IANA again, stating clearly that using distinct ports > reflects WG consensus; > - should that fail, we could use an ephemeral port for DTLS, announce it > as a sub-TLV of multicast Hello (recall that DTLS uses unicast only); > - should that be considered to fragile, we can publish the draft with no > port assignment, and have implementations squat an unallocated port. > > > What are people's thoughts? > > None that can be expressed without profanity. > > (Please have a look at the IANA UDP port registry -- thousands of ports > have been allocated to completely undocumented obscure protocols, and > they're refusing to allocate a single port for a standards track document?) > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Fri Jun 7 13:26:55 2019 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 9F3631200C7; Fri, 7 Jun 2019 13:26:52 -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.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <155993921258.27361.8816286977330136579@ietfa.amsl.com> Date: Fri, 07 Jun 2019 13:26:52 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-hmac-05.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-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, 07 Jun 2019 20:26:53 -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 : HMAC authentication for the Babel routing protocol Authors : Clara Do Weronika Kolodziejak Juliusz Chroboczek Filename : draft-ietf-babel-hmac-05.txt Pages : 18 Date : 2019-06-07 Abstract: This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance. This document updates RFC 6126bis and obsoletes RFC 7298. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-hmac/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-hmac-05 https://datatracker.ietf.org/doc/html/draft-ietf-babel-hmac-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-hmac-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 7 13:37:09 2019 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 8FEEA120141 for ; Fri, 7 Jun 2019 13:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 zZHTYvcuHxqw for ; Fri, 7 Jun 2019 13:37:06 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25309120140 for ; Fri, 7 Jun 2019 13:37:05 -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/82085) with ESMTP id x57Kb1rB007795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Jun 2019 22:37:01 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x57Kb2as009736; Fri, 7 Jun 2019 22:37: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 23AFB8EF3D; Fri, 7 Jun 2019 22:37:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id RVObO-CoyfBw; Fri, 7 Jun 2019 22:37:03 +0200 (CEST) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1965B8EF3B; Fri, 7 Jun 2019 22:37:03 +0200 (CEST) Date: Fri, 07 Jun 2019 22:37:03 +0200 Message-ID: <87tvd1ku8g.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake Cc: David Schinazi , Babel at IETF In-Reply-To: References: <87tvda7omc.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 07 Jun 2019 22:37:01 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 07 Jun 2019 22:37:02 +0200 (CEST) X-Miltered: at korolev with ID 5CFACAED.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5CFACAEE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5CFACAED.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5CFACAEE.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 : 5CFACAED.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5CFACAEE.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] Babel over DTLS and UDP ports X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 07 Jun 2019 20:37:08 -0000 > I don't think the IANA expert is trying to be bureaucratic; Sorry if I worded that too strongly. (To my discharge, it was during exam season, and I was collapsing under the weight of uncorrected student papers.) -- Juliusz From nobody Thu Jun 20 10:47:36 2019 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 D332712012D; Thu, 20 Jun 2019 10:47:33 -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.98.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156105285382.3060.7127107418409642152@ietfa.amsl.com> Date: Thu, 20 Jun 2019 10:47:33 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-hmac-06.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-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, 20 Jun 2019 17:47:34 -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 : HMAC authentication for the Babel routing protocol Authors : Clara Do Weronika Kolodziejak Juliusz Chroboczek Filename : draft-ietf-babel-hmac-06.txt Pages : 19 Date : 2019-06-20 Abstract: This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance. This document updates RFC 6126bis and obsoletes RFC 7298. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-hmac/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-hmac-06 https://datatracker.ietf.org/doc/html/draft-ietf-babel-hmac-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-hmac-06 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 Jun 20 11:05:19 2019 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 397AA120018; Thu, 20 Jun 2019 11:05:12 -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.98.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156105391217.2916.10817132598068553312@ietfa.amsl.com> Date: Thu, 20 Jun 2019 11:05:12 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-hmac-07.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-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, 20 Jun 2019 18:05:12 -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 : HMAC authentication for the Babel routing protocol Authors : Clara Do Weronika Kolodziejak Juliusz Chroboczek Filename : draft-ietf-babel-hmac-07.txt Pages : 19 Date : 2019-06-20 Abstract: This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance. This document obsoletes RFC 7298. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-hmac/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-hmac-07 https://datatracker.ietf.org/doc/html/draft-ietf-babel-hmac-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-hmac-07 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 Jun 20 11:28:49 2019 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 5937012009C; Thu, 20 Jun 2019 11:28:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.98.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: babel-chairs@ietf.org, babel@ietf.org, draft-ietf-babel-applicability@ietf.org, Donald Eastlake , d3e3e3@gmail.com, martin.vigoureux@nokia.com Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156105532735.3122.6878503391989528541.idtracker@ietfa.amsl.com> Date: Thu, 20 Jun 2019 11:28:47 -0700 Archived-At: Subject: [babel] Last Call: (Applicability of the Babel routing protocol) to Informational RFC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-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, 20 Jun 2019 18:28:47 -0000 The IESG has received a request from the Babel routing protocol WG (babel) to consider the following document: - 'Applicability of the Babel routing protocol' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-07-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Babel is a routing protocol based on the distance-vector algorithm augmented with mechanisms for loop avoidance and starvation avoidance. In this document, we argue that there exist niches where Babel is useful and that are not adequately served by more mature protocols. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-babel-applicability/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-babel-applicability/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jun 20 11:29:37 2019 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 06A2E12018F; Thu, 20 Jun 2019 11:29:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.98.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com, draft-ietf-babel-dtls@ietf.org, martin.vigoureux@nokia.com Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156105537001.3114.5662675673410583106.idtracker@ietfa.amsl.com> Date: Thu, 20 Jun 2019 11:29:30 -0700 Archived-At: Subject: [babel] Last Call: (Babel Routing Protocol over Datagram Transport Layer Security) to Proposed Standard X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-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, 20 Jun 2019 18:29:35 -0000 The IESG has received a request from the Babel routing protocol WG (babel) to consider the following document: - 'Babel Routing Protocol over Datagram Transport Layer Security' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-07-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Babel Routing Protocol does not contain any means to authenticate neighbours or protect messages sent between them. This document specifies a mechanism to ensure these properties, using Datagram Transport Layer Security (DTLS). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jun 20 11:30:21 2019 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 2B26112014B; Thu, 20 Jun 2019 11:30:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.98.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: draft-ietf-babel-rfc6126bis@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com, martin.vigoureux@nokia.com Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156105540916.2933.16211708123186819533.idtracker@ietfa.amsl.com> Date: Thu, 20 Jun 2019 11:30:09 -0700 Archived-At: Subject: [babel] Last Call: (The Babel Routing Protocol) to Proposed Standard X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-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, 20 Jun 2019 18:30:15 -0000 The IESG has received a request from the Babel routing protocol WG (babel) to consider the following document: - 'The Babel Routing Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-07-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol, and obsoletes RFCs 6126 and 7557. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jun 20 11:31:02 2019 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 21882120186; Thu, 20 Jun 2019 11:30:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.98.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: babel-chairs@ietf.org, babel@ietf.org, draft-ietf-babel-hmac@ietf.org, Donald Eastlake , d3e3e3@gmail.com, martin.vigoureux@nokia.com Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156105545212.2973.1113304261991325847.idtracker@ietfa.amsl.com> Date: Thu, 20 Jun 2019 11:30:52 -0700 Archived-At: Subject: [babel] Last Call: (HMAC authentication for the Babel routing protocol) to Proposed Standard X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-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, 20 Jun 2019 18:31:00 -0000 The IESG has received a request from the Babel routing protocol WG (babel) to consider the following document: - 'HMAC authentication for the Babel routing protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-07-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance. This document obsoletes RFC 7298. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-babel-hmac/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-babel-hmac/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7693: The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC) (Informational - Independent Submission Editor stream) From nobody Thu Jun 20 15:16:28 2019 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 ACD331201DB; Thu, 20 Jun 2019 15:16:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: David Schinazi via Datatracker To: Cc: draft-ietf-babel-hmac.all@ietf.org, ietf@ietf.org, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: David Schinazi Message-ID: <156106898665.12408.8788016399506415627@ietfa.amsl.com> Date: Thu, 20 Jun 2019 15:16:26 -0700 Archived-At: Subject: [babel] Genart last call review of draft-ietf-babel-hmac-07 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-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, 20 Jun 2019 22:16:27 -0000 Reviewer: David Schinazi Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-babel-hmac-07 Reviewer: David Schinazi Review Date: 2019-06-20 IETF LC End Date: 2019-07-04 IESG Telechat date: Not scheduled for a telechat Summary: Document is ready for publication. It is concise and well-written. Major issues: None Minor issues: None Nits/editorial comments: - On the second line of Section 3.1, I think "Section 3.2.3 [RFC6126bis]" should be "Section 3.2.3 of [RFC6126bis]" From nobody Thu Jun 20 23:27:13 2019 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 4F85812006F; Thu, 20 Jun 2019 23:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 r585kXg2IEXY; Thu, 20 Jun 2019 23:27:10 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 23C1C120025; Thu, 20 Jun 2019 23:27:10 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id u13so1305242iop.0; Thu, 20 Jun 2019 23:27:10 -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=G4L/qi5m9PYSoGX1FrDDKrK3YUXkxFpwAg3S+h0uG0g=; b=alOD4P5oaxCRP4fcyzEeWfBybQTiEpyBM7/VWWcSHDwmhgXvuf7Ef+mE1NNAahQUf/ HCsV9Df3+UICjCQiz4R2mc1DlQTWzXpoGAc5AYEmmVmaz2yQuRP+wx2MKhaEHaV5Mu53 9SBkOXdiU+7JOZk5YAnr3iuh0lsGX9oFkjSuoakGNnvlcdVJDFbjBGT9A3e9Itquq5IV tlNv3JXDq08C2TyHRUDI3vzfa/cUkclANER+ISmSbrsuc3/AwoGqyDQSKw6pV6f9Nhb9 Hql3yB3LCQ3/pxH4j3mVCzluYMkFhS19uIcVvIBbOQ/rw3KlNeIMgnoazx7Z+t+G1EZR KFbg== 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=G4L/qi5m9PYSoGX1FrDDKrK3YUXkxFpwAg3S+h0uG0g=; b=rREINsyUJPlkCIZruYl/pAHO/U8aw5PKk+H2+NVG2Qt4Kgxe9erQRVA5Z0ZUUybPk9 DEuVG7fJ+bdP2zAyAnK+vxlXzALVxkSFl2BFredpkvK2TDuTprE0ajw2eo12Br4Pfd1n n1yJVdrSBMsGlG1GeJuoPcC92huDp5LQndCfblFy0FycByQDiljq6zJmkEmj3knuTsvO PH6h1Vy/kMA9uT3teyo0X9va1LMZphhhdCi1P2w5Khb/ktIFWzh7z3CrTakv/GVt5PE1 m6mKRPSKc2P2C79O42MGsP6sgICeUApzQqG7VUKvHQULhWpSci2wjkOpZIZr8kjJoJsY n9MQ== X-Gm-Message-State: APjAAAX3w4WU2UV87nFEHxEiQBB63yrItTzrFXeN34Eu6XyhTo3Ju7N+ Rw0Wih45wX+CXRySOogqfih+sXERFaGnOBI8L5CTK19v X-Google-Smtp-Source: APXvYqx/t6u9Iw9S/XMyykfSRzQNFRCWbhRRMxo1s+UFw3nqTWuiO/s92zMXTZKATe8p33DRw80kRp2SIErmKCFEJlY= X-Received: by 2002:a5e:c00a:: with SMTP id u10mr50393596iol.24.1561098429005; Thu, 20 Jun 2019 23:27:09 -0700 (PDT) MIME-Version: 1.0 From: Donald Eastlake Date: Fri, 21 Jun 2019 02:26:57 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [babel] My affiliation X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 21 Jun 2019 06:27:12 -0000 In case anyone was wondering, I am employed by and affiliated with Futurewei Technologies, Inc., a wholly owned but independently operated subsidiary of Huawei Technologies. Futurewei Technologies, Inc., is not on the US Government entity list and not subject to any special export restrictions as far as I know. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com From nobody Sat Jun 22 10:23:29 2019 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 DF79E12011A; Sat, 22 Jun 2019 10:23:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley via Datatracker To: Cc: draft-ietf-babel-rfc6126bis.all@ietf.org, ietf@ietf.org, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Russ Housley Message-ID: <156122420684.16418.15464371573444699739@ietfa.amsl.com> Date: Sat, 22 Jun 2019 10:23:26 -0700 Archived-At: Subject: [babel] Genart last call review of draft-ietf-babel-rfc6126bis-10 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-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, 22 Jun 2019 17:23:27 -0000 Reviewer: Russ Housley Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-babel-rfc6126bis-10 Reviewer: Russ Housley Review Date: 2019-06-22 IETF LC End Date: 2019-07-04 IESG Telechat date: Unknown Summary: Ready with Nits Major Concerns: None Minor Concerns: None Nits: Section 3.7.2 says: ... A node SHOULD NOT send triggered updates for other reasons, such as when there is a minor fluctuation in a route's metric, when the selected next hop changes, or to propagate a new sequence number (except to satisfy a request, as specified in Section 3.8). This seem backwards to me. Perhaps: ... The node MUST send triggered updates to satisfy a request, as specified in Section 3.8; however, a node SHOULD NOT send triggered updates for other reasons, including a minor fluctuation in a metric for a route, the selected next hop changes, or to propagate a new sequence number. Section 4 says: A Babel packet is sent as the body of a UDP datagram, with network- layer hop count set to 1, destined to a well-known multicast address or to a unicast address, over IPv4 or IPv6; in the case of IPv6, these addresses are link-local. It seems to me that this should be reworded as MUST statements. A Babel packet MUST be sent as the body of a UDP datagram, with network-layer hop count set to 1, destined to a well-known multicast address or to a unicast address, over either IPv4 or IPv6. When IPv6 addresses are used, the addresses MUST be link-local. Section 4.1.2 says: A router-id is an arbitrary 8-octet value. A router-id MUST NOT consist of either all zeroes or all ones. I do not think you are referring to octets with a value of one. I think you mean that the router-id cannot be 0x0000000000000000 or 0xffffffffffffffff. Please reword. From nobody Mon Jun 24 18:11:25 2019 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 5DA2C1201EC; Mon, 24 Jun 2019 18:11:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern via Datatracker To: Cc: ietf@ietf.org, babel@ietf.org, draft-ietf-babel-applicability.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Joel Halpern Message-ID: <156142508331.17776.2290417666551756858@ietfa.amsl.com> Date: Mon, 24 Jun 2019 18:11:23 -0700 Archived-At: Subject: [babel] Genart last call review of draft-ietf-babel-applicability-06 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-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, 25 Jun 2019 01:11:23 -0000 Reviewer: Joel Halpern Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-babel-applicability-06 Reviewer: Joel Halpern Review Date: 2019-06-24 IETF LC End Date: 2019-07-04 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as an Informational RFC Major issues: N/A Minor issues: N/A Nits/editorial comments: In section 2.2, in talking about "metric M", if I have understood properly, I think it would be clearer if you referred to "metric value M". From nobody Tue Jun 25 09:50:39 2019 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 277A61208D8; Tue, 25 Jun 2019 09:50:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu via Datatracker To: Cc: draft-ietf-babel-dtls.all@ietf.org, ietf@ietf.org, babel@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Dan Romascanu Message-ID: <156148141106.31261.11148445355862352575@ietfa.amsl.com> Date: Tue, 25 Jun 2019 09:50:11 -0700 Archived-At: Subject: [babel] Genart last call review of draft-ietf-babel-dtls-05 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-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, 25 Jun 2019 16:50:15 -0000 Reviewer: Dan Romascanu Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-babel-dtls-05 Reviewer: Dan Romascanu Review Date: 2019-06-25 IETF LC End Date: 2019-07-04 IESG Telechat date: Not scheduled for a telechat Summary: The document is Ready from a Gen-ART perspective. A couple of unclear / redundant statements are mentioned in the 'nits/editorial comments' bullet below. Major issues: Minor issues: Nits/editorial comments: 1. In section 2.1: > The default port for Babel over DTLS is registered with IANA as the "babel-dtls" port (UDP port TBD, see Section 4), and the port exchanging unencrypted Babel traffic is registered as the "babel" port (UDP port 6696). A reference would be desirable here. 2. In section 2.4 > Nodes MUST silently ignore any unprotected packet sent over unicast. When parsing an unprotected packet, a node MUST silently ignore all TLVs that are not of type Hello. Nodes MUST also silently ignore any unprotected Hello with the Unicast flag set. Is the last sentence necessary? Is this case not covered by the statement in the first sentence? From nobody Tue Jun 25 11:29:53 2019 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 95757120997; Tue, 25 Jun 2019 11:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 2N6MUsJ-7t5t; Tue, 25 Jun 2019 11:29:37 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 5D859120379; Tue, 25 Jun 2019 11:29:29 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id 136so13366946lfa.8; Tue, 25 Jun 2019 11:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fZK+jtCYP5vZZGaBRKfeO1bOYp3LwA4rsRa0q0xYVdk=; b=H2/9Ao+q43hsRsXOoT/5NQGH6z+2kOOR0R3Pocsk/c0uJYONCMPzUqZo/baIRnsmwy nb+4voZkvyU3FtRfTamj8JzN6thIHrN/vjT99d+A4yvHvwN2cAvTGZAxZ082xw4nK7gs mzLjkoIIh/KN9txxPW5klvV0U/KvmF0WmEXbU7LebMPXatWT5f/8XeTSmnAqiEjJUth1 /kEs/Nnx7I6+oL2IO3yk1STczj58aiCUK7mJ+RvADRVUII/8zZom05O7uLmn9FpaxNHT 22oKHZ3jon8OvvY0mX7geYdGkwEm7UPDqdWYO5G1iCdDNBo2JZMsa74v2mux7S0HqtD6 F84A== 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=fZK+jtCYP5vZZGaBRKfeO1bOYp3LwA4rsRa0q0xYVdk=; b=EC0MAgdhJLK1fWDMTqDPLeIG8a16z8wpFMHszZ1L39blUO2ZJZgS3a3y77/GlQgHTk ox0L07URNSG4u+Fo01vUaIRZWGMBOGKya/kpas7SDcqshbW2TssZSsQ8NFJ1P/C6Sb1+ vab3mKiFCyQBmy9PPgDJM+bdirvFGnw4jsiRXIcWJpp6AOYq6LK56SHN1qddeUR1gH/W KEvvcVlxT5gpQZW/+AYUvqou6ONtOmCUL7YvZ6tlOniOwvN4uZKJ++YVk74Z611dLjAG 6rlmDCWdykqfQmZ55Essaw73Y7IYzRGzHR0n2BRr9kVpuN6aoQmK/r/9rDDe0nag5JC/ 2utQ== X-Gm-Message-State: APjAAAXImW9UUONqIWT5gOdWpPt6+6yOMwNq9QwZvXa97aBx2Buy7TVs hJboFiAvw4wc2vhY/vTqeni4mJ+oiD3fDhs+qOA= X-Google-Smtp-Source: APXvYqy/M4wcLGSIgUS/U9ShzfrcymNHLcXIxlPeYMMrJ9VSexWsaRxS+r9mrYT7YaufI+iQ+mAZk8Lftp5RGTizw4g= X-Received: by 2002:a05:6512:51c:: with SMTP id o28mr112017lfb.67.1561487367412; Tue, 25 Jun 2019 11:29:27 -0700 (PDT) MIME-Version: 1.0 References: <156148141106.31261.11148445355862352575@ietfa.amsl.com> In-Reply-To: <156148141106.31261.11148445355862352575@ietfa.amsl.com> From: David Schinazi Date: Tue, 25 Jun 2019 11:29:16 -0700 Message-ID: To: Dan Romascanu Cc: gen-art@ietf.org, draft-ietf-babel-dtls.all@ietf.org, IETF Discussion , Babel at IETF Content-Type: multipart/alternative; boundary="000000000000db1e06058c2a1b33" Archived-At: Subject: Re: [babel] Genart last call review of draft-ietf-babel-dtls-05 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 25 Jun 2019 18:29:39 -0000 --000000000000db1e06058c2a1b33 Content-Type: text/plain; charset="UTF-8" Hello Dan, and thanks for your review. Comments inline. 1. In section 2.1: > > > The default port > for Babel over DTLS is registered with IANA as the "babel-dtls" port > (UDP port TBD, see Section 4), and the port exchanging unencrypted > Babel traffic is registered as the "babel" port (UDP port 6696). > > A reference would be desirable here. > What reference do you have in mind? This paragraph already has a reference to Section 4 (IANA Considerations). > 2. In section 2.4 > > > Nodes MUST silently ignore any unprotected > packet sent over unicast. When parsing an unprotected packet, a node > MUST silently ignore all TLVs that are not of type Hello. Nodes MUST > also silently ignore any unprotected Hello with the Unicast flag set. > > Is the last sentence necessary? Is this case not covered by the statement > in > the first sentence? > The Unicast flag is a bit in the Babel packet. This statement instructs nodes to ignore a Hello TLV which was received over multicast but has the unicast flag set. Thanks, David --000000000000db1e06058c2a1b33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Dan, and thanks for your review. Co= mments inline.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> 1. In section 2.1:

> The default port
=C2=A0 =C2=A0for Babel over DTLS is registered with IANA as the "babel= -dtls" port
=C2=A0 =C2=A0(UDP port TBD, see Section 4), and the port exchanging unencry= pted
=C2=A0 =C2=A0Babel traffic is registered as the "babel" port (UDP= port 6696).

A reference would be desirable here.

Wh= at reference do you have in mind? This paragraph already has a
re= ference to Section 4 (IANA Considerations).
=C2=A0
2. In section 2.4

> Nodes MUST silently ignore any unprotected
=C2=A0 =C2=A0packet sent over unicast.=C2=A0 When parsing an unprotected pa= cket, a node
=C2=A0 =C2=A0MUST silently ignore all TLVs that are not of type Hello.=C2= =A0 Nodes MUST
=C2=A0 =C2=A0also silently ignore any unprotected Hello with the Unicast fl= ag set.

Is the last sentence necessary? Is this case not covered by the statement i= n
the first sentence?

The Unicast flag is= a bit in the Babel packet. This statement instructs nodes
to ign= ore a Hello TLV which was received over multicast but has the unicast flag = set.

Thanks,
David
=C2=A0
--000000000000db1e06058c2a1b33-- From nobody Tue Jun 25 11:41:07 2019 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 8D1B3120995; Tue, 25 Jun 2019 11:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 QuHFADUkTu-H; Tue, 25 Jun 2019 11:41:04 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 9CBE61202E0; Tue, 25 Jun 2019 11:41:04 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id n5so272979ioc.7; Tue, 25 Jun 2019 11:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LKwxavEBodJ3OPwazuUaCUziZ6MQqRiwwFKpeAK3IrE=; b=OLob05BrlSX42IvLKbvgI8t5WBPYKs4/1Rawn5PwBCGemNnbMgsuDhSGEz28HbCazT gv/sfOwyh9RY/aiGp4ShDWw6/bVI0HxQOxv3mz9y+RkT8jRA0BuZE8SUNM+/U0bacCrx mctjiPwaJUsNagTSOtuTRWvFgvli2V4NmDgKgRfLAKvjin/AZbpLvKTCu/LStfH3Hmec 7cxlzXdgmmq8pOF3CHW/1J5SxLABtTkG4qfmdqpyb1ErbvrXzVvOmdMXBYVLC1OD85BF 3Fiw26L+dbhZ06sgDhTCTvz5ruNbDWVLkbKs5+CAhpmLgh3IfQL5hv7m4VDeDo7tkVVg Hf1Q== 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=LKwxavEBodJ3OPwazuUaCUziZ6MQqRiwwFKpeAK3IrE=; b=HBBoByiPrJ1PVzAHMMC0LdLGo06/u8gXoNRrqSn2mmBJfUlOmxs7O6ORb3o3Eyn4nh L/INvzuD9DyR3GihOzu+u8g0ibmfGbS88jvb04eXW/5DvZe8QLQEyaa2NHSE/rpBGlFI ka5ukfRELfswFDFucHcQ3XUuGYwZbD/O2b9QFZCgQuFxMyn3snloTxJniuaza+KjHqEA xa7onfUkgtXVPGueQJs7Xr2SQm4+CnU2OsaqPpT3ti3Ulx6g61wtxjaBeucxTObHJF1C PP4UsF599mrfCD5O5P9qsaSZJkMSnWkWLIUqVjDHBWidP9lxiSfxYQ073WwD51+dEgwK i7PQ== X-Gm-Message-State: APjAAAVwEjlAf4AYAH+qgXB5nsdz++FUcASf4+jBd4GTjELg9pGEftA7 4AWyNO5hG9YMJ0/EMmKQSXBtFm4jasYmFL16rr4= X-Google-Smtp-Source: APXvYqzb7yh/Dui2LjwDzb8hMTPlNhoj/7oaqGexufNmdtR6xrsq/7VxcuEwjGoHUTOhCiwkt5LFExR3Hs545KzcRzM= X-Received: by 2002:a5d:8451:: with SMTP id w17mr63532ior.226.1561488063907; Tue, 25 Jun 2019 11:41:03 -0700 (PDT) MIME-Version: 1.0 References: <156148141106.31261.11148445355862352575@ietfa.amsl.com> In-Reply-To: From: Dan Romascanu Date: Tue, 25 Jun 2019 21:40:51 +0300 Message-ID: To: David Schinazi Cc: gen-art , draft-ietf-babel-dtls.all@ietf.org, IETF Discussion , Babel at IETF Content-Type: multipart/alternative; boundary="0000000000005ec9ca058c2a454d" Archived-At: Subject: Re: [babel] Genart last call review of draft-ietf-babel-dtls-05 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 25 Jun 2019 18:41:06 -0000 --0000000000005ec9ca058c2a454d Content-Type: text/plain; charset="UTF-8" Thanks for the quick reply. See in-line. regards, Dan On Tue, Jun 25, 2019 at 9:29 PM David Schinazi wrote: > Hello Dan, and thanks for your review. Comments inline. > > 1. In section 2.1: >> >> > The default port >> for Babel over DTLS is registered with IANA as the "babel-dtls" port >> (UDP port TBD, see Section 4), and the port exchanging unencrypted >> Babel traffic is registered as the "babel" port (UDP port 6696). >> >> A reference would be desirable here. >> > > What reference do you have in mind? This paragraph already has a > reference to Section 4 (IANA Considerations). > the section in the Babel spec that defines the "babel" port (UDP port 6696, see ....) > >> 2. In section 2.4 >> >> > Nodes MUST silently ignore any unprotected >> packet sent over unicast. When parsing an unprotected packet, a node >> MUST silently ignore all TLVs that are not of type Hello. Nodes MUST >> also silently ignore any unprotected Hello with the Unicast flag set. >> >> Is the last sentence necessary? Is this case not covered by the statement >> in >> the first sentence? >> > > The Unicast flag is a bit in the Babel packet. This statement instructs > nodes > to ignore a Hello TLV which was received over multicast but has the > unicast flag set. > Thanks for the clarification. > Thanks, > David > > --0000000000005ec9ca058c2a454d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the quick reply.

See in-line.

regards,

Dan


On Tue, Jun 25, 2019 at 9:2= 9 PM David Schinazi <dschina= zi.ietf@gmail.com> wrote:
Hello Dan, and thanks fo= r your review. Comments inline.

1. In section 2.1:

> The default port
=C2=A0 =C2=A0for Babel over DTLS is registered with IANA as the "babel= -dtls" port
=C2=A0 =C2=A0(UDP port TBD, see Section 4), and the port exchanging unencry= pted
=C2=A0 =C2=A0Babel traffic is registered as the "babel" port (UDP= port 6696).

A reference would be desirable here.

Wh= at reference do you have in mind? This paragraph already has a
re= ference to Section 4 (IANA Considerations).
<= div>
the section in the Babel spec that defines the "bab= el" port (UDP port 6696, see ....)


=C2=A0
2. In section 2.4

> Nodes MUST silently ignore any unprotected
=C2=A0 =C2=A0packet sent over unicast.=C2=A0 When parsing an unprotected pa= cket, a node
=C2=A0 =C2=A0MUST silently ignore all TLVs that are not of type Hello.=C2= =A0 Nodes MUST
=C2=A0 =C2=A0also silently ignore any unprotected Hello with the Unicast fl= ag set.

Is the last sentence necessary? Is this case not covered by the statement i= n
the first sentence?

The Unicast flag is= a bit in the Babel packet. This statement instructs nodes
to ign= ore a Hello TLV which was received over multicast but has the unicast flag = set.

Thanks for the clari= fication.


= Thanks,
David
=C2=A0
--0000000000005ec9ca058c2a454d-- From nobody Tue Jun 25 12:20:11 2019 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 22ED6120C36; Tue, 25 Jun 2019 12:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 1-AWo8XVFTK2; Tue, 25 Jun 2019 12:19:52 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 0DA16120C07; Tue, 25 Jun 2019 12:19:52 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id 136so13470385lfa.8; Tue, 25 Jun 2019 12:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/BLpxN86CpFZcrHFoA/pf4CL1wzr8VcesxDb8Lm15qo=; b=BukpaEu/ZahfXESGI2lbOTwYt1AfE440MuqzNakADkRlAzo+TQW9rq7GnzyHFo8hH2 cHDtvBWFA2SI17+DmADi226RstD/7gWsdY26wHDLGlY9YlK67v4aDhYkSmvpefAa+OZB 0e8i94QXPjRstbI7j2y5AOM45kKS69DzzXSPPtSl4i40HhQvI1dwx59MyDhunDJybRuB 8BhqnAQfFKznDzqEckK9e8Kvb2OE8gwoWUt+aw+8+ps7Y5vCYUifeAAujKN1RZJQpvl2 T2k+ZnAz3V3CyDwxh4rchFqbis7GbzEXA3eJH+CydkRh9zsAXrYtrqXNFy0AzIY4DdHk DiQA== 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=/BLpxN86CpFZcrHFoA/pf4CL1wzr8VcesxDb8Lm15qo=; b=G6s5ayW2e3ljumBmcLTWYSGGgOcT30c1x4z23JOtGFJoU+toM6W2+6sgU+Pd8e2qYw 7CfZjrrn27QudHB3J4poRqjvgr7xGeCNESsshHfKiIKLeBASRwjVxRb/jBJvH+nIrK4C IljN1ABEdUlnIaBJvuynnWKns//oGAsFz82J/sv9HnOcFu7V8O5Naz0S+4HTbJpykf0n nFy1Gel/G8corZq8LKnBuWRJ5nV6PmjMM3XG8k3QVrMxJ0rJZ01coZkOLNYoGZnilYuh tv2SU2XmSkzSL7TQviUQlJmBnCGkz893umXgwIdi/7Vz9H/znImZAVIe25hpINuS6cVi 7A5g== X-Gm-Message-State: APjAAAX/yPY+mjCevoR2bi01hdvid+62u35hdJ5EZDFvxV9WwAo6TZMV J3Uv4HegDCOmjM32jiJU9Nzb/S92KAIu2aYAuik= X-Google-Smtp-Source: APXvYqykynUy8CJa0FjWsjI+zB22DYayeqQBY4rLSO9VX6W7AHTlgQU5oxlDQQii6zoe6LXAjbxecdQB2CulGp7SjHI= X-Received: by 2002:ac2:4848:: with SMTP id 8mr263496lfy.10.1561490390203; Tue, 25 Jun 2019 12:19:50 -0700 (PDT) MIME-Version: 1.0 References: <156148141106.31261.11148445355862352575@ietfa.amsl.com> In-Reply-To: From: David Schinazi Date: Tue, 25 Jun 2019 12:19:39 -0700 Message-ID: To: Dan Romascanu Cc: gen-art , draft-ietf-babel-dtls.all@ietf.org, IETF Discussion , Babel at IETF Content-Type: multipart/alternative; boundary="0000000000000740cd058c2ad0b3" Archived-At: Subject: Re: [babel] Genart last call review of draft-ietf-babel-dtls-05 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 25 Jun 2019 19:19:54 -0000 --0000000000000740cd058c2ad0b3 Content-Type: text/plain; charset="UTF-8" Thanks Dan. I've pushed a commit with your suggestions: https://github.com/jech/babel-drafts/commit/8d6a6fc05ce4c621b38d2c7621c4157300380078 We'll upload -06 at the end of this round of comments. David On Tue, Jun 25, 2019 at 11:41 AM Dan Romascanu wrote: > Thanks for the quick reply. > > See in-line. > > regards, > > Dan > > > On Tue, Jun 25, 2019 at 9:29 PM David Schinazi > wrote: > >> Hello Dan, and thanks for your review. Comments inline. >> >> 1. In section 2.1: >>> >>> > The default port >>> for Babel over DTLS is registered with IANA as the "babel-dtls" port >>> (UDP port TBD, see Section 4), and the port exchanging unencrypted >>> Babel traffic is registered as the "babel" port (UDP port 6696). >>> >>> A reference would be desirable here. >>> >> >> What reference do you have in mind? This paragraph already has a >> reference to Section 4 (IANA Considerations). >> > > the section in the Babel spec that defines the "babel" port (UDP port > 6696, see ....) > > > >> >>> 2. In section 2.4 >>> >>> > Nodes MUST silently ignore any unprotected >>> packet sent over unicast. When parsing an unprotected packet, a node >>> MUST silently ignore all TLVs that are not of type Hello. Nodes MUST >>> also silently ignore any unprotected Hello with the Unicast flag set. >>> >>> Is the last sentence necessary? Is this case not covered by the >>> statement in >>> the first sentence? >>> >> >> The Unicast flag is a bit in the Babel packet. This statement instructs >> nodes >> to ignore a Hello TLV which was received over multicast but has the >> unicast flag set. >> > > Thanks for the clarification. > > >> Thanks, >> David >> >> > --0000000000000740cd058c2ad0b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Dan. I've pushed a commit with your suggestions= :

We&#= 39;ll upload -06 at the end of this round of comments.

=
David

On Tue, Jun 25, 2019 at 11:41 AM Dan Romascanu <dromasca@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Thanks for the quick reply.

See= in-line.

regards,

D= an


On Tue, Jun 25, 2019 at 9:29 PM David Schinazi <<= a href=3D"mailto:dschinazi.ietf@gmail.com" target=3D"_blank">dschinazi.ietf= @gmail.com> wrote:
Hello Dan, and thanks for your= review. Comments inline.

1. In section 2.1:

> The default port
=C2=A0 =C2=A0for Babel over DTLS is registered with IANA as the "babel= -dtls" port
=C2=A0 =C2=A0(UDP port TBD, see Section 4), and the port exchanging unencry= pted
=C2=A0 =C2=A0Babel traffic is registered as the "babel" port (UDP= port 6696).

A reference would be desirable here.

Wh= at reference do you have in mind? This paragraph already has a
re= ference to Section 4 (IANA Considerations).
<= div>
the section in the Babel spec that defines the "bab= el" port (UDP port 6696, see ....)


=C2=A0
2. In section 2.4

> Nodes MUST silently ignore any unprotected
=C2=A0 =C2=A0packet sent over unicast.=C2=A0 When parsing an unprotected pa= cket, a node
=C2=A0 =C2=A0MUST silently ignore all TLVs that are not of type Hello.=C2= =A0 Nodes MUST
=C2=A0 =C2=A0also silently ignore any unprotected Hello with the Unicast fl= ag set.

Is the last sentence necessary? Is this case not covered by the statement i= n
the first sentence?

The Unicast flag is= a bit in the Babel packet. This statement instructs nodes
to ign= ore a Hello TLV which was received over multicast but has the unicast flag = set.

Thanks for the clari= fication.


= Thanks,
David
=C2=A0
--0000000000000740cd058c2ad0b3-- From nobody Thu Jun 27 17:39:20 2019 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 ACE241200F7; Thu, 27 Jun 2019 17:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 Lp9gNuBEVFEu; Thu, 27 Jun 2019 17:39:00 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2879D1200B2; Thu, 27 Jun 2019 17:38:59 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x5S0ctVJ029709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Jun 2019 02:38:55 +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/82085) with ESMTP id x5S0ct6O028979; Fri, 28 Jun 2019 02:38:55 +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 A94E648EBA; Fri, 28 Jun 2019 02:38:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id twm-dKLVtOEJ; Fri, 28 Jun 2019 02:38:56 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6C80048EB8; Fri, 28 Jun 2019 02:38:56 +0200 (CEST) Date: Fri, 28 Jun 2019 02:38:56 +0200 Message-ID: <87woh6a6hr.wl-jch@irif.fr> From: Juliusz Chroboczek To: Russ Housley Cc: , draft-ietf-babel-rfc6126bis.all@ietf.org, ietf@ietf.org, babel@ietf.org In-Reply-To: <156122420684.16418.15464371573444699739@ietfa.amsl.com> References: <156122420684.16418.15464371573444699739@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 [IPv6:2001:660:3301:8000::1:2]); Fri, 28 Jun 2019 02:38:55 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 28 Jun 2019 02:38:55 +0200 (CEST) X-Miltered: at korolev with ID 5D15619F.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D15619F.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D15619F.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D15619F.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 : 5D15619F.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D15619F.002 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Genart last call review of draft-ietf-babel-rfc6126bis-10 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 00:39:03 -0000 Dear Russ, Thank you very much for your review. I agree with all of your comments save one, I'll publish a new revision taking your comments into account as soon as possible. > ... A node SHOULD NOT send triggered updates > for other reasons, such as when there is a minor fluctuation in a > route's metric, when the selected next hop changes, or to propagate a > new sequence number (except to satisfy a request, as specified in > Section 3.8). > This seem backwards to me. Perhaps: > ... The node MUST send triggered updates to satisfy a request, as > specified in Section 3.8; however, a node SHOULD NOT send > triggered updates for other reasons, including a minor fluctuation > in a metric for a route, the selected next hop changes, or to > propagate a new sequence number. I disagree. The requirement to send triggered updates is already present in 3.8.1.1, we should not repeat it. This section is concerned with avoiding excessive noise. > Section 4 says: > A Babel packet is sent as the body of a UDP datagram, with network- > layer hop count set to 1, destined to a well-known multicast address > or to a unicast address, over IPv4 or IPv6; in the case of IPv6, > these addresses are link-local. > It seems to me that this should be reworded as MUST statements. Agreed. > Section 4.1.2 says: > A router-id is an arbitrary 8-octet value. A router-id MUST NOT > consist of either all zeroes or all ones. > I do not think you are referring to octets with a value of one. I > think you mean that the router-id cannot be 0x0000000000000000 or > 0xffffffffffffffff. Please reword. Agreed. Thanks again, -- Juliusz From nobody Thu Jun 27 17:41:47 2019 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 C008B120169; Thu, 27 Jun 2019 17:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 Dar_Ak06oBAd; Thu, 27 Jun 2019 17:41: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 EFD231200B2; Thu, 27 Jun 2019 17:41:26 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x5S0fMo0030372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Jun 2019 02:41:22 +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/82085) with ESMTP id x5S0fMmN029546; Fri, 28 Jun 2019 02:41:22 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5EC9A48ED2; Fri, 28 Jun 2019 02:41:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id be8M4au5OmoI; Fri, 28 Jun 2019 02:41:23 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 439C648ED0; Fri, 28 Jun 2019 02:41:22 +0200 (CEST) Date: Fri, 28 Jun 2019 02:41:22 +0200 Message-ID: <87v9wqa6dp.wl-jch@irif.fr> From: Juliusz Chroboczek To: Joel Halpern Cc: , ietf@ietf.org, babel@ietf.org, draft-ietf-babel-applicability.all@ietf.org In-Reply-To: <156142508331.17776.2290417666551756858@ietfa.amsl.com> References: <156142508331.17776.2290417666551756858@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 [IPv6:2001:660:3301:8000::1:2]); Fri, 28 Jun 2019 02:41:22 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 28 Jun 2019 02:41:22 +0200 (CEST) X-Miltered: at korolev with ID 5D156232.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D156232.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D156232.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D156232.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 : 5D156232.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D156232.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] Genart last call review of draft-ietf-babel-applicability-06 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 00:41:32 -0000 Dear Joel, Thank you very much for your review. > Nits/editorial comments: > In section 2.2, in talking about "metric M", if I have understood properly, > I think it would be clearer if you referred to "metric value M". Thanks, noted. If that's okay with you, I'll wait for the RTGDIR review before submitting a new revision. -- Juliusz From nobody Thu Jun 27 18:12:15 2019 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 75D061201A2; Thu, 27 Jun 2019 18:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 fT6D7mYkK5Dv; Thu, 27 Jun 2019 18:12:11 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 5B68212009C; Thu, 27 Jun 2019 18:12:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 45Zdyz1t9Dz1sq7n; Thu, 27 Jun 2019 18:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1561684331; bh=KItTNs8prDTSHaGfkN4GJdFjMRICtixzsigGKn62m8c=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=BP+aV87TmOCLDk0sJRamnPGtKjFUlOiegWuCfs86W/D/8ka1UzmCgY2TDjMFTwcqU fSQc/CxdyFqgsq7xcB4WHh0kI3UauLLSYw6TQ64xgXg4YK1svsVIsVcXsnRiwCqxVN mSZAM/L7QZlKJQbnIqd9PiyV4rADYcz0pG6+NWKM= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 45Zdyx6Tq1z1sq3y; Thu, 27 Jun 2019 18:12:09 -0700 (PDT) To: Juliusz Chroboczek Cc: gen-art@ietf.org, ietf@ietf.org, babel@ietf.org, draft-ietf-babel-applicability.all@ietf.org References: <156142508331.17776.2290417666551756858@ietfa.amsl.com> <87v9wqa6dp.wl-jch@irif.fr> From: "Joel M. Halpern" Message-ID: <77d2cc55-45fa-ce00-5c06-c5dff3a50510@joelhalpern.com> Date: Thu, 27 Jun 2019 21:12:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <87v9wqa6dp.wl-jch@irif.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [babel] Genart last call review of draft-ietf-babel-applicability-06 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 01:12:14 -0000 Yes, it is (of course) fine to wait for other feedback before submitting a revision. Yours, Joel On 6/27/19 8:41 PM, Juliusz Chroboczek wrote: > Dear Joel, > > Thank you very much for your review. > >> Nits/editorial comments: >> In section 2.2, in talking about "metric M", if I have understood properly, >> I think it would be clearer if you referred to "metric value M". > > Thanks, noted. If that's okay with you, I'll wait for the RTGDIR review > before submitting a new revision. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > From nobody Fri Jun 28 05:31:37 2019 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 639B612009E for ; Fri, 28 Jun 2019 05:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFpbl-4IXqgt for ; Fri, 28 Jun 2019 05:31:27 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA75120058 for ; Fri, 28 Jun 2019 05:31:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 16F1D300AF1 for ; Fri, 28 Jun 2019 08:04:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OVeqIjT5tZSq for ; Fri, 28 Jun 2019 08:04:30 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id B551A3000D7; Fri, 28 Jun 2019 08:04:29 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <87woh6a6hr.wl-jch@irif.fr> Date: Fri, 28 Jun 2019 08:23:45 -0400 Cc: IETF Gen-ART , draft-ietf-babel-rfc6126bis.all@ietf.org, IETF , babel@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <514CAB4A-FADD-4C5C-A653-1C6953BB2F1E@vigilsec.com> References: <156122420684.16418.15464371573444699739@ietfa.amsl.com> <87woh6a6hr.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [babel] Genart last call review of draft-ietf-babel-rfc6126bis-10 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 12:31:28 -0000 Juliusz: > Thank you very much for your review. I agree with all of your comments > save one, I'll publish a new revision taking your comments into account as > soon as possible. > >> ... A node SHOULD NOT send triggered updates >> for other reasons, such as when there is a minor fluctuation in a >> route's metric, when the selected next hop changes, or to propagate a >> new sequence number (except to satisfy a request, as specified in >> Section 3.8). > >> This seem backwards to me. Perhaps: > >> ... The node MUST send triggered updates to satisfy a request, as >> specified in Section 3.8; however, a node SHOULD NOT send >> triggered updates for other reasons, including a minor fluctuation >> in a metric for a route, the selected next hop changes, or to >> propagate a new sequence number. > > I disagree. The requirement to send triggered updates is already present > in 3.8.1.1, we should not repeat it. This section is concerned with > avoiding excessive noise. I defer to your experience. Russ From nobody Fri Jun 28 06:22:04 2019 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 B35F0120146 for ; Fri, 28 Jun 2019 06:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 knDHuyAPddU1 for ; Fri, 28 Jun 2019 06:21:59 -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 9B5911200C1 for ; Fri, 28 Jun 2019 06:21:59 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x5SDLthF005508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 28 Jun 2019 15:21:55 +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/82085) with ESMTP id x5SDLtI8017400 for ; Fri, 28 Jun 2019 15:21:55 +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 CA4A84EFDE for ; Fri, 28 Jun 2019 15:21:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id FuFXJrAm4KnF for ; Fri, 28 Jun 2019 15:21:56 +0200 (CEST) Received: from lanthane.irif.fr (unknown [172.23.36.89]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id BB7664EFDC for ; Fri, 28 Jun 2019 15:21:55 +0200 (CEST) Date: Fri, 28 Jun 2019 15:21:55 +0200 Message-ID: <874l49j158.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 28 Jun 2019 15:21:55 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 28 Jun 2019 15:21:55 +0200 (CEST) X-Miltered: at korolev with ID 5D161473.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D161473.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D161473.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D161473.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 : 5D161473.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D161473.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: [babel] Minor clarification to HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 13:22:02 -0000 Dear all, Sawssen and Étienne (in copy of this mail) are currently working on cleaning up and completing the reference implementation of draft-...-hmac. We have just realised that the draft is not quite clear on two points. The draft says that a neighbour entry MUST NOT be created before HMAC is verified (Section 4.3 first bullet). It later says that a neighbour entry "might need to be created" when a challenge is sent, and "may need to be created" when a challenge is received. However, it does not say whether it is legal to create an entry earlier. I would therefore like to kindly request the permission of the group and the chairs to add the following between the first and second bullet points of Section 4.3: * A neighbour entry for the sender of the packet MAY be created at this stage. (Alternatively, an implementation MAY delay the creation of a neighbour entry until a challenge request or reply is received.) This clarification does not invalidate any implementations, it just makes the intent of the draft authors more explicit. -- Juliusz From nobody Fri Jun 28 06:35:00 2019 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 36397120123 for ; Fri, 28 Jun 2019 06:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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 LCIu8hWkxGjX for ; Fri, 28 Jun 2019 06:34:57 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12A012004A for ; Fri, 28 Jun 2019 06:34:57 -0700 (PDT) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x5SDQMLk013138; Fri, 28 Jun 2019 09:34:56 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2tdk1qsgeq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Jun 2019 09:34:56 -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 x5SDYthm001570; Fri, 28 Jun 2019 09:34:55 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x5SDYk0N001399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Jun 2019 09:34:49 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 441EE4009E73; Fri, 28 Jun 2019 13:34:46 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30484.vci.att.com (Service) with ESMTPS id 319B64009E72; Fri, 28 Jun 2019 13:34:46 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.211]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0439.000; Fri, 28 Jun 2019 09:34:45 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" , "'babel@ietf.org'" Thread-Topic: [babel] Minor clarification to HMAC Thread-Index: AQHVLbR/a7/lZ4ddDE6T9I4Loqwt2qaxENPw Date: Fri, 28 Jun 2019 13:34:44 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E1FAFA0@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <874l49j158.wl-jch@irif.fr> In-Reply-To: <874l49j158.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.232.247] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-28_05:, , 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=996 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906280159 Archived-At: Subject: Re: [babel] Minor clarification to HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 13:34:59 -0000 > The draft says that a neighbour entry MUST NOT be created before HMAC is > verified (Section 4.3 first bullet). >=20 > It later says that a neighbour entry "might need to be created" when a > challenge is sent, and "may need to be created" when a challenge is > received. However, it does not say whether it is legal to create an entr= y > earlier. >=20 > I would therefore like to kindly request the permission of the group and = the > chairs to add the following between the first and second bullet points of > Section 4.3: >=20 > * A neighbour entry for the sender of the packet MAY be created at this > stage. (Alternatively, an implementation MAY delay the creation of > a neighbour entry until a challenge request or reply is received.) >=20 > This clarification does not invalidate any implementations, it just makes= the > intent of the draft authors more explicit. +1 I think this is a good change. Barbara From nobody Fri Jun 28 07:01:24 2019 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 1FD291200B5 for ; Fri, 28 Jun 2019 07:01:22 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tni8Ai-cSY6H for ; Fri, 28 Jun 2019 07:01:20 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (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 4C03512004A for ; Fri, 28 Jun 2019 07:01:20 -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=1561730477; bh=FYRGoweoJm0LiN9KLHz0V2GMomVjmX/9zbof8cGL97Q=; h=From:To:Subject:In-Reply-To:References:Date:From; b=wUV9vVjYewgJk+m24yGHzPB3/sOcSUWjrtOCd81oTiX8awsvXMglf9IOptvQFBAN2 4WMPi71UenXvV6wQmypl6DuQtQKUlxyxPyhup7C8POxj/5gxOiYpyOGdlUYfbX2bCc Ei70OqR0ciwMnYLxkVaht2nSUWiVsMxd8qOlsW4F6DwT89rAGo3l46uAJuFLxsKsk/ x3NVc/jWP7grrYK6UHSCkzymLiPbjVvTdanuCMlaqTeWt44A9wguPKJ3nXJVSu8hXE 31eWXM51yEU77wJ2j0p2KCGYjdo5X073Vie6DVg00bmbAdo1ir3KGo/P2OyaBoA8SM agITMdTcz7yxA== To: "STARK\, BARBARA H" , 'Juliusz Chroboczek' , "'babel\@ietf.org'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E1FAFA0@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <874l49j158.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E1FAFA0@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Fri, 28 Jun 2019 16:01:16 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <878stl95cj.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Minor clarification to HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 14:01:22 -0000 "STARK, BARBARA H" writes: >> The draft says that a neighbour entry MUST NOT be created before HMAC is >> verified (Section 4.3 first bullet). >> >> It later says that a neighbour entry "might need to be created" when a >> challenge is sent, and "may need to be created" when a challenge is >> received. However, it does not say whether it is legal to create an entry >> earlier. >> >> I would therefore like to kindly request the permission of the group and the >> chairs to add the following between the first and second bullet points of >> Section 4.3: >> >> * A neighbour entry for the sender of the packet MAY be created at this >> stage. (Alternatively, an implementation MAY delay the creation of >> a neighbour entry until a challenge request or reply is received.) >> >> This clarification does not invalidate any implementations, it just makes the >> intent of the draft authors more explicit. > > +1 > I think this is a good change. +1 -Toke From nobody Fri Jun 28 07:17:31 2019 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 B9E0A12012B for ; Fri, 28 Jun 2019 07:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kapsi.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3mg2sxXgyQg for ; Fri, 28 Jun 2019 07:17:26 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF91112004A for ; Fri, 28 Jun 2019 07:17:25 -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:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=kgp7PrgclP6eUS7TJHK47J6MK1me3vuRRKtsv6L1+co=; b=vTlx4ZIBCsEZOdXVEffmKq4+NX FQkMPzk2RE5DlZKivD7lcTofdRffwDEPeXwUHMNpEH+to52YxzUBYCETGTbtwwwTxnIViKFOVwJzU YRnW1xlmctdYJvixOuAFgZVpgyOQwDm3pXNSK/Tbe+0tHefDcksSIRyfc7FmZ3Lo36UCIl6kqqQc7 lRgkVyz+JIvzvveP9aZtlHPdM93EflKuDtkoMt63NnhHHfvL788cLmhDVV5f+3AVoSIBV9j8FB6Qu pRHbqAm7XUk2YzUP1uueGR2liKkuok1I8Np+sTOQ/CqDxBcEjtdeFf/YiUCclQxO5+Bpn1Vl24DgS 2lFNGtIA==; Received: from 91-155-69-60.elisa-laajakaista.fi ([91.155.69.60] helo=himawari.lan) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hgrgo-0001Lc-9u; Fri, 28 Jun 2019 17:17:22 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Markus Stenberg In-Reply-To: <874l49j158.wl-jch@irif.fr> Date: Fri, 28 Jun 2019 17:17:21 +0300 Cc: babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6C3AA518-8EF8-493A-835D-DE096E75D07B@iki.fi> References: <874l49j158.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-SA-Exim-Connect-IP: 91.155.69.60 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] Minor clarification to HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 14:17:29 -0000 In terms of security properties, notably resource exhaustion/contention, = I am bit leery of creating entry before validity of remote party is = actually verified (=3D challenge response received). I prefer the old = text. I am not quite sure why the second 'may need to be created' is = there.. I guess naive implementation would just remember specific nonces it has = sent/freceived, but for new peers you can also just use e.g. nonce that = contains timestamp (+ peer address (+- something))[1], which allows = challenge sender to remain stateless until challenge responder proves = they have the key. So -1 from me. (Yes, I do wear my tinfoil hat even during summer.) Cheers, -Markus [1] extra stuff is mostly for replay protection purposes, but I am not = sure if it is a threat or not in this case. I have just cycled 140km, = sue me. > On 28.06.2019, at 16.21, Juliusz Chroboczek wrote: >=20 > Dear all, >=20 > Sawssen and =C3=89tienne (in copy of this mail) are currently working = on > cleaning up and completing the reference implementation of = draft-...-hmac. > We have just realised that the draft is not quite clear on two points. >=20 > The draft says that a neighbour entry MUST NOT be created before HMAC = is > verified (Section 4.3 first bullet). >=20 > It later says that a neighbour entry "might need to be created" when > a challenge is sent, and "may need to be created" when a challenge is > received. However, it does not say whether it is legal to create an = entry > earlier. >=20 > I would therefore like to kindly request the permission of the group = and > the chairs to add the following between the first and second bullet = points > of Section 4.3: >=20 > * A neighbour entry for the sender of the packet MAY be created at = this > stage. (Alternatively, an implementation MAY delay the creation of > a neighbour entry until a challenge request or reply is received.) >=20 > This clarification does not invalidate any implementations, it just = makes > the intent of the draft authors more explicit. >=20 > -- Juliusz >=20 >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel >=20 From nobody Fri Jun 28 10:46:08 2019 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 3A4A01203BC for ; Fri, 28 Jun 2019 10:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaLquaDBPQ1w for ; Fri, 28 Jun 2019 10:46:03 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27CFB12000E for ; Fri, 28 Jun 2019 10:46:03 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id t28so6789242lje.9 for ; Fri, 28 Jun 2019 10:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JfIBjLQgAyq/s5q1KTj6QEBaohPlkx5EztgfGdk2aYM=; b=oOe8uO/+9TCVnXURbSPKP0L/K0AMeX2/uAX031tx8a6Sqo8AYKICE7xHVtjw98pvKA IN9wHfoNSwuiMAgmt6CgrC6gQnJA5u9Vwzv503N7GYkHuQKlt8LwLPSovl+V6TJZgngr oN4OyyCnfZEwPnFwqslCFFegAAudeGLKsB98i0LPygipvjkSPu2Is2BhXJJ/VVkrHZ7T fgnP/VQuTSFtLge+M4hgLbwwQfNgrTsau+SoY35EbXYeH+4B8jPr0MjqtynIk8bC6gA2 K+ujcHq8rHH7gI4UY7buRq+D8XzF9QyBpRcVKZwS3efyzjaHBS7QC6t5TZaRll0Q/zQp eOOw== 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=JfIBjLQgAyq/s5q1KTj6QEBaohPlkx5EztgfGdk2aYM=; b=H6hNnxQr2py4C4OEHQ3zGBK0cNeXt/lNh082AGqY3K0eWyJ4fCJilG4XICZfXxRSs0 IGN5GYmYNnhbBroBQfvCXfSDa7Nr3hq+8gaPxT3BImYO3iQKgJzKMg1ZmqB3p1DNZ7aL ozj5VbLrZvAUQSZq2NbsY5uRu9RI7nCUhoW4mlCpXeQ0Om/MyBmSaEBYDU12E8Uw9MFt pJGfjtG44ANpnS/J6LLZ1beSIXrZBXHsSdOHGClg0R+AGh/P4Ir89zsP6FigS6UeqKtq Vdgz8shC2KV50PUUA+LTunLRss05VMUnuQ+lgRXlMiRn9fFoNoH2JWJIxvAV84zTWgde QsSQ== X-Gm-Message-State: APjAAAWKVQFdsPBCOBkEE/3XkhPIhuO/ZJ3jJoARLXOhRZql8vXxG0W5 ZiI69QQcD9Qwijx8FuK90fL3jwpLWYGoMJXWbTk= X-Google-Smtp-Source: APXvYqzYZhiZ8Q+U8KpDSJB0VB9sP1CyoPcVstHBgPnGw/MC9FzWMrQeyKGITn3kMyKiaj6aDW7nBJ8RrpWB0NmznJM= X-Received: by 2002:a2e:89c8:: with SMTP id c8mr7007632ljk.70.1561743961379; Fri, 28 Jun 2019 10:46:01 -0700 (PDT) MIME-Version: 1.0 References: <874l49j158.wl-jch@irif.fr> <6C3AA518-8EF8-493A-835D-DE096E75D07B@iki.fi> In-Reply-To: <6C3AA518-8EF8-493A-835D-DE096E75D07B@iki.fi> From: David Schinazi Date: Fri, 28 Jun 2019 10:45:50 -0700 Message-ID: To: Markus Stenberg Cc: Juliusz Chroboczek , Babel at IETF Content-Type: multipart/alternative; boundary="0000000000000c56e7058c65dad3" Archived-At: Subject: Re: [babel] Minor clarification to HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 17:46:06 -0000 --0000000000000c56e7058c65dad3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable When a node detects a new neighbour (by receiving a multicast hello), it sends a challenge. I can imagine several ways to implement this: - create the neighbor entry at this point - have a separate table of pending challenges - come up with a clever stateless scheme involving cookies (maybe?) But how the node handles the challenge is an implementation matter. A rate-limiting and anti-DoS mechanism can be added to all of these. Therefore, I support adding this MAY, because it gives implementors leeway. David On Fri, Jun 28, 2019 at 7:17 AM Markus Stenberg wrote: > In terms of security properties, notably resource exhaustion/contention, = I > am bit leery of creating entry before validity of remote party is actuall= y > verified (=3D challenge response received). I prefer the old text. I am n= ot > quite sure why the second 'may need to be created' is there.. > > I guess naive implementation would just remember specific nonces it has > sent/freceived, but for new peers you can also just use e.g. nonce that > contains timestamp (+ peer address (+- something))[1], which allows > challenge sender to remain stateless until challenge responder proves the= y > have the key. > > So -1 from me. (Yes, I do wear my tinfoil hat even during summer.) > > Cheers, > > -Markus > > [1] extra stuff is mostly for replay protection purposes, but I am not > sure if it is a threat or not in this case. I have just cycled 140km, sue > me. > > > On 28.06.2019, at 16.21, Juliusz Chroboczek wrote: > > > > Dear all, > > > > Sawssen and =C3=89tienne (in copy of this mail) are currently working o= n > > cleaning up and completing the reference implementation of > draft-...-hmac. > > We have just realised that the draft is not quite clear on two points. > > > > The draft says that a neighbour entry MUST NOT be created before HMAC i= s > > verified (Section 4.3 first bullet). > > > > It later says that a neighbour entry "might need to be created" when > > a challenge is sent, and "may need to be created" when a challenge is > > received. However, it does not say whether it is legal to create an > entry > > earlier. > > > > I would therefore like to kindly request the permission of the group an= d > > the chairs to add the following between the first and second bullet > points > > of Section 4.3: > > > > * A neighbour entry for the sender of the packet MAY be created at thi= s > > stage. (Alternatively, an implementation MAY delay the creation of > > a neighbour entry until a challenge request or reply is received.) > > > > This clarification does not invalidate any implementations, it just mak= es > > the intent of the draft authors more explicit. > > > > -- Juliusz > > > > > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://www.ietf.org/mailman/listinfo/babel > > > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --0000000000000c56e7058c65dad3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
When a node detects a new neighbour (by receiving a multic= ast hello), it sends a challenge.
I can imagine several ways to impleme= nt this:
- create the neighbor entry at this point
- ha= ve a separate table of pending challenges
- come up with a clever= stateless scheme involving cookies (maybe?)
But how the node han= dles the challenge is an implementation matter.
A rate-limiti= ng and anti-DoS mechanism can be added to all of these.

Therefore, I support adding this MAY, because it gives implementors l= eeway.

David


On Fri, Jun 28, 2= 019 at 7:17 AM Markus Stenberg <markus.stenberg@iki.fi> wrote:
In terms of security properties, notably resource e= xhaustion/contention, I am bit leery of creating entry before validity of r= emote party is actually verified (=3D challenge response received). I prefe= r the old text. I am not quite sure why the second 'may need to be crea= ted' is there..

I guess naive implementation would just remember specific nonces it has sen= t/freceived, but for new peers you can also just use e.g. nonce that contai= ns timestamp (+ peer address (+- something))[1], which allows challenge sen= der to remain stateless until challenge responder proves they have the key.=

So -1 from me. (Yes, I do wear my tinfoil hat even during summer.)

Cheers,

-Markus

[1] extra stuff is mostly for replay protection purposes, but I am not sure= if it is a threat or not in this case. I have just cycled 140km, sue me.
> On 28.06.2019, at 16.21, Juliusz Chroboczek <jch@irif.fr> wrote:
>
> Dear all,
>
> Sawssen and =C3=89tienne (in copy of this mail) are currently working = on
> cleaning up and completing the reference implementation of draft-...-h= mac.
> We have just realised that the draft is not quite clear on two points.=
>
> The draft says that a neighbour entry MUST NOT be created before HMAC = is
> verified (Section 4.3 first bullet).
>
> It later says that a neighbour entry "might need to be created&qu= ot; when
> a challenge is sent, and "may need to be created" when a cha= llenge is
> received.=C2=A0 However, it does not say whether it is legal to create= an entry
> earlier.
>
> I would therefore like to kindly request the permission of the group a= nd
> the chairs to add the following between the first and second bullet po= ints
> of Section 4.3:
>
>=C2=A0 * A neighbour entry for the sender of the packet MAY be created = at this
>=C2=A0 =C2=A0 stage.=C2=A0 (Alternatively, an implementation MAY delay = the creation of
>=C2=A0 =C2=A0 a neighbour entry until a challenge request or reply is r= eceived.)
>
> This clarification does not invalidate any implementations, it just ma= kes
> the intent of the draft authors more explicit.
>
> -- Juliusz
>
>
> _______________________________________________
> babel mailing list
> babel@ietf.org=
> https://www.ietf.org/mailman/listinfo/babel
>

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--0000000000000c56e7058c65dad3-- From nobody Fri Jun 28 10:58:16 2019 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 674D812060B for ; Fri, 28 Jun 2019 10:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Hu6ujIMZK52 for ; Fri, 28 Jun 2019 10:58:11 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 86A9F12075C for ; Fri, 28 Jun 2019 10:57:58 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id i189so3351887pfg.10 for ; Fri, 28 Jun 2019 10:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CWbgvPVTG7Bpe4P2EabOReJmTxs0j4+sq2N0dWyasjI=; b=fPH+cuzz2XxF72Rg9/Jz97Bk/krL42TUqNl4tQY973MeAuiEDpqpPNZnngeLZ32dWf P1FrV1vCA8ql3CRL6CsA9UJ7pQmlPDNQtoxWPNcc5omNqzqPcKA7Ppdnoxw0qRJ0k4iy NZshAjwVmphLvPXb/Pm6vr+r5qt8u9Y49wiJ9KCqOTOjwGIFXMAnznjrWcE+P/82na8u /NO4Tl+HhZJ0yNy8by33p5+x+NZ5UX5BcfEJLcq2lBSFosd6lHCtpc/KOfAsLbRl+QL2 /430Jc2iOJIRP8Ej96XxKhfY7JjEPRU3bNs8I9rKzksT2t61IwL/ClCaGW9FLC/7bJMS UzQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CWbgvPVTG7Bpe4P2EabOReJmTxs0j4+sq2N0dWyasjI=; b=YIIc+WWg3crI8L9/w9G560ZgW4uVmHr5y8JBT2C9cUsoonqwbxx+7Um7Ip39tn84Vg ISMT4vx0V7pS6xBKj2NtxjDLq8JgKwi0zrAQV12IPbt44xBR/7QAAJyYjRSRq1CLKE5L VgzGtt/gkzwjZseXBzuztUe3eF8Nx5UzaeqWuHB7vtdoyobgylwRiZJQi/IkR4WMWEcs TgsT/7K2ToP6IEzAR5L3UE8N6Ylb/AgUJkckClk3P6/hBJkhRIhEilD/QgadLZYBrppV DzNke832b5iG47ZJQv1omORrWQudibzWf3MZa96/I2T6Sxo6ZpdUue+O2CbztdlmUmqX 2eig== X-Gm-Message-State: APjAAAUZfQfT36LBQe3UbaROl06SR78Nz39pBmae5jHnR6M9ezN4klHt MUFT0kZxyOu0/NR5lMtacyTAMW3A X-Google-Smtp-Source: APXvYqysIFx9q+ohF0Ehgac92t3dhDaIRF9SQJjj7m/frZV5ftz9QRRtAO8b18M/5VtkWHGZT+LrlA== X-Received: by 2002:a17:90a:1904:: with SMTP id 4mr15097084pjg.116.1561744677761; Fri, 28 Jun 2019 10:57:57 -0700 (PDT) Received: from [172.26.35.147] ([76.14.1.154]) by smtp.gmail.com with ESMTPSA id a3sm2696311pff.122.2019.06.28.10.57.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jun 2019 10:57:56 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-8A7012C5-6106-4558-8344-2D7929A22F68 Mime-Version: 1.0 (1.0) From: Mahesh Jethanandani X-Mailer: iPad Mail (16A404) In-Reply-To: Date: Fri, 28 Jun 2019 10:57:56 -0700 Cc: Markus Stenberg , Babel at IETF , Juliusz Chroboczek Content-Transfer-Encoding: 7bit Message-Id: References: <874l49j158.wl-jch@irif.fr> <6C3AA518-8EF8-493A-835D-DE096E75D07B@iki.fi> To: David Schinazi Archived-At: Subject: Re: [babel] Minor clarification to HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 17:58:14 -0000 --Apple-Mail-8A7012C5-6106-4558-8344-2D7929A22F68 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To me this sounds much like a SYN flood attack in TCP, where TCP resources w= ere allocated before the ACK came back. And TCP had to come back to clarify t= his, rather than leave it as a implementation level detail. If we agree that a MAY should be allowed, I would like to see some guidance g= iven on some implementation choices including the fact that a separate table= of pending challenges should be kept to prevent an attack.=20 Thanks. Mahesh Jethanandani mjethanandani@gmail.com > On Jun 28, 2019, at 10:45 AM, David Schinazi wr= ote: >=20 > When a node detects a new neighbour (by receiving a multicast hello), it s= ends a challenge. > I can imagine several ways to implement this: > - create the neighbor entry at this point > - have a separate table of pending challenges > - come up with a clever stateless scheme involving cookies (maybe?) > But how the node handles the challenge is an implementation matter. > A rate-limiting and anti-DoS mechanism can be added to all of these. >=20 > Therefore, I support adding this MAY, because it gives implementors leeway= . >=20 > David >=20 >=20 >> On Fri, Jun 28, 2019 at 7:17 AM Markus Stenberg w= rote: >> In terms of security properties, notably resource exhaustion/contention, I= am bit leery of creating entry before validity of remote party is actually v= erified (=3D challenge response received). I prefer the old text. I am not q= uite sure why the second 'may need to be created' is there.. >>=20 >> I guess naive implementation would just remember specific nonces it has s= ent/freceived, but for new peers you can also just use e.g. nonce that conta= ins timestamp (+ peer address (+- something))[1], which allows challenge sen= der to remain stateless until challenge responder proves they have the key. >>=20 >> So -1 from me. (Yes, I do wear my tinfoil hat even during summer.) >>=20 >> Cheers, >>=20 >> -Markus >>=20 >> [1] extra stuff is mostly for replay protection purposes, but I am not su= re if it is a threat or not in this case. I have just cycled 140km, sue me. >>=20 >> > On 28.06.2019, at 16.21, Juliusz Chroboczek wrote: >> >=20 >> > Dear all, >> >=20 >> > Sawssen and =C3=89tienne (in copy of this mail) are currently working o= n >> > cleaning up and completing the reference implementation of draft-...-hm= ac. >> > We have just realised that the draft is not quite clear on two points. >> >=20 >> > The draft says that a neighbour entry MUST NOT be created before HMAC i= s >> > verified (Section 4.3 first bullet). >> >=20 >> > It later says that a neighbour entry "might need to be created" when >> > a challenge is sent, and "may need to be created" when a challenge is >> > received. However, it does not say whether it is legal to create an en= try >> > earlier. >> >=20 >> > I would therefore like to kindly request the permission of the group an= d >> > the chairs to add the following between the first and second bullet poi= nts >> > of Section 4.3: >> >=20 >> > * A neighbour entry for the sender of the packet MAY be created at thi= s >> > stage. (Alternatively, an implementation MAY delay the creation of >> > a neighbour entry until a challenge request or reply is received.) >> >=20 >> > This clarification does not invalidate any implementations, it just mak= es >> > the intent of the draft authors more explicit. >> >=20 >> > -- Juliusz >> >=20 >> >=20 >> > _______________________________________________ >> > babel mailing list >> > babel@ietf.org >> > https://www.ietf.org/mailman/listinfo/babel >> >=20 >>=20 >> _______________________________________________ >> babel mailing list >> babel@ietf.org >> https://www.ietf.org/mailman/listinfo/babel > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel --Apple-Mail-8A7012C5-6106-4558-8344-2D7929A22F68 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable To me this sounds much like a SYN flood att= ack in TCP, where TCP resources were allocated before the ACK came back. And= TCP had to come back to clarify this, rather than leave it as a implementat= ion level detail.

If we agree that a MAY should be allowe= d, I would like to see some guidance given on some implementation choices in= cluding the fact that a separate table of pending challenges should be kept t= o prevent an attack. 

Thanks.

Mahesh Jethanandani

On Jun 28, 2019, at 10:45 AM, David Schinazi <dschinazi.ietf@gmail.com> wrote:

When a node de= tects a new neighbour (by receiving a multicast hello), it sends a challenge= .
I can imagine several ways to implement this:
- create the n= eighbor entry at this point
- have a separate table of pending cha= llenges
- come up with a clever stateless scheme involving cookies= (maybe?)
But how the node handles the challenge is an implementat= ion matter.
A rate-limiting and anti-DoS mechanism can be adde= d to all of these.

Therefore, I support adding this= MAY, because it gives implementors leeway.

David


On Fri, Jun 28, 2019 at 7:17 AM Markus Stenberg <markus.stenberg@iki.fi> wrote:
In terms of security= properties, notably resource exhaustion/contention, I am bit leery of creat= ing entry before validity of remote party is actually verified (=3D challeng= e response received). I prefer the old text. I am not quite sure why the sec= ond 'may need to be created' is there..

I guess naive implementation would just remember specific nonces it has sent= /freceived, but for new peers you can also just use e.g. nonce that contains= timestamp (+ peer address (+- something))[1], which allows challenge sender= to remain stateless until challenge responder proves they have the key.
=
So -1 from me. (Yes, I do wear my tinfoil hat even during summer.)

Cheers,

-Markus

[1] extra stuff is mostly for replay protection purposes, but I am not sure i= f it is a threat or not in this case. I have just cycled 140km, sue me.

> On 28.06.2019, at 16.21, Juliusz Chroboczek <jch@irif.fr> wrote:
>
> Dear all,
>
> Sawssen and =C3=89tienne (in copy of this mail) are currently working o= n
> cleaning up and completing the reference implementation of draft-...-hm= ac.
> We have just realised that the draft is not quite clear on two points.<= br> >
> The draft says that a neighbour entry MUST NOT be created before HMAC i= s
> verified (Section 4.3 first bullet).
>
> It later says that a neighbour entry "might need to be created" when > a challenge is sent, and "may need to be created" when a challenge is > received.  However, it does not say whether it is legal to create a= n entry
> earlier.
>
> I would therefore like to kindly request the permission of the group an= d
> the chairs to add the following between the first and second bullet poi= nts
> of Section 4.3:
>
>  * A neighbour entry for the sender of the packet MAY be created a= t this
>    stage.  (Alternatively, an implementation MAY delay t= he creation of
>    a neighbour entry until a challenge request or reply is re= ceived.)
>
> This clarification does not invalidate any implementations, it just mak= es
> the intent of the draft authors more explicit.
>
> -- Juliusz
>
>
> _______________________________________________
> babel mailing list
> babel@ietf.org<= br> > https://www.ietf.org/mailman/listinfo/babel
>

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
________= _______________________________________
babel mailing list
babel@ietf.orghttps://www.= ietf.org/mailman/listinfo/babel
= --Apple-Mail-8A7012C5-6106-4558-8344-2D7929A22F68-- From nobody Fri Jun 28 11:54:23 2019 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 C16251201DB; Fri, 28 Jun 2019 11:54:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: draft-ietf-babel-hmac.all@ietf.org, ietf@ietf.org, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Sparks Message-ID: <156174806170.21879.2999727589481093933@ietfa.amsl.com> Date: Fri, 28 Jun 2019 11:54:21 -0700 Archived-At: Subject: [babel] Secdir last call review of draft-ietf-babel-hmac-07 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-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, 28 Jun 2019 18:54:22 -0000 Reviewer: Robert Sparks Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready for publication as a Proposed Standard RFC, but has a nit that should be considered before publication. Nit: (This was part of my early review of -00) The claim in 1.1 about not requiring persistent storage is contradicted by the definition of the protocol. At the very least, there is the need to persist the most recent (index,PC) seen. From nobody Fri Jun 28 15:59:25 2019 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 4442012094F; Fri, 28 Jun 2019 15:57:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: martin.vigoureux@nokia.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176267227.11015.13205570239322724200.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:57:52 -0700 Archived-At: Subject: [babel] babel - Requested session has been scheduled for IETF 105 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-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, 28 Jun 2019 22:57:58 -0000 Dear Donald Eastlake, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. babel Session 1 (1:00 requested) Wednesday, 24 July 2019, Afternoon Session II 1550-1650 Room Name: Sainte-Catherine size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/babel.ics Request Information: --------------------------------------------------------- Working Group Name: Babel routing protocol Area Name: Routing Area Session Requester: Donald Eastlake Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 24 Conflicts to Avoid: First Priority: rtgwg idr bess sfc Second Priority: dnsop saag lsr rtgarea Third Priority: mptcp cfrg homenet secdispatch People who must be present: Donald E. Eastlake 3rd Russ White Martin Vigoureux Resources Requested: Special Requests: Meeting toward the end of the day Thursday or in the last slot Thursday has worked well for BABEL. --------------------------------------------------------- From nobody Fri Jun 28 16:44:43 2019 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 3FE9A120709; Fri, 28 Jun 2019 16:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 Bmnvqk0ftS1p; Fri, 28 Jun 2019 16:44: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 9D287120705; Fri, 28 Jun 2019 16:44:36 -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/82085) with ESMTP id x5SNiWAO009110; Sat, 29 Jun 2019 01:44:32 +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 A1D5D4A4E3; Sat, 29 Jun 2019 01:44:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id O1ir-0GRb5SA; Sat, 29 Jun 2019 01:44:33 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 709134A4E0; Sat, 29 Jun 2019 01:44:33 +0200 (CEST) Date: Sat, 29 Jun 2019 01:44:33 +0200 Message-ID: <878stlz34u.wl-jch@irif.fr> From: Juliusz Chroboczek To: Robert Sparks Cc: , draft-ietf-babel-hmac.all@ietf.org, ietf@ietf.org, babel@ietf.org In-Reply-To: <156174806170.21879.2999727589481093933@ietfa.amsl.com> References: <156174806170.21879.2999727589481093933@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]); Sat, 29 Jun 2019 01:44:32 +0200 (CEST) X-Miltered: at korolev with ID 5D16A660.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D16A660.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 : 5D16A660.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] Secdir last call review of draft-ietf-babel-hmac-07 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 28 Jun 2019 23:44:42 -0000 Dear Robert, > Nit: (This was part of my early review of -00) > The claim in 1.1 about not requiring persistent storage is contradicted by the > definition of the protocol. At the very least, there is the need to persist the > most recent (index,PC) seen. I most respectfully disagree. The whole point of the challenge/response mechanism is to avoid the need for persistent storage. If a node loses the information about a neighbour (e.g. because it has rebooted and lost the index/PC of the neighbour), it can simply send a new challenge to recover the state. Here is what is written in Section 2 (Conceptual overview): By itself, the PC mechanism is not sufficient to protect against replay. Consider a peer A that has no information about a peer B (e.g., because it has recently rebooted). Suppose that A receives a packet ostensibly from B carrying a given PC; since A has no information about B, it has no way to determine whether the packet is freshly generated or a replay of a previously sent packet. In this situation, A discards the packet and challenges B to prove that it knows the HMAC key. It sends a "challenge request", a TLV containing a unique nonce, a value that has never been used before and will never be used again. B replies to the challenge request with a "challenge reply", a TLV containing a copy of the nonce chosen by A, in a packet protected by HMAC and containing the new value of B's PC. Since the nonce has never been used before, B's reply proves B's knowledge of the HMAC key and the freshness of the PC. Should you disagree with the fact that this mechanism allows a node to recover the state that it has discarded, I request that you provide an example scenario in which this mechanism fails. -- Juliusz From nobody Sat Jun 29 02:41:50 2019 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 0A3B6120121 for ; Sat, 29 Jun 2019 02:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 KQ_FDJXG8h0p for ; Sat, 29 Jun 2019 02:41:48 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1455120047 for ; Sat, 29 Jun 2019 02:41:47 -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/82085) with ESMTP id x5T9feRx004589; Sat, 29 Jun 2019 11:41: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 3514B4C428; Sat, 29 Jun 2019 11:41:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id nGkUHI2c1gmm; Sat, 29 Jun 2019 11:41:42 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7BF2D4C426; Sat, 29 Jun 2019 11:41:38 +0200 (CEST) Date: Sat, 29 Jun 2019 11:41:38 +0200 Message-ID: <87ef3c20fh.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: babel@ietf.org In-Reply-To: <6C3AA518-8EF8-493A-835D-DE096E75D07B@iki.fi> References: <874l49j158.wl-jch@irif.fr> <6C3AA518-8EF8-493A-835D-DE096E75D07B@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 29 Jun 2019 11:41:43 +0200 (CEST) X-Miltered: at korolev with ID 5D173254.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D173254.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 : 5D173254.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Minor clarification to HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 29 Jun 2019 09:41:50 -0000 > In terms of security properties, notably resource exhaustion/contention, > I am bit leery of creating entry before validity of remote party is > actually verified (= challenge response received). I prefer the old > text. I initially thought like you, but Sawssen and Étienne convinced me that creating the entry late does not add any security. Suppose that the packet passes HMAC. Then one of the possible cases is possible: - the neighbour entry already exists; - the neighbour entry doesn't exist, and we're going to send a challenge. In the first case, the point is moot. In the second case, we're going to create a neighbour entry anyway, so we might as well create it immediately. (Note that the data structures of the protocol are conceptual, not prescriptive -- an implementation is allowed e.g. to use an "incomplete neighbour" data structure that is smaller than a full neighbour structure for holding uncompleted challenges, as long as the effect is identical to what is described in the protocol. > I am not quite sure why the second 'may need to be created' is there.. I was hoping nobody would notice ;-) For the challenge to be successful, the neighbour entry must exist -- there's no way we could have sent a challenge if no neighbour entry exists. (It could be the case of course that the challenge reply is an attack, and no neighbour entry exists, so the implementation must still check for the existence of the neighbour entry.) I didn't want to mention that right now, in order to limit the amount of confusion. > I guess naive implementation would just remember specific nonces it has > sent/freceived, but for new peers you can also just use e.g. nonce that > contains timestamp (+ peer address (+- something))[1], which allows > challenge sender to remain stateless until challenge responder proves > they have the key. Yes. The protocol is designed to make it possible to encode a cookie in the Nonce (that's why Nonces can be as much as 192 octets long). However, the draft does not specify how to implement it with cookies, so the point is somewhat moot. (Note that even with cookies, you still need to rate-limit challenges. A global challenge counter should be enough, but I haven't given it any serious thought. Which is why I won't attempt to specify the cookie variant of the protocol in this revision of the protocol.) > So -1 from me. (Yes, I do wear my tinfoil hat even during summer.) Please reconsider in light of the above. -- Juliusz From nobody Sat Jun 29 02:52:08 2019 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 96B371200FF for ; Sat, 29 Jun 2019 02:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 L2nA4ZT9j2jd for ; Sat, 29 Jun 2019 02:52:05 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAFFE120033 for ; Sat, 29 Jun 2019 02:52:04 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x5T9pxR1007104; Sat, 29 Jun 2019 11:52:00 +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 9C7C74C4EE; Sat, 29 Jun 2019 11:52: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 f98Vc3S8xOt0; Sat, 29 Jun 2019 11:52:01 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 857FF4C4EB; Sat, 29 Jun 2019 11:52:01 +0200 (CEST) Date: Sat, 29 Jun 2019 11:52:01 +0200 Message-ID: <87d0iw1zy6.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mahesh Jethanandani Cc: Babel at IETF In-Reply-To: References: <874l49j158.wl-jch@irif.fr> <6C3AA518-8EF8-493A-835D-DE096E75D07B@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 29 Jun 2019 11:52:00 +0200 (CEST) X-Miltered: at korolev with ID 5D1734BF.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D1734BF.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 : 5D1734BF.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] Minor clarification to HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 29 Jun 2019 09:52:07 -0000 > To me this sounds much like a SYN flood attack in TCP, where TCP resources were > allocated before the ACK came back. And TCP had to come back to clarify this, > rather than leave it as a implementation level detail. RFC 4987. The issues are similar, the same defenses apply, but there is one significant difference. The very first thing that happens is that the HMAC is verified. No state is created if the HMAC fails (Section 4.3, first bullet). What is more, the HMAC includes a pseudo-header (Section 4.1), so a packet can only be replayed by spoofing the source address it was originally sent from. Since neighbour entries are indexed by source address, the amount of state an attacker can create is limited by the number of different source addresses in his collection of previously captured packets. What is more, everytime the network undergoes key rotation, all of the captured packets are invalidated. So an easy defense is to roll over the keys often enough so that the attacker can only create a bounded amount of state. > If we agree that a MAY should be allowed, I would like to see some guidance > given on some implementation choices including the fact that a separate table > of pending challenges should be kept to prevent an attack. Please check the last two paragraphs of Section 6 (Security Considerations), and let me know if you think I should add something there. -- Juliusz From nobody Sat Jun 29 02:53:23 2019 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 736C51200B7 for ; Sat, 29 Jun 2019 02:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 YqsnhWvrejSt for ; Sat, 29 Jun 2019 02:53:19 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A96120033 for ; Sat, 29 Jun 2019 02:53:18 -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:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=lhca9ZcPcSv1QJtD6SwuAzzFoa4UdmlX93c5tGQ2Qqo=; b=IzpvuCL9REr5uWGMFEWp7ctU5b ETtjUshDccL+Lzkk/j93R9Gomc8UJayV3DtWG116XGHO/PF44E/ivMFmOfi5CO2BjGnkPYi3ljti/ zBd48vD56Z2UyoUi7tZB0sYAKvzVHmgyy9HOhvQXwJov9mG8OHlXEcAOKJvgZiRWawHao/KYU3q78 hgDKHSQeIlBAUcHKcyEUvxz/qSWjDay5Iey3y0wF1QutS90M0L3a3gxDvqOrPcIDOi6KxZCWzu/Yu RrAL0/JBcI1Ho3iIyAoblZe4RpgwNBc6GVSVB9fviuBVIFYh1A3NdbJVbl5Gar5PoIYMXbykQc1Zb Hd13QfIQ==; Received: from 91-155-69-60.elisa-laajakaista.fi ([91.155.69.60] helo=[192.168.42.210]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hhA2l-0003DP-Pm; Sat, 29 Jun 2019 12:53:15 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Markus Stenberg In-Reply-To: <87ef3c20fh.wl-jch@irif.fr> Date: Sat, 29 Jun 2019 12:53:15 +0300 Cc: babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3CFB1069-5307-40F2-89DD-CA82CE2976A1@iki.fi> References: <874l49j158.wl-jch@irif.fr> <6C3AA518-8EF8-493A-835D-DE096E75D07B@iki.fi> <87ef3c20fh.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-SA-Exim-Connect-IP: 91.155.69.60 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] Minor clarification to HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 29 Jun 2019 09:53:21 -0000 > On 29 Jun 2019, at 12.41, Juliusz Chroboczek wrote: >> In terms of security properties, notably resource = exhaustion/contention, >> I am bit leery of creating entry before validity of remote party is >> actually verified (=3D challenge response received). I prefer the old >> text. > I initially thought like you, but Sawssen and =C3=89tienne convinced = me that > creating the entry late does not add any security. >=20 > Suppose that the packet passes HMAC. Then one of the possible cases = is > possible: >=20 > - the neighbour entry already exists; > - the neighbour entry doesn't exist, and we're going to send a = challenge. >=20 > In the first case, the point is moot. In the second case, we're going = to > create a neighbour entry anyway, so we might as well create it = immediately. >=20 > (Note that the data structures of the protocol are conceptual, not > prescriptive -- an implementation is allowed e.g. to use an = "incomplete > neighbour" data structure that is smaller than a full neighbour = structure > for holding uncompleted challenges, as long as the effect is identical = to > what is described in the protocol. Is there some mechanism in place that prevents replay of historic = packets? As the HMAC key itself does not change over time, storing = (large amounts of) historic payloads with valid HMAC is not hard. Tthe value is bit questionable GIVEN router ID is stable, but if it is = not, there is actually potential attack vector here.. RFC6126bis = suggests even random router ids as valid strategy and does not mandate = their storage. (Also given large domain, it might be possible to gather more routers=E2=80= =99 sent packets than there is space in neighbor table in limited = implementations.) Still -1. Cheers, -Markus= From nobody Sat Jun 29 03:14:12 2019 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 CC4751200DB for ; Sat, 29 Jun 2019 03:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 JEArajf6LEHU for ; Sat, 29 Jun 2019 03:14:08 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13112120111 for ; Sat, 29 Jun 2019 03:14:07 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x5TAE3JO013320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 29 Jun 2019 12:14:03 +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/82085) with ESMTP id x5TAE4HZ006435; Sat, 29 Jun 2019 12:14: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 3CC6A4C66E; Sat, 29 Jun 2019 12:14:06 +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 T5eqqkmGAhFV; Sat, 29 Jun 2019 12:14:05 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 32A634C66C; Sat, 29 Jun 2019 12:14:05 +0200 (CEST) Date: Sat, 29 Jun 2019 12:14:05 +0200 Message-ID: <87a7e01yxe.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: babel@ietf.org In-Reply-To: <3CFB1069-5307-40F2-89DD-CA82CE2976A1@iki.fi> References: <874l49j158.wl-jch@irif.fr> <6C3AA518-8EF8-493A-835D-DE096E75D07B@iki.fi> <87ef3c20fh.wl-jch@irif.fr> <3CFB1069-5307-40F2-89DD-CA82CE2976A1@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 29 Jun 2019 12:14:03 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 29 Jun 2019 12:14:04 +0200 (CEST) X-Miltered: at korolev with ID 5D1739EB.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D1739EC.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D1739EB.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D1739EC.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 : 5D1739EB.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D1739EC.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] Minor clarification to HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 29 Jun 2019 10:14:10 -0000 > Is there some mechanism in place that prevents replay of historic > packets? As the HMAC key itself does not change over time, storing > (large amounts of) historic payloads with valid HMAC is not hard. > Tthe value is bit questionable GIVEN router ID is stable, but if it is > not, there is actually potential attack vector here.. It's not the router ID, it's the link-local IP address. In order to create /n/ neighbour entries, an attacker needs to have captured correctly signed packets with /n/ distinct source IPs. (That's per interface. If an attacker is able to spoof packets on multiple interfaces, then the situation becomes worse.) (I'm tempted to follow Mahesh's advice, and rewrite the last two paragraphs of the Security Considerations section with reference to RFC 4987. Advice?) -- Juliusz From nobody Sat Jun 29 03:22:40 2019 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 88D261200B2 for ; Sat, 29 Jun 2019 03:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 fX6D3bjzChUb for ; Sat, 29 Jun 2019 03:22:38 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD0D212006B for ; Sat, 29 Jun 2019 03:22:37 -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:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=uIydqKNZzkZ+AbaXM2xTc8SeM+5Rp1BWS8jgBFIFWeM=; b=lc5cGuL4dM+hbIkltAmNHfaSHG Ndza6Vq0bdGrSlpS59rW+mEKjkcafcLgb8nFqzLvqbaP/IXGPS81nQX/eHAT+xuHYfYu7qRYoiJKO IJ5J71uWnofL0cVOVsHhd03uCLlrRAE9Rtv22lxSTYfUtAG9TUkJOB6/L6pdDZ+1g87PBCLskzZk9 D3M904VU71jLwoFLcTOBDc7Eg2uxmjv8REdRtyM5aJTDlJJx33RGh21y6Fk66mIuRvOxxkpiScMOy y+mLfUDE60hymZj3RHL1w3+KIEHD2ym7O9H3RJ+jLxBjDpa8YClB8NhqmJ8umtJhyFIPk6IYj7gus NIJzwtdA==; Received: from 91-155-69-60.elisa-laajakaista.fi ([91.155.69.60] helo=[192.168.42.210]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hhAV9-0002Xa-Cm; Sat, 29 Jun 2019 13:22:35 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Markus Stenberg In-Reply-To: <87a7e01yxe.wl-jch@irif.fr> Date: Sat, 29 Jun 2019 13:22:34 +0300 Cc: babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5154BFF0-4BE3-4F72-AAA4-AC65DEDF2A97@iki.fi> References: <874l49j158.wl-jch@irif.fr> <6C3AA518-8EF8-493A-835D-DE096E75D07B@iki.fi> <87ef3c20fh.wl-jch@irif.fr> <3CFB1069-5307-40F2-89DD-CA82CE2976A1@iki.fi> <87a7e01yxe.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-SA-Exim-Connect-IP: 91.155.69.60 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] Minor clarification to HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 29 Jun 2019 10:22:39 -0000 I think I am being dense (I haven=E2=80=99t looked at the protocol in = awhile), but=20 a) babel-hmac does not have even reference to link-local address, and b) 6126bis states it is used only to index remote entries Doesn=E2=80=99t this mean that by forging the link-local addresses = (which are not included in HMAC) and then replaying valid HMAC packets = you can fill table as you want if this consideration is relaxed? -Markus > On 29 Jun 2019, at 13.14, Juliusz Chroboczek wrote: >=20 >> Is there some mechanism in place that prevents replay of historic >> packets? As the HMAC key itself does not change over time, storing >> (large amounts of) historic payloads with valid HMAC is not hard. >> Tthe value is bit questionable GIVEN router ID is stable, but if it = is >> not, there is actually potential attack vector here.. >=20 > It's not the router ID, it's the link-local IP address. In order to > create /n/ neighbour entries, an attacker needs to have captured = correctly > signed packets with /n/ distinct source IPs. (That's per interface. = If > an attacker is able to spoof packets on multiple interfaces, then the > situation becomes worse.) >=20 > (I'm tempted to follow Mahesh's advice, and rewrite the last two > paragraphs of the Security Considerations section with reference to > RFC 4987. Advice?) >=20 > -- Juliusz >=20 From nobody Sat Jun 29 03:25:07 2019 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 4093E12006B; Sat, 29 Jun 2019 03:25:05 -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.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156180390518.12818.10057028417927642502@ietfa.amsl.com> Date: Sat, 29 Jun 2019 03:25:05 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-rfc6126bis-11.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-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, 29 Jun 2019 10:25:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : The Babel Routing Protocol Authors : Juliusz Chroboczek David Schinazi Filename : draft-ietf-babel-rfc6126bis-11.txt Pages : 61 Date : 2019-06-29 Abstract: Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol, and obsoletes RFCs 6126 and 7557. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-11 https://datatracker.ietf.org/doc/html/draft-ietf-babel-rfc6126bis-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-rfc6126bis-11 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 Jun 29 03:30:03 2019 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 C04D21200B2; Sat, 29 Jun 2019 03:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 x0SWtazwlSKB; Sat, 29 Jun 2019 03:29:52 -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 40BA012000F; Sat, 29 Jun 2019 03:29:52 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x5TATlJU017566; Sat, 29 Jun 2019 12:29:47 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 4074F4C887; Sat, 29 Jun 2019 12:29:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id W1csmrRCYZRA; Sat, 29 Jun 2019 12:29:49 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C6FF24C884; Sat, 29 Jun 2019 12:29:48 +0200 (CEST) Date: Sat, 29 Jun 2019 12:29:48 +0200 Message-ID: <878stk1y77.wl-jch@irif.fr> From: Juliusz Chroboczek To: Russ Housley Cc: IETF Gen-ART , draft-ietf-babel-rfc6126bis.all@ietf.org, IETF , babel@ietf.org In-Reply-To: <514CAB4A-FADD-4C5C-A653-1C6953BB2F1E@vigilsec.com> References: <156122420684.16418.15464371573444699739@ietfa.amsl.com> <87woh6a6hr.wl-jch@irif.fr> <514CAB4A-FADD-4C5C-A653-1C6953BB2F1E@vigilsec.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]); Sat, 29 Jun 2019 12:29:47 +0200 (CEST) X-Miltered: at korolev with ID 5D173D9B.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D173D9B.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 : 5D173D9B.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] Genart last call review of draft-ietf-babel-rfc6126bis-10 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 29 Jun 2019 10:29:54 -0000 Done in -11. Thanks again for your review. -- Juliusz From nobody Sat Jun 29 03:37:40 2019 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 A33701200DB for ; Sat, 29 Jun 2019 03:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 jPWBEmbORCku for ; Sat, 29 Jun 2019 03:37:37 -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 CBC88120108 for ; Sat, 29 Jun 2019 03:37:36 -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/82085) with ESMTP id x5TAbWGJ020316; Sat, 29 Jun 2019 12:37:32 +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 2382F4C9E9; Sat, 29 Jun 2019 12:37:35 +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 91IoBY5Uw6ut; Sat, 29 Jun 2019 12:37:34 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1943A4C9E3; Sat, 29 Jun 2019 12:37:34 +0200 (CEST) Date: Sat, 29 Jun 2019 12:37:34 +0200 Message-ID: <877e941xu9.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: babel@ietf.org In-Reply-To: <5154BFF0-4BE3-4F72-AAA4-AC65DEDF2A97@iki.fi> References: <874l49j158.wl-jch@irif.fr> <6C3AA518-8EF8-493A-835D-DE096E75D07B@iki.fi> <87ef3c20fh.wl-jch@irif.fr> <3CFB1069-5307-40F2-89DD-CA82CE2976A1@iki.fi> <87a7e01yxe.wl-jch@irif.fr> <5154BFF0-4BE3-4F72-AAA4-AC65DEDF2A97@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 29 Jun 2019 12:37:32 +0200 (CEST) X-Miltered: at korolev with ID 5D173F6C.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D173F6C.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 : 5D173F6C.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] Minor clarification to HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 29 Jun 2019 10:37:40 -0000 > I think I am being dense (I haven’t looked at the protocol in awhile), Perhaps we're not undestanding each other. Let's work it out. > a) babel-hmac does not have even reference to link-local address, and Section 4.1: First, the node builds a pseudo-header that will participate in HMAC computation but will not be sent. [...] Src address The source IP address of the packet. RFC 6126bis Section 4: A Babel packet MUST be silently ignored unless its source address is either a link-local IPv6 address or an IPv4 address belonging to the local network, and its source port is the well-known Babel port. > Doesn’t this mean that by forging the link-local addresses (which are > not included in HMAC) They are included in HMAC computation, see citation from 4.1 above. > and then replaying valid HMAC packets you can fill table as you want if > this consideration is relaxed? I don't think that's the case. (And if you're right, then it's a serious flaw indeed.) -- Juliusz From nobody Sat Jun 29 03:40:43 2019 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 AA0401200EF for ; Sat, 29 Jun 2019 03:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 kAACdVT73--h for ; Sat, 29 Jun 2019 03:40:40 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F2EB1200DB for ; Sat, 29 Jun 2019 03:40:40 -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:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=auOgDsQNgaEDvmMuVJIqb7vSEjGdlXe0f+tL0xEMj2c=; b=DTbDqzB3JtX/IVHibzAJI08yc3 gqx25GXGPRLSsvCqKkAP/emxMyNab9IkK/n1j2jhRGBZGFgOWSIpX73eF9tJKv9YXIj49H8vpHnuZ gUY3NyQAEheECe+3F8TVsdhmzqqtqV6bcYIz5oe2N5LzIx0VO+A1XDjNfihXSMawZsAgNsuiEVQnp DIpZen0iQb33K5ewgxHc0HZzsIlacMNGRs4RPi1naVg8Nw5BQkKQ1DS+KwAJsKuZxIrHVNNMjK1J+ I+OgV2kt/ygAyw/yC+n0KfIPtFruBvRrg62uRCOLQDCvqHwHAvidz+cylZe3r7PJt+pLKXO4wU8L+ 5eYi2FYg==; Received: from 91-155-69-60.elisa-laajakaista.fi ([91.155.69.60] helo=[192.168.42.210]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hhAmc-0007Wt-E7; Sat, 29 Jun 2019 13:40:38 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Markus Stenberg In-Reply-To: <877e941xu9.wl-jch@irif.fr> Date: Sat, 29 Jun 2019 13:40:37 +0300 Cc: babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2EACCFA6-6214-4C95-9951-873B9C0F4B98@iki.fi> References: <874l49j158.wl-jch@irif.fr> <6C3AA518-8EF8-493A-835D-DE096E75D07B@iki.fi> <87ef3c20fh.wl-jch@irif.fr> <3CFB1069-5307-40F2-89DD-CA82CE2976A1@iki.fi> <87a7e01yxe.wl-jch@irif.fr> <5154BFF0-4BE3-4F72-AAA4-AC65DEDF2A97@iki.fi> <877e941xu9.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-SA-Exim-Connect-IP: 91.155.69.60 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] Minor clarification to HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 29 Jun 2019 10:40:42 -0000 > On 29 Jun 2019, at 13.37, Juliusz Chroboczek wrote: >> I think I am being dense (I haven=E2=80=99t looked at the protocol in = awhile), >=20 > Perhaps we're not undestanding each other. Let's work it out. >=20 >> a) babel-hmac does not have even reference to link-local address, and >=20 > Section 4.1: >=20 > First, the node builds a pseudo-header that will participate in HMAC > computation but will not be sent. > [...] > Src address The source IP address of the packet. >=20 > RFC 6126bis Section 4: >=20 > A Babel packet MUST be silently ignored unless its source address is > either a link-local IPv6 address or an IPv4 address belonging to the > local network, and its source port is the well-known Babel port. Ah ok, I didn=E2=80=99t read it through again (just did some searching), = so that=E2=80=99s correct. Non-issue for most part. > I don't think that's the case. (And if you're right, then it's a = serious > flaw indeed.) So at most you can have # of network size spurious replayed neighbour = table entries. No idea how limited implementations might behave with = that (e.g. fixed neighbour table size in a largish network with same = HMAC key), but I think that given security consideration text it is fine = then as long as the behavior is mentioned somewhere. -Markus= From nobody Sat Jun 29 03:54:16 2019 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 C68AC12011C for ; Sat, 29 Jun 2019 03:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 cd1FkAHXXmGB for ; Sat, 29 Jun 2019 03:54: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 272111200DB for ; Sat, 29 Jun 2019 03:54:11 -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/82085) with ESMTP id x5TAs7Re024499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 29 Jun 2019 12:54:07 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x5TAs7es014333; Sat, 29 Jun 2019 12:54:07 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 71EB64CB65; Sat, 29 Jun 2019 12:54:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id DyHntL9mdrzG; Sat, 29 Jun 2019 12:54:08 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 5CEA04CB60; Sat, 29 Jun 2019 12:54:05 +0200 (CEST) Date: Sat, 29 Jun 2019 12:54:05 +0200 Message-ID: <874l481x2q.wl-jch@irif.fr> From: Juliusz Chroboczek To: Markus Stenberg Cc: babel@ietf.org In-Reply-To: <2EACCFA6-6214-4C95-9951-873B9C0F4B98@iki.fi> References: <874l49j158.wl-jch@irif.fr> <6C3AA518-8EF8-493A-835D-DE096E75D07B@iki.fi> <87ef3c20fh.wl-jch@irif.fr> <3CFB1069-5307-40F2-89DD-CA82CE2976A1@iki.fi> <87a7e01yxe.wl-jch@irif.fr> <5154BFF0-4BE3-4F72-AAA4-AC65DEDF2A97@iki.fi> <877e941xu9.wl-jch@irif.fr> <2EACCFA6-6214-4C95-9951-873B9C0F4B98@iki.fi> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 29 Jun 2019 12:54:07 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 29 Jun 2019 12:54:08 +0200 (CEST) X-Miltered: at korolev with ID 5D17434F.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D17434F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D17434F.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D17434F.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 : 5D17434F.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D17434F.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] Minor clarification to HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 29 Jun 2019 10:54:14 -0000 > So at most you can have # of network size spurious replayed neighbour > table entries. Right. We're hoping that implementations don't change their link-local IP addresses too often, i.e. that (genuine) link-locals are reasonably stable. > No idea how limited implementations might behave with that (e.g. fixed > neighbour table size in a largish network with same HMAC key), I'll add a note to the Security Considerations that implementations want to ensure that they fail gracefully when the neighbour table overflows (i.e. that they fail to establish any new adjacencies rather than crashing.) > I think that given security consideration text it is fine then as long > as the behavior is mentioned somewhere. Are you retracting your -1? -- Juliusz From nobody Sat Jun 29 04:01:51 2019 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 17B201200F3 for ; Sat, 29 Jun 2019 04:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 wWCsyT4l99za for ; Sat, 29 Jun 2019 04:01:46 -0700 (PDT) Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06C9012006F for ; Sat, 29 Jun 2019 04:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=o2uVMiEPvIKCh5HFIZ+yxfYhzW6S90KpeJMYrnjjgLg=; b=pNUg4SMKsyTov5HLrpsis7GLrf hRvibHBUyoPgHtvzIN5RGDX48Oqg1fIiLk/EEOa5tZWl+x/NnawFqBeKTy7+LfJPcN0ewwFrsAkeV H9LgyFXPHPXI093+Vn95pJIpJcFQ0ltBMc9a9NByqXW3DIsn1ZvWtzyJ08OTcLujz2IR5Hw+qaowj Uy+sLzNFsP2m2+gVzaQeQ2U6PIxsOyNcxCFXzaMYKcaC615dZtngJjwTjgNhs2F5qSc5QczPIIgdv ceO9KLkUZtElsNLc60ewLOyWKFLDEHoi9nyhlC7b1DQsiI3rv0ynJyjRzM0BKm68RfDgy07BBlGsN trNNM6Sw==; Received: from 91-155-69-60.elisa-laajakaista.fi ([91.155.69.60] helo=[192.168.42.210]) by mail.kapsi.fi with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hhB71-0004ri-5t; Sat, 29 Jun 2019 14:01:43 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Markus Stenberg In-Reply-To: <874l481x2q.wl-jch@irif.fr> Date: Sat, 29 Jun 2019 14:01:42 +0300 Cc: babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <874l49j158.wl-jch@irif.fr> <6C3AA518-8EF8-493A-835D-DE096E75D07B@iki.fi> <87ef3c20fh.wl-jch@irif.fr> <3CFB1069-5307-40F2-89DD-CA82CE2976A1@iki.fi> <87a7e01yxe.wl-jch@irif.fr> <5154BFF0-4BE3-4F72-AAA4-AC65DEDF2A97@iki.fi> <877e941xu9.wl-jch@irif.fr> <2EACCFA6-6214-4C95-9951-873B9C0F4B98@iki.fi> <874l481x2q.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-SA-Exim-Connect-IP: 91.155.69.60 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] Minor clarification to HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 29 Jun 2019 11:01:49 -0000 > On 29 Jun 2019, at 13.54, Juliusz Chroboczek wrote: >> So at most you can have # of network size spurious replayed neighbour >> table entries. > Right. We're hoping that implementations don't change their = link-local IP > addresses too often, i.e. that (genuine) link-locals are reasonably = stable. Well, I assume routers don=E2=80=99t really want to be private (some = wifi nodes change macs frequently for privacy purposes). >> No idea how limited implementations might behave with that (e.g. = fixed >> neighbour table size in a largish network with same HMAC key), >=20 > I'll add a note to the Security Considerations that implementations = want > to ensure that they fail gracefully when the neighbour table overflows > (i.e. that they fail to establish any new adjacencies rather than > crashing.) >=20 >> I think that given security consideration text it is fine then as = long >> as the behavior is mentioned somewhere. >=20 > Are you retracting your -1? Yes, given the s.c. text is sensible.=20 -Markus= From nobody Sat Jun 29 21:21:19 2019 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 4BDB3120020 for ; Sat, 29 Jun 2019 21:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3Azey5TWBqb for ; Sat, 29 Jun 2019 21:21:16 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 072B2120047 for ; Sat, 29 Jun 2019 21:21:16 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id x4so10176037wrt.6 for ; Sat, 29 Jun 2019 21:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+GibUzp035qCM+B+FZcbGPgYvb3dT08sV5OG3B4Mri0=; b=PDo2prF4MlBSSBgSRs32RfAjB+MNBBYngLCFq/jYJ44wzeKZxjRAhVRCqQlRc4d8bL 4x4f50jm3sevbJLtWmrVNHRhRzfcfvvIG0xDPKyDrPwc52PiqIOOEQf9rtKiYXOp5vkg yxzYYgeQJEnZzl5C3of3tA99PQyOVVKMS10nGkjnzByZ4x77I/bz4Xq+gq1aie96oRbq qeOiw2JX4cAPHQU+vD2CDVEZR4Rcjaba0Kh6+XAwtVSzBj+ZakTDZTVCQJ6737A7k+lN jS9ySasBbF+G1R58b/oWlxliG8sFRjmOFQBtJFym2zH6sN+vMDzISmz5xqCi7+c85XxE eX4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+GibUzp035qCM+B+FZcbGPgYvb3dT08sV5OG3B4Mri0=; b=gRVCJpufpnJ8B1cFy/51bbgkyzqxsDGG/s261uAVnElySz2XZ0+KlIqTMx7/qhb/f2 cpZTF21R3Tk7wwASF7OqsVu8y25pSNZci2tdjmz/w/0OXWaoIDLwrVXHbwXsE7dct430 5OGzkJP0wkpxYkmT9iyklcsydI/RBW7Ufnv1cBV9tqxnHfqLL69KnaSzmM7kxLIt7uMU W66NWyYS6YdaPAPWHC7te7CT7BI3iuJQBztFX9A615A3szLvSI7nSZHH5GViticxRwWG nSVkwb0fvnG0F1hcKSAOd3l1iVO6cqgntZAtkh1sOpIMcdeyleoMdsTP0BScPb0lSP7I 2b1w== X-Gm-Message-State: APjAAAXc242CJ2ojXQIPdKPLdl3nyEhkn51rRlQvSjLHNyOuCABjTeLR RLSQ+cMYq2R/Jcix2GuD4a4= X-Google-Smtp-Source: APXvYqz9+Wm98iyBS4287yPkYKz5FmsA54Wkca4mYceTXjy3bUNI3RLEJOmESMfFbK4Zzadc3M2QQA== X-Received: by 2002:a5d:5186:: with SMTP id k6mr14632351wrv.30.1561868474553; Sat, 29 Jun 2019 21:21:14 -0700 (PDT) Received: from [192.168.0.24] (cpc141876-watf13-2-0-cust467.15-2.cable.virginm.net. [86.13.125.212]) by smtp.gmail.com with ESMTPSA id g123sm4705298wme.12.2019.06.29.21.21.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Jun 2019 21:21:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Mahesh Jethanandani X-Mailer: iPad Mail (16A404) In-Reply-To: <87a7e01yxe.wl-jch@irif.fr> Date: Sun, 30 Jun 2019 05:21:12 +0100 Cc: Markus Stenberg , babel@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <874l49j158.wl-jch@irif.fr> <6C3AA518-8EF8-493A-835D-DE096E75D07B@iki.fi> <87ef3c20fh.wl-jch@irif.fr> <3CFB1069-5307-40F2-89DD-CA82CE2976A1@iki.fi> <87a7e01yxe.wl-jch@irif.fr> To: Juliusz Chroboczek Archived-At: Subject: Re: [babel] Minor clarification to HMAC X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 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, 30 Jun 2019 04:21:18 -0000 > On Jun 29, 2019, at 11:14 AM, Juliusz Chroboczek wrote: > > (I'm tempted to follow Mahesh's advice, and rewrite the last two > paragraphs of the Security Considerations section with reference to > RFC 4987. Advice?) Yes, I think it would be helpful. Thanks. Mahesh Jethanandani mjethanandani@gmail.com