From nobody Thu Aug 1 06:00: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 C06EB120145 for ; Thu, 1 Aug 2019 06:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wORvVCz3yqsx for ; Thu, 1 Aug 2019 06:00:48 -0700 (PDT) Received: from zm-mta-out-1.u-ga.fr (zm-mta-out-1.u-ga.fr [152.77.200.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9ADF1200F9 for ; Thu, 1 Aug 2019 06:00:47 -0700 (PDT) Received: from zm-mta-out.u-ga.fr (zm-mta-out.u-ga.fr [152.77.200.58]) by zm-mta-out-1.u-ga.fr (Postfix) with ESMTP id A3051A02D2; Thu, 1 Aug 2019 15:00:45 +0200 (CEST) Received: from smtps.univ-grenoble-alpes.fr (smtps2.u-ga.fr [195.83.24.202]) by zm-mta-out.u-ga.fr (Postfix) with ESMTP id 9F055E0062; Thu, 1 Aug 2019 15:00:45 +0200 (CEST) Received: from imag.fr (blaine.imag.fr [129.88.55.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jonglezb@univ-grenoble-alpes.fr) by smtps.univ-grenoble-alpes.fr (Postfix) with ESMTPSA id 9B5C360414; Thu, 1 Aug 2019 15:00:45 +0200 (CEST) Date: Thu, 1 Aug 2019 15:00:44 +0200 From: Baptiste Jonglez To: Donald Eastlake Cc: Babel at IETF , Juliusz Chroboczek Message-ID: <20190801130044.qdmiurynzudnt32h@imag.fr> References: <87r26df406.wl-jch@irif.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bo72tkr6dlk5invy" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Greylist: Whitelist-UGA SMTP Authentifie (jonglezb@univ-grenoble-alpes.fr) via smtps-465 ACL (99) Archived-At: Subject: Re: [babel] RTT consensus 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: Thu, 01 Aug 2019 13:00:51 -0000 --bo72tkr6dlk5invy Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 30, 2019 at 04:43:52PM -0400, Donald Eastlake wrote: > On Fri, Jul 26, 2019 at 7:07 AM Juliusz Chroboczek wrote: > > > > 1. There appears to be consensus that we keep the current =B5s granular= ity. > > > > Good. >=20 > This was the consensus in the room in Montreal and I haven't seen any > opposition to it but to be sure it's confirmed on this mailing list, > I'll wait until this coming Saturday to formally declare consensus on > that point. I also think we should keep the current =B5s granularity. --=20 Baptiste Jonglez PhD student Univ. Grenoble Alpes LIG lab Drakkar team | Polaris team at INRIA --bo72tkr6dlk5invy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEktPR7/7QieSQeRfBok0RNW6j3zkFAl1C4nwACgkQok0RNW6j 3zmtYw/+Lsu2CKLBDPdnyyN5lu+VLblsOgLiP9f447zvqLOfP9hDVoqsgYwynhzX ZvzccVuTp+sj4r/YcQj1ekryGucv04R97Xy0EHwpveIIF2En7Dim6iU5cBgMfwl7 K6wv016wvs7dyUIPB1xpjF2+zMWoz/luPp9iC5Js29/pEjorKrvYcQB5ev/ZsTFL MloKaWAjzwx7Wxmy1vSvWNoy9bVWoQHyXqEaK0ylCxtvWSMnTe/PYSed+MkDDo93 nktK9FHLDc7uWlMVyTvlRqiHniFx+InJasOgzrVX3t9qInhvwwtgG0E/yhBRUY4r v35FnpnGiQNIpKbC2v1WWrqN5xoko4+BxsAXGgy1gNf7BXqFbAgp0sulavc2IyQt ktEuq8mrz/5xOiU1Z9jt9dkwqPVsxnDkYL6/JA6zG2uGkZVkjk1bpsREI0bp0xUy hS767Ow6/8Xyos7ZWQ8xMtQ7XhuX7+wjDeInB7J2EXOBYH2EU/EMhvnIm8flL1hw EiqOuN/Iw+eZ2ID5Ec5EtlYU8udV0RYSGKcguLpzbPvBSEHWuNK4KKvppjQUM5Lr w4xdSylO17O39F++H5YGPBTdfWErUolj1mS1tKT+dQfRvpPVKvhyNZn+BVAT9KPT vRFMyGTHWlkzacvb/TKcEwmKO3jNnd4xxElvg2hUY7323El2+Ug= =N4fT -----END PGP SIGNATURE----- --bo72tkr6dlk5invy-- From nobody Thu Aug 1 07:09: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 3283312018A for ; Thu, 1 Aug 2019 07:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEVIEUEDpUlm for ; Thu, 1 Aug 2019 07:09:11 -0700 (PDT) Received: from zm-mta-out-1.u-ga.fr (zm-mta-out-1.u-ga.fr [152.77.200.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04DA4120170 for ; Thu, 1 Aug 2019 07:09:11 -0700 (PDT) Received: from zm-mta-out.u-ga.fr (zm-mta-out.u-ga.fr [152.77.200.58]) by zm-mta-out-1.u-ga.fr (Postfix) with ESMTP id B379DA03CA; Thu, 1 Aug 2019 16:09:09 +0200 (CEST) Received: from smtps.univ-grenoble-alpes.fr (smtps2.u-ga.fr [195.83.24.202]) by zm-mta-out.u-ga.fr (Postfix) with ESMTP id AEF1FE0062; Thu, 1 Aug 2019 16:09:09 +0200 (CEST) Received: from imag.fr (blaine.imag.fr [129.88.55.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jonglezb@univ-grenoble-alpes.fr) by smtps.univ-grenoble-alpes.fr (Postfix) with ESMTPSA id AA64C607CD; Thu, 1 Aug 2019 16:09:09 +0200 (CEST) Date: Thu, 1 Aug 2019 16:09:08 +0200 From: Baptiste Jonglez To: "STARK, BARBARA H" Cc: 'Juliusz Chroboczek' , 'Mahesh Jethanandani' , "'babel@ietf.org'" Message-ID: <20190801140908.i3fa3v4t5r7sbqr6@imag.fr> References: <20190725151332.ywxjpxpxoritx4ql@imag.fr> <59AF71F0-DFD6-40D4-8A2F-AD7068D28107@att.com> <87wog4ebgi.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E248BD3@GAALPA1MSGUSRBF.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ld2w4ecpb3b2to24" Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E248BD3@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: NeoMutt/20170113 (1.7.2) X-Greylist: Whitelist-UGA SMTP Authentifie (jonglezb@univ-grenoble-alpes.fr) via smtps-465 ACL (99) Archived-At: Subject: Re: [babel] Babel-RTT information model and example parameters 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: Thu, 01 Aug 2019 14:09:13 -0000 --ld2w4ecpb3b2to24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 29, 2019 at 09:11:38PM +0000, STARK, BARBARA H wrote: > > > The only parameter I think is definitely needed is one to > > > enable/disable use of RTT in metric calculations. > >=20 > > Unfortunately not. In a congested and bufferbloated network, tuning of= the > > saturation value (rtt-max) is necessary in order to avoid oscillations. > >=20 > > This mail has the full approval of the Commission for Truth in Advertis= ing. > >=20 > > -- Juliusz >=20 > I see the draft says "In addition, in order to enhance stability (Section= 2.3), the mapping should be bounded -- above a certain RTT, all links are = equally bad." Is this what you mean by rtt-max? To me, this would indicate = it would be ok to define a parameter rtt-max, because it's suggested in the= base spec that all implementations have it. Hmm, it needs more thinking. Should we require or strongly suggest that the mapping function has some properties, for instance that it SHOULD be non-decreasing and bounded? > Would it be the same rtt-max for all interfaces, or defined per > interface? In babeld, we make that configurable per-interface, and it really makes sense because Babel can be used in heterogeneous networks. Below is an extract of the babeld man page with all RTT-related parameters. They are all per-interface, although babeld also allows to configure any per-interface setting as a global default. rtt-decay This specifies the decay factor for the exponential moving average of RTT samples, in units of 1/256. Must be between 1 and 256, inclusive. Higher values discard old samples faster. The default is 42. rtt-min This specifies the minimum RTT, in milliseconds, starting from which we increase the cost to a neighbour. The additional cost is linear in (rtt - rtt-min). The default is 10 ms. rtt-max This specifies the maximum RTT, in milliseconds, above which we don't increase the cost to a neighbour. The default is 120 ms. max-rtt-penalty This specifies the maximum cost added to a neighbour because of RTT, i.e. when the RTT is higher or equal than rtt-max. The default is 96 if the interface is of type tunnel, and 0 otherwise. > Additionally... > Should this "should" be "SHOULD"? I see no normative language in the draf= t. Should there be some normative requirements? It seems a bit weird to me = to have a specification that doesn't tell you what MUST be done to be compl= iant with the spec. Good catch. We do use normative language in a few places in the draft, but I agree we should (or SHOULD?) make it more consistent. I will try to improve that for the next revision. Baptiste --=20 Baptiste Jonglez PhD student Univ. Grenoble Alpes LIG lab Drakkar team | Polaris team at INRIA --ld2w4ecpb3b2to24 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEktPR7/7QieSQeRfBok0RNW6j3zkFAl1C8oAACgkQok0RNW6j 3zlSPA/9F9xXVi08paS0NZjM6G0JV7J0kh3AYEL+ZR1CSPVXEEpXy4/wzcTkZ6uL R5lRpsCFrsJE0ju5q5/e+kX2B8InPHlpLXesxsnl1m1P3RwttK0wR8Tl/L+V3KdQ VJY85quiDNuwoJt0QfFpGALDJtGA+lpRu5GmYeHq5DljtId5AtwEVtLv/6aDj50p Mvd8HtabX7wVHPEaCRMVBtb2SSFWxZyVVApc4xA+Z2XINmxCMSDiIzzMZOg0KS5Y LV4RH7ZbhvyX8C4VR7t3bi1Na4b6KvWTGMH1Xa08FOc3C+EE535Je4ClO+wlrEeY rL5HWHNkFnyY4MbD22EVXkSolWQjOhHZZZNbIc9nOjy1zodYzXQ7yf1aCAq2OZsA xy4e8VmvYBIquDXdw16KmtxXLnKHUuqRiLduvcrCR7EMgvdcdzNKvI3j/ltIiTOw GZbJocu8IDv7TG4eVtMC/3WueMJYy3p5RuqZMuFc8yPlXK1dEDRtxI7XKT7VbLLn b+ViGerXose29kTXkUGTHfocmFKgWoU4OiSnleB+1TVCPgwjDPcc5TW+UgVFPX1F GTA93dgrZq35e/kym7ORuROk+p8WAKcKYPaa6T9ynON8BRPJZlr6I5uqQINkzrtA OK8ypdkcKLUuFCdccmNpTS7meHDBDU/8N/Esh3BgMYUs97Kzh+g= =HDl9 -----END PGP SIGNATURE----- --ld2w4ecpb3b2to24-- From nobody Thu Aug 1 16:32:46 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 C84721200FB; Thu, 1 Aug 2019 16:32:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Yingzhen Qu 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.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yingzhen Qu Message-ID: <156470236376.19191.1026181661457374790@ietfa.amsl.com> Date: Thu, 01 Aug 2019 16:32:43 -0700 Archived-At: Subject: [babel] Rtgdir telechat review of draft-ietf-babel-rfc6126bis-11 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, 01 Aug 2019 23:32:44 -0000 Reviewer: Yingzhen Qu Review result: Has Issues I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-babel-rfc6126bis Reviewer: Yingzhen Qu Review Date: 1 August 2019 Intended Status: Standards Track Summary: This document describes the Babel routing protocol, and obsoletes RFC 6126 and 7557. Note: both RFC 6126 and 7557 are experimental, the current bis version is standards track. I don’t know the history behind, but just want to point it out. Overall comments: The document is mostly well written. I’m not a native speaker, so I’d leave all language nits to RFC editors. Issues: (the line number is used is from idnits) There are security concerns raised by Secdir review: https://datatracker.ietf.org/doc/review-ietf-babel-rfc6126bis-10-secdir-lc-kaufman-2019-06-28/ The description about packet trailer is in RFC 7557 section 2.5, but not included in the bis version. Considering this document will obsolete RFC 7557, I suppose it should be self-complete, so readers don’t need to go back to RFC 7557 for more information. There are multiple places in the document about TLV/Sub-TLV being “self-terminating”, but I didn’t find what it means. Maybe I’m missing something here? Section 1.1 “unmanaged and wireless environment”, what does “unmanaged” mean here? Section 3.2.3 The interface Hello seqno is changed to outing multicast hello seqno, however there is no description about unicast hello at all. While I was reading it, I kept thinking what if it’s unicast hello? Is there a unicast hello timer needed? From later sections, I realized there are unicast hellos. So I’d suggest add some descriptions to avoid the confusion. Section 3.2.4 There is “the expected incoming Unicast Hello sequence number” and “the outgoing Unicast Hello sequence number”, but it was not mentioned in section 3.2.3 (related with previous comment). Section 3.8.1.1 After a node receives a route request, if the given prefix doesn’t exist in its route table, it MUST send a retraction for that prefix. So my question is whether a node is allowed to send multiple explicit requests for a given prefix? If so, what happens if both retractions and updates are received? Section 4.4 1616 4.4. Sub-TLV Format 1618 Every TLV carries an explicit length in its header; however, most 1619 TLVs are self-terminating, in the sense that it is possible to 1620 determine the length of the body without reference to the explicit 1621 Length field. If a TLV has a self-terminating format, then it MAY 1622 allow a sequence of sub-TLVs to follow the body. This section is about Sub-TLV, however the description language in this paragraph is mainly about TLV. Section 4.5 it says that “an implementation may choose to use a dedicated stateless parser to parse the packet trailer”. Will the packet trailer be able to use the state parser if there are state there useful or just for implementation purpose? Although there is no packet trailer defined at this moment. Section 4.5 1674 parsing a TLV MUST update the parser state even if the TLV is 1675 otherwise ignored due to an unknown mandatory sub-TLV. Section 4.6.5 1805 send a new scheduled Hello TLV with the same setting of the 1806 Unicast flag. If this is 0, then this Hello represents an I’d suggest changing the text to “the same setting of flags” instead of “the same setting of the Unicast flag”, considering the flags will be extended later. Nits: 1049 metric) from a neighbour neigh with a link cost value equal to cost, 1050 it checks whether it already has a route table entry indexed by [neighbour neigh] => [neighbour] Thanks, Yingzhen From nobody Fri Aug 2 01:21: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 F0141120025; Fri, 2 Aug 2019 01:21: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 RifokqLyxQZI; Fri, 2 Aug 2019 01:21: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 D8E19120019; Fri, 2 Aug 2019 01:20:56 -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 x728KomG014827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Aug 2019 10:20:50 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x728KpdU022695; Fri, 2 Aug 2019 10:20:51 +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 DE86D441B4; Fri, 2 Aug 2019 10:20:53 +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 EnQf3OjR9joF; Fri, 2 Aug 2019 10:20:52 +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 77806441B2; Fri, 2 Aug 2019 10:20:48 +0200 (CEST) Date: Fri, 02 Aug 2019 10:20:46 +0200 Message-ID: <87o918ou5d.wl-jch@irif.fr> From: Juliusz Chroboczek To: Yingzhen Qu Cc: , draft-ietf-babel-rfc6126bis.all@ietf.org, ietf@ietf.org, babel@ietf.org In-Reply-To: <156470236376.19191.1026181661457374790@ietfa.amsl.com> References: <156470236376.19191.1026181661457374790@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=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 02 Aug 2019 10:20:50 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 02 Aug 2019 10:20:51 +0200 (CEST) X-Miltered: at korolev with ID 5D43F262.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D43F263.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D43F262.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D43F263.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 : 5D43F262.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D43F263.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] Rtgdir telechat review of draft-ietf-babel-rfc6126bis-11 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, 02 Aug 2019 08:21:03 -0000 Dear Mr Qu, Thank you for your review. > The description about packet trailer is in RFC 7557 section 2.5, but not > included in the bis version. Considering this document will obsolete RFC 7557, > I suppose it should be self-complete, so readers don’t need to go back to RFC > 7557 for more information. The packet trailer is described in Section 4.2. > There are multiple places in the document about TLV/Sub-TLV being > “self-terminating”, but I didn’t find what it means. Maybe I’m missing > something here? This is defined in Section 4.4. I have checked that all uses of self-terminating occur after its definition. > Section 1.1 > “unmanaged and wireless environment”, what does “unmanaged” mean here? Not being actively managed by a human administrator. This is a non-normative section. Please let me know if I'm using this term badly. > Section 3.2.3 > The interface Hello seqno is changed to outing multicast hello seqno, however > there is no description about unicast hello at all. Unicast Hellos are per-neighbour, so they appear in Section 3.2.4 (Section 3.2.3 describes per-interface data structure while 3.2.4 describes per-neighbour structures). Both kinds of Hellos are described in more detail in Section 3.4.1. > While I was reading it, I kept thinking what if it’s unicast hello? Is > there a unicast hello timer needed? There is one, see Section 3.2.4, penultimate paragraph. > From later sections, I realized there are unicast hellos. So I’d suggest > add some descriptions to avoid the confusion. Sections 3.2.4 and 3.4.1. > Section 3.2.4 > There is “the expected incoming Unicast Hello sequence number” and “the > outgoing Unicast Hello sequence number”, but it was not mentioned in section > 3.2.3 (related with previous comment). That's right. Section 3.2.3 describes per-interface data. Section 3.2.4 describes per-neighbour data. Multicast Hellos are per-interface. Unicast Hellos are per-neighbour. > Section 3.8.1.1 > After a node receives a route request, if the given prefix doesn’t exist in its > route table, it MUST send a retraction for that prefix. So my question is > whether a node is allowed to send multiple explicit requests for a given > prefix? There's nothing forbidding it. It may send multiple requests to different neighbours (over unicast), or multiple requests on different interfaces (over multicast). There's also nothing forbidding a node from sending multiple requests to the same destination, e.g. to compensate for packet loss. (Our implementation experience shows that, at least over 802.11, such aggressive behaviour is not useful, it increases noise without having a measurable effect on convergence time, hence the SHOULD in Section 3.8.2.3 which only requires a single request. However, further research might yield new insights, which is why this document does not explicitly disallow such behaviour.) > If so, what happens if both retractions and updates are received? The procedure described in Section 3.5.4 is run for each received update or retraction, which results in the construction of the data structures used as input for the precedure described in Section 3.6. > 1616 4.4. Sub-TLV Format > This section is about Sub-TLV, however the description language in this > paragraph is mainly about TLV. Good catch, thanks. I'll fix that. > Section 4.5 > it says that “an implementation may choose to use a dedicated stateless parser > to parse the packet trailer”. Will the packet trailer be able to use the state > parser if there are state there useful or just for implementation purpose? I do not understand this comment. Please clarify. > Although there is no packet trailer defined at this moment. Section 4.2. > Section 4.5 > 1674 parsing a TLV MUST update the parser state even if the TLV is > 1675 otherwise ignored due to an unknown mandatory sub-TLV. I believe you may have forgotten to write your comment. > Section 4.6.5 > 1805 send a new scheduled Hello TLV with the same setting of the > 1806 Unicast flag. If this is 0, then this Hello represents an > I’d suggest changing the text to “the same setting of flags” instead of “the > same setting of the Unicast flag”, considering the flags will be extended later. I disagree. This paragraph is about the multicast/unicast dichotomy, not about future flags of an informative nature. > Nits: > 1049 metric) from a neighbour neigh with a link cost value equal to cost, > 1050 it checks whether it already has a route table entry indexed by > [neighbour neigh] => [neighbour] I disagree. We're defining the variable neigh, which we use in the next sequence. Regards, -- Juliusz Chroboczek From nobody Fri Aug 2 01:30:22 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 7C388120026; Fri, 2 Aug 2019 01:30: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 4Pm10ACcIYTB; Fri, 2 Aug 2019 01:30: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 1FBC8120019; Fri, 2 Aug 2019 01:30:11 -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 x728U6MG017326; Fri, 2 Aug 2019 10:30:06 +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 1C05844279; Fri, 2 Aug 2019 10:30:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id iytW-UuNJjkE; Fri, 2 Aug 2019 10:30:09 +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 24B0144277; Fri, 2 Aug 2019 10:30:09 +0200 (CEST) Date: Fri, 02 Aug 2019 10:30:09 +0200 Message-ID: <87imrgotpq.wl-jch@irif.fr> From: Juliusz Chroboczek To: Yingzhen Qu Cc: , draft-ietf-babel-rfc6126bis.all@ietf.org, ietf@ietf.org, babel@ietf.org In-Reply-To: <87o918ou5d.wl-jch@irif.fr> References: <156470236376.19191.1026181661457374790@ietfa.amsl.com> <87o918ou5d.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 [194.254.61.138]); Fri, 02 Aug 2019 10:30:06 +0200 (CEST) X-Miltered: at korolev with ID 5D43F48E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D43F48E.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 : 5D43F48E.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Rtgdir telechat review of draft-ietf-babel-rfc6126bis-11 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, 02 Aug 2019 08:30:14 -0000 >> 1616 4.4. Sub-TLV Format >> This section is about Sub-TLV, however the description language in this >> paragraph is mainly about TLV. > Good catch, thanks. Actually, this section starts by describing how sub-TLVs fit within TLVs, so it's correct as it stands. -- Juliusz Chroboczek From nobody Sat Aug 3 14:52:38 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 9E709120143; Sat, 3 Aug 2019 14:52:36 -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 hC_KIvi3hoEe; Sat, 3 Aug 2019 14:52:35 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 0AFED120134; Sat, 3 Aug 2019 14:52:35 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id k8so159905244iot.1; Sat, 03 Aug 2019 14:52:35 -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:content-transfer-encoding; bh=bTxqtSGvY41GPZ2Kq53qC0iqwgFuT4w0oQ9aDCdw/T8=; b=QuEcYiYJJvtyIQUgM9rTpwRJ8IaokPdMegBTE+pyQkDZVYkys+yZNBCKCyFc/FKjWT mOPsvxmtPk3D5rX1DyQ8FgBaL/eXVvjuAyGDdQoCjjr4YxApk5i2C6e7eqz7nPhfIf/z yrb5tqtjO2YXJr0BhS8nJlhASY000tLPXBttxPLhzfocsjZuWUAARcFBhqiN5RClbIOE hbU4piq5Yym5QFP9nkUBRMuLG+x3B+MBx2tpY190GKihaWVgcYhvLtjrNGB49Mmp3eMk KzYwujUsc5067bCk02IbxTHZB/HbSL7hgG4PjC/ih89V9PDmt9rTlhpaLsLB4tppYOQk qHCw== 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:content-transfer-encoding; bh=bTxqtSGvY41GPZ2Kq53qC0iqwgFuT4w0oQ9aDCdw/T8=; b=YMTYOUDOycLIqXFI7tD+ubAlJ9tL7stG3zfh0YTjIcJkIsS0Pd0D3oZ1beP8uJ8mT2 7e0/J40oZEVgOVd3V4it3jNR5BL1dInTrzxgsuKVb2PWjIrUaDpvSVQPOf2UsHX+TBSX fGR3y3Tk3OUCeQRQ2zpAD/e/9ljZDOsQ5L1+Quib+/KB2APhjhA+xXGqNpyI0bvWJYB2 0+rVskuVv20aq9DO/6Eg9lIQja0jl+mtB2Tc9PTL4zyITERsd4SEfagt4HTA/yu0NiwW hnIHkyfcPwnC4PzpK60sRM/JzFFpEYujxuin9YCEiwPAJcxFpk6XZdXZEis5BwAK4v+i BENw== X-Gm-Message-State: APjAAAXe6H9xx38c3Skrfd9809pyqNRKdPZ5i0lz0+b9K7f56a1hAvSr rYcEBFfinG0KQ2SA8tNnckrYplc36NKFXfTBeNTu+g== X-Google-Smtp-Source: APXvYqwU0q0FrRgkTN5IcQVh0CXMNnmATbDqYSUR1QUT5PL7X81C9ruilUyDTVmtsdoGW2+JGuVc3FjJDRb65wHCjDA= X-Received: by 2002:a6b:f80b:: with SMTP id o11mr17007175ioh.40.1564869153900; Sat, 03 Aug 2019 14:52:33 -0700 (PDT) MIME-Version: 1.0 References: <87r26df406.wl-jch@irif.fr> In-Reply-To: From: Donald Eastlake Date: Sat, 3 Aug 2019 17:52:22 -0400 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] RTT consensus 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, 03 Aug 2019 21:52:37 -0000 his message declares WG consensus to keep the 1 microsecond timestamp resolution. Thanks, Donald (Co-Chair) PS: I notice that in the last paragraph of Section 1, there is "(1ms)". The "ms" could represent microseconds but I think that in this context it more commonly means milliseconds. Suggest that the next time the draft is revised, this be expanded to "(1 microsecond)". =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com On Tue, Jul 30, 2019 at 4:43 PM Donald Eastlake wrote: > > On Fri, Jul 26, 2019 at 7:07 AM Juliusz Chroboczek wrote: > > > > 1. There appears to be consensus that we keep the current =C2=B5s granu= larity. > > > > Good. > > This was the consensus in the room in Montreal and I haven't seen any > opposition to it but to be sure it's confirmed on this mailing list, > I'll wait until this coming Saturday to formally declare consensus on > that point. > > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 1424 Pro Shop Court, Davenport, FL 33896 USA > d3e3e3@gmail.com > > > 2. There is some misgivings about attaching transmit timestamps to Hell= o > > packets > > > > The alternative is to define a new TLV that contains just a transmit > > timestamp and deprecate (but not obsolete -- no flag day) the current > > transmit timestamp sub-TLV (attached to a Hello). > > > > We need more thought. > > > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://www.ietf.org/mailman/listinfo/babel From nobody Sun Aug 4 18:47:05 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 1F10312013D; Sun, 4 Aug 2019 18:47:04 -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.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156496962402.26572.16204290795859744323@ietfa.amsl.com> Date: Sun, 04 Aug 2019 18:47:04 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-information-model-08.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: Mon, 05 Aug 2019 01:47:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : Babel Information Model Authors : Barbara Stark Mahesh Jethanandani Filename : draft-ietf-babel-information-model-08.txt Pages : 28 Date : 2019-08-04 Abstract: This Babel Information Model can be used to create data models under various data modeling regimes. It allows a Babel implementation (via a management protocol or interface) to report on its current state and may allow some limited configuration of protocol constants. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-information-model-08 https://datatracker.ietf.org/doc/html/draft-ietf-babel-information-model-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-information-model-08 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 Mon Aug 5 00:02:03 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 BD2D612004D; Mon, 5 Aug 2019 00:01:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <156498851376.24465.4531172446015994141.idtracker@ietfa.amsl.com> Date: Mon, 05 Aug 2019 00:01:53 -0700 Archived-At: Subject: [babel] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-babel-rfc6126bis-11=3A_=28with_COMMENT=29?= 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: Mon, 05 Aug 2019 07:01:54 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-babel-rfc6126bis-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Dear authors, Thank you for the work put into this document and its companion documents. The text is usually clear and explanations are concise and easy to understand. I have nevertheless some COMMENTs and a few NITs. Regards, -éric == COMMENTS == -- Section 1.1 -- In the properties bullet points, "its diameter" is it about the loop diameter or the network diameter? I suspect the latter but this is ambiguous IMHO. -- Section 3 -- It is unclear by reading "The protocol encoding is slightly more compact when router-ids are assigned in the same manner as the IPv6 layer assigns host IDs." whether EUI-64 is referred here. I also fail to see in section 4.6.7 (router-id TLV) what is the encoding benefit? -- Section 3.1 -- Should there be a mention of maximum UDP datagram size? and some words on layer-3 fragmentation ? I understand that section 4 has a section on this, so, perhaps refer already to that section for completeness ? -- Sections 3.2.3 and 3.2.4 -- Does a dual-stack host have to send 2 hello? One on each protocol stack (v6 or v4) ? Unclear from the explanation. -- Section 3.4.2 -- It is unclear to me whether a link to a neighbor (router-id) can have different cost based on the v6 or v4. -- Section 4 -- Is there a reason why the well-known ports and multicast group addresses are not spelled out in this section ? They only appear in the IANA considerations section. Also, should the hello be sent over v6 _AND_ v4 ? -- Section 4.2 -- No a real comment, just an appreciation of your humor: "The arbitrary but carefully chosen value 42" ;-) you made my Monday morning ! -- Section 4.4 -- Is there any reason why the 'mandatory bit' does not appear in the packet structure? -- Section 4.6.2 -- Is there any reason why the "MBZ" is not expanded ? Must Be Zero ? -- Section 4.6.3 -- I wonder how the receiver could estimate the propagation time (in each direction BTW) + queuing time + whatever delay... -- Section 4.6.7 -- Should the router-id field length be repeated here as well ? == NITS == -- Section 1.1 -- Rather than using 'naive' to describe RIP, let's rather use 'trivial' or 'simple' ;-) s/the routers involved participate/the involved routers participate/ ? -- Section 3.2.6 -- Suggest to use '0xffff' rather than 'FFFF' and be consistent in the use of lowercase / uppercase for hexadecimal numbers. -- Section 4.5 -- Parsing "since for correct parsing it must be identical across implementations" is not easy... a comma would be welcome. -- Section 4.6.3 -- s/receiver send/receiver sends/ From nobody Mon Aug 5 00:37:47 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 444A512002F; Mon, 5 Aug 2019 00:37:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-babel-dtls@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <156499066627.24529.10259312583734398168.idtracker@ietfa.amsl.com> Date: Mon, 05 Aug 2019 00:37:46 -0700 Archived-At: Subject: [babel] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-babel-dtls-07=3A_=28with_COMMENT=29?= 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: Mon, 05 Aug 2019 07:37:46 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-babel-dtls-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. I have only two COMMENTs. Regards, -éric == COMMENTS == -- Section 1.2 -- The text refers to the security consideration of RFC6121bis for an extended comparison of HMAC & DTLS except that there is no additional information in RFC 6121bis. -- Section 2.1 -- It is a little unclear to me whether a mix of DTLS and non-DTLS Babel nodes can exist on the same layer-2 network. I guess no (as implied later) but a clear sentence would help. From nobody Mon Aug 5 00:57:06 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 C5D7112001A; Mon, 5 Aug 2019 00:57:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-babel-hmac@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <156499182480.24510.10221692265742263303.idtracker@ietfa.amsl.com> Date: Mon, 05 Aug 2019 00:57:04 -0700 Archived-At: Subject: [babel] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-babel-hmac-08=3A_=28with_COMMENT=29?= 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: Mon, 05 Aug 2019 07:57:05 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-babel-hmac-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-hmac/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Using HMAC is usually simple but this document builds a lot of negotiation around HMAC. Regards, -éric == COMMENTS == I am a little puzzled by why HMAC keys/mechanisms are not identified to facilitate the key rollover. The used mechanism appears a little heavy on the required computing effort to compute several HMAC. -- Section 1 -- The text about attacks on the Babel routing protocol should be better placed in the security considerations of RFC7216bis. == NITS == The DTLS document use the writing <"babel" port> while here it is . From nobody Mon Aug 5 04:36:30 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 99CA3120194; Mon, 5 Aug 2019 04:36:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-babel-applicability@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <156500498261.24571.204581663078651704.idtracker@ietfa.amsl.com> Date: Mon, 05 Aug 2019 04:36:22 -0700 Archived-At: Subject: [babel] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-bab?= =?utf-8?q?el-applicability-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Mon, 05 Aug 2019 11:36:23 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-babel-applicability-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-applicability/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Julius, Thank you for the work put into this document. I have one DISCUSS and a couple of COMMENTs. One generic comment: is there a need to describe (even in a short format) Babel again? Regards, -éric == DISCUSS == -- Section 2.2 -- The 'bug resistance' property of Babel was perhaps learned during the implementation, but, I wonder whether the document may simply state 'robust with respect to bugs', this is quite a strong statement that needs to be backed by facts or proof. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- == COMMENTS == The title of the document is about 'applicability'; but, should it also include 'use cases' in the title ? -- Section 3.1 -- The 2nd paragraph is too dense: should explain why Babel is a good fit. -- Section 5 -- Comparison between HMAC & DTLS variants is probably irrelevant in this document. Though, a use case with security in mind would be benefitial. Also, the comparison should include all aspects including confidentiality and anti-reply for both HMAC & DTLS. == NITS == -- Section 2.2 -- As I am not a native English speaker, I wonder whether 'light' should not be preferred to 'weak' in "These weak requirements make Babel a robust protocol" -- Section 3.1 -- Suggest to change the section name into "Diverse networks" or "heterogenous networks". From nobody Mon Aug 5 04:59:29 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 532231201ED; Mon, 5 Aug 2019 04:59: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 Z73H3Aj6LbEP; Mon, 5 Aug 2019 04:59: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 344341201EE; Mon, 5 Aug 2019 04:59:06 -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 x75Bwwjh014566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 Aug 2019 13:58:58 +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 x75Bwxlu014032; Mon, 5 Aug 2019 13:58:59 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 0E4E14E301; Mon, 5 Aug 2019 13:59: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 CkSADH5C3Xdb; Mon, 5 Aug 2019 13:59:00 +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 482944E2FB; Mon, 5 Aug 2019 13:59:00 +0200 (CEST) Date: Mon, 05 Aug 2019 13:59:00 +0200 Message-ID: <87v9vblt6j.wl-jch@irif.fr> From: Juliusz Chroboczek To: =?ISO-8859-1?Q?=C9ric?= Vyncke Cc: "The IESG" , draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156498851376.24465.4531172446015994141.idtracker@ietfa.amsl.com> References: <156498851376.24465.4531172446015994141.idtracker@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]); Mon, 05 Aug 2019 13:58:58 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 05 Aug 2019 13:58:59 +0200 (CEST) X-Miltered: at korolev with ID 5D481A02.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D481A03.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D481A02.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D481A03.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 : 5D481A02.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D481A03.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] =?iso-8859-1?q?=C9ric_Vyncke=27s_No_Objection_on_draft-i?= =?iso-8859-1?q?etf-babel-rfc6126bis-11=3A_=28with_COMMENT=29?= 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: Mon, 05 Aug 2019 11:59:20 -0000 Dear Eric, Thank you very much for your detailed review. Since your nits are (thankfully) fairly minor, I'll be fixing them in the git repository[1] and only submit a new revision at a later time. [1] https://github.com/jech/babel-drafts > In the properties bullet points, "its diameter" is it about the loop diameter > or the network diameter? I suspect the latter but this is ambiguous IMHO. The former. Reworded. > It is unclear by reading "The protocol encoding is slightly more compact when > router-ids are assigned in the same manner as the IPv6 layer assigns host IDs." > whether EUI-64 is referred here. I also fail to see in section 4.6.7 (router-id > TLV) what is the encoding benefit? Flag "R" in the Update TLV. It allows copying the router-id from the advertised prefix. This is dramatically effective in mesh networks (where each node advertises its own loopback address), not so much in traditional prefix-based networks. I've added a forward ref. > -- Section 3.1 -- > Should there be a mention of maximum UDP datagram size? and some words on > layer-3 fragmentation ? I understand that section 4 has a section on this, so, > perhaps refer already to that section for completeness ? We're already referring to it ("as described in Section 4 below"). I don't think it is worth overloading this section any further. > -- Sections 3.2.3 and 3.2.4 -- > Does a dual-stack host have to send 2 hello? One on each protocol stack (v6 or > v4) ? Unclear from the explanation. As far as the protocol is concerned, both deployment models are possible: - the BGP-style double-stack model, where a single protocol instance (running over IPv4 or IPv6) carries both IPv4 and IPv6 routes; - the "ships in the night" model, where two protocol instances are run, one over IPv4, one over IPv6. In the double-stack model (which is what all current implementations implement), a single IPv6 hello is sent. I'm not sure if this should be spelled out explicitly -- FWIW, none of the Babel implementers had any trouble with that. (In principle, the protocol could be run directly over the link layer, IS-IS style, which could perhaps be useful in some IoT-style scenarios. It could even use different encapsulations on different interfaces, for example UDP/IPv6 over a tunnel but raw Ethernet over a physical interface. However, since this has never been implemented, this draft doesn't allow that kind of operation.) > -- Section 3.4.2 -- > It is unclear to me whether a link to a neighbor (router-id) can have > different cost based on the v6 or v4. Not in the double-stack model, no. There's a single cost per neighbour. The same effect, however, can be achieved by computing different metrics for different address families, i.e. by using the address family as a parameter in the metric computation described in Section 3.5.2 -- this is analoguous to using different prepending rules in BGP. This is implemented by both babeld and BIRD. > -- Section 4 -- > Is there a reason why the well-known ports and multicast group addresses are > not spelled out in this section ? They only appear in the IANA considerations > section. I prefer to avoid duplication to the extent possible. > Also, should the hello be sent over v6 _AND_ v4 ? Not in the double-stack deployment model, no. > -- Section 4.4 -- > Is there any reason why the 'mandatory bit' does not appear in the packet > structure? The mandatory bit is considered as part of the Type, i.e., the first mandatory sub-TLV number is 128; I don't think there's a way to express that in a packet diagram. I've clarified the wording and left the packet diagram unchanged. > -- Section 4.6.2 -- > Is there any reason why the "MBZ" is not expanded ? Must Be Zero ? Done. > -- Section 4.6.3 -- > I wonder how the receiver could estimate the propagation time (in each > direction BTW) + queuing time + whatever delay... The intent here is that the sender uses a reasonable margin. For example, the reference implementation uses a margin equal to interval/3. I don't want to give any advice here, since we don't currently have a lot of implementation experience with ACKs in Babel (the mechanism is currently only used by the optional algorithm described in the second bullet point in Section 3.5.5, and this is only implemented in BIRD). > -- Section 4.6.7 -- > Should the router-id field length be repeated here as well ? No. > == NITS == > -- Section 1.1 -- > Rather than using 'naive' to describe RIP, let's rather use 'trivial' or > 'simple' ;-) I most humbly disagree. "Naive" here applies to "distance-vector protocol", meaning that RIP uses the "naive distance-vector", i.e. distance vector with no additional mechanisms. > s/the routers involved participate/the involved routers participate/ ? I most humbly disagree. > -- Section 3.2.6 -- > Suggest to use '0xffff' rather than 'FFFF' and be consistent in the use of > lowercase / uppercase for hexadecimal numbers. I've switched to uppercase throughout. > -- Section 4.5 -- > Parsing "since for correct parsing it must be identical across implementations" > is not easy... a comma would be welcome. This sentence has been shot, and replaced by a shorter one. > -- Section 4.6.3 -- > s/receiver send/receiver sends/ Disagree, this is in the conjunctive. Thanks again for your review, -- Juliusz From nobody Mon Aug 5 05:51:27 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 07F4B1201C3; Mon, 5 Aug 2019 05:51:14 -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 jR2PLqaxslVB; Mon, 5 Aug 2019 05:51:11 -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 805AF1201B0; Mon, 5 Aug 2019 05:51: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 x75Cp2Pn001199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 Aug 2019 14:51:02 +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 x75Cp2C4029838; Mon, 5 Aug 2019 14:51: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 758E64E5C3; Mon, 5 Aug 2019 14:51:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id K3rll7R96Jpe; Mon, 5 Aug 2019 14:51:04 +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 C591F4E5BF; Mon, 5 Aug 2019 14:51:02 +0200 (CEST) Date: Mon, 05 Aug 2019 14:51:02 +0200 Message-ID: <87tvavlqrt.wl-jch@irif.fr> From: Juliusz Chroboczek To: =?ISO-8859-1?Q?=C9ric?= Vyncke Cc: "The IESG" , draft-ietf-babel-applicability@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156500498261.24571.204581663078651704.idtracker@ietfa.amsl.com> References: <156500498261.24571.204581663078651704.idtracker@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=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]); Mon, 05 Aug 2019 14:51:02 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 05 Aug 2019 14:51:02 +0200 (CEST) X-Miltered: at korolev with ID 5D482636.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D482636.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D482636.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D482636.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 : 5D482636.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D482636.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] =?iso-8859-1?q?=C9ric_Vyncke=27s_Discuss_on_draft-ietf-b?= =?iso-8859-1?q?abel-applicability-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Mon, 05 Aug 2019 12:51:14 -0000 Dear Eric, Thanks for your review. > == DISCUSS == > -- Section 2.2 -- > The 'bug resistance' property of Babel was perhaps learned during the > implementation, but, I wonder whether the document may simply state 'robust > with respect to bugs', this is quite a strong statement that needs to be backed > by facts or proof. Would you be satisfied if I added the following paragraph? Or would you prefer some other resolution? For example, an early version of the reference implementation would very occasionally corrupt the contents of its receive buffer. With high probability, the bug would corrupt the destination address of an IPv6 host route, which would cause a spurious "martian" route to be announced to the network and then silently time out, with no ill effects. (For the sake of old times, I'll recall that I was the guilty party, and that the bug was fixed by Grgoire Henry and Julien Cristau who spent almost a whole night observing a Babel node. They weren't pleased.) > The title of the document is about 'applicability'; but, should it also > include 'use cases' in the title ? I prefer shorter titles, but I don't feel strongly either way. Perhaps the list can chime in? > Section 3.1 > The 2nd paragraph is too dense: should explain why Babel is a good fit. Agreed, I'll reword. > -- Section 5 -- > Comparison between HMAC & DTLS variants is probably irrelevant in this > document. Though, a use case with security in mind would be benefitial. There are no known use cases. Our users run Babel over secure link layers, and nobody has requested security mechanisms embedded within the protocol. The security mechanisms were designed solely in order to satisfy IETF requirements. (To be fair, it was a lot of fun.) > Also, the comparison should include all aspects including confidentiality and > anti-reply for both HMAC & DTLS. The document currently says: Babel-HMAC [HMAC] is a simple and easy to implement mechanism that only guarantees authenticity and integrity of the routing traffic, and only supports symmetric keying with a small number of keys (typically just one or two), but is invulnerable to replay even in the absence of persistent state. Babel-DTLS [DTLS] is a more complex mechanism, that requires some minor changes to be made to a typical Babel implementation and depends on a DTLS stack being available, but inherits all of the features of DTLS, notably confidentiality and the ability to use asymmetric keys. Please let me know if you feel that this paragraph needs to be expanded or otherwise reworded, and, if so, in what way. Thanks again, -- Juliusz From nobody Mon Aug 5 05:55: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 926E91201CB; Mon, 5 Aug 2019 05:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=nCYZXH1W; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0y2BMsRk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l87EEGB7BaN2; Mon, 5 Aug 2019 05:55:35 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779461201B0; Mon, 5 Aug 2019 05:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2234; q=dns/txt; s=iport; t=1565009735; x=1566219335; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NstSYKkMf7yX5eWO8Iu4xGBK2wpZ2aghPvnzRb5nZh0=; b=nCYZXH1W8ifaAws08cmNdNKIhseH2L6wkKNW7gIqSlK2rCgW9rQvGlBw DP+jYp5+OfLxUOa83pw6r4aHd7ROalAe70gY2LAfvO4Hqo00I8+kqz6H4 Rb5ugyejtjuLj4PCKjKbivxj1XNRRd992kiDZk6CUOzKGgELPl9KP+7Cc 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AgEhxhBymHwttAX7XCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhSN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuIF1z9J/3nRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COBQDrJkhd/4kNJK1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBZ4FFUAOBQiAECyqEHoNHA4stgjYll1mCUgNUCQEBAQwBAS0CAQGEPwI?= =?us-ascii?q?XglgjOBMBAwEBBAEBAgEGbYUeDIVLAQEBAgESEREMAQElEgEPAgEIDgwCJgI?= =?us-ascii?q?CAjAVBQsCBA4FIoMAgWsDDg8BAqBJAoE4iGBxgTKCegEBBYUDGIITCYEMKIt?= =?us-ascii?q?jF4FAP4EQAScME4JMPoREF4J0MoImjlgxmy5tCQKCG5QeG4IvhyyOToMqog0?= =?us-ascii?q?CBAIEBQIOAQEFgWchgVhwFWUBgkGCQjeDOopTcoEpjRMBAQ?= X-IronPort-AV: E=Sophos;i="5.64,349,1559520000"; d="scan'208";a="606509377" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Aug 2019 12:55:22 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x75CtMki005974 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Aug 2019 12:55:22 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 07:55:21 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 07:55:21 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 5 Aug 2019 07:55:21 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eZD2D9U9QQtKzTQeGT9QZlK8MmsF8gvEhKpBFY7y2tYJJFtOZP0RAswe6ZrsE3XtsPgNIegEhAjgCzXNuOYmuinrgEvh1VyLjY04GoaRcFAoAbdDM7kYBHNjhpBA9mw0YpiZv8YnxEMsDufItnxRiBnxR9iKx0AWkmXyAuuyDknSFdH6XyYv9nwWryBhOII9/xkM7cuaqk999+rXnPwEKAMqg8R4SkW/w7rlvo/3tYYWcHBGCLkYFEbh3ALHL5EWc0VT+RwhABz24CTIw1v74TGLAKPgsqPhU//HFSkqAVps2RPTV6qW9aOyqdkFD0F9Nzj6GBaIllk7ME9ZdnJXww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NstSYKkMf7yX5eWO8Iu4xGBK2wpZ2aghPvnzRb5nZh0=; b=V/jthsl/DzSQOwb4fPZ2XUT65+7uheEhpuV/ykUfUI3u2Is6omZ9jMS5219iOpb1qGOt3GTT0BL5SMhEjGLq/SABSO1Ge2gYRtiyUNSRPPo2YxmCA99GUEHnXx3YfDun4sJU/GIcEad7sUEkz0wRTqNEfOdOrnb+4jCBhV7WhBWQ27fWmT4qlG3/OBBG5yvl+sdYf+F1CzMv6f4HiqOQrQa6Jxlh2BZ3SrYAEUL6g+iUwxfyaS7x+5wSPJay5tuDbc0ugEHbErQ00e8PR4Zy/Tf62RlDqbj1f6W/ii9TDuchLYKRg0xhQDGik1+VEgsC3xMfm4JvgJXWodQD4+SNSw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NstSYKkMf7yX5eWO8Iu4xGBK2wpZ2aghPvnzRb5nZh0=; b=0y2BMsRkpFkzGYSi/NmFfsVVW4a364Ic1mbXUgLtcDYiTkxiqiDAIB+uS2wFvZpq/U3AJD3sJS9A2vdM9ATvvC6L2uyyHZITd8jYQClkOo9TwzqY4dDQCSuZfqgwRKUkxOyRUVa1OwGKbwKkATIhL42BX510rNkdak7bT/HuSE8= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB4030.namprd11.prod.outlook.com (10.255.181.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.16; Mon, 5 Aug 2019 12:55:20 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::cc02:dc35:1f73:653c]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::cc02:dc35:1f73:653c%7]) with mapi id 15.20.2136.018; Mon, 5 Aug 2019 12:55:20 +0000 From: "Eric Vyncke (evyncke)" To: Juliusz Chroboczek CC: The IESG , "draft-ietf-babel-rfc6126bis@ietf.org" , Donald Eastlake , "babel-chairs@ietf.org" , "babel@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtYmFi?= =?utf-8?Q?el-rfc6126bis-11:_(with_COMMENT)?= Thread-Index: AQHVS4UqQLG3jsUS+Ea2nZEu5x5lgqbspI6A Date: Mon, 5 Aug 2019 12:55:20 +0000 Message-ID: <518548BD-80F5-4F02-9362-EC61D0D5CA7B@cisco.com> References: <156498851376.24465.4531172446015994141.idtracker@ietfa.amsl.com> <87v9vblt6j.wl-jch@irif.fr> In-Reply-To: <87v9vblt6j.wl-jch@irif.fr> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1b.0.190715 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:94cc:3600:4eda:dc83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f9ce22c4-8933-4417-29a9-08d719a42c3e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4030; x-ms-traffictypediagnostic: MN2PR11MB4030: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01208B1E18 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(136003)(366004)(396003)(376002)(199004)(189003)(7736002)(5660300002)(6512007)(486006)(2616005)(46003)(224303003)(446003)(11346002)(99286004)(36756003)(476003)(305945005)(25786009)(54906003)(33656002)(186003)(4326008)(68736007)(6916009)(86362001)(478600001)(6436002)(76116006)(66446008)(64756008)(66556008)(66946007)(66476007)(8936002)(14454004)(229853002)(316002)(6486002)(81166006)(6116002)(2906002)(256004)(71200400001)(81156014)(91956017)(58126008)(71190400001)(76176011)(53936002)(102836004)(6246003)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4030; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: EbpVqLY23RjFvco0HoW5rC2gY+RN7a4fT1wkQfw37uUMMvMltEHqTD47CLJzNnRM8PqoZUAK92Yd4A+2u20mKbGrcWHjLpVoOaIsww1qjThXgUqXz1V/aNfgrCYLS3uxJQK41mXb4pH70RpxN6feE8ulZlN4vxP10clQ4uv5+w8WI5dUf64Y15YtjLlNZvX2CVXdhOIcqnWUjy9TFfDaMewOGxSzpRPKbmkyu1fiWUofy5AwRiPAiEuttj0JWl0IDm5KiXkh5Tuy5k1Pp4nYKHIzNTaCi0xqlkHK4aj5CpHCLsSCXuLsL6ecI0vk4Wzws/6XOUsGz90OyLGOjDPNw75HC07/eAURkVJ+l2Jw3iu53ckBJWz5sMbDqrzXPznoKfw1sA4ewtPvHUq3RG+ZSEJLocSuATjfF2oyQvFf3Fw= Content-Type: text/plain; charset="utf-8" Content-ID: <7EF3D1530621D24B9E5E268B87C473CD@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f9ce22c4-8933-4417-29a9-08d719a42c3e X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2019 12:55:20.0788 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: evyncke@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4030 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [babel] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-babel-rfc6126bis-11=3A_=28with_COMMENT=29?= 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: Mon, 05 Aug 2019 12:55:38 -0000 SnVsaXVzeiwNCg0KVGhhbmsgeW91IGZvciB0aGUgcHJvbXB0IHJlYWN0aW9uLiBJIGFncmVlIHdp dGggYWxsIHlvdXIgcG9pbnRzIChldmVuIHdoZW4geW91IGRpc2FncmVlIHdpdGggbWUgOy0pICkg ZXhjZXB0IG9uIHRoZSBvbmUtYmVsb3c6IGR1YWwtc3RhY2sgQmFiZWwgb3IgInNoaXBzIGluIHRo ZSBuaWdodCIuIFBsZWFzZSBzdGF0ZSBzb21ld2hlcmUgdGhhdCB0aGUgdHdvIG9wdGlvbnMgYXJl IGF2YWlsYWJsZTsgcGVyaGFwcyBieSBzaW1wbHkgY29weWluZyB0aGUgdGV4dCBvZiB5b3VyIHJl cGx5IGluIHlvdXIgZG9jdW1lbnQuDQoNCkJpZW4gw6AgdG9pDQoNCi3DqXJpYw0KDQoNCu+7v09u IDA1LzA4LzIwMTksIDEzOjU5LCAiSnVsaXVzeiBDaHJvYm9jemVrIiA8amNoQGlyaWYuZnI+IHdy b3RlOg0KICAgIA0KICAgID4gLS0gU2VjdGlvbnMgMy4yLjMgYW5kIDMuMi40IC0tDQogICAgDQog ICAgPiBEb2VzIGEgZHVhbC1zdGFjayBob3N0IGhhdmUgdG8gc2VuZCAyIGhlbGxvPyBPbmUgb24g ZWFjaCBwcm90b2NvbCBzdGFjayAodjYgb3INCiAgICA+IHY0KSA/IFVuY2xlYXIgZnJvbSB0aGUg ZXhwbGFuYXRpb24uDQogICAgDQogICAgQXMgZmFyIGFzIHRoZSBwcm90b2NvbCBpcyBjb25jZXJu ZWQsIGJvdGggZGVwbG95bWVudCBtb2RlbHMgYXJlIHBvc3NpYmxlOg0KICAgIA0KICAgICAgLSB0 aGUgQkdQLXN0eWxlIGRvdWJsZS1zdGFjayBtb2RlbCwgd2hlcmUgYSBzaW5nbGUgcHJvdG9jb2wg aW5zdGFuY2UNCiAgICAgICAgKHJ1bm5pbmcgb3ZlciBJUHY0IG9yIElQdjYpIGNhcnJpZXMgYm90 aCBJUHY0IGFuZCBJUHY2IHJvdXRlczsNCiAgICAgIC0gdGhlICJzaGlwcyBpbiB0aGUgbmlnaHQi IG1vZGVsLCB3aGVyZSB0d28gcHJvdG9jb2wgaW5zdGFuY2VzIGFyZSBydW4sDQogICAgICAgIG9u ZSBvdmVyIElQdjQsIG9uZSBvdmVyIElQdjYuDQogICAgDQogICAgSW4gdGhlIGRvdWJsZS1zdGFj ayBtb2RlbCAod2hpY2ggaXMgd2hhdCBhbGwgY3VycmVudCBpbXBsZW1lbnRhdGlvbnMNCiAgICBp bXBsZW1lbnQpLCBhIHNpbmdsZSBJUHY2IGhlbGxvIGlzIHNlbnQuICBJJ20gbm90IHN1cmUgaWYg dGhpcyBzaG91bGQgYmUNCiAgICBzcGVsbGVkIG91dCBleHBsaWNpdGx5IC0tIEZXSVcsIG5vbmUg b2YgdGhlIEJhYmVsIGltcGxlbWVudGVycyBoYWQgYW55DQogICAgdHJvdWJsZSB3aXRoIHRoYXQu DQogICAgDQogICAgKEluIHByaW5jaXBsZSwgdGhlIHByb3RvY29sIGNvdWxkIGJlIHJ1biBkaXJl Y3RseSBvdmVyIHRoZSBsaW5rIGxheWVyLA0KICAgIElTLUlTIHN0eWxlLCB3aGljaCBjb3VsZCBw ZXJoYXBzIGJlIHVzZWZ1bCBpbiBzb21lIElvVC1zdHlsZSBzY2VuYXJpb3MuDQogICAgSXQgY291 bGQgZXZlbiB1c2UgZGlmZmVyZW50IGVuY2Fwc3VsYXRpb25zIG9uIGRpZmZlcmVudCBpbnRlcmZh Y2VzLCBmb3INCiAgICBleGFtcGxlIFVEUC9JUHY2IG92ZXIgYSB0dW5uZWwgYnV0IHJhdyBFdGhl cm5ldCBvdmVyIGEgcGh5c2ljYWwgaW50ZXJmYWNlLg0KICAgIEhvd2V2ZXIsIHNpbmNlIHRoaXMg aGFzIG5ldmVyIGJlZW4gaW1wbGVtZW50ZWQsIHRoaXMgZHJhZnQgZG9lc24ndCBhbGxvdw0KICAg IHRoYXQga2luZCBvZiBvcGVyYXRpb24uKQ0KICAgIA0KDQo= From nobody Mon Aug 5 06:07:14 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 5AC16120072; Mon, 5 Aug 2019 06:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=k+a2FtrA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Sb0hCCQV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhyQulTKN7xG; Mon, 5 Aug 2019 06:07:10 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14FF51201CA; Mon, 5 Aug 2019 06:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5782; q=dns/txt; s=iport; t=1565010430; x=1566220030; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gdWY5Rk1atCfzUVJtZU7ZczfPipDO6NiHCfRrcjnLzI=; b=k+a2FtrAsluYNMqavxhE+yiEPTCGk3X6weK53Ij1A+92xTTwxsE5v4hF 8a4aR+KZYYoucPHQb8soB9f+ZfFr4HEbL0WWEUbgkTiQ9vL6IA+tN4C5v Zu+9N3RNXU12YTnEF1yfQTLENOlNT8gQda1aCpeQq4oqK+rkwJZ1xp+YL Q=; IronPort-PHdr: =?us-ascii?q?9a23=3A0hrzahPDHIZJk+hq+s8l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj2Mu/sZC83NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiAAALKUhd/5BdJa1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBVQUBAQsBgURQA4FCIAQLKoQeg0cDiy2CW5dZgS4UgRADVAkBAQEMAQE?= =?us-ascii?q?tAgEBhD8CF4JYIzYHDgEDAQEEAQECAQZthR4MhUsBAQECARIREQwBASoNAQ8?= =?us-ascii?q?CAQgODAImAgICMBUFCwIEDgUigwCBawMODwECoFICgTiIYHGBMoJ6AQEFhQQ?= =?us-ascii?q?YghMJgQwoAYtiF4FAP4ERJx+CTD6EDE+CdDKCJo5YMY15jTUGZwkCghuLUYh?= =?us-ascii?q?NFAeCL4csjk6DKqINAgQCBAUCDgEBBYFXCCmBWHAVGiEqAYJBgkI3gzqKU3K?= =?us-ascii?q?BKY0TAQE?= X-IronPort-AV: E=Sophos;i="5.64,350,1559520000"; d="scan'208";a="391549240" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Aug 2019 13:07:08 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x75D788m026675 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Aug 2019 13:07:08 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 08:07:07 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 08:07:02 -0500 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 5 Aug 2019 08:07:02 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CEdgYR7Tazr/g1R+oNQT3OSuMaEJ6F0t1VHI8CGLB13ojprYBK1VhJanqZ28vpE1K9lxo4jtjTPaRyH2TjxiR9/WdYStzahTXfYCcC+bnzhzybppo7hjxdDgytstRPejs5pV7WwqdUczZ0ZQ5BeC8Dh4wvlr1Hj8lq+GbS6KCZkDXlw/vdct6PZSfKAdX7BJf2yWmKjG9sg+jNCP5i0+eI5PTMH4aobYCiXO2MRCEG57FYJXKu48HOQB33SRZAQn0FYFH1KNTi6wmGx9j9WeC06CMJBsxWQksH6UeZjDGIiIyZbhYYOrOJXq0px3A2r0JN/0vdBxBjZ1O37X++uU3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gdWY5Rk1atCfzUVJtZU7ZczfPipDO6NiHCfRrcjnLzI=; b=dchwtljV88jeBoPX+b6GZwjl8HoBG1xLPbEnrBex+iRke7B+u845+OPJxwZwO1O1gFVCkUtsBCEgJ7nGKyUnxx784ApPlb6JKTMENBSmvV5hSaEfnFlXkRWy2dbuNBjtEsezlhU+5m/XR2ODGsjiVLXdVi6ck5aD9W7veUUOr04sWzdBBTPpZ1gS2kh16DjJ4toUT8VB+87GOlmG67VfXeRKsKFeXtsqj3wKYfVzvj9JflrzboRMvZrYSyjffUTAl8wlIn2vegUU+MwSBLqTiqXLsf7nTyfXJeVdsTBHqea9wIqLuDWq+8bg3tZbzlNn+VmNWFJ7uKtE8aRNuiVH+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gdWY5Rk1atCfzUVJtZU7ZczfPipDO6NiHCfRrcjnLzI=; b=Sb0hCCQV8uUnE54BKxi7s23CGn+7mF+4nElV/m7qJZjFidIIRg8X5l3jSyPo0WtTZd80xZrV39YTCUtI+ZAxvAA8EmNOEgHrYz6j3egicG2Rz5LiyNEJR6GlBmYOYPO3Iw5Q4uj4FPys7FcFEGSdE8Ph6T8BnnwlUTb+uZV4/nY= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB4237.namprd11.prod.outlook.com (10.255.90.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.16; Mon, 5 Aug 2019 13:07:01 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::cc02:dc35:1f73:653c]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::cc02:dc35:1f73:653c%7]) with mapi id 15.20.2136.018; Mon, 5 Aug 2019 13:07:01 +0000 From: "Eric Vyncke (evyncke)" To: Juliusz Chroboczek CC: The IESG , "draft-ietf-babel-applicability@ietf.org" , Donald Eastlake , "babel-chairs@ietf.org" , "babel@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWJhYmVsLWFw?= =?utf-8?Q?plicability-07:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHVS4yC9IRr9kOJFkyEIZoqBpjKFKbsp7uA Date: Mon, 5 Aug 2019 13:07:01 +0000 Message-ID: References: <156500498261.24571.204581663078651704.idtracker@ietfa.amsl.com> <87tvavlqrt.wl-jch@irif.fr> In-Reply-To: <87tvavlqrt.wl-jch@irif.fr> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1b.0.190715 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:94cc:3600:4eda:dc83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9b60d928-ca97-47ea-e7ab-08d719a5ce13 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4237; x-ms-traffictypediagnostic: MN2PR11MB4237: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01208B1E18 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(346002)(376002)(396003)(366004)(39860400002)(136003)(189003)(199004)(86362001)(46003)(14454004)(33656002)(66574012)(6116002)(6916009)(36756003)(5660300002)(6246003)(7736002)(305945005)(58126008)(316002)(53936002)(68736007)(478600001)(6486002)(6506007)(76176011)(54906003)(224303003)(102836004)(99286004)(8936002)(186003)(229853002)(4326008)(6512007)(91956017)(2906002)(76116006)(81166006)(81156014)(6436002)(25786009)(14444005)(256004)(71190400001)(71200400001)(66946007)(476003)(64756008)(11346002)(446003)(66476007)(66556008)(486006)(2616005)(66446008)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4237; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: b6PejG/PkRaAXgFPJ0vgauQ151OJhVx7XfldK1qiIIIqxAn0ZYZNdIhIyj/01DPz6ABvMYICCQzpbUwpUxDGO6iQS8MvpWkl99L1mLB9t55FVf9bWcU4QQ/6PvspLEVryLucP1CWoCOlGgWPrA0FlQ8r5OGBmUcwsZKLVsfUYbON8faFsWoyy4iYnfRxrewLJfJ5yfJerv/tEJ9foPEZ+bt8q9wzGgUwAIDiy7dfECU2u3LTiorEuQBNll7OoF3VAIDT+W9rMRafhTcWlMASSlosED2jVQypLj+u3dX9/hZ6WOv4Z5JivRj138f7enQQmNr6vjdmYRGOhKRlBWKHB1mP3bXLbPGGZBzoLF0Fwqg639dBzJjyXsgs1o5CBbIkuFEB/a+/qgtpE0kXf79R/nd2zJ9prbcAP+8muiJqvhM= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9b60d928-ca97-47ea-e7ab-08d719a5ce13 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2019 13:07:01.1794 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: evyncke@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4237 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [babel] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-bab?= =?utf-8?q?el-applicability-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Mon, 05 Aug 2019 13:07:13 -0000 QWJvdXQgbXkgRElTQ1VTUywgdGhlIGV4cGxhbmF0b3J5IHRleHQgaXMgZ29vZCBidXQgaXQgaXMg J2p1c3QgYW4gZXhwbGFuYXRpb24nIGFuZCBub3QgYSBwcm92ZW4gcHJvcGVydHkgb2YgQmFiZWwu IElmIHlvdSByZW1vdmUgdGhlICdyb2J1c3Qgd3J0IGJ1Z3MnIGZyb20gdGhlIGxpc3QgYmVsb3cg dGhlIGFzc2VydGF0aW9uIG9mIHByb3RvY29sIHJvYnVzdG5lc3MgdGhlbiBJIHdpbGwgYmUgc2F0 aXNmaWVkIGFuZCB3aWxsIHJlbW92ZSB0aGUgRElTQ1VTUy4gU2ltcGx5IGFkZCB0aGUgdGV4dCBi ZWxvdyB0aGUgZW51bWVyYXRpb24gYnVsbGV0cyBhbmQgc3RhcnRzIHdpdGggIkV4cGVyaWVuY2Ug Z2FpbmVkIGluIGltcGxlbWVudGF0aW9uIGludGVyb3BlcmF0aW9uIHRlc3Rpbmcgc2hvd3MgdGhh dCAuLi4uIi4NCg0KRm9yIHRoZSB0ZXh0IGFib3V0IHNlY3VyaXR5LCB3aGF0IGFib3V0IHNvbWV0 aGluZyBsaWtlOg0KIiAgICAgQmFiZWwtSE1BQyBbSE1BQ10gaXMgYSBzaW1wbGUgYW5kIGVhc3kg dG8gaW1wbGVtZW50IG1lY2hhbmlzbSB0aGF0DQogICAgICAgb25seSBndWFyYW50ZWVzIGF1dGhl bnRpY2l0eSwgaW50ZWdyaXR5LCBhbmQgYW50aS1yZXBsYXkgb2YgdGhlIHJvdXRpbmcgdHJhZmZp YywNCiAgICAgICBhbmQgb25seSBzdXBwb3J0cyBzeW1tZXRyaWMga2V5aW5nIHdpdGggYSBzbWFs bCBudW1iZXIgb2Yga2V5cw0KICAgICAgICh0eXBpY2FsbHkganVzdCBvbmUgb3IgdHdvKS4gIEJh YmVsLURUTFMgW0RUTFNdIGlzIGEgbW9yZSBjb21wbGV4DQogICAgICAgbWVjaGFuaXNtLCB0aGF0 IHJlcXVpcmVzIHNvbWUgbWlub3IgY2hhbmdlcyB0byBiZSBtYWRlIHRvIGEgdHlwaWNhbA0KICAg ICAgIEJhYmVsIGltcGxlbWVudGF0aW9uIGFuZCBkZXBlbmRzIG9uIGEgRFRMUyBzdGFjayBiZWlu ZyBhdmFpbGFibGUsIGJ1dA0KICAgICAgIGluaGVyaXRzIGFsbCBvZiB0aGUgZmVhdHVyZXMgb2Yg RFRMUywgbm90YWJseSBhdXRoZW50aWNpdHksIGludGVncml0eSwgIGNvbmZpZGVudGlhbGl0eSwg YW5kIHRoZQ0KICAgICAgIGFiaWxpdHkgdG8gdXNlIGFzeW1tZXRyaWMga2V5cy4NCiIgICAodW5z dXJlIGFib3V0IGFudGktcmVwbGF5IG9mIERUTFMgdGhvdWdoKQ0KDQoNCi3DqXJpYw0KDQoNCg0K 77u/T24gMDUvMDgvMjAxOSwgMTQ6NTEsICJKdWxpdXN6IENocm9ib2N6ZWsiIDxqY2hAaXJpZi5m cj4gd3JvdGU6DQoNCiAgICBEZWFyIEVyaWMsDQogICAgDQogICAgVGhhbmtzIGZvciB5b3VyIHJl dmlldy4NCiAgICANCiAgICA+ID09IERJU0NVU1MgPT0NCiAgICANCiAgICA+IC0tIFNlY3Rpb24g Mi4yIC0tDQogICAgDQogICAgPiBUaGUgJ2J1ZyByZXNpc3RhbmNlJyBwcm9wZXJ0eSBvZiBCYWJl bCB3YXMgcGVyaGFwcyBsZWFybmVkIGR1cmluZyB0aGUNCiAgICA+IGltcGxlbWVudGF0aW9uLCBi dXQsIEkgd29uZGVyIHdoZXRoZXIgdGhlIGRvY3VtZW50IG1heSBzaW1wbHkgc3RhdGUgJ3JvYnVz dA0KICAgID4gd2l0aCByZXNwZWN0IHRvIGJ1Z3MnLCB0aGlzIGlzIHF1aXRlIGEgc3Ryb25nIHN0 YXRlbWVudCB0aGF0IG5lZWRzIHRvIGJlIGJhY2tlZA0KICAgID4gYnkgZmFjdHMgb3IgcHJvb2Yu DQogICAgDQogICAgV291bGQgeW91IGJlIHNhdGlzZmllZCBpZiBJIGFkZGVkIHRoZSBmb2xsb3dp bmcgcGFyYWdyYXBoPyAgT3Igd291bGQgeW91DQogICAgcHJlZmVyIHNvbWUgb3RoZXIgcmVzb2x1 dGlvbj8NCiAgICANCiAgICAgIEZvciBleGFtcGxlLCBhbiBlYXJseSB2ZXJzaW9uIG9mIHRoZSBy ZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gd291bGQgdmVyeQ0KICAgICAgb2NjYXNpb25hbGx5IGNv cnJ1cHQgdGhlIGNvbnRlbnRzIG9mIGl0cyByZWNlaXZlIGJ1ZmZlci4gIFdpdGggaGlnaA0KICAg ICAgcHJvYmFiaWxpdHksIHRoZSBidWcgd291bGQgY29ycnVwdCB0aGUgZGVzdGluYXRpb24gYWRk cmVzcyBvZiBhbiBJUHY2DQogICAgICBob3N0IHJvdXRlLCB3aGljaCB3b3VsZCBjYXVzZSBhIHNw dXJpb3VzICJtYXJ0aWFuIiByb3V0ZSB0byBiZSBhbm5vdW5jZWQNCiAgICAgIHRvIHRoZSBuZXR3 b3JrIGFuZCB0aGVuIHNpbGVudGx5IHRpbWUgb3V0LCB3aXRoIG5vIGlsbCBlZmZlY3RzLg0KICAg IA0KICAgIChGb3IgdGhlIHNha2Ugb2Ygb2xkIHRpbWVzLCBJJ2xsIHJlY2FsbCB0aGF0IEkgd2Fz IHRoZSBndWlsdHkgcGFydHksIGFuZA0KICAgIHRoYXQgdGhlIGJ1ZyB3YXMgZml4ZWQgYnkgR3LD qWdvaXJlIEhlbnJ5IGFuZCBKdWxpZW4gQ3Jpc3RhdSB3aG8gc3BlbnQNCiAgICBhbG1vc3QgYSB3 aG9sZSBuaWdodCBvYnNlcnZpbmcgYSBCYWJlbCBub2RlLiAgVGhleSB3ZXJlbid0IHBsZWFzZWQu KQ0KICAgIA0KICAgID4gVGhlIHRpdGxlIG9mIHRoZSBkb2N1bWVudCBpcyBhYm91dCAnYXBwbGlj YWJpbGl0eSc7IGJ1dCwgc2hvdWxkIGl0IGFsc28NCiAgICA+IGluY2x1ZGUgJ3VzZSBjYXNlcycg aW4gdGhlIHRpdGxlID8NCiAgICANCiAgICBJIHByZWZlciBzaG9ydGVyIHRpdGxlcywgYnV0IEkg ZG9uJ3QgZmVlbCBzdHJvbmdseSBlaXRoZXIgd2F5LiAgUGVyaGFwcw0KICAgIHRoZSBsaXN0IGNh biBjaGltZSBpbj8NCiAgICANCiAgICA+IFNlY3Rpb24gMy4xDQogICAgDQogICAgPiBUaGUgMm5k IHBhcmFncmFwaCBpcyB0b28gZGVuc2U6IHNob3VsZCBleHBsYWluIHdoeSBCYWJlbCBpcyBhIGdv b2QgZml0Lg0KICAgIA0KICAgIEFncmVlZCwgSSdsbCByZXdvcmQuDQogICAgDQogICAgPiAtLSBT ZWN0aW9uIDUgLS0NCiAgICANCiAgICA+IENvbXBhcmlzb24gYmV0d2VlbiBITUFDICYgRFRMUyB2 YXJpYW50cyBpcyBwcm9iYWJseSBpcnJlbGV2YW50IGluIHRoaXMNCiAgICA+IGRvY3VtZW50LiBU aG91Z2gsIGEgdXNlIGNhc2Ugd2l0aCBzZWN1cml0eSBpbiBtaW5kIHdvdWxkIGJlIGJlbmVmaXRp YWwuDQogICAgDQogICAgVGhlcmUgYXJlIG5vIGtub3duIHVzZSBjYXNlcy4gIE91ciB1c2VycyBy dW4gQmFiZWwgb3ZlciBzZWN1cmUgbGluaw0KICAgIGxheWVycywgYW5kIG5vYm9keSBoYXMgcmVx dWVzdGVkIHNlY3VyaXR5IG1lY2hhbmlzbXMgZW1iZWRkZWQgd2l0aGluIHRoZQ0KICAgIHByb3Rv Y29sLiAgVGhlIHNlY3VyaXR5IG1lY2hhbmlzbXMgd2VyZSBkZXNpZ25lZCBzb2xlbHkgaW4gb3Jk ZXIgdG8NCiAgICBzYXRpc2Z5IElFVEYgcmVxdWlyZW1lbnRzLiAgKFRvIGJlIGZhaXIsIGl0IHdh cyBhIGxvdCBvZiBmdW4uKQ0KICAgIA0KICAgID4gQWxzbywgdGhlIGNvbXBhcmlzb24gc2hvdWxk IGluY2x1ZGUgYWxsIGFzcGVjdHMgaW5jbHVkaW5nIGNvbmZpZGVudGlhbGl0eSBhbmQNCiAgICA+ IGFudGktcmVwbHkgZm9yIGJvdGggSE1BQyAmIERUTFMuDQogICAgDQogICAgVGhlIGRvY3VtZW50 IGN1cnJlbnRseSBzYXlzOg0KICAgIA0KICAgICAgIEJhYmVsLUhNQUMgW0hNQUNdIGlzIGEgc2lt cGxlIGFuZCBlYXN5IHRvIGltcGxlbWVudCBtZWNoYW5pc20gdGhhdA0KICAgICAgIG9ubHkgZ3Vh cmFudGVlcyBhdXRoZW50aWNpdHkgYW5kIGludGVncml0eSBvZiB0aGUgcm91dGluZyB0cmFmZmlj LA0KICAgICAgIGFuZCBvbmx5IHN1cHBvcnRzIHN5bW1ldHJpYyBrZXlpbmcgd2l0aCBhIHNtYWxs IG51bWJlciBvZiBrZXlzDQogICAgICAgKHR5cGljYWxseSBqdXN0IG9uZSBvciB0d28pLCBidXQg aXMgaW52dWxuZXJhYmxlIHRvIHJlcGxheSBldmVuIGluDQogICAgICAgdGhlIGFic2VuY2Ugb2Yg cGVyc2lzdGVudCBzdGF0ZS4gIEJhYmVsLURUTFMgW0RUTFNdIGlzIGEgbW9yZSBjb21wbGV4DQog ICAgICAgbWVjaGFuaXNtLCB0aGF0IHJlcXVpcmVzIHNvbWUgbWlub3IgY2hhbmdlcyB0byBiZSBt YWRlIHRvIGEgdHlwaWNhbA0KICAgICAgIEJhYmVsIGltcGxlbWVudGF0aW9uIGFuZCBkZXBlbmRz IG9uIGEgRFRMUyBzdGFjayBiZWluZyBhdmFpbGFibGUsIGJ1dA0KICAgICAgIGluaGVyaXRzIGFs bCBvZiB0aGUgZmVhdHVyZXMgb2YgRFRMUywgbm90YWJseSBjb25maWRlbnRpYWxpdHkgYW5kIHRo ZQ0KICAgICAgIGFiaWxpdHkgdG8gdXNlIGFzeW1tZXRyaWMga2V5cy4NCiAgICANCiAgICBQbGVh c2UgbGV0IG1lIGtub3cgaWYgeW91IGZlZWwgdGhhdCB0aGlzIHBhcmFncmFwaCBuZWVkcyB0byBi ZSBleHBhbmRlZCBvcg0KICAgIG90aGVyd2lzZSByZXdvcmRlZCwgYW5kLCBpZiBzbywgaW4gd2hh dCB3YXkuDQogICAgDQogICAgVGhhbmtzIGFnYWluLA0KICAgIA0KICAgIC0tIEp1bGl1c3oNCiAg ICANCg0K From nobody Mon Aug 5 07:34:44 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 05778120236; Mon, 5 Aug 2019 07:34: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 oBCj0F3_YiSu; Mon, 5 Aug 2019 07:34:41 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD87120234; Mon, 5 Aug 2019 07:34:40 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x75EYWPa002917; Mon, 5 Aug 2019 16:34: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 F33104EB6F; Mon, 5 Aug 2019 16:34: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 zrX_8Wcs2XMR; Mon, 5 Aug 2019 16:34:35 +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 10BCC4EB6D; Mon, 5 Aug 2019 16:34:34 +0200 (CEST) Date: Mon, 05 Aug 2019 16:34:34 +0200 Message-ID: <87mugnllz9.wl-jch@irif.fr> From: Juliusz Chroboczek To: "Eric Vyncke (evyncke)" Cc: The IESG , "draft-ietf-babel-rfc6126bis@ietf.org" , Donald Eastlake , "babel-chairs@ietf.org" , "babel@ietf.org" In-Reply-To: <518548BD-80F5-4F02-9362-EC61D0D5CA7B@cisco.com> References: <156498851376.24465.4531172446015994141.idtracker@ietfa.amsl.com> <87v9vblt6j.wl-jch@irif.fr> <518548BD-80F5-4F02-9362-EC61D0D5CA7B@cisco.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]); Mon, 05 Aug 2019 16:34:32 +0200 (CEST) X-Miltered: at korolev with ID 5D483E78.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D483E78.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 : 5D483E78.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] =?iso-8859-1?q?=C9ric_Vyncke=27s_No_Objection_on_draft-i?= =?iso-8859-1?q?etf-babel-rfc6126bis-11=3A_=28with_COMMENT=29?= 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: Mon, 05 Aug 2019 14:34:42 -0000 > Please state somewhere that the two options are available; perhaps by > simply copying the text of your reply in your document. I've added the following paragraph to Section 3.1: The protocol's control traffic can be carried indifferently over IPv6 or over IPv4, and prefixes of either address family can be announced over either protocol. Thus, there are at least two natural deployment models: using IPv6 exclusively for all control traffic, or running two distinct protocol instances, one for each address family. The exclusive use of IPv6 for all control traffic is RECOMMENDED, since using both protocols at the same time doubles the amount of traffic devoted to neighbour discovery and link quality estimation. List: this adds a SHOULD to the draft. Since this reflects implementation practice, I am fairly confident that it also reflects our consensus, please yell if I'm wrong. -- Juliusz From nobody Mon Aug 5 07:42:32 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 A1FF8120234; Mon, 5 Aug 2019 07:42:30 -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-hmac.all@ietf.org, ietf@ietf.org, babel@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Dan Romascanu Message-ID: <156501615060.24541.14266875792954906382@ietfa.amsl.com> Date: Mon, 05 Aug 2019 07:42:30 -0700 Archived-At: Subject: [babel] Opsdir last call review of draft-ietf-babel-hmac-08 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: Mon, 05 Aug 2019 14:42:31 -0000 Reviewer: Dan Romascanu Review result: Ready This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance. As this is not a new protocol but rather an extension of the existing Babel routing protocol allowing for both unicast and multicast datagrams to be used, a full RFC 5706 review does not apply. The document is Ready from and operational and manageability point of view. It is clearly written and provides all needed information to operators. It states that the deployment can be made incrementally in existing networks where current implementations of Babel are already present. It is important for operators to pay attention at the restrictions of applicability defined in section 1.1. There are also a number of recommendations in the text related to configuration parameters that are of interests not only for implementers but also for operators deploying these extensions - for example in sections 4.3.1.1, and 4.4. I would have preferred these to be included in a separate 'Operational Considerations' section. From nobody Mon Aug 5 08:06:26 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 352F512016B; Mon, 5 Aug 2019 08:06:24 -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 DBIXYCJICy_n; Mon, 5 Aug 2019 08:06:22 -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 C331F12004A; Mon, 5 Aug 2019 08:06:21 -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 x75F6EUZ013651; Mon, 5 Aug 2019 17:06:14 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 7D0984ECFE; Mon, 5 Aug 2019 17:06:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id O0EaHIcXe2wR; Mon, 5 Aug 2019 17:06:16 +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 9628F4ECFC; Mon, 5 Aug 2019 17:06:16 +0200 (CEST) Date: Mon, 05 Aug 2019 17:06:16 +0200 Message-ID: <87k1brlkif.wl-jch@irif.fr> From: Juliusz Chroboczek To: "Eric Vyncke (evyncke)" Cc: The IESG , "draft-ietf-babel-applicability@ietf.org" , Donald Eastlake , "babel-chairs@ietf.org" , "babel@ietf.org" In-Reply-To: References: <156500498261.24571.204581663078651704.idtracker@ietfa.amsl.com> <87tvavlqrt.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 [194.254.61.138]); Mon, 05 Aug 2019 17:06:14 +0200 (CEST) X-Miltered: at korolev with ID 5D4845E6.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4845E6.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 : 5D4845E6.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] =?iso-8859-1?q?=C9ric_Vyncke=27s_Discuss_on_draft-ietf-b?= =?iso-8859-1?q?abel-applicability-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Mon, 05 Aug 2019 15:06:25 -0000 > About my DISCUSS [...] Simply add the text below the enumeration bullets Ah, I see now what you mean. Yes, that makes perfect sense. In addition to the above, our implementation experience indicates that Babel tends to be robust with respect to bugs: more often than not, an implementation bug does not violate the properties on which Babel relies, and therefore slows down convergence or causes sub- optimal routing rather than causing the network to collapse. I'll work through your remaining points and submit a -08. -- Juliusz From nobody Mon Aug 5 08:23:01 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 79D9B12004A; Mon, 5 Aug 2019 08:22:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-babel-applicability@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <156501857349.24525.10768788622753886835.idtracker@ietfa.amsl.com> Date: Mon, 05 Aug 2019 08:22:53 -0700 Archived-At: Subject: [babel] Alissa Cooper's No Objection on draft-ietf-babel-applicability-07: (with COMMENT) 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: Mon, 05 Aug 2019 15:22:54 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-babel-applicability-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-applicability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for writing this. I find the use of "we" and "our" odd for a consensus document. I think the document would be improved if these used the document itself as the subject (e.g., "this document describes" instead of "we describe"). I think the claims made in the bulleted list at the end of Section 2.2 need citations. From nobody Mon Aug 5 08:24: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 4B6EC120162; Mon, 5 Aug 2019 08:23:54 -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 (2048-bit key) header.d=cooperw.in header.b=vjQ3I7jb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ukoTDaR9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBw_oR49FMEQ; Mon, 5 Aug 2019 08:23:52 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0F312004A; Mon, 5 Aug 2019 08:23:52 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id C5259303; Mon, 5 Aug 2019 11:23:50 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 05 Aug 2019 11:23:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=U EV0Z6Sz8OyDUksJ36ZCvfa8/RXbQj1thCgeAM6yhPA=; b=vjQ3I7jbulGcBJsKT A37+OjijOJaFlWlXZfYSQM62ldvDIf5R1tr5gxlWfkEhyVY2kndLsYwA3e+ysWbd 92U3Jr/guFz0UglBwpeznYooKt15VohrCujNi6lNUPq0tvTY3x2LJB6AJegHetNF wjq5GWeoLhyiXaEnSy3RFCmrfkPei9gs1C1V69wOSWfMGjalVXJl4tyKYXAblAlS +uT6S8VwMR18/An76GmVPQ2ddyNXLws/Px5SkOeW/qZzv+AHlK21JkyA4IYkoMVX gN9PkDEq0cH4e7o2KidjJ9ffC0Q9Z8Jywd0H/2s25crAnUcpgKa9KDzbzwPEX9kW QVbag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=UEV0Z6Sz8OyDUksJ36ZCvfa8/RXbQj1thCgeAM6yh PA=; b=ukoTDaR9PzEkExLE/wiYgvIrSULHkj8jyoaq9VwEyOuxNR+Sl1AyJvMdt 1eq/MpYIjMZkgLySzuwH39rPHg1/h+f5c3U8ktvQ1IxI5liq0O3jE43epwtwStRz YdlrVhapLIJY0ffl8L6piuitOakOKRMON34SuYRFg03KoN2zNO09xtAIDZOHJn69 xhUe+96f9km9hZ5MJUVRkkPPt+p8sK/a+rINhvXOQiMQJBFbLzgsE8NT8x1oEvSc LJEslWoSOUylKg6qShCLrHS4ls7wRZBbQUB5RyWa9/ayDizxkP2xZ067evaKz+i9 m5T60rhdO/DA2eMuPNdOvjP6ZN8RA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddtjedgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrkedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.80]) by mail.messagingengine.com (Postfix) with ESMTPA id DFB2A380089; Mon, 5 Aug 2019 11:23:48 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <444a37f8-52a0-eb7f-18d3-b8edb2eaabfd@joelhalpern.com> Date: Mon, 5 Aug 2019 11:23:47 -0400 Cc: Juliusz Chroboczek , gen-art@ietf.org, ietf@ietf.org, babel@ietf.org, draft-ietf-babel-applicability.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <86A0400C-CF6C-497A-8439-0EC8629373BB@cooperw.in> References: <156142508331.17776.2290417666551756858@ietfa.amsl.com> <878st9x6nu.wl-jch@irif.fr> <444a37f8-52a0-eb7f-18d3-b8edb2eaabfd@joelhalpern.com> To: Joel Halpern Direct X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] [Gen-art] 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: Mon, 05 Aug 2019 15:23:55 -0000 Joel, thanks for your review. Juliusz, thanks for your responses. I = think the phrasing in 2.2 is clear enough as-is. I entered a No = Objection ballot. Alissa > On Jul 7, 2019, at 11:06 AM, Joel Halpern Direct = wrote: >=20 > I do not consider this a show-stopper (I listed it as a nit / = editorial), but at least the -07 text does not look better in this = regard. >=20 > In my experience, if this were indeed mathematics, one would talk = about a metric (how one measures) and a distance (the result of applying = the measure. E.g. Given two points in a metric space, with a distance = between them of d, ... Or more verbosely, given a space with a metric = M, the distance between two points a and b is M(A, b). >=20 > Yours, > Joel >=20 > On 7/7/19 10:26 AM, Juliusz Chroboczek wrote: >> Dear Joel, >> Thank you very much for your kind 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". >> This section has been expanded with human-readable text and a = reference to >> a research paper, and should therefore now be easier to understand. >> I have, however, decided to follow the usual style of mathematical >> writing, and have therefore chosen not to follow your advice. I hope = that >> is okay. >> Thanks again, >> -- Juliusz >> _______________________________________________ >> babel mailing list >> babel@ietf.org >> https://www.ietf.org/mailman/listinfo/babel >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Mon Aug 5 08:46: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 EA59512004E; Mon, 5 Aug 2019 08:46:25 -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.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156501998587.24445.11063165279798547541@ietfa.amsl.com> Date: Mon, 05 Aug 2019 08:46:25 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-applicability-08.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: Mon, 05 Aug 2019 15:46:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : Applicability of the Babel routing protocol Author : Juliusz Chroboczek Filename : draft-ietf-babel-applicability-08.txt Pages : 11 Date : 2019-08-05 Abstract: Babel is a routing protocol based on the distance-vector algorithm augmented with mechanisms for loop avoidance and starvation avoidance. This document describes a number of niches where Babel has been found to be useful and that are arguably not adequately served by more mature protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-applicability/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-applicability-08 https://datatracker.ietf.org/doc/html/draft-ietf-babel-applicability-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-applicability-08 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 Mon Aug 5 08:46:56 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 0FB24120295 for ; Mon, 5 Aug 2019 08:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHDcbCHJJTp0 for ; Mon, 5 Aug 2019 08:46:40 -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 2FE8E120232 for ; Mon, 5 Aug 2019 08:46:40 -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 x75FkXHO030676 for ; Mon, 5 Aug 2019 11:46:38 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2u6q4yghf8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 05 Aug 2019 11:46:37 -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 x75FkQbV021143 for ; Mon, 5 Aug 2019 11:46:26 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x75FkKo1020921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 5 Aug 2019 11:46:22 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 05D6E4014661 for ; Mon, 5 Aug 2019 15:46:20 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30483.vci.att.com (Service) with ESMTPS id E36C04000687 for ; Mon, 5 Aug 2019 15:46:19 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0439.000; Mon, 5 Aug 2019 11:46:19 -0400 From: "STARK, BARBARA H" To: "'babel@ietf.org'" Thread-Topic: [babel] I-D Action: draft-ietf-babel-information-model-08.txt Thread-Index: AQHVSy+136XJ0cDtj0yz+6M8HuFcTqbsr76w Date: Mon, 5 Aug 2019 15:46:18 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E254159@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <156496962402.26572.16204290795859744323@ietfa.amsl.com> In-Reply-To: <156496962402.26572.16204290795859744323@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.218.236] 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-08-05_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=998 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908050174 Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-08.txt 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: Mon, 05 Aug 2019 15:46:54 -0000 Hi babel WG and chairs, I've posted a -08 (without consulting Mahesh, but it just has the items agr= eed on in Montreal). I'd like to start another WGLC now, please? One thing I still want to get better is the language in babel-route-receive= d-metric and babel-route-calculated-metric around using something other tha= n an unsigned int in case something has to be done to represent NULL (vs. z= ero). The proposed (in Montreal) language is in babel-route-calculated-metr= ic and a slightly different way of wording it is in babel-route-received-me= tric. If you like one better than the other let me know (I'm leaning toward= s my different wording). I'm also going to ask my BBF friends if they have = a suggestion for clearly wording this (since that's where the problem is co= ming from). I also noticed after posting that I failed to update the list of configurab= le parameters in the Overview (Section 2). I'll fix that after WGLC, if tha= t's ok. Specifically, "create/delete babel-hmac objects" and "create/delete= babel-dtls objects" should be "create/delete HMAC key sets" and "create/de= lete DTLS certificate sets", and "Interface: Link type" gets replaced with = "interface: Metric algorithm" and "interface: Split horizon". Barbara > -----Original Message----- > From: babel On Behalf Of internet- > drafts@ietf.org > Sent: Sunday, August 04, 2019 9:47 PM > To: i-d-announce@ietf.org > Cc: babel@ietf.org > Subject: [babel] I-D Action: draft-ietf-babel-information-model-08.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Babel routing protocol WG of the IETF. >=20 > Title : Babel Information Model > Authors : Barbara Stark > Mahesh Jethanandani > Filename : draft-ietf-babel-information-model-08.txt > Pages : 28 > Date : 2019-08-04 >=20 > Abstract: > This Babel Information Model can be used to create data models under > various data modeling regimes. It allows a Babel implementation (via > a management protocol or interface) to report on its current state > and may allow some limited configuration of protocol constants. From nobody Mon Aug 5 08:54:30 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 954D1120192; Mon, 5 Aug 2019 08:54:21 -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 WagL7LjqQ6tU; Mon, 5 Aug 2019 08:54:20 -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 C50AD120162; Mon, 5 Aug 2019 08:54:19 -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 x75FsBIf029356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 Aug 2019 17:54:11 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x75FsBXI026845; Mon, 5 Aug 2019 17:54:11 +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 5FF734EF2A; Mon, 5 Aug 2019 17:54:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id ur4MmFN9m-Cm; Mon, 5 Aug 2019 17:54:13 +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 69F314EF28; Mon, 5 Aug 2019 17:54:13 +0200 (CEST) Date: Mon, 05 Aug 2019 17:54:13 +0200 Message-ID: <87ftmfliai.wl-jch@irif.fr> From: Juliusz Chroboczek To: Alissa Cooper Cc: "The IESG" , draft-ietf-babel-applicability@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156501857349.24525.10768788622753886835.idtracker@ietfa.amsl.com> References: <156501857349.24525.10768788622753886835.idtracker@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]); Mon, 05 Aug 2019 17:54:11 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 05 Aug 2019 17:54:11 +0200 (CEST) X-Miltered: at korolev with ID 5D485123.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D485123.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D485123.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D485123.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 : 5D485123.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D485123.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] Alissa Cooper's No Objection on draft-ietf-babel-applicability-07: (with COMMENT) 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: Mon, 05 Aug 2019 15:54:22 -0000 Dear Alissa, Thanks for your review. > I find the use of "we" and "our" odd for a consensus document. I think the > document would be improved if these used the document itself as the subject > (e.g., "this document describes" instead of "we describe"). Agreed. Fixed in -08. > I think the claims made in the bulleted list at the end of Section 2.2 need > citations. I agree, but I won't do it. Please let me explain. The fact that Babel has the claimed properties has been proved, but I haven't published the proof yet. (The proof has been reviewed by a competent specialist of the area, who concluded "that looks like a proof to me". Which, knowing the individual, I consider as high praise indeed.) As for the fact that realistic networks have the required properties -- that's something that, to the best of my knowledge, hasn't been studied much. The best source IMHO is Griffin and Sobrinho (already cited as [METAROUTING] in this draft), but it's mostly about properties of BGP networks, and therefore doesn't directly apply to the kind of networks considered in this document. So there's not much I can do at this time. If you know otherwise, please let me know. -- Juliusz From nobody Mon Aug 5 09:02:42 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 BA21C120162; Mon, 5 Aug 2019 09:02:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-babel-applicability@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <156502095275.24400.10195847773477673173.idtracker@ietfa.amsl.com> Date: Mon, 05 Aug 2019 09:02:32 -0700 Archived-At: Subject: [babel] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-babel-applicability-08=3A_=28with_COMMENT=29?= 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: Mon, 05 Aug 2019 16:02:33 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-babel-applicability-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-applicability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Juliusz, Thank you for addressing my previous DISCUSS. I have edited my position to "no objection". -éric == (previous) DISCUSS == -- Section 2.2 -- The 'bug resistance' property of Babel was perhaps learned during the implementation, but, I wonder whether the document may simply state 'robust with respect to bugs', this is quite a strong statement that needs to be backed by facts or proof. == COMMENTS == The title of the document is about 'applicability'; but, should it also include 'use cases' in the title ? -- Section 3.1 -- The 2nd paragraph is too dense: should explain why Babel is a good fit. -- Section 5 -- Comparison between HMAC & DTLS variants is probably irrelevant in this document. Though, a use case with security in mind would be benefitial. Also, the comparison should include all aspects including confidentiality and anti-reply for both HMAC & DTLS. == NITS == -- Section 2.2 -- As I am not a native English speaker, I wonder whether 'light' should not be preferred to 'weak' in "These weak requirements make Babel a robust protocol" -- Section 3.1 -- Suggest to change the section name into "Diverse networks" or "heterogenous networks". From nobody Mon Aug 5 09:20:06 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 E4C7F1202C1; Mon, 5 Aug 2019 09:19:51 -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 jkE7ZDFcxZYY; Mon, 5 Aug 2019 09:19:50 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93A51202CD; Mon, 5 Aug 2019 09:19:49 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x75GJg1Q007665; Mon, 5 Aug 2019 18:19:42 +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 9CFD94F03A; Mon, 5 Aug 2019 18:19:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id dDP6ZlFezjyc; Mon, 5 Aug 2019 18:19:44 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id ECCDF4F036; Mon, 5 Aug 2019 18:19:41 +0200 (CEST) Date: Mon, 05 Aug 2019 18:19:41 +0200 Message-ID: <87ef1zlh42.wl-jch@irif.fr> From: Juliusz Chroboczek To: =?ISO-8859-1?Q?=C9ric?= Vyncke Cc: "The IESG" , draft-ietf-babel-hmac@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156499182480.24510.10221692265742263303.idtracker@ietfa.amsl.com> References: <156499182480.24510.10221692265742263303.idtracker@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]); Mon, 05 Aug 2019 18:19:42 +0200 (CEST) X-Miltered: at korolev with ID 5D48571E.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D48571E.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 : 5D48571E.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] =?iso-8859-1?q?=C9ric_Vyncke=27s_No_Objection_on_draft-i?= =?iso-8859-1?q?etf-babel-hmac-08=3A_=28with_COMMENT=29?= 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: Mon, 05 Aug 2019 16:20:04 -0000 > I am a little puzzled by why HMAC keys/mechanisms are not identified to > facilitate the key rollover. The used mechanism appears a little heavy on the > required computing effort to compute several HMAC. This is a difficult tradeoff, and one that was extensively discussed on the mailing list. For any onlookers, the issue that Eric is referring to is that the HMAC TLV only carries the HMAC: there is no key identifier, and there is no indication of the HMAC algorithm used. The receiving peer simply computes its own HMAC of the packet with its configured (algo, key) pair(s), and performs a bitwise comparison with the value(s) included by the sender. This choice has a number of positive consequences: - the user interface is simplified (there's no key identifier) and hence the opportunity for human error is reduced (there's no opportunity for key identifier mismatches between routers); - the packet format is dramatically simplified, which is important for a security mechanism; - there is no need for yet another IANA registry for HMAC algorithms -- a new algorithm can be deployed privately without involving a third party. It also has one negative consequence: - during key rotation, HMAC must be computed twice, once for each configured key. Since this protocol is not designed for carrying large numbers of keys, and since HMAC computation is a reasonably cheap operation (and one that is likely to be hardware-accelerated in production routers), it was felt that the benefits of simplicity and protocol agility override the minor computational cost. For me, the overriding consideration is the simplicity of the user interface -- a security mechanism will not get deployed unless network administrators feel comfortable with it. > The text about attacks on the Babel routing protocol should be better placed in > the security considerations of RFC7216bis. I'll think it over. > The DTLS document use the writing <"babel" port> while here it is . Right. I'll fix that. -- Juliusz From nobody Mon Aug 5 09:44: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 5D06012024E; Mon, 5 Aug 2019 09:44:38 -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 (2048-bit key) header.d=cooperw.in header.b=1t3W+eZP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=r8P8S+5o Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obhodNh7PXEq; Mon, 5 Aug 2019 09:44:36 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDF2812015C; Mon, 5 Aug 2019 09:44:36 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id E82984A0; Mon, 5 Aug 2019 12:44:35 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Mon, 05 Aug 2019 12:44:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=r Irph3fmwRoJdOkFdB2xT2I6g1USUshmN5o8CxasXsQ=; b=1t3W+eZPzP7lCNL4t Boa3kqkMCMBI31h6KeX3GS6o+Qw46zUn2adaJpIa5y5/qQZsW6IyVE6BFQMnDcIE Xv13w+MC83hulb1vf/zJBBTTEkNE6WouEPHur9ttWl/o5N/Ob7z+1G8/G1jCSUkV fF55dZzhzjj0MD6el7nKeK2Zv1gYjyvQXpA5fs7pWueCAx/0gMSOMpJ26hV4CyiW 5fBmVd18opJ7FDpJHKh2gFsm7kFBFMip1BwD7h1oMtfIgohfMhpBGrRakA9j8ZA1 6AoIYGDLRrtsqlR5eJowk7oWWHm0Qj/eaS1nODNuGKEJeRBi8vCl0tWwOUHMbm+Z LKfNw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=rIrph3fmwRoJdOkFdB2xT2I6g1USUshmN5o8CxasX sQ=; b=r8P8S+5o+939NGAEGv9fFNFAncsUR1Hg9p4vLhOIUAerHMzxJ3xz3A5fe WNSSELz4/nsAei+1ZaR4CqpUWXwWVi5iY973JHLourGII/KQGemqtXwnBooI6udV vRzMEYxF2sMgGwI4uTXhAnGvKsm36+FnZau2Jfm4WJyA4zZ0dUv4HBKBTnpTdpB4 4U4LmyELuQu/YI5yMAsZVQLMNc8hnrPTGG6VAHsyHg9C8S7loqPhY8ttM3Czr3Fd iP5KfPQPU9xxu6DsCyOl3FXVSo1HvoNuimjPvMljXM3RfKcMikNITD4AhfURIvsZ lMSYwYEU12fQgSH3yoQRTVo8zPLgw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddtjedguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhi shhsrgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecukfhppe dujeefrdefkedruddujedrkedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhs rgestghoohhpvghrfidrihhnnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.80]) by mail.messagingengine.com (Postfix) with ESMTPA id 8479238008B; Mon, 5 Aug 2019 12:44:34 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <87ftmfliai.wl-jch@irif.fr> Date: Mon, 5 Aug 2019 12:44:33 -0400 Cc: IESG , draft-ietf-babel-applicability@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156501857349.24525.10768788622753886835.idtracker@ietfa.amsl.com> <87ftmfliai.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Alissa Cooper's No Objection on draft-ietf-babel-applicability-07: (with COMMENT) 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: Mon, 05 Aug 2019 16:44:38 -0000 Hi Juliusz, > On Aug 5, 2019, at 11:54 AM, Juliusz Chroboczek wrote: >=20 > Dear Alissa, >=20 > Thanks for your review. >=20 >> I find the use of "we" and "our" odd for a consensus document. I = think the >> document would be improved if these used the document itself as the = subject >> (e.g., "this document describes" instead of "we describe"). >=20 > Agreed. Fixed in -08. >=20 >> I think the claims made in the bulleted list at the end of Section = 2.2 need >> citations. >=20 > I agree, but I won't do it. Please let me explain. >=20 > The fact that Babel has the claimed properties has been proved, but > I haven't published the proof yet. (The proof has been reviewed by > a competent specialist of the area, who concluded "that looks like a = proof > to me". Which, knowing the individual, I consider as high praise = indeed.) >=20 > As for the fact that realistic networks have the required properties = -- > that's something that, to the best of my knowledge, hasn't been = studied > much. The best source IMHO is Griffin and Sobrinho (already cited as > [METAROUTING] in this draft), but it's mostly about properties of BGP > networks, and therefore doesn't directly apply to the kind of networks > considered in this document. >=20 > So there's not much I can do at this time. If you know otherwise, = please > let me know. In that case I think not making the claims is a better option. The one = about bugs seems particularly problematic =E2=80=94 with my = layperson=E2=80=99s understanding of this protocol, it seems as though = if new developers start looking to implement this it would be very hard = to predict how often any particular bug that any implementer might = introduce would interfere with the protocol operation. If there isn=E2=80=99= t some evidence to back this up it seems wiser not to claim it. Thanks, Alissa >=20 > -- Juliusz From nobody Mon Aug 5 10:00:52 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 7EB261202A0; Mon, 5 Aug 2019 10:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7XO9QoGrIFC; Mon, 5 Aug 2019 10:00:49 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A782120297; Mon, 5 Aug 2019 10:00:49 -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 x75H0dHE027309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 Aug 2019 19:00:40 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x75H0eZW010474; Mon, 5 Aug 2019 19:00: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 07B544F1E9; Mon, 5 Aug 2019 19:00: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 GHSC8Li7SFy0; Mon, 5 Aug 2019 19:00:41 +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 B57CD4F1E7; Mon, 5 Aug 2019 19:00:41 +0200 (CEST) Date: Mon, 05 Aug 2019 19:00:41 +0200 Message-ID: <87d0hjlf7q.wl-jch@irif.fr> From: Juliusz Chroboczek To: Alissa Cooper Cc: IESG , draft-ietf-babel-applicability@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: References: <156501857349.24525.10768788622753886835.idtracker@ietfa.amsl.com> <87ftmfliai.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Mon, 05 Aug 2019 19:00:40 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 05 Aug 2019 19:00:40 +0200 (CEST) X-Miltered: at korolev with ID 5D4860B7.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D4860B8.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4860B7.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D4860B8.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 : 5D4860B7.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D4860B8.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] Alissa Cooper's No Objection on draft-ietf-babel-applicability-07: (with COMMENT) 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: Mon, 05 Aug 2019 17:00:52 -0000 >> So there's not much I can do at this time. If you know otherwise, please >> let me know. > In that case I think not making the claims is a better option. The one > about bugs seems particularly problematic As far as bug resistence is concerned -- I agree. This has been weakened in -08 at the prompting of ric Vyncke, please let me know if you with me to weaken it further. As far as the other two properties are concerned (unusual networks and unusual metrics), I must most humbly disagree. There is a fair body of circumstantial evidence that favours these claims, such as the references [DELAY-BASED], [REAL-WORLD] and [BRIDGING-LAYERS] of this document, as well as a number of experiments [1,2] that I don't feel comfortable citing at the current time. [1] http://people.ac.upc.edu/leandro/pubs/eomrpfwcn.pdf [2] https://www.irif.fr/~jch/software/babel/battlemeshv10.html Sorry for that. -- Juliusz From nobody Mon Aug 5 16:44: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 88CB61200CC; Mon, 5 Aug 2019 16:44:46 -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 mPOvb36OcZ5O; Mon, 5 Aug 2019 16:44:45 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 56E1112000E; Mon, 5 Aug 2019 16:44:45 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id r6so88049126oti.3; Mon, 05 Aug 2019 16:44:45 -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=EIITd1TCkMon+7/5K3dci7FVgVnEdUhQ1KoOQ/7zhEE=; b=scWmB6so+dYhiLjbrqTiACNYCj1HXaRN/63RPTxPX5+Lnpw/aDHXbI7CxvcMM4X0YO x8bhhN1YM1FtiPpWr+4zNtY46RM3NhGL5udssSuH4aHgk5S4OSJtsbJogiLxvKwxMdiL n4OV8e+kwVlFyCXOzKcf5Q3mvAGz5Xh3DquDoq3KvPxt2gd/rfc9W/nf6pjB37PeXxMe o9SATTW0YAK53hg/mfy4wo3VRIWrhH3iWbNaNGuMNsrSX2gvQAXjK6cioYQKWH81+3CM tO7w89aKqLLP2O7Tt04hGNNIRO4jWKTt9g3K2D8tPNAUt5X39P1zynoUN3Sz5wT+p74w Q7nQ== 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=EIITd1TCkMon+7/5K3dci7FVgVnEdUhQ1KoOQ/7zhEE=; b=o965m7XQKYNlmkEKzRoctlcmydt7jkKXw82HZaOAsGq4hwkax+JEVftW7OdKJcKfg+ HYV3GqgJ5qsHISOFZuQcYX0D64w2FK0SN5OaiIDJnmZIynaY6FtPBp+1zHw4XfxZiLjO u9JUa6VD/bDmh70uANJqebI7M6tvp1L5Fi3ANzntdwtUqHzHdDQ086a2KghxG8vAEoMJ t7WoDUbujuWu8rlJ6Lxnwt9oZYAUMcKfajb+CHFs4+RqGY0z/GKxJ7iz8rbwISp4ochR 7xma7P6vc4+MHNRZ8dVWSiQeoAWLo/SraxC4xiY3RG/lyGWaiw+IrOZj/oMbwdKkK0KF uk+Q== X-Gm-Message-State: APjAAAV59U5gArSxM/4m0LbxVgIbyCzphi1UZH1wDeaA3xYtxBTfWsVq DXRWcioFah3bKTTwo1MuaPYDaw3H2WDaCYBtk6Y3Jg== X-Google-Smtp-Source: APXvYqzXGPjDxeX+5ToJMyJsyMe+cVVPsPp3a03VSu+K67UregUJ8eOsoG/mBOg8tOYl5QfFlp9k22iqch++Ial0X9A= X-Received: by 2002:a5d:8411:: with SMTP id i17mr587332ion.83.1565048684586; Mon, 05 Aug 2019 16:44:44 -0700 (PDT) MIME-Version: 1.0 References: <156498851376.24465.4531172446015994141.idtracker@ietfa.amsl.com> <87v9vblt6j.wl-jch@irif.fr> <518548BD-80F5-4F02-9362-EC61D0D5CA7B@cisco.com> <87mugnllz9.wl-jch@irif.fr> In-Reply-To: <87mugnllz9.wl-jch@irif.fr> From: Donald Eastlake Date: Mon, 5 Aug 2019 19:44:33 -0400 Message-ID: To: Juliusz Chroboczek Cc: "Eric Vyncke (evyncke)" , The IESG , "draft-ietf-babel-rfc6126bis@ietf.org" , "babel-chairs@ietf.org" , "babel@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-babel-rfc6126bis-11=3A_=28with_COMMENT=29?= 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: Mon, 05 Aug 2019 23:44:47 -0000 Speaking as an individual, I'm OK with that addition. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com On Mon, Aug 5, 2019 at 10:34 AM Juliusz Chroboczek wrote: > > > Please state somewhere that the two options are available; perhaps by > > simply copying the text of your reply in your document. > > I've added the following paragraph to Section 3.1: > > The protocol's control traffic can be carried indifferently over IPv6 > or over IPv4, and prefixes of either address family can be announced > over either protocol. Thus, there are at least two natural > deployment models: using IPv6 exclusively for all control traffic, or > running two distinct protocol instances, one for each address family. > The exclusive use of IPv6 for all control traffic is RECOMMENDED, > since using both protocols at the same time doubles the amount of > traffic devoted to neighbour discovery and link quality estimation. > > List: this adds a SHOULD to the draft. Since this reflects implementation > practice, I am fairly confident that it also reflects our consensus, please > yell if I'm wrong. > > -- Juliusz From nobody Mon Aug 5 19:09:57 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 71E6D120058; Mon, 5 Aug 2019 19:09:56 -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 JCpr2tkB0zxN; Mon, 5 Aug 2019 19:09:54 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 9A8781200DE; Mon, 5 Aug 2019 19:09:54 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id d17so88777951oth.5; Mon, 05 Aug 2019 19:09:54 -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:content-transfer-encoding; bh=cV3fuhWPsULqU5evkswxke1Lfpsm0dQ0IfhyVjT9OGg=; b=n3gMaetBTtMi5fqHcFHpNGIeq1xuEZx0+fbtKxbJiJPhJioDwfkHecYPReC/djvmVT SBNe9Eh7DHNuX4YgZmJqjDRydo216avdR+PzNhky+FRa84KSWpPWATd/p1OxoJkpbYlg iuWwhOK3/m9/aLmMUYw5im58lbf7OSKiXRrBzFsvSeF4N7JmlhrQIn5khch/7DHQvtWF Gy4i8WYyvP2tG8RYumw6Fju5QCsmo0dTN91PPxJT6U800PTpDmD4EygfIUyHdqPHkDg3 hnHOzUz2C+kynQ56t6F+moQb06MH/jbnCuBrZbVGuYSooKvuslcWx0V/wkm4WVLV4TsZ a7yA== 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:content-transfer-encoding; bh=cV3fuhWPsULqU5evkswxke1Lfpsm0dQ0IfhyVjT9OGg=; b=mKhhPT7ihH8VHxqqLaYNMB51C9moycC0yCGuD21A56KePk2CbcNPYHFD767y/50Bv8 cOcJ3JqLOWtUktivVbXFYseQGT8j7viIYQW0nEpRbH8LpNyVeCNG1m04mOcx5EJr73Ft uz06ADLM6dKyZahaARD3nm/e0MtYE1RhMiBmA6reO2Ci85NH64vvSBBCe9BAop1i0hS0 Moyy6cgIGviq7TWxulPE26FTJd3A8C8oJbe1FYIMXKLy3B1G3jKZI3P72OqqS++xmIR8 Xwm9MbFiT97OnXeaitu5t4k0lEXpkKf8eaaV1MTIMMzl7hQ8nwnz8Q5vA7C25rzbiGHY g7Rg== X-Gm-Message-State: APjAAAWxjsgZHH82vD0An76R2btDp7+h6spy1nh5PVfUDtSLnMZvW6kU /XCdQnICH8G+wTPrYfbvz0tJy2jQEM9XZ36qwy0RYyG4 X-Google-Smtp-Source: APXvYqyDVZBi7Yl9NvDA6UY8IjCVj6TZs8kMBjtQXyeizm3EKmlSC6pAUQXgb4YtqQzFjCArEqP+cfscaQ28jcU0hCk= X-Received: by 2002:a5d:960f:: with SMTP id w15mr1081883iol.24.1565057393439; Mon, 05 Aug 2019 19:09:53 -0700 (PDT) MIME-Version: 1.0 References: <156496962402.26572.16204290795859744323@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114E254159@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E254159@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Donald Eastlake Date: Mon, 5 Aug 2019 22:09:40 -0400 Message-ID: To: "babel@ietf.org" Cc: babel-chairs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [babel] 2nd WG Last Call: draft-ietf-babel-information-model (through 21 August) 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, 06 Aug 2019 02:09:56 -0000 Hi, A WG Last Call was issued some time ago for draft-ietf-babel-information-model-01.txt. There was no consensus on the mailing list although the Last Call was not formally closed at that time. The draft has been significantly modified since then. So, this message is the start of a 2nd WG Last Call, running through August 21st, 2019, this time on draft-ietf-babel-information-model-08.txt Thanks, Donald PS: This call is for a little longer than two weeks because, although I plan to monitor email, I will be traveling 13-20 August. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com On Mon, Aug 5, 2019 at 11:47 AM STARK, BARBARA H wrote: > > Hi babel WG and chairs, > I've posted a -08 (without consulting Mahesh, but it just has the items a= greed on in Montreal). > I'd like to start another WGLC now, please? > > One thing I still want to get better is the language in babel-route-recei= ved-metric and babel-route-calculated-metric around using something other t= han an unsigned int in case something has to be done to represent NULL (vs.= zero). The proposed (in Montreal) language is in babel-route-calculated-me= tric and a slightly different way of wording it is in babel-route-received-= metric. If you like one better than the other let me know (I'm leaning towa= rds my different wording). I'm also going to ask my BBF friends if they hav= e a suggestion for clearly wording this (since that's where the problem is = coming from). > > I also noticed after posting that I failed to update the list of configur= able parameters in the Overview (Section 2). I'll fix that after WGLC, if t= hat's ok. Specifically, "create/delete babel-hmac objects" and "create/dele= te babel-dtls objects" should be "create/delete HMAC key sets" and "create/= delete DTLS certificate sets", and "Interface: Link type" gets replaced wit= h "interface: Metric algorithm" and "interface: Split horizon". > Barbara > > > -----Original Message----- > > From: babel On Behalf Of internet- > > drafts@ietf.org > > Sent: Sunday, August 04, 2019 9:47 PM > > To: i-d-announce@ietf.org > > Cc: babel@ietf.org > > Subject: [babel] I-D Action: draft-ietf-babel-information-model-08.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the Babel routing protocol WG of the IETF. > > > > Title : Babel Information Model > > Authors : Barbara Stark > > Mahesh Jethanandani > > Filename : draft-ietf-babel-information-model-08.txt > > Pages : 28 > > Date : 2019-08-04 > > > > Abstract: > > This Babel Information Model can be used to create data models under > > various data modeling regimes. It allows a Babel implementation (vi= a > > a management protocol or interface) to report on its current state > > and may allow some limited configuration of protocol constants. > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Mon Aug 5 22:09:34 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 B504E12012B; Mon, 5 Aug 2019 22:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 BAF-adPSwTfE; Mon, 5 Aug 2019 22:09:29 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 9E8A3120132; Mon, 5 Aug 2019 22:09:29 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7659JZa015390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 6 Aug 2019 01:09:21 -0400 Date: Tue, 6 Aug 2019 00:09:18 -0500 From: Benjamin Kaduk To: "Eric Vyncke (evyncke)" Cc: Juliusz Chroboczek , Donald Eastlake , "babel-chairs@ietf.org" , "draft-ietf-babel-applicability@ietf.org" , The IESG , "babel@ietf.org" Message-ID: <20190806050918.GC59807@kduck.mit.edu> References: <156500498261.24571.204581663078651704.idtracker@ietfa.amsl.com> <87tvavlqrt.wl-jch@irif.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [babel] =?iso-8859-1?q?=C9ric_Vyncke=27s_Discuss_on_draft-ietf-b?= =?iso-8859-1?q?abel-applicability-07=3A__=28with_DISCUSS_and_COMMENT=29?= 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, 06 Aug 2019 05:09:32 -0000 On Mon, Aug 05, 2019 at 01:07:01PM +0000, Eric Vyncke (evyncke) wrote: > About my DISCUSS, the explanatory text is good but it is 'just an explanation' and not a proven property of Babel. If you remove the 'robust wrt bugs' from the list below the assertation of protocol robustness then I will be satisfied and will remove the DISCUSS. Simply add the text below the enumeration bullets and starts with "Experience gained in implementation interoperation testing shows that ....". > > For the text about security, what about something like: > " Babel-HMAC [HMAC] is a simple and easy to implement mechanism that > only guarantees authenticity, integrity, and anti-replay of the routing traffic, > and only supports symmetric keying with a small number of keys > (typically just one or two). Babel-DTLS [DTLS] is a more complex > mechanism, that requires some minor changes to be made to a typical > Babel implementation and depends on a DTLS stack being available, but > inherits all of the features of DTLS, notably authenticity, integrity, confidentiality, and the > ability to use asymmetric keys. > " (unsure about anti-replay of DTLS though) (see https://weeklyad.target.com/?lnk=dNav_weeklyad -- it's optional, building off the sequence number.) -Ben From nobody Tue Aug 6 04:32:32 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 EB8D11200B7; Tue, 6 Aug 2019 04:32:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-babel-applicability@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <156509114995.19226.16020049490173399413.idtracker@ietfa.amsl.com> Date: Tue, 06 Aug 2019 04:32:29 -0700 Archived-At: Subject: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-babel-applicability-08=3A_=28with_COMMENT=29?= 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, 06 Aug 2019 11:32:30 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-babel-applicability-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-applicability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for writing this document and the recent updates. While it is an easy read, I agree with others that there might still be some case where maybe benefits are overstated, e.g. sec 2.1 is not very objective and only provides basically two anecdotes. Other examples are these sentences: "In addition to the above, our implementation experience indicates that Babel tends to be robust with respect to bugs: more often than not, an implementation bug does not violate the properties on which Babel relies, and therefore slows down convergence or causes sub- optimal routing rather than causing the network to collapse." or "No other routing protocol known to us is similarly robust and efficient in this particular kind of topology." (also still one "us" here) From nobody Tue Aug 6 05:45: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 40C68120142; Tue, 6 Aug 2019 05:45:34 -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 B_-T1YeI8EeQ; Tue, 6 Aug 2019 05:45:32 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A321200B5; Tue, 6 Aug 2019 05:45:31 -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 x76CjQBC004136; Tue, 6 Aug 2019 14:45:26 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9559A4A682; Tue, 6 Aug 2019 14:45:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id QYFipBrgwAR0; Tue, 6 Aug 2019 14:45:28 +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 22D214A67F; Tue, 6 Aug 2019 14:45:26 +0200 (CEST) Date: Tue, 06 Aug 2019 14:45:25 +0200 Message-ID: <87v9vabgyi.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mirja =?ISO-8859-1?Q?K=FChlewind?= Cc: "The IESG" , draft-ietf-babel-applicability@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156509114995.19226.16020049490173399413.idtracker@ietfa.amsl.com> References: <156509114995.19226.16020049490173399413.idtracker@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]); Tue, 06 Aug 2019 14:45:26 +0200 (CEST) X-Miltered: at korolev with ID 5D497666.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D497666.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 : 5D497666.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] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_dra?= =?iso-8859-1?q?ft-ietf-babel-applicability-08=3A_=28with_COMMENT=29?= 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, 06 Aug 2019 12:45:34 -0000 Dear Mirja, Thank you for your review. > 2.1 is not very objective and only provides basically two anecdotes. I would appreciate it if you could spell out what it is that you find objectionable about Setion 2.1? The intent of this section is to give the reader actual empirical data, I'd be interested to know why you find that objectionable. > "In addition to the above, our implementation experience indicates > that Babel tends to be robust with respect to bugs: more often than > not, an implementation bug does not violate the properties on which > Babel relies, and therefore slows down convergence or causes sub- > optimal routing rather than causing the network to collapse." Could you please spell out what it is that bothers you about this paragraph? The intent here is to share our implementation experience with the reader. > "No other routing protocol known to us is similarly robust and > efficient in this particular kind of topology." Again, your objection is not clear to me. Are you disagreeing with the claim (e.g., because you know otherwise), or do you believe that this statement doesn't belong in this document, and if so, why? > (also still one "us" here) Could you please suggest a better wording? -- Juliusz From nobody Tue Aug 6 05:56:14 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 93423120189; Tue, 6 Aug 2019 05:56:05 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 YAZpfJL07NUS; Tue, 6 Aug 2019 05:56:03 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 19095120176; Tue, 6 Aug 2019 05:56:03 -0700 (PDT) Received: from 200116b82cb33400c17a7b26249d0b8e.dip.versatel-1u1.de ([2001:16b8:2cb3:3400:c17a:7b26:249d:b8e]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1huz0P-0008Sm-Ei; Tue, 06 Aug 2019 14:55:57 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <87v9vabgyi.wl-jch@irif.fr> Date: Tue, 6 Aug 2019 14:55:56 +0200 Cc: Donald Eastlake , babel-chairs@ietf.org, draft-ietf-babel-applicability@ietf.org, The IESG , babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <49D95485-0AEF-4698-980E-0F128A630934@kuehlewind.net> References: <156509114995.19226.16020049490173399413.idtracker@ietfa.amsl.com> <87v9vabgyi.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1565096163;71f4fbd1; X-HE-SMSGID: 1huz0P-0008Sm-Ei Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-babel-applicability-08=3A_=28with_COMMENT=29?= 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, 06 Aug 2019 12:56:06 -0000 Hi Juliusz, These are all no big concerns, but rather comments on the style for an = RFC (compared to a paper). See some examples below. > On 6. Aug 2019, at 14:45, Juliusz Chroboczek wrote: >=20 > Dear Mirja, >=20 > Thank you for your review. >=20 >> 2.1 is not very objective and only provides basically two anecdotes. >=20 > I would appreciate it if you could spell out what it is that you find > objectionable about Setion 2.1? The intent of this section is to give = the > reader actual empirical data, I'd be interested to know why you find = that > objectionable. 15 minutes to explain really depends on the two people involved. Also = implementing =E2=80=9Cover two nights=E2=80=9D really doesn=E2=80=99t = tell me much. I think it would be more useful to e.g. talk about the = lines of code or number of components or whatever.=20 It not a problem to have these anecdotes in the draft but I would not = claim that these two experiences prove that the protocol is simple. >=20 >> "In addition to the above, our implementation experience indicates >> that Babel tends to be robust with respect to bugs: more often than >> not, an implementation bug does not violate the properties on which >> Babel relies, and therefore slows down convergence or causes sub- >> optimal routing rather than causing the network to collapse." >=20 > Could you please spell out what it is that bothers you about this > paragraph? The intent here is to share our implementation experience = with > the reader. I think the =E2=80=9Cmore often than not=E2=80=9D is again very blurry. = E.g. I would recommend to say instead:=20 "In addition to the above, implementation experience indicates that Babel tends to be robust with respect to bugs: in various=20 cases implementation bugs did not violate the properties on which Babel relies, and therefore slowed down convergence or caused sub- optimal routing but did not cause the network to collapse." >=20 >> "No other routing protocol known to us is similarly robust and >> efficient in this particular kind of topology." >=20 > Again, your objection is not clear to me. Are you disagreeing with = the > claim (e.g., because you know otherwise), or do you believe that this > statement doesn't belong in this document, and if so, why? I would rather suggest: =E2=80=9COther widely deployed routing protocol are less robust and = efficient in this particular kind of topology.=E2=80=9D I believe there are still more cases in the draft which could be toned = down a bit to avoid overstating but make a more objective statement = instead. Mirja >=20 >> (also still one "us" here) >=20 > Could you please suggest a better wording? >=20 > -- Juliusz >=20 >=20 From nobody Tue Aug 6 06:19:44 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 8985A12015B; Tue, 6 Aug 2019 06:19:34 -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 Y2s9ZYGwqSHZ; Tue, 6 Aug 2019 06:19:32 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE8012013E; Tue, 6 Aug 2019 06:19:32 -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 x76DJRKL014843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Aug 2019 15:19:27 +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 x76DJROC010077; Tue, 6 Aug 2019 15:19:27 +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 10B004A8C8; Tue, 6 Aug 2019 15:19:30 +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 TYSyXMiG2BK3; Tue, 6 Aug 2019 15:19:29 +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 0B4D14A8C6; Tue, 6 Aug 2019 15:19:29 +0200 (CEST) Date: Tue, 06 Aug 2019 15:19:28 +0200 Message-ID: <87tvaubfdr.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mirja Kuehlewind Cc: Donald Eastlake , babel-chairs@ietf.org, draft-ietf-babel-applicability@ietf.org, The IESG , babel@ietf.org In-Reply-To: <49D95485-0AEF-4698-980E-0F128A630934@kuehlewind.net> References: <156509114995.19226.16020049490173399413.idtracker@ietfa.amsl.com> <87v9vabgyi.wl-jch@irif.fr> <49D95485-0AEF-4698-980E-0F128A630934@kuehlewind.net> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 06 Aug 2019 15:19:27 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 06 Aug 2019 15:19:27 +0200 (CEST) X-Miltered: at korolev with ID 5D497E5F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D497E5F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D497E5F.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D497E5F.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 : 5D497E5F.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D497E5F.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] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_dra?= =?iso-8859-1?q?ft-ietf-babel-applicability-08=3A_=28with_COMMENT=29?= 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, 06 Aug 2019 13:19:35 -0000 The changes below are in git, I'm not submitting a new revision yet. > 15 minutes to explain really depends on the two people involved. I'm speaking about giving a talk. I've done it repeatedly, last time was just two weeks ago. I'll keep this bit, if that's okay with you. > Also implementing “over two nights” really doesn’t tell me much. I think > it would be more useful to e.g. talk about the lines of code or number > of components or whatever. I most humbly disagree. Time required to do an independent reimplementation is a much better indicator than mere lines of code. > I think the “more often than not” is again very blurry. E.g. I would recommend to say instead: > "In addition to the above, implementation experience indicates > that Babel tends to be robust with respect to bugs: in various > cases implementation bugs did not violate the properties on which > Babel relies, and therefore slowed down convergence or caused sub- > optimal routing but did not cause the network to collapse." Agreed. I've put "in many cases". >>> "No other routing protocol known to us is similarly robust and >>> efficient in this particular kind of topology." >> Again, your objection is not clear to me. Are you disagreeing with the >> claim (e.g., because you know otherwise), or do you believe that this >> statement doesn't belong in this document, and if so, why? > I would rather suggest: > “Other widely deployed routing protocol are less robust and efficient in > this particular kind of topology.” I've removed this sentence completely. > I believe there are still more cases in the draft which could be toned > down a bit to avoid overstating but make a more objective statement > instead. Since I'm the original designer, I'm naturally biased. I'd appreciate it if you could specify exactly which bits you find objectionable. Thanks, -- Juliusz From nobody Tue Aug 6 08:00: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 502BB1201E6; Tue, 6 Aug 2019 08:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=TVQyQDyq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hmSBZ8ZN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxFjgZISwYmm; Tue, 6 Aug 2019 08:00:10 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56D4B12019B; Tue, 6 Aug 2019 08:00:10 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 5FE95545; Tue, 6 Aug 2019 11:00:09 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 06 Aug 2019 11:00:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=r Ins1Ur4Phg2Mud/bwNS8ODlpX0Fl84Dc1rQyRewRno=; b=TVQyQDyqpahq+/evu skCZfP1qqjc2NFfzWrhdXyO1jv7mqyDa+d8Uv07pHb4YXkoO3ZqJl5zWTlwO9ONH XnAVAystR4YVygd2JFmyAEgnjsbxgM0cTloVlUFW4H7iEpCmkkXB7Yy0YuAPVv3d igPAyRXOu01Xy4ImC4LPRGoGtlXYXkuAbtnidIm5Qdvd3Qp+rGLkNBtWZq7K8TaN 74jiTSvWPMXYau6e6ps7sz5MZ23ypbRfiAWAhLx3XpYhfUayH0PfEQ5ajRAzi8Zi rGddplnm11o1lJ1V1HsBb1vTLfTsFXD55OK2ea+NRrymIyiCU1I4iNUo4tc71TMO h7chA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=rIns1Ur4Phg2Mud/bwNS8ODlpX0Fl84Dc1rQyRewR no=; b=hmSBZ8ZNxAw8CQpSXxQG76EpgapHXARbSAGqXcfOjjDaZm3Z2Boa3YVUD mQLWv3EqC6N9zdKJvQt4Xy9DLNm5XpW6CoxnluU4LSiGCN57oKBPPTSpdPmNwyDu edn6LA1U1HwsprGLyh3Wmxt3mm+LjMEzChQvctF2QxKqFv4ZW051gIjdZ9PzALa4 nO41GO30JyXabS3NmKB+Dt3RTXrjPZJyGE6eC4rgZ9N0fXtCbjVTvV08OzL6wjfV ElC6YImdE/rv6OzPEK3YE2uZ9oPIFJZhb3LzNLmyqw+m1jTfYH3fNDj9YiL+1afT 57Ew82VhrK/hXrSMTyXv+1QzvE1PA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddutddgkeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihhrihhfrdhfrhdpuhhptgdrvgguuhenucfkphepudejfedrfeekrdduudejrdek feenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinh enucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.83]) by mail.messagingengine.com (Postfix) with ESMTPA id 8CA163800AB; Tue, 6 Aug 2019 11:00:06 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <87d0hjlf7q.wl-jch@irif.fr> Date: Tue, 6 Aug 2019 11:00:04 -0400 Cc: IESG , draft-ietf-babel-applicability@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <77BC44D1-1486-4557-91A4-C7F56DB4240C@cooperw.in> References: <156501857349.24525.10768788622753886835.idtracker@ietfa.amsl.com> <87ftmfliai.wl-jch@irif.fr> <87d0hjlf7q.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Alissa Cooper's No Objection on draft-ietf-babel-applicability-07: (with COMMENT) 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, 06 Aug 2019 15:00:13 -0000 Hi Juliusz, > On Aug 5, 2019, at 1:00 PM, Juliusz Chroboczek wrote: >=20 >>> So there's not much I can do at this time. If you know otherwise, = please >>> let me know. >=20 >> In that case I think not making the claims is a better option. The = one >> about bugs seems particularly problematic >=20 > As far as bug resistence is concerned -- I agree. This has been = weakened > in -08 at the prompting of =C3=89ric Vyncke, please let me know if you = with me > to weaken it further. Mirja=E2=80=99s suggested formulation is an improvement I think. >=20 > As far as the other two properties are concerned (unusual networks and > unusual metrics), I must most humbly disagree. There is a fair body = of > circumstantial evidence that favours these claims, such as the = references > [DELAY-BASED], [REAL-WORLD] and [BRIDGING-LAYERS] Could you add these citations in the appropriate places in the bulleted = list of claims? Thanks, Alissa > of this document, as > well as a number of experiments [1,2] that I don't feel comfortable = citing > at the current time. >=20 > [1] http://people.ac.upc.edu/leandro/pubs/eomrpfwcn.pdf > [2] https://www.irif.fr/~jch/software/babel/battlemeshv10.html >=20 > Sorry for that. >=20 > -- Juliusz From nobody Tue Aug 6 08:30: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 5870A120272; Tue, 6 Aug 2019 08:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 5ejh760Cfs1C; Tue, 6 Aug 2019 08:30:08 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 075A512021F; Tue, 6 Aug 2019 08:30:07 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x76FTw11018523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 6 Aug 2019 11:30:03 -0400 Date: Tue, 6 Aug 2019 10:29:58 -0500 From: Benjamin Kaduk To: Juliusz Chroboczek Cc: =?iso-8859-1?Q?=C9ric?= Vyncke , Donald Eastlake , babel-chairs@ietf.org, draft-ietf-babel-applicability@ietf.org, The IESG , babel@ietf.org Message-ID: <20190806152958.GE59807@kduck.mit.edu> References: <156500498261.24571.204581663078651704.idtracker@ietfa.amsl.com> <87tvavlqrt.wl-jch@irif.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87tvavlqrt.wl-jch@irif.fr> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [babel] =?iso-8859-1?q?=C9ric_Vyncke=27s_Discuss_on_draft-ietf-b?= =?iso-8859-1?q?abel-applicability-07=3A__=28with_DISCUSS_and_COMMENT=29?= 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, 06 Aug 2019 15:30:09 -0000 Jumping in on one narrow question... On Mon, Aug 05, 2019 at 02:51:02PM +0200, Juliusz Chroboczek wrote: > > > -- Section 5 -- > > > Comparison between HMAC & DTLS variants is probably irrelevant in this > > document. Though, a use case with security in mind would be benefitial. > > There are no known use cases. Our users run Babel over secure link > layers, and nobody has requested security mechanisms embedded within the > protocol. The security mechanisms were designed solely in order to > satisfy IETF requirements. (To be fair, it was a lot of fun.) How does the HOMENET usage of babel fit into this? I would be surprised if they were expecting secure link layers to be used inside the home, but it does seem like the threat model for HOMENET includes hostile or compromised devices in the home. Thanks, Ben From nobody Tue Aug 6 08:30:52 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 B7E8C12030B; Tue, 6 Aug 2019 08:30: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 G5DtpbO0MXxt; Tue, 6 Aug 2019 08:30:41 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 498BD120375; Tue, 6 Aug 2019 08:30:33 -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 x76FUNMR019576; Tue, 6 Aug 2019 17:30:23 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 76A704B149; Tue, 6 Aug 2019 17:30:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id XVVOs4yJRMP6; Tue, 6 Aug 2019 17:30:25 +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 8D9B24B147; Tue, 6 Aug 2019 17:30:25 +0200 (CEST) Date: Tue, 06 Aug 2019 17:30:25 +0200 Message-ID: <87h86ub9bi.wl-jch@irif.fr> From: Juliusz Chroboczek To: Alissa Cooper Cc: IESG , draft-ietf-babel-applicability@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <77BC44D1-1486-4557-91A4-C7F56DB4240C@cooperw.in> References: <156501857349.24525.10768788622753886835.idtracker@ietfa.amsl.com> <87ftmfliai.wl-jch@irif.fr> <87d0hjlf7q.wl-jch@irif.fr> <77BC44D1-1486-4557-91A4-C7F56DB4240C@cooperw.in> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 06 Aug 2019 17:30:23 +0200 (CEST) X-Miltered: at korolev with ID 5D499D0F.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D499D0F.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 : 5D499D0F.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] Alissa Cooper's No Objection on draft-ietf-babel-applicability-07: (with COMMENT) 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, 06 Aug 2019 15:30:43 -0000 >> As far as bug resistence is concerned -- I agree. This has been weakened >> in -08 at the prompting of Éric Vyncke, please let me know if you with me >> to weaken it further. > Mirja’s suggested formulation is an improvement I think. Done. >> As far as the other two properties are concerned (unusual networks and >> unusual metrics), I must most humbly disagree. There is a fair body of >> circumstantial evidence that favours these claims, such as the references >> [DELAY-BASED], [REAL-WORLD] and [BRIDGING-LAYERS] > Could you add these citations in the appropriate places in the bulleted > list of claims? I've added a forward ref to Section 3 where these papers are duly cited. -- Juliusz From nobody Tue Aug 6 09:25:26 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 AB1BD12012C; Tue, 6 Aug 2019 09:25:24 -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 Rs5cJf8u_UMG; Tue, 6 Aug 2019 09:25:22 -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 557581200F6; Tue, 6 Aug 2019 09:25:22 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x76GPCbh031553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Aug 2019 18:25:12 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x76GPCQC014291; Tue, 6 Aug 2019 18:25:12 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id DBF764B518; Tue, 6 Aug 2019 18:25:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 55QB2q2WsrHa; Tue, 6 Aug 2019 18:25:14 +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 578F64B515; Tue, 6 Aug 2019 18:25:11 +0200 (CEST) Date: Tue, 06 Aug 2019 18:25:11 +0200 Message-ID: <87ef1yb6s8.wl-jch@irif.fr> From: Juliusz Chroboczek To: Benjamin Kaduk Cc: =?ISO-8859-1?Q?=C9ric?= Vyncke , Donald Eastlake , babel-chairs@ietf.org, draft-ietf-babel-applicability@ietf.org, The IESG , babel@ietf.org In-Reply-To: <20190806152958.GE59807@kduck.mit.edu> References: <156500498261.24571.204581663078651704.idtracker@ietfa.amsl.com> <87tvavlqrt.wl-jch@irif.fr> <20190806152958.GE59807@kduck.mit.edu> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 06 Aug 2019 18:25:12 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 06 Aug 2019 18:25:12 +0200 (CEST) X-Miltered: at korolev with ID 5D49A9E8.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D49A9E8.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D49A9E8.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D49A9E8.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 : 5D49A9E8.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D49A9E8.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] =?iso-8859-1?q?=C9ric_Vyncke=27s_Discuss_on_draft-ietf-b?= =?iso-8859-1?q?abel-applicability-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 06 Aug 2019 16:25:25 -0000 > How does the HOMENET usage of babel fit into this? I would be surprised if > they were expecting secure link layers to be used inside the home, but it > does seem like the threat model for HOMENET includes hostile or compromised > devices in the home. Barbara will correct me if I'm wrong, but as far as I know, the Homenet working group hasn't decided on a security mechanism yet. I have heard opinions to the effect that Homenet requires asymmetric authentication, in which case Babel-DTLS would be necessary, but I wouldn't presume to judge whether these opinions represent WG consensus. -- Juliusz From nobody Tue Aug 6 11:14:32 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 D179A120668; Tue, 6 Aug 2019 11:14:23 -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 shR1fgilqyDt; Tue, 6 Aug 2019 11:14:22 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CDDF120667; Tue, 6 Aug 2019 11:14:22 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x76HxTaq008791; Tue, 6 Aug 2019 14:14:21 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2u7desaf80-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 Aug 2019 14:14:19 -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 x76IDXa4018436; Tue, 6 Aug 2019 14:13:34 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x76IDQLu018227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Aug 2019 14:13:26 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 21C354009E70; Tue, 6 Aug 2019 18:13:26 +0000 (GMT) Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30485.vci.att.com (Service) with ESMTPS id 0C2654009E63; Tue, 6 Aug 2019 18:13:26 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0439.000; Tue, 6 Aug 2019 14:13:25 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" , "'Benjamin Kaduk'" CC: "'babel@ietf.org'" , "'homenet@ietf.org'" Thread-Topic: =?utf-8?B?W2JhYmVsXSAgw4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRm?= =?utf-8?B?LWJhYmVsLWFwcGxpY2FiaWxpdHktMDc6ICh3aXRoIERJU0NVU1MgYW5kIENP?= =?utf-8?Q?MMENT)?= Thread-Index: AQHVTHOUmfiiRY491EyCa83IR+EA46buZEHA Date: Tue, 6 Aug 2019 18:13:25 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E25674D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <156500498261.24571.204581663078651704.idtracker@ietfa.amsl.com> <87tvavlqrt.wl-jch@irif.fr> <20190806152958.GE59807@kduck.mit.edu> <87ef1yb6s8.wl-jch@irif.fr> In-Reply-To: <87ef1yb6s8.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.214.248] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-06_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908060158 Archived-At: Subject: Re: [babel] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-bab?= =?utf-8?q?el-applicability-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 06 Aug 2019 18:14:24 -0000 UmVtb3ZpbmcgdW5uZWNlc3NhcnkgcGFydGljaXBhbnRzIGZyb20gdGhlIGRpc2N1c3Npb24gKEkg ZG9uJ3QgdGhpbmsgaXRzIHJlbGV2YW50IHRvIHRoZSBJRVNHIHJldmlldyBvZiBiYWJlbC1hcHBs aWNhYmlsaXR5PyksIGFuZCBhZGRpbmcgaG9tZW5ldC4uLg0KDQo+ID4gSG93IGRvZXMgdGhlIEhP TUVORVQgdXNhZ2Ugb2YgYmFiZWwgZml0IGludG8gdGhpcz8gIEkgd291bGQgYmUNCj4gPiBzdXJw cmlzZWQgaWYgdGhleSB3ZXJlIGV4cGVjdGluZyBzZWN1cmUgbGluayBsYXllcnMgdG8gYmUgdXNl ZCBpbnNpZGUNCj4gPiB0aGUgaG9tZSwgYnV0IGl0IGRvZXMgc2VlbSBsaWtlIHRoZSB0aHJlYXQg bW9kZWwgZm9yIEhPTUVORVQgaW5jbHVkZXMNCj4gPiBob3N0aWxlIG9yIGNvbXByb21pc2VkIGRl dmljZXMgaW4gdGhlIGhvbWUuDQo+IA0KPiBCYXJiYXJhIHdpbGwgY29ycmVjdCBtZSBpZiBJJ20g d3JvbmcsIGJ1dCBhcyBmYXIgYXMgSSBrbm93LCB0aGUgSG9tZW5ldA0KPiB3b3JraW5nIGdyb3Vw IGhhc24ndCBkZWNpZGVkIG9uIGEgc2VjdXJpdHkgbWVjaGFuaXNtIHlldC4gIEkgaGF2ZSBoZWFy ZA0KPiBvcGluaW9ucyB0byB0aGUgZWZmZWN0IHRoYXQgSG9tZW5ldCByZXF1aXJlcyBhc3ltbWV0 cmljIGF1dGhlbnRpY2F0aW9uLCBpbg0KPiB3aGljaCBjYXNlIEJhYmVsLURUTFMgd291bGQgYmUg bmVjZXNzYXJ5LCBidXQgSSB3b3VsZG4ndCBwcmVzdW1lIHRvIGp1ZGdlDQo+IHdoZXRoZXIgdGhl c2Ugb3BpbmlvbnMgcmVwcmVzZW50IFdHIGNvbnNlbnN1cy4NCg0KSG9tZW5ldCBXRyBoYXNuJ3Qg ZG9jdW1lbnRlZCBpdHMgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIC0tIGZvciBhbnl0aGluZy4NClRo ZSBjdXJyZW50IG1vZGVsIGZvciBzZWN1cmluZyBob21lIG5ldHdvcmtzIGlzIHRvIHNlY3VyZSB0 aGUgcGh5c2ljYWwgbGF5ZXJzLiANClRoZSBub3JtYWwgcHJhY3RpY2UgZm9yIGRlYWxpbmcgd2l0 aCBjb21wcm9taXNlZCBkZXZpY2VzIGluIHRoZSBob21lIGlzIHRvIHJlbW92ZSBvciBmaXggdGhl bSB3aGVuIHNvbWVvbmUgZmlndXJlcyBvdXQgdGhleSdyZSBjb21wcm9taXNlZC4NCk15IHBlcnNv bmFsIChpbmRpdmlkdWFsKSBvcGluaW9uIGlzIGl0J3MgZXh0cmVtZWx5IGltcG9ydGFudCB0byBo YXZlIHRvb2xzIHRvIGRpc2NvdmVyIHdoZW4gYSBkZXZpY2UgaXMgY2F1c2luZyB0cm91YmxlLiBP bi1nb2luZyBwcm90ZWN0aW9uIGFnYWluc3Qgc3VjaCBkZXZpY2VzIChzbyB0aGV5IGNhbiBiZSBz YWZlbHkoPykgbGVmdCBvbiB0aGUgaG9tZSBuZXR3b3JrIGluZGVmaW5pdGVseSBhbmQgcGVvcGxl IGNhbiBmZWVsIHNlY3VyZT8/Pz8pIGlzbid0IGltcG9ydGFudCBvciBldmVuIG5lY2Vzc2FyaWx5 IGEgZ29vZCBpZGVhLg0KDQpCYWJlbC1ITUFDIGNvdWxkIGlkZW50aWZ5IGFueXRoaW5nIHRyeWlu ZyB0byB0YWxrIEJhYmVsIHdpdGhvdXQgYSBrZXkuIElmIHRoZSBjb21wcm9taXNlZCBkZXZpY2Ug aGFzIGJlZW4gZ2l2ZW4gdGhlIGtleXMgKGJlY2F1c2UgdGhlIHVzZXIgdGhvdWdodCBpdCBjb3Vs ZCBiZSB0cnVzdGVkIGFuZCBkaWRuJ3Qga25vdyBpdCB3YXMgY29tcHJvbWlzZWQpLCB0aGVuIG5l aXRoZXIgSE1BQyBub3IgRFRMUyB3aWxsIGJlIG9mIGFueSBwcm90ZWN0aW9uLg0K From nobody Tue Aug 6 12:04: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 26F1712013C for ; Tue, 6 Aug 2019 12:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 ndO0GNuIY12a for ; Tue, 6 Aug 2019 12:04:16 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 BFD501200A3 for ; Tue, 6 Aug 2019 12:04:16 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id p184so42004719pfp.7 for ; Tue, 06 Aug 2019 12:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pmpIsDFlo768njtw3zQTJ6M6lkCVHEAGL/RBYMxExmI=; b=gyIbyHVvJjXJYBTWS2NWFdjAIsttT8e919F3lD1lqDAWlvtivk2hFnlxHUM5AsAexo iXx+SkrCUtQbW7QsTl+8EF/7UOMQr7LhBDjbtZiMG3XE/nlW6BeAzhvc1qxStBA0np/U V67tb+IPmu2Mngvkd65UDW++fTap+Rt/ENYJRJhv8dpVt/4qyQ6dcWuxb259AArVBQGI /k/gLjuJHXv2yxdmhzKHrj4ZfnDpFZ75UXYgatD/oCv2iFJelyr4A4P+0gJP1IY+C0bY uallrLyrLia1o+RR7eWJ1yfkD/XGdAK1L7UT3+edNubPL1PUZYDcHmTPDFfSGC0P4kNu phuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pmpIsDFlo768njtw3zQTJ6M6lkCVHEAGL/RBYMxExmI=; b=umnT36adx/9gqtzaXPUHIegfH9TDytq+DpO2nyWJ++DVul2ifJZoG+m13AeF/9Ud3H hk3yazsa/g3Rr74bl03R/3moy+nOXqFtPZYiMEoid/tZ2saOfj51mbZAjFwLVMrLKxto JOdUO0SLwSkqbKsEWKo0mDmSHNG8Pnw7e74xDWt9ZZxqxcGBJiUZwz6AgFjOWqazoWL2 0GQsebLp9exe+Nq6ecwmAdT0GQL3Eze5Je1mZnB5M6xPcOLrkPRAbuVwin7qC6bWznaL /KCg921lJOvVMPqEYt4OUUZS05reL0X7k23A/pk/hE8rtrx4Xvpp8RcW8VGf7vBCwwn0 SvpA== X-Gm-Message-State: APjAAAVyjhY+kg7WV9ZvzSEOUBi2lkpEi/P6llZsuXB4Q8UfcE+e98ep NLOzkLN9DUn0b75J9FGR0TJO6GWYD98= X-Google-Smtp-Source: APXvYqyJIFLCqfkz7fYb8ZPZ2hKOVfnEqoYYOHX5+P+j0Is2iY/AVXKkrcRkMxsCIyIHPynBa+ug8Q== X-Received: by 2002:a17:90a:3401:: with SMTP id o1mr4624282pjb.7.1565118256055; Tue, 06 Aug 2019 12:04:16 -0700 (PDT) Received: from [10.33.122.240] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id z20sm139922789pfk.72.2019.08.06.12.04.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Aug 2019 12:04:14 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> Content-Type: multipart/mixed; boundary="Apple-Mail=_29C2421E-7C8D-4C62-BE9F-039DF6A825F7" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 6 Aug 2019 12:04:13 -0700 In-Reply-To: <8736itu6j8.wl-jch@irif.fr> Cc: Babel at IETF To: Juliusz Chroboczek References: <8736itu6j8.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Example configuration 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, 06 Aug 2019 19:04:19 -0000 --Apple-Mail=_29C2421E-7C8D-4C62-BE9F-039DF6A825F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Juliusz, As I said before, thanks for these examples. They truly will help anyone = trying to configure babel using NETCONF/YANG. See inline. > On Jul 25, 2019, at 2:51 PM, Juliusz Chroboczek wrote: >=20 >> In my presentation on the YANG model for Babel, I asked for help in >> trying to improve the example configuration of Babel. The example was >> shown in XML, but that does not mean I am expecting anyone to help me >> improve the example in XML. >=20 > I'll use the syntax of the babeld configuration file. >=20 > Here's a pretty minimal config: >=20 > interface eth0 > interface wlan0 >=20 > This says to run Babel on interfaces eth0 and wlan0. Babeld will > automatically detect that eth0 is wired and wlan0 is wireless, and = will > configure the right parameters automatically. The XML encoding of the above example can be found in = example-babel-configuration-2.4.xml which is attached to this e-mail. >=20 > Here's a slightly less minimal configuration: >=20 > interface eth0 > interface eth1 type wireless > interface tun0 type tunnel >=20 > Here, interface eth1 is an Ethernet bridged to a wireless radio, so > babeld's autodetection fails, and the interface type needs to be > configured manually. Tunnels are not detected automatically, so this > needs to be specified. >=20 > This is equivalent to the following: >=20 > interface eth0 > interface eth1 link-quality true split-horizon false > interface tun0 enable-timestamps true max-rtt-penalty 96 The XML encoding of the above example can be found in = example-babel-configuration-2.5.xml. You will notice that eth1 type is = set to =E2=80=98wireless=E2=80=99 using =E2=80=98link-properties=E2=80=99.= Same for tun0 and =E2=80=98tunnel=E2=80=99. >=20 > Here's another configuration: >=20 > interface eth0 > interface ppp0 hello-interval 30 update-interval 120 > in if ppp0 metric 1024 > out if ppp0 metric 1024 >=20 > Here, ppp0 is a metered 3G link used for fallback connectivity. It = runs > with much higher than default time constants in order to avoid control > traffic as much as possible, and the metric of routes through that = link > are increased so that they are not used unless all other options fail. Here is where I am stuck. Currently, there is a = babel-mcast-hello-interval parameter defined in the information model = under the interface. But this a read-only attribute, meaning it is a = operational value, not a configuration value. There is no unicast hello = interval, which is what I am assuming you mean above. So the question = is, do we need one, and if it is configurable parameter, it needs to = read-write. Secondly, babel-update-interval is also an read-only = (operational) parameter, therefore cannot be configured. If this needs = to be a configurable parameter, the information model will need to be = updated. Also, there is no metric configuration on an interface today. Certainly = not based on in and out traffic. If we need to add it, the information = model needs to be updated. >=20 > Here's a configuration for David: >=20 > interface eth0 > interface wlan0 unicast true >=20 > This requests that all control traffic other than Hellos on the wlan0 > interface be sent as unicast. This can be useful when wlan0 uses > a technology on which multicast is prohibitively expensive. Currently, we have no way to configure an interface to send unicast = traffic in a preferred manner. If this is required, we will need to = update the babel-interface-obj in the information model. I also notice = something called unicast-only, which by its name tells me send unicast = traffic only. Also not in the information model. >=20 > Another one: >=20 > interface atm0 split-horizon false unicast true Currently, I can configure the interface for split-horizon, but cannot = configure it for unicast traffic. Looks like we need this to be added. >=20 > Here, atm0 is an NBMA interface. Transitive connectivity is not > guaranteed, so we disable the split-horizon optimisation. Unicast is = to > be preferred to multicast whenever possible. >=20 > Here is a configuration that is not yet implemented, but planned for > a future version: >=20 > interface wg0 unicast-only true > neighbour fe80::1234 if wg0 >=20 > Here, wg0 is a Wireguard tunnel, and doesn't support multicast at all. > All traffic over that interface is sent as unicast, so automatic = discovery > is not possible. Thus, we need to specify the link-local addresses of > neighbours manually. Again, this is something that the current information model does not = support. If we need to be able to specify a link-local address for a = neighbor, the information model will need to be updated. That command = also needs to specify which interface the link local address needs to be = associated with. >=20 > Hope this helps, Yes, it does. And plenty! >=20 > -- Juliusz >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_29C2421E-7C8D-4C62-BE9F-039DF6A825F7 Content-Disposition: attachment; filename=example-babel-configuration-2.4.xml Content-Type: application/xml; x-unix-mode=0644; name="example-babel-configuration-2.4.xml" Content-Transfer-Encoding: 7bit eth0 ianaift:ethernetCsmacd true wlan0 ianaift:ieee80211 true babel:babel name:babel true true eth0 true wlan0 true --Apple-Mail=_29C2421E-7C8D-4C62-BE9F-039DF6A825F7 Content-Disposition: attachment; filename=example-babel-configuration-2.5.xml Content-Type: application/xml; x-unix-mode=0644; name="example-babel-configuration-2.5.xml" Content-Transfer-Encoding: 7bit eth0 ianaift:ethernetCsmacd true eth1 ianaift:ethernetCsmacd true tun0 ianaift:tunnel true babel:babel name:babel true true eth0 true eth1 true wireless tun0 true tunnel --Apple-Mail=_29C2421E-7C8D-4C62-BE9F-039DF6A825F7 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_29C2421E-7C8D-4C62-BE9F-039DF6A825F7-- From nobody Tue Aug 6 12:39:02 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 196A812016E for ; Tue, 6 Aug 2019 12:39:00 -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 ByPow-kHo9Yy for ; Tue, 6 Aug 2019 12:38:57 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9291512003F for ; Tue, 6 Aug 2019 12:38:57 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x76Jcq4j009765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Aug 2019 21:38:52 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x76Jcqm5016097; Tue, 6 Aug 2019 21:38:52 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3EF8E4BDCC; Tue, 6 Aug 2019 21:38:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id LIq9yravlhmB; Tue, 6 Aug 2019 21:38:54 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 494464BDCA; Tue, 6 Aug 2019 21:38:54 +0200 (CEST) Date: Tue, 06 Aug 2019 21:38:53 +0200 Message-ID: <877e7qaxte.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mahesh Jethanandani Cc: Babel at IETF In-Reply-To: <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 06 Aug 2019 21:38:52 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 06 Aug 2019 21:38:52 +0200 (CEST) X-Miltered: at korolev with ID 5D49D74C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D49D74C.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D49D74C.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D49D74C.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 : 5D49D74C.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D49D74C.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] Example configuration 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, 06 Aug 2019 19:39:00 -0000 >> Here's a slightly less minimal configuration: >> >> interface eth0 >> interface eth1 type wireless >> interface tun0 type tunnel [...] >> This is equivalent to the following: >> >> interface eth0 >> interface eth1 link-quality true split-horizon false >> interface tun0 enable-timestamps true max-rtt-penalty 96 > The XML encoding of the above example can be found in > example-babel-configuration-2.5.xml. You will notice that eth1 type is > set to ‘wireless’ using ‘link-properties’. Same for tun0 and ‘tunnel’. Hmm. Draft-ietf-babel-information-model-08 removes the interface type, and uses the underlying properties instead. Shouldn't the YANG model do the same, or is there some reason why the YANG model should be using interface types instead? >> interface eth0 >> interface ppp0 hello-interval 30 update-interval 120 >> in if ppp0 metric 1024 >> out if ppp0 metric 1024 > Here is where I am stuck. Currently, there is > a babel-mcast-hello-interval parameter defined in the information model > under the interface. But this a read-only attribute, meaning it is > a operational value, not a configuration value. It should be configurable. > There is no unicast hello interval, which is what I am assuming you mean > above. No, I mean the multicast interval. > Also, there is no metric configuration on an interface today. Certainly > not based on in and out traffic. The metric configuration is not attached to the interface, it's a filter. Filters are a separate kind of entity, and need not contain an interface entry. For example, one may say in ip 10.0.0.0/8 metric 128 in which case the filter applies to all routes with a destination in 10/8. -- Juliusz From nobody Tue Aug 6 13:04:57 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 C295612013C for ; Tue, 6 Aug 2019 13:04:55 -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 rSW1haDOB_7N for ; Tue, 6 Aug 2019 13:04:54 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1EC91200D8 for ; Tue, 6 Aug 2019 13:04:53 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x76K4kCe013964; Tue, 6 Aug 2019 22:04:46 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 6FCC14BEFF; Tue, 6 Aug 2019 22:04:49 +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 V2oNdll70hPL; Tue, 6 Aug 2019 22:04:48 +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 6D1174BEFC; Tue, 6 Aug 2019 22:04:47 +0200 (CEST) Date: Tue, 06 Aug 2019 22:04:47 +0200 Message-ID: <875znaawm8.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'babel@ietf.org'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E254159@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <156496962402.26572.16204290795859744323@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114E254159@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 06 Aug 2019 22:04:46 +0200 (CEST) X-Miltered: at korolev with ID 5D49DD5E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D49DD5E.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 : 5D49DD5E.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-08.txt 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, 06 Aug 2019 20:04:56 -0000 # Section 1. "one of these security mechanisms" -> "one or both of these security mechanisms" "(contingent on a management protocol with Babel support being implemented)" I don't know what this means "a referential [...] structure." I don't know what this means # Section 3.2 "Default is ff02:0:0:0:0:0:1:6". Why not write this as ff02::1:6, as is usual? # Section 3.3 The metric computation algorithm is described twice, here and globally in the babel-information-obj. Is the global value a default for newly created interfaces, or does it provide a value in case the interface-obj doesn't specify it? Please clarify. The same goes for babel-hmac-algorithm. # Section 3.4 Aren't we missing an entry for the total number of packets sent? Should these entries be optional? # Section 3.5 I don't think that the nbr-stats entries is useful. A neighbour is a transient data structure, and neighbours get destroyed when they become unreachable. Thus, there is no good place to persist the statistics. I suggest moving all statistics into the interface-obj, and not keeping per-neighbour stats. babel-exp-{m,u}cast-hello-seqno: the use of 0 for undefined is not a good idea, since 0 is a perfectly valid seqno. babel-ucast-hello-seqno: what's the value when the implementation is not sending unicast hellos? babel-cost: this is written in a different style. I suggest something like "the link cost, as computed from...". # Section 3.6 See above. I suggest moving this into the interface-stats object, and only keeping aggregate statistics. # Section 3.7 babel-route-router-id: suggst "the router-id of the router that originated this route". # Section 3.9 babel-key-use-{sign, verify}: good idea, I'll add this to the implementation. babel-hmac-test: why non-empty? From nobody Tue Aug 6 13:10:34 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 9C619120223 for ; Tue, 6 Aug 2019 13:10:32 -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 9K0GRPKPvyEY for ; Tue, 6 Aug 2019 13:10:31 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6B11200D8 for ; Tue, 6 Aug 2019 13:10:30 -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 x76KANUk014700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Aug 2019 22:10:23 +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 x76KANDv020403; Tue, 6 Aug 2019 22:10:23 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 789354BF29; Tue, 6 Aug 2019 22:10:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id kEaZXp8sOWnE; Tue, 6 Aug 2019 22:10:25 +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 DF75D4BF26; Tue, 6 Aug 2019 22:10:24 +0200 (CEST) Date: Tue, 06 Aug 2019 22:10:24 +0200 Message-ID: <874l2uawcv.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'babel@ietf.org'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E254159@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <156496962402.26572.16204290795859744323@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114E254159@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 06 Aug 2019 22:10:23 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 06 Aug 2019 22:10:24 +0200 (CEST) X-Miltered: at korolev with ID 5D49DEAF.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D49DEAF.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D49DEAF.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D49DEAF.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 : 5D49DEAF.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D49DEAF.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-08.txt 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, 06 Aug 2019 20:10:33 -0000 Sections 3.1 and 3.3 -- please remove the hmac-algorithm. The algorithm is a property of a key, not of an interface. There's no need to specify the algo here, it is determined by the set of configured keys. (And it is quite legal to use keys with different algos on the same interface, for example when transitioning from one algorithm to a different one.) The second point is something we've discussed before. The implementation has the interface point at the set of keys; in the model, the key set points at the interface. Is the discrepancy intentional? -- Juliusz From nobody Tue Aug 6 13:12:36 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 AB29A1200D8 for ; Tue, 6 Aug 2019 13:12:34 -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 lxbytMiK3Chz for ; Tue, 6 Aug 2019 13:12:32 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 B0D8912013C for ; Tue, 6 Aug 2019 13:12:31 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id i189so42105862pfg.10 for ; Tue, 06 Aug 2019 13:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3ejT12++IpMoML0bkXG89QkZPDDt0ankcMlbTdZxeVM=; b=nRTwV7elAg14iu7KPPzK1ezkjIdGP/vr1yD+GSTzKStDrAKotxQNKoUU1E8c8EUeFg EdDg9FmkxM8I3sycJbk6zD+F0OUcfvAVjN9vGvJ05LFaX3gKg1NMngSKxj50nb23fqFa 9XKaq3gjMbwCt+HIEjBbYKPAz6L7Mdf6oFGVGPPaAJel+4s0vFml/AQYaGFR8H0OVlar j6MYydjtX+H42Qy9gioN4UDsVLHJspEQQJuB2uCz0nE6AKGJeJrncgCBdLwZyEtugKmU Xnf9rqWmQgl0YM0Xv9GUW+yAY/6kA08cE8n5DgU3ze5gLfdlT4vK039HcQm8ErYOA9cF dF3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=3ejT12++IpMoML0bkXG89QkZPDDt0ankcMlbTdZxeVM=; b=WXNz0FCEH5a7vn/Z2S2CZe3aVMrA/bM0PhLD3v7UCCBwQE5fZFNvnr2QPHT7SJSDM5 TJmH5/lYm6ySEAA1cl0IplRV00edzVD2sTFKMpPzI4uFiEjTNj4XO7bNjOHopEFN3zNf qU8f4ui1d9P4HE7ebrO+2ntFoZWAjVvaZAgLhUpCe4Aqo1ubjMsUrHnWvD1Fya56fVSJ hH6N0oGX8cNFN+y2/8y8xgpnVPLxgDmwrzuH2481abblOteGVAkNF5rqJEV/8SUCmSyJ R3XvPVYqTQRZCL0Rv0vP/2qcqxWd8mIm0J2+k0Lnxy4rMeqfieXskT1k7lRlNRl0CH8q UOYQ== X-Gm-Message-State: APjAAAXc2EDayXiGL+4/b0h8PfW2utYQyt76H0J+XrE9TaGA8zYRHQno rJIC7pCjEJGJkpIVO+XIg04= X-Google-Smtp-Source: APXvYqxMyHCbnMSPqhbI9x/2FpN629M/tXoo8Nfowt9nEV0ev4MBokczNoyOw4gd2LX+OCMj9vDg8Q== X-Received: by 2002:a65:53cb:: with SMTP id z11mr4182907pgr.200.1565122351114; Tue, 06 Aug 2019 13:12:31 -0700 (PDT) Received: from [10.33.122.240] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id p65sm87858498pfp.58.2019.08.06.13.12.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Aug 2019 13:12:29 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3872FF85-787C-4BF5-A48B-92BBFC43D21F" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 6 Aug 2019 13:12:29 -0700 In-Reply-To: <877e7qaxte.wl-jch@irif.fr> Cc: Babel at IETF To: Juliusz Chroboczek References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Example configuration 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, 06 Aug 2019 20:12:35 -0000 --Apple-Mail=_3872FF85-787C-4BF5-A48B-92BBFC43D21F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 6, 2019, at 12:38 PM, Juliusz Chroboczek wrote: >=20 >>> Here's a slightly less minimal configuration: >>>=20 >>> interface eth0 >>> interface eth1 type wireless >>> interface tun0 type tunnel >=20 > [...] >=20 >>> This is equivalent to the following: >>>=20 >>> interface eth0 >>> interface eth1 link-quality true split-horizon false >>> interface tun0 enable-timestamps true max-rtt-penalty 96 >=20 >> The XML encoding of the above example can be found in >> example-babel-configuration-2.5.xml. You will notice that eth1 type = is >> set to =E2=80=98wireless=E2=80=99 using =E2=80=98link-properties=E2=80=99= . Same for tun0 and =E2=80=98tunnel=E2=80=99. >=20 > Hmm. Draft-ietf-babel-information-model-08 removes the interface = type, > and uses the underlying properties instead. Shouldn't the YANG model = do > the same, or is there some reason why the YANG model should be using > interface types instead? I am still playing catchup with -08 changes in the information model. I am also not clear on the underlying properties. If the interface is = eth1, its underlying property will be of a wired 802.3 like interface. I = thought the whole idea of specifying the type was an indication that = eth1 is an Ethernet bridged to a wireless radio. How would you derive a = =E2=80=98wireless=E2=80=99 like information from the underlying = property? >=20 >>> interface eth0 >>> interface ppp0 hello-interval 30 update-interval 120 >>> in if ppp0 metric 1024 >>> out if ppp0 metric 1024 >=20 >> Here is where I am stuck. Currently, there is >> a babel-mcast-hello-interval parameter defined in the information = model >> under the interface. But this a read-only attribute, meaning it is >> a operational value, not a configuration value. >=20 > It should be configurable. Just to confirm. Both babel-mcast-hello-interval and = babel-update-interval need to be read-write (configurable) properties. >=20 >> There is no unicast hello interval, which is what I am assuming you = mean >> above. >=20 > No, I mean the multicast interval. >=20 >> Also, there is no metric configuration on an interface today. = Certainly >> not based on in and out traffic. >=20 > The metric configuration is not attached to the interface, it's a = filter. > Filters are a separate kind of entity, and need not contain an = interface > entry. For example, one may say >=20 > in ip 10.0.0.0/8 metric 128 >=20 > in which case the filter applies to all routes with a destination in = 10/8. In other words, a global configuration that applies across all routes = with that destination. I am not aware of any way to do this with our = current information model. We are looking at an addition to the = information model. In summary, we are looking at the following changes to the information = model that will then be followed by updates in the YANG model. Change babel-mcast-hello-interval and babel-update-interval to rw = property. Add global level filter capability Add a way to mark an interface for unicast-preferred (please feel free = to suggest a better name), and unicast-only as boolean configurable = properties. Add a capability to specify a link-local address for a neighbor. And whatever comes out of the discussion around underlying property of = an interface. Thanks >=20 > -- Juliusz Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_3872FF85-787C-4BF5-A48B-92BBFC43D21F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 6, 2019, at 12:38 PM, Juliusz Chroboczek <jch@irif.fr> = wrote:

Here's a slightly less minimal configuration:
interface eth0
interface eth1 type wireless
interface tun0 type tunnel

[...]

This is equivalent to the following:

interface eth0
interface eth1 = link-quality true split-horizon false
interface tun0 = enable-timestamps true max-rtt-penalty 96

The XML encoding of the above example can be = found in
example-babel-configuration-2.5.xml. You will = notice that eth1 type is
set to =E2=80=98wireless=E2=80=99 = using =E2=80=98link-properties=E2=80=99. Same for tun0 and = =E2=80=98tunnel=E2=80=99.

Hmm. =  Draft-ietf-babel-information-model-08 removes the interface = type,
and uses the underlying properties instead. =  Shouldn't the YANG model do
the same, or is there = some reason why the YANG model should be using
interface = types instead?

I am still playing catchup with -08 changes in the = information model.

I am also not = clear on the underlying properties. If the interface is eth1, its = underlying property will be of a wired 802.3 like interface. I thought = the whole idea of specifying the type was an indication that eth1 is an = Ethernet bridged to a wireless radio. How would you derive a = =E2=80=98wireless=E2=80=99 like information from the underlying = property?


interface = eth0
interface ppp0 hello-interval 30 update-interval = 120
in if ppp0 metric 1024
out if ppp0 = metric 1024

Here is where I am = stuck. Currently, there is
a babel-mcast-hello-interval = parameter defined in the information model
under the = interface. But this a read-only attribute, meaning it is
a = operational value, not a configuration value.

It should be configurable.

Just to = confirm. Both babel-mcast-hello-interval and babel-update-interval need = to be read-write (configurable) properties.


There is = no unicast hello interval, which is what I am assuming you mean
above.

No, I mean = the multicast interval.

Also, there is no metric configuration on an = interface today. Certainly
not based on in and out = traffic.

The metric = configuration is not attached to the interface, it's a filter.
Filters are a separate kind of entity, and need not contain = an interface
entry.  For example, one may say

 in ip 10.0.0.0/8 metric 128

in which case the filter applies to all routes = with a destination in 10/8.

In other = words, a global configuration that applies across all routes with that = destination. I am not aware of any way to do this with our current = information model. We are looking at an addition to the information = model.

In summary, we are looking at = the following changes to the information model that will then be = followed by updates in the YANG model.

  • Change = babel-mcast-hello-interval and babel-update-interval to rw = property.
  • Add global level filter capability
  • Add a way to mark an interface for unicast-preferred (please = feel free to suggest a better name), and unicast-only as boolean = configurable properties.
  • Add a capability to specify = a link-local address for a neighbor.
  • And whatever = comes out of the discussion around underlying property of an = interface.

Thanks


-- Juliusz

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_3872FF85-787C-4BF5-A48B-92BBFC43D21F-- From nobody Tue Aug 6 14:31: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 A6786120033 for ; Tue, 6 Aug 2019 14:31:22 -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 guxLD05SMXFM for ; Tue, 6 Aug 2019 14:31:20 -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 13A76120025 for ; Tue, 6 Aug 2019 14:31:19 -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 x76LVEbe025747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Aug 2019 23:31:14 +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 x76LVE0H029429; Tue, 6 Aug 2019 23:31:14 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 972B44C22A; Tue, 6 Aug 2019 23:31:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id vb9spdCEB3u3; Tue, 6 Aug 2019 23:31:16 +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 089724C227; Tue, 6 Aug 2019 23:31:14 +0200 (CEST) Date: Tue, 06 Aug 2019 23:31:13 +0200 Message-ID: <8736ieasm6.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mahesh Jethanandani Cc: Babel at IETF In-Reply-To: <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 06 Aug 2019 23:31:14 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 06 Aug 2019 23:31:15 +0200 (CEST) X-Miltered: at korolev with ID 5D49F1A2.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D49F1A2.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D49F1A2.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D49F1A2.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 : 5D49F1A2.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D49F1A2.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Example configuration 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, 06 Aug 2019 21:31:23 -0000 > I am also not clear on the underlying properties. If the interface is eth1, > its underlying property will be of a wired 802.3 like interface. I thought the > whole idea of specifying the type was an indication that eth1 is an Ethernet > bridged to a wireless radio. How would you derive a ‘wireless’ like > information from the underlying property? The protocol doesn't know about interface types. From the point of view of the protocol, there are a number of algorithms that can optionally be selected or enabled on a given interface. These include: - link-quality estimation (2-out-of-3 or ETX); - split-horizon (on or off); - RTT estimation (draft-ietf-babel-rtt); - use of unicast instead of multicast; - ... The choice of parameters requires intimate knowledge of the protocol and the implementation. For that reason, the babeld implementation packages useful combinations within the interface type parameter "type wired" is a shortcut for "link-quality 2-out-of-3 split-horizon true" "type wireless" is a shortcut for "link-quality etc split-horizon false" "type tunnel" is a shortcut for "link-quality 2-out-of-3 max-rtt-penalty 96" However, other combinations are possible, and some of them are actually useful -- "link-quality 2-out-of-3 split-horizon false" makes perfect sense for an NBMA network. Therefore, the interface type cannot in general be synthesized from the configuration parameters of the interface. So what's the information model to do? My opinion is to consider the interface type as a UI issue, and put the underlying parameters in the information model, which is what Barbara has implemented in -08. Other solutions are possible, of course, and I'm quite open to considering them if someone has a plan. > Just to confirm. Both babel-mcast-hello-interval and babel-update-interval > need to be read-write (configurable) properties. Aye. > Filters are a separate kind of entity, and need not contain an interface > entry. For example, one may say > in ip 10.0.0.0/8 metric 128 > in which case the filter applies to all routes with a destination in 10/8. > In other words, a global configuration that applies across all routes with > that destination. I am not aware of any way to do this with our current > information model. We are looking at an addition to the information model. Here's what other YANG models do: - the RIP YANG model ignores filtering, although most RIP implementations support it; - the BGP YANG model imports draft-ietf-rtgwg-policy-model. I suggest we follow the lead of RIP, and consider filtering as out of scope for the YANG model. Filtering is a complex beast, it tends to grow over time (it's the cleanest place to add implementation-specific hooks), and I don't think we have the manpower to do a good job. > * Change babel-mcast-hello-interval and babel-update-interval to rw property. Yes. > * Add global level filter capability Not necessarily. See above. > * Add a way to mark an interface for unicast-preferred (please feel free to > suggest a better name), and unicast-only as boolean configurable properties. Babeld calles the former simply "unicast". The latter is not implemented yet, so please don't define it yet, it might never happen. > * Add a capability to specify a link-local address for a neighbor. Not quite -- it's about defining a static neighbour for unicast-only operation. Again, it might never happen. -- Juliusz From nobody Tue Aug 6 16:58:28 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 88D3712009C for ; Tue, 6 Aug 2019 16:58:26 -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 T1OyEnrwXlHq for ; Tue, 6 Aug 2019 16:58:24 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30C112008B for ; Tue, 6 Aug 2019 16:58:23 -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 x76NwCnb013566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Aug 2019 01:58:12 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x76NwCE4012680; Wed, 7 Aug 2019 01:58:12 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 77FDB4C589; Wed, 7 Aug 2019 01:58:15 +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 3IWm0Tg_72DD; Wed, 7 Aug 2019 01:58:14 +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 AA0054C586; Wed, 7 Aug 2019 01:58:11 +0200 (CEST) Date: Wed, 07 Aug 2019 01:58:11 +0200 Message-ID: <87y305alt8.wl-jch@irif.fr> From: Juliusz Chroboczek To: Henning Rogge Cc: "Yemin (Amy)" , antonin.decimo@gmail.com, dschinazi.ietf@gmail.com, Martin Vigoureux , =?ISO-8859-1?Q?LucAndr=E9?= Burdet , babel@ietf.org In-Reply-To: References: <156105440578.3118.4917846383408119793.idtracker@ietfa.amsl.com> <9C5FD3EFA72E1740A3D41BADDE0B461FCFC76069@DGGEMM528-MBX.china.huawei.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]); Wed, 07 Aug 2019 01:58:13 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 07 Aug 2019 01:58:13 +0200 (CEST) X-Miltered: at korolev with ID 5D4A1414.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D4A1414.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4A1414.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D4A1414.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 : 5D4A1414.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D4A1414.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] rtgdir Last Call Review requested: draft-ietf-babel-dtls 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, 06 Aug 2019 23:58:27 -0000 Hi Henning, Good to hear from you again. The two main authors of this draft appear to be on holiday, so I'll answer your review to the best of my capacities. > Chapter 2.3: > I wonder if using DTLS protected unicast Hellos should be mandatory... > using unprotected multicast to determine bidirectional reachability > looks like a good way to do a cheap denial ofa service attack. In Babel, bidirectional reachability is established by a Hello/IHU exchange. This document requires IHUs to be authenticated, therefore bidirectional reachability will never be established with an attacker. However, this doesn't prevent DoS attacks: - an attacker could send cleartext Hellos from spoofed addresses, thus causing the victim to create unbounded numbers of neighbour entries; - an attacker could send DTLS ClientHello packets from spoofed addresses, with a similar effect. Requiring an authenticated Hello is not workable, since an authenticated Hello cannot be sent until after the DTLS handshake has completed. This is somewhat mitigated by the fact that only packets from link-local addresses are accepted (see Section 2.1 of this draft and Section 4 of RFC 6126bis). This is what the draft has to say on the subject (Section 5): A malicious client might attempt to perform a high number of DTLS handshakes with a server. As the clients are not uniquely identified by the protocol and can be obfuscated with IPv6 temporary addresses, a server needs to mitigate the impact of such an attack. Such mitigation might involve rate limiting handshakes from a given subnet or more advanced denial of service avoidance techniques beyond the scope of this document. I'm not happy with this either. > Chapter 2.5: > What happens when a node starts a new DTLS connection and there is > already one in the neighbor table? This could both be an attempt to > attack Babel, a reboot of a node or just a matter of misconfiguration > of two nodes. Section 2.1: If a node receives a new DTLS connection from a neighbour to whom it already has a connection, the node MUST NOT discard the older connection until it has completed the handshake of the new one and validated the identity of the peer. > Chapter 3: > Different pairs of nodes could select different ciphers, resulting in > different MTUs. I assume this is no problem for Babel (could be > mentioned in the chapter). I am not competent to answer this, we'll need to wait for David or Antonin to resurface. > Some of the design decisions of regarding the three questions could be > mentioned in chapter 5 (Security Implications). David? Antonin? -- Juliusz From nobody Tue Aug 6 17:19:46 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 26E5C1200B1 for ; Tue, 6 Aug 2019 17:19:45 -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 rlwwGKZYaHcR for ; Tue, 6 Aug 2019 17:19:42 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0: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 5989912009C for ; Tue, 6 Aug 2019 17:19:42 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id m30so42417622pff.8 for ; Tue, 06 Aug 2019 17:19:42 -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=zdGs+817Ban5qDlhjKlB0v5kzyjikGa01rYEVhci8h0=; b=LL3EHHoaUdUgnkh3G2KGaUoYX4+48ebg3F3Z9mdDBshdL8GEhKku3hoHfPKgGO/MSv cRbqvlMrUa7dGcQnNdKwizTu9rgkmASLBAj9oHQuu+w7YMC3XqmECXWHP1i5jMWcB+hT rany6wgBuPVAypfhSC+BP+TxEVI4MFYi0F0djSGLNukg7VNMtNqy3Oo5gCkwEjovG/YG 84CVi9KGvTDDuUrK1loCrl8H0hfHh4p3YZPKrnFUKyBw9goGKOAwejyosqk/Fit7J4f/ Vzn/MBFmaHW82w1Iai0s7+LBvoYOG+milspK0WQ2r9LHnHPqTIi8i+3fxhB7JVz4+tz1 OROg== 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=zdGs+817Ban5qDlhjKlB0v5kzyjikGa01rYEVhci8h0=; b=Mz+jxh/4Pp+XW5lhI6QEnMNKQxRVva6AYiWEAxVCK/DYoAz9pUxRVE7jbhx3cgzQuI 1NXWAD+wNnoBLUWr64caLOlLH45Jw7/bh4RPs/eFfTDb1dCjCzLLA06Em4VcKZbCMMLN aIUkINkfEW2x8GL94TFIXD7OhcuiJK7RLmRO5Co/nrD5f/aZKszJHxiyXJAxSeUX3Zx0 bNHIfIf7BQ+GYquIYG9h11qbNG4pilMEGkTIe6ChPKekVSvzDe0ntLmJdpclZQKdTrrP qZg3ctKMvL67F9PE+BSWKusnvvBV9Kjt1ainaVk4Q4XDHLGutVLwO+D+D9EHoJZztpxD ORxA== X-Gm-Message-State: APjAAAV7hslSYCijFJ+TYs6a9GzwqNILXgHDsezzP8+6UejaeJpKdwvD 2LM5PZTzkGv0K2K4WSFV3ug= X-Google-Smtp-Source: APXvYqwF5zeJWTTND2MK+oIPnfM1JjEiMkAZvvKI8AEgsgD/Ur+Zi50JIjg1XuL0gP1ezg9ZqERj4g== X-Received: by 2002:aa7:9786:: with SMTP id o6mr6293014pfp.222.1565137181755; Tue, 06 Aug 2019 17:19:41 -0700 (PDT) Received: from [10.33.122.240] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id v10sm87114093pfe.163.2019.08.06.17.19.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Aug 2019 17:19:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mahesh Jethanandani In-Reply-To: <8736ieasm6.wl-jch@irif.fr> Date: Tue, 6 Aug 2019 17:19:39 -0700 Cc: Babel at IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Example configuration 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: Wed, 07 Aug 2019 00:19:45 -0000 > On Aug 6, 2019, at 2:31 PM, Juliusz Chroboczek wrote: >=20 >> I am also not clear on the underlying properties. If the interface is = eth1, >> its underlying property will be of a wired 802.3 like interface. I = thought the >> whole idea of specifying the type was an indication that eth1 is an = Ethernet >> bridged to a wireless radio. How would you derive a =E2=80=98wireless=E2= =80=99 like >> information from the underlying property? >=20 > The protocol doesn't know about interface types. =46rom the point of = view > of the protocol, there are a number of algorithms that can optionally = be > selected or enabled on a given interface. These include: >=20 > - link-quality estimation (2-out-of-3 or ETX); > - split-horizon (on or off); > - RTT estimation (draft-ietf-babel-rtt); > - use of unicast instead of multicast; > - ... >=20 > The choice of parameters requires intimate knowledge of the protocol = and > the implementation. For that reason, the babeld implementation = packages > useful combinations within the interface type parameter >=20 > "type wired" is a shortcut for "link-quality 2-out-of-3 split-horizon = true" > "type wireless" is a shortcut for "link-quality etc split-horizon = false" > "type tunnel" is a shortcut for "link-quality 2-out-of-3 = max-rtt-penalty 96" >=20 > However, other combinations are possible, and some of them are = actually > useful -- "link-quality 2-out-of-3 split-horizon false" makes perfect > sense for an NBMA network. Therefore, the interface type cannot in > general be synthesized from the configuration parameters of the = interface. >=20 > So what's the information model to do? My opinion is to consider the > interface type as a UI issue, and put the underlying parameters in the > information model, which is what Barbara has implemented in -08. = Other > solutions are possible, of course, and I'm quite open to considering = them > if someone has a plan. In -08 version of the draft, all references to wired, wireless, tunnel = and others are gone. That in addition to babel-link-properties. If they = are underlying parameters, they are truly invisible :-). That means = there is no way to specify most of the link properties that you describe = above, with the exception of split-horizon, which is lone link property = under babel-interace-obj. I understand that it is difficult for an operator without intimate = knowledge to know how to configure these properties. And that is why = these should be optional properties. However, without them, there is no = way for an operator to influence how the protocol works.=20 My suggestion would be that the link properties be moved into an obj of = their own, something like a list of babel-link-properties-obj. We can = document the examples you have above. They do not have to be specified = by default. Operators that do want to, can define any combination of = link properties, like you do above with wired, wireless and tunnel. They = can call them whatever they want. One item in this list in then = referenced by the babel-interface-obj which tells it which link = properties if any have been specified for that interface. Something like = this: object { =E2=80=A6. [babel-link-properties rw babel-link-properties<0..*>;] } babel-information-obj; object { [reference rw babel-link-properties;] =E2=80=A6.. } babel-interface-obj; object { string rw name; [string rw babel-link-quality;] [boolean rw babel-split-horizon;] [uint rw babel-max-rtt-penalty;] [boolean rw babel-unicast;] } babel-link-properties; Tomorrow, if we want to add more properties, the babel-link-properties = obj can be extended.=20 >=20 >> Just to confirm. Both babel-mcast-hello-interval and = babel-update-interval >> need to be read-write (configurable) properties. >=20 > Aye. >=20 >> Filters are a separate kind of entity, and need not contain an = interface >> entry. For example, one may say >=20 >> in ip 10.0.0.0/8 metric 128 >=20 >> in which case the filter applies to all routes with a destination = in 10/8. >=20 >> In other words, a global configuration that applies across all routes = with >> that destination. I am not aware of any way to do this with our = current >> information model. We are looking at an addition to the information = model. >=20 > Here's what other YANG models do: >=20 > - the RIP YANG model ignores filtering, although most RIP > implementations support it; > - the BGP YANG model imports draft-ietf-rtgwg-policy-model. Ok. Let me follow up on the separate e-mail thread that you started with = describing Babel filtering and routing policies. If it becomes too = complex, we can drop it. Thanks. >=20 > I suggest we follow the lead of RIP, and consider filtering as out of > scope for the YANG model. Filtering is a complex beast, it tends to = grow > over time (it's the cleanest place to add implementation-specific = hooks), > and I don't think we have the manpower to do a good job. >=20 >> * Change babel-mcast-hello-interval and babel-update-interval to rw = property. >=20 > Yes. >=20 >> * Add global level filter capability >=20 > Not necessarily. See above. >=20 >> * Add a way to mark an interface for unicast-preferred (please feel = free to >> suggest a better name), and unicast-only as boolean configurable = properties. >=20 > Babeld calles the former simply "unicast". The latter is not = implemented > yet, so please don't define it yet, it might never happen. >=20 >> * Add a capability to specify a link-local address for a neighbor. >=20 > Not quite -- it's about defining a static neighbour for unicast-only > operation. Again, it might never happen. >=20 > -- Juliusz Mahesh Jethanandani mjethanandani@gmail.com From nobody Tue Aug 6 18:00: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 22C1D1200B2 for ; Tue, 6 Aug 2019 18:00:38 -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 RgnffJekoAyH for ; Tue, 6 Aug 2019 18:00:36 -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 12D5E1200B1 for ; Tue, 6 Aug 2019 18:00:35 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7710UDF021873; Wed, 7 Aug 2019 03:00:30 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id AE7274C6F8; Wed, 7 Aug 2019 03:00:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 4EjyrRQffULt; Wed, 7 Aug 2019 03:00:28 +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 4FBEE4C6F3; Wed, 7 Aug 2019 03:00:26 +0200 (CEST) Date: Wed, 07 Aug 2019 03:00:26 +0200 Message-ID: <87pnlhaixh.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mahesh Jethanandani Cc: Babel at IETF In-Reply-To: References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.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 [194.254.61.138]); Wed, 07 Aug 2019 03:00:30 +0200 (CEST) X-Miltered: at korolev with ID 5D4A22AE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4A22AE.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 : 5D4A22AE.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] Example configuration 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: Wed, 07 Aug 2019 01:00:38 -0000 >> The protocol doesn't know about interface types. From the point of view >> of the protocol, there are a number of algorithms that can optionally be >> selected or enabled on a given interface. These include: >> >> - link-quality estimation (2-out-of-3 or ETX); >> - split-horizon (on or off); >> - RTT estimation (draft-ietf-babel-rtt); >> - use of unicast instead of multicast; >> - ... > In -08 version of the draft, all references to wired, wireless, tunnel > and others are gone. That in addition to babel-link-properties. If they > are underlying parameters, they are truly invisible :-). Wired, wireless etc. are the UI interface types. The underlying properties are link-quality and split-horizon (in RFC 6126bis) and the RTT estimation parameters (in draft-ietf-babel-rtt). > I understand that it is difficult for an operatori without intimate > knowledge to know how to configure these properties. And that is why > these should be optional properties. However, without them, there is no > way for an operator to influence how the protocol works. I think we're not understanding each other. I am not arguing about hiding any information, quite the opposite, I am in favour of exporting the underlying properties and leaving the link type to the UI. >> I don't think we have the manpower to do a good job. > Ok. Let me follow up on the separate e-mail thread that you started with > describing Babel filtering and routing policies. If it becomes too > complex, we can drop it. Sure, but please keep my comment about manpower in mind. -- Juliusz From nobody Tue Aug 6 18:14:58 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 A167A1200B1; Tue, 6 Aug 2019 18:14:56 -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.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156514049658.27311.12378992512555336869@ietfa.amsl.com> Date: Tue, 06 Aug 2019 18:14:56 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-rfc6126bis-12.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: Wed, 07 Aug 2019 01:14:57 -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-12.txt Pages : 61 Date : 2019-08-06 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-12 https://datatracker.ietf.org/doc/html/draft-ietf-babel-rfc6126bis-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-rfc6126bis-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 6 18:19:08 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 0938A12009C; Tue, 6 Aug 2019 18:19:00 -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.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156514073999.27352.16336152206620509060@ietfa.amsl.com> Date: Tue, 06 Aug 2019 18:19:00 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-applicability-09.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: Wed, 07 Aug 2019 01:19:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : Applicability of the Babel routing protocol Author : Juliusz Chroboczek Filename : draft-ietf-babel-applicability-09.txt Pages : 11 Date : 2019-08-06 Abstract: Babel is a routing protocol based on the distance-vector algorithm augmented with mechanisms for loop avoidance and starvation avoidance. This document describes a number of niches where Babel has been found to be useful and that are arguably not adequately served by more mature protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-applicability/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-applicability-09 https://datatracker.ietf.org/doc/html/draft-ietf-babel-applicability-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-applicability-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 6 23:46: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 9A1B21200E3; Tue, 6 Aug 2019 23:45:59 -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 yISxyR5-Vu3o; Tue, 6 Aug 2019 23:45:57 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 D452B120024; Tue, 6 Aug 2019 23:45:56 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id r6so100112373oti.3; Tue, 06 Aug 2019 23:45:56 -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=juMrup7X4/43AuDwHiVR1pEY6Uom+G14WWMUMY6pHlE=; b=gknRRW+St/9efxHkFP+JLhPpsQCSXoln9OiORd6JMii6CyaPMeV378cb4eUFVk+q5Z FUycMmUL4V3q5yYoKd/2pLV9mafCuw6aWj06lUyrfoPEfWw4YyXew0X4pCmDmVHn0yx0 usrT83sFmDf0Dq71iqjodE118yEV45M1gj3OGYC/Vh5HwUGNYpuwCet6vP6K04O0jqk0 Qs3Fex+dPeyZWT9HF2JMYu8eiPcoIjdTxc2dyVybIS/NWdkUo3H23TcIuRNsKqse22fV A8v4Q5WGqaHzNSSusnjahYuZEssm1Y2u1v/iMQKervhwtaQvgr+VD4v67Jh8739sv0Uz esxA== 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=juMrup7X4/43AuDwHiVR1pEY6Uom+G14WWMUMY6pHlE=; b=iZ9i8bGnYYP2LtfRRE6gpaoNol/BNaV24RB39Rym9GLfM6ZuUCiJ21wMM8ZY5AZaT0 O/jJg+36nhxp7jaQpwwXMFae5wby1Pg5QlqHW9XP1Qt3tyYSjYUuVrUACyPKv/v4IoQu UuL9SRZWR1bTvX4jr/mey2dRhDoaSUw7Y4vuZWTlaq+bYPZ94BZ24LKE+KnsSBYWrjxx ppJclOJFKboOK4+ZwGe639Y+pSP8c5OzuWnzt8m8sDnsx3gj5wqMmqFX3qGk4ADUIggD dLOiOG0r8se1OwbNR8Au2+UOOa4ImBn4RGwTrqaJ86F8dbHCEjtf/muSuDuDeBIrmuTR pF6A== X-Gm-Message-State: APjAAAXoyANAxUhkiqqAqDn4RgtRfgb+lf1qVr4Hg7Kn4FAZKJKi/KRn F2uNdxng8Yk1dW7g3NXm9Ni/Fxy0lWcZZCQ3Ag== X-Google-Smtp-Source: APXvYqwKc/bDPKUKEy3f/hfDbT6Tp6Gq3PxulP9FHCGTs4alXebRVzEBQOybSstQwHY7EUquSG4dMCmAfzxWf6uvMN0= X-Received: by 2002:a02:22c6:: with SMTP id o189mr8413474jao.35.1565160356134; Tue, 06 Aug 2019 23:45:56 -0700 (PDT) MIME-Version: 1.0 References: <156470236376.19191.1026181661457374790@ietfa.amsl.com> <87o918ou5d.wl-jch@irif.fr> In-Reply-To: <87o918ou5d.wl-jch@irif.fr> From: Yingzhen Qu Date: Tue, 6 Aug 2019 23:44:53 -0700 Message-ID: To: Juliusz Chroboczek Cc: rtg-dir@ietf.org, draft-ietf-babel-rfc6126bis.all@ietf.org, ietf@ietf.org, babel@ietf.org Content-Type: multipart/alternative; boundary="0000000000000b4511058f814b11" Archived-At: Subject: Re: [babel] Rtgdir telechat review of draft-ietf-babel-rfc6126bis-11 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: Wed, 07 Aug 2019 06:46:00 -0000 --0000000000000b4511058f814b11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Juliusz, Thanks for your reply, please see my response below starting with [YQ]. Thanks, Yingzhen On Fri, Aug 2, 2019 at 1:20 AM Juliusz Chroboczek wrote: > Dear Mr Qu, > > Thank you for your review. > > > The description about packet trailer is in RFC 7557 section 2.5, but no= t > > included in the bis version. Considering this document will obsolete RF= C > 7557, > > I suppose it should be self-complete, so readers don=E2=80=99t need to = go back > to RFC > > 7557 for more information. > > The packet trailer is described in Section 4.2. > > [YQ]: In RFC 7557 section 2.5, there is a clear description about how the packet trailer length is calculated etc. Personally I feel it's more straightforward, but if you think section 4.2 is enough, I'm not going to insist. > > There are multiple places in the document about TLV/Sub-TLV being > > =E2=80=9Cself-terminating=E2=80=9D, but I didn=E2=80=99t find what it m= eans. Maybe I=E2=80=99m missing > > something here? > > This is defined in Section 4.4. I have checked that all uses of > self-terminating occur after its definition. > > [YQ]: in section 4.4, it says self-terminating can be used to determine the length of the TLV body without using the length field. This is clear, however what does it look like? how to detect it? maybe I'm missing something here. > > Section 1.1 > > =E2=80=9Cunmanaged and wireless environment=E2=80=9D, what does =E2=80= =9Cunmanaged=E2=80=9D mean here? > > Not being actively managed by a human administrator. This is a > non-normative > section. Please let me know if I'm using this term badly. > > [YQ]: my understanding is unmanaged can mean anything, like no management at all. I don't think it's a good term, especially put together with wireless. maybe try to add a bit more explanation? > Section 3.2.3 > > The interface Hello seqno is changed to outing multicast hello seqno, > however > > there is no description about unicast hello at all. > > Unicast Hellos are per-neighbour, so they appear in Section 3.2.4 (Sectio= n > 3.2.3 describes per-interface data structure while 3.2.4 describes > per-neighbour structures). Both kinds of Hellos are described in more > detail in Section 3.4.1. > [YQ]: there is nothing wrong with current text. I was thinking of adding unicast just for easy readability. same for the following three related questions. > > > While I was reading it, I kept thinking what if it=E2=80=99s unicast he= llo? Is > > there a unicast hello timer needed? > > There is one, see Section 3.2.4, penultimate paragraph. > > > From later sections, I realized there are unicast hellos. So I=E2=80=99= d suggest > > add some descriptions to avoid the confusion. > > Sections 3.2.4 and 3.4.1. > > > Section 3.2.4 > > There is =E2=80=9Cthe expected incoming Unicast Hello sequence number= =E2=80=9D and =E2=80=9Cthe > > outgoing Unicast Hello sequence number=E2=80=9D, but it was not mention= ed in > section > > 3.2.3 (related with previous comment). > > That's right. Section 3.2.3 describes per-interface data. Section 3.2.4 > describes per-neighbour data. Multicast Hellos are per-interface. > Unicast Hellos are per-neighbour. > > > Section 3.8.1.1 > > After a node receives a route request, if the given prefix doesn=E2=80= =99t exist > in its > > route table, it MUST send a retraction for that prefix. So my question = is > > whether a node is allowed to send multiple explicit requests for a give= n > > prefix? > > There's nothing forbidding it. It may send multiple requests to differen= t > neighbours (over unicast), or multiple requests on different interfaces > (over multicast). There's also nothing forbidding a node from sending > multiple requests to the same destination, e.g. to compensate for packet > loss. > > (Our implementation experience shows that, at least over 802.11, such > aggressive behaviour is not useful, it increases noise without having > a measurable effect on convergence time, hence the SHOULD in Section > 3.8.2.3 which only requires a single request. However, further research > might yield new insights, which is why this document does not explicitly > disallow such behaviour.) > > [YQ] thanks for the explanation. I'm just wondering whether we should document it somewhere? > > If so, what happens if both retractions and updates are received? > > The procedure described in Section 3.5.4 is run for each received update > or retraction, which results in the construction of the data structures > used as input for the precedure described in Section 3.6. > [YQ]: got it. > > 1616 4.4. Sub-TLV Format > > > This section is about Sub-TLV, however the description language in this > > paragraph is mainly about TLV. > > Good catch, thanks. I'll fix that. > [YQ]: same as comments regarding unicast hello, current text is not wrong. > > > Section 4.5 > > it says that =E2=80=9Can implementation may choose to use a dedicated s= tateless > parser > > to parse the packet trailer=E2=80=9D. Will the packet trailer be able t= o use the > state > > parser if there are state there useful or just for implementation > purpose? > > I do not understand this comment. Please clarify. > > [YQ]: My understanding is Babel uses a stateful parser, and TLVs in the packet trailer are not allowed to modify the state. So the text here is suggesting to implement a stateless parser for packet trailer. so the question is: will packet trailer to able to use/read the state? is the stateless parser suggested just for implementation simplicity? > > Although there is no packet trailer defined at this moment. > > Section 4.2. > [YQ]: I meant besides the pad1 and padN, there is no real functional packet trailer defined at this moment, but it's open for extensions. > > > Section 4.5 > > 1674 parsing a TLV MUST update the parser state even if the TLV i= s > > 1675 otherwise ignored due to an unknown mandatory sub-TLV. > > I believe you may have forgotten to write your comment. > > [YQ]: is it correct that the parser state is updated by a TLV even if the TLV is ignored due to unknown sub-tlv? what about a TLV ignored due to other reasons? > Section 4.6.5 > > 1805 send a new scheduled Hello TLV with the same > setting of the > > 1806 Unicast flag. If this is 0, then this Hello > represents an > > I=E2=80=99d suggest changing the text to =E2=80=9Cthe same setting of f= lags=E2=80=9D instead of > =E2=80=9Cthe > > same setting of the Unicast flag=E2=80=9D, considering the flags will b= e > extended later. > > I disagree. This paragraph is about the multicast/unicast dichotomy, not > about future flags of an informative nature. > > [YQ]: then I misunderstood it. I thought it was meant to copy the entire flag field. > Nits: > > > 1049 metric) from a neighbour neigh with a link cost value equal > to cost, > > 1050 it checks whether it already has a route table entry indexed > by > > [neighbour neigh] =3D> [neighbour] > > I disagree. We're defining the variable neigh, which we use in the next > sequence. > > [YQ]: it seems that this is the only place using "neigh", so I thought it was a typo. I would suggest some clarification. > Regards, > > -- Juliusz Chroboczek > --0000000000000b4511058f814b11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Juliusz,

Thanks for your = reply, please see my response below starting with [YQ].

<= /div>
Thanks,
Yingzhen

On Fri, Aug 2, 2019 at 1:20 AM Juliusz = Chroboczek <jch@irif.fr= > wrote:
Dear Mr Qu,

Thank you for your review.

> The description about packet trailer is in RFC 7557 section 2.5, but n= ot
> included in the bis version. Considering this document will obsolete R= FC 7557,
> I suppose it should be self-complete, so readers don=E2=80=99t need to= go back to RFC
> 7557 for more information.

The packet trailer is described in Section 4.2.

[YQ]: In RFC 7557 section 2.5, there is a clear descr= iption about how the packet trailer length is calculated etc. Personally I = feel it's more straightforward, but if you think section 4.2 is enough,= I'm not going to insist.
=C2=A0
> There are multiple places in the document about TLV/Sub-TLV being
> =E2=80=9Cself-terminating=E2=80=9D, but I didn=E2=80=99t find what it = means. Maybe I=E2=80=99m missing
> something here?

This is defined in Section 4.4.=C2=A0 I have checked that all uses of
self-terminating occur after its definition.

[YQ]:= in section 4.4, it says self-terminating can be used to determine the leng= th of the TLV body without using the length field. This is clear, however w= hat does it look like? how to detect it? maybe I'm missing something he= re.
=C2=A0
> Section 1.1
> =E2=80=9Cunmanaged and wireless environment=E2=80=9D, what does =E2=80= =9Cunmanaged=E2=80=9D mean here?

Not being actively managed by a human administrator.=C2=A0 This is a non-no= rmative
section.=C2=A0 Please let me know if I'm using this term badly.

[YQ]: my understanding is unmanaged can mean anything= , like no management at all. I don't think it's a good term, especi= ally put together with wireless. =C2=A0maybe try to add a bit more explanat= ion? =C2=A0

> Section 3.2.3
> The interface Hello seqno is changed to outing multicast hello seqno, = however
> there is no description about unicast hello at all.

Unicast Hellos are per-neighbour, so they appear in Section 3.2.4 (Section<= br> 3.2.3 describes per-interface data structure while 3.2.4 describes
per-neighbour structures).=C2=A0 Both kinds of Hellos are described in more=
detail in Section 3.4.1.
[YQ]: there is nothing wrong = with current text. I was thinking of adding unicast just for easy readabili= ty. same for the following three related questions.

> While I was reading it, I kept thinking what if it=E2=80=99s unicast h= ello? Is
> there a unicast hello timer needed?

There is one, see Section 3.2.4, penultimate paragraph.

> From later sections, I realized there are unicast hellos. So I=E2=80= =99d suggest
> add some descriptions to avoid the confusion.

Sections 3.2.4 and 3.4.1.

> Section 3.2.4
> There is =E2=80=9Cthe expected incoming Unicast Hello sequence number= =E2=80=9D and =E2=80=9Cthe
> outgoing Unicast Hello sequence number=E2=80=9D, but it was not mentio= ned in section
> 3.2.3 (related with previous comment).

That's right.=C2=A0 Section 3.2.3 describes per-interface data.=C2=A0 S= ection 3.2.4
describes per-neighbour data.=C2=A0 Multicast Hellos are per-interface.
Unicast Hellos are per-neighbour.

> Section 3.8.1.1
> After a node receives a route request, if the given prefix doesn=E2=80= =99t exist in its
> route table, it MUST send a retraction for that prefix. So my question= is
> whether a node is allowed to send multiple explicit requests for a giv= en
> prefix?

There's nothing forbidding it.=C2=A0 It may send multiple requests to d= ifferent
neighbours (over unicast), or multiple requests on different interfaces
(over multicast).=C2=A0 There's also nothing forbidding a node from sen= ding
multiple requests to the same destination, e.g. to compensate for packet loss.

(Our implementation experience shows that, at least over 802.11, such
aggressive behaviour is not useful, it increases noise without having
a measurable effect on convergence time, hence the SHOULD in Section
3.8.2.3 which only requires a single request.=C2=A0 However, further resear= ch
might yield new insights, which is why this document does not explicitly disallow such behaviour.)

[YQ] thanks for the explanation. I'm just wonderi= ng whether we should document it somewhere?
=C2=A0
> If so, what happens if both retractions and updates are received?

The procedure described in Section 3.5.4 is run for each received update or retraction, which results in the construction of the data structures
used as input for the precedure described in Section 3.6.
<= div>
[YQ]: got it.
=C2=A0
> 1616=C2=A0 =C2=A0 4.4.=C2=A0 Sub-TLV Format

> This section is about Sub-TLV, however the description language in thi= s
> paragraph is mainly about TLV.

Good catch, thanks.=C2=A0 I'll fix that.
=C2=A0
[YQ]: same as comments regarding unicast hello, current text is not= wrong.

> Section 4.5
> it says that =E2=80=9Can implementation may choose to use a dedicated = stateless parser
> to parse the packet trailer=E2=80=9D. Will the packet trailer be able = to use the state
> parser if there are state there useful or just for implementation purp= ose?

I do not understand this comment.=C2=A0 Please clarify.

[YQ]: My understanding is Babel uses a stateful parse= r, and TLVs in the packet trailer are not allowed to modify the state. So t= he text here is suggesting to implement a stateless parser for packet trail= er. so the question is: will packet trailer to able to use/read the state? = is the stateless parser suggested just for implementation simplicity?
=
=C2=A0=C2=A0
> Although there is no packet trailer defined at this moment.

Section 4.2.
[YQ]: I meant besides the pad1 and padN, = there is no real functional packet trailer defined at this moment, but it&#= 39;s open for extensions.

> Section 4.5
> 1674=C2=A0 =C2=A0 =C2=A0 =C2=A0parsing a TLV MUST update the parser st= ate even if the TLV is
> 1675=C2=A0 =C2=A0 =C2=A0 =C2=A0otherwise ignored due to an unknown man= datory sub-TLV.

I believe you may have forgotten to write your comment.

[YQ]: is it correct that the parser state is updated = by a TLV even if the TLV is ignored due to unknown sub-tlv? what about a TL= V ignored due to other reasons?=C2=A0

> Section 4.6.5
> 1805=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0send= a new scheduled Hello TLV with the same setting of the
> 1806=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Unic= ast flag.=C2=A0 If this is 0, then this Hello represents an
> I=E2=80=99d suggest changing the text to =E2=80=9Cthe same setting of = flags=E2=80=9D instead of =E2=80=9Cthe
> same setting of the Unicast flag=E2=80=9D, considering the flags will = be extended later.

I disagree.=C2=A0 This paragraph is about the multicast/unicast dichotomy, = not
about future flags of an informative nature.

[YQ]: then I misunderstood it. I thought it was meant= to copy the entire flag field.

> Nits:

> 1049=C2=A0 =C2=A0 =C2=A0 =C2=A0metric) from a neighbour neigh with a l= ink cost value equal to cost,
> 1050=C2=A0 =C2=A0 =C2=A0 =C2=A0it checks whether it already has a rout= e table entry indexed by
> [neighbour neigh] =3D> [neighbour]

I disagree.=C2=A0 We're defining the variable neigh, which we use in th= e next
sequence.

[YQ]: it seems that this is the only place using &quo= t;neigh", so I thought it was a typo. I would suggest some clarificati= on.

=C2=A0
Regards,

-- Juliusz Chroboczek
--0000000000000b4511058f814b11-- From nobody Wed Aug 7 02:37: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 91FB4120320; Wed, 7 Aug 2019 02:37:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov via Datatracker To: "The IESG" Cc: draft-ietf-babel-hmac@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alexey Melnikov Message-ID: <156517064359.8374.15633363662249550509.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2019 02:37:23 -0700 Archived-At: Subject: [babel] Alexey Melnikov's No Objection on draft-ietf-babel-hmac-08: (with COMMENT) 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: Wed, 07 Aug 2019 09:37:23 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-babel-hmac-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-hmac/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please mention RFC2104 in section 2 when HMAC is mentioned for the first time. From nobody Wed Aug 7 03:57:10 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 DDB9312068F; Wed, 7 Aug 2019 03:56:59 -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 dJ-FkkyCFRz1; Wed, 7 Aug 2019 03:56:57 -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 8B97D1201E3; Wed, 7 Aug 2019 03:56:57 -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=1565175414; bh=CtaL12aCvMeuKTZNEfg1bmwNZZYETJ2k6cFr3ldxjY0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZwujylGFyVXOEwmoOqbFU4ztYsO9xaqDA9AJANKvret9+A9X+Ov/Kf0qol77BgfM+ GmdKSn9GrBz7C0VwJI/TIYche2dOHomswYYoEKSjYCan8Vl9tr9MDw/9mU2Jb4occn HzlHx/R2lIhiwck+AM3ruaYfGseoFzCUGXQgdbczTyQJPwZCailpo5YKmwEKgK9bvg c9meTCI5fKVgmkEY0V7jpnbmUAZC944/dMAMCpwYiVBXNfPTinXVbm234L/NRSt+gz 3Kvb4O3FCd9xScnvY7iGIJ5vVR5ET2iRtVi2TcpXJmlPXuAuOqzuFKrWkugPjLtItc v5spe6klYqXYg== To: Donald Eastlake , Juliusz Chroboczek Cc: "draft-ietf-babel-rfc6126bis\@ietf.org" , "babel-chairs\@ietf.org" , "Eric Vyncke \(evyncke\)" , The IESG , "babel\@ietf.org" In-Reply-To: References: <156498851376.24465.4531172446015994141.idtracker@ietfa.amsl.com> <87v9vblt6j.wl-jch@irif.fr> <518548BD-80F5-4F02-9362-EC61D0D5CA7B@cisco.com> <87mugnllz9.wl-jch@irif.fr> Date: Wed, 07 Aug 2019 12:56:53 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87tvattf9m.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-babel-rfc6126bis-11=3A_=28with_COMMENT=29?= 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: Wed, 07 Aug 2019 10:57:00 -0000 Donald Eastlake writes: > Speaking as an individual, I'm OK with that addition. Me too (I do think I suggested dropping v4 support completely at some point ;)). -Toke From nobody Wed Aug 7 03:57:46 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 AC65E1206A8 for ; Wed, 7 Aug 2019 03:57:45 -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 Jf8KfbveYMSL for ; Wed, 7 Aug 2019 03:57:43 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 82A761201E3 for ; Wed, 7 Aug 2019 03:57:43 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id h28so63644106lfj.5 for ; Wed, 07 Aug 2019 03:57:43 -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=5IpmvxEM0eBtGNW5Bu92nGuqGp4A74340U79zM8mrxo=; b=bgjI6MKAC0sx9qV4cGL+jfc+XkbDjcHw0cBaBM8hdTTKfPxE+35MLeeezRTFp1iu9i KN+eUVcy64dlYHe5h7UU4GseT4EYrfv5XwTbAVV44wFhBiape4nzj4XtP9iL7Pex+wcI toxzEqAfW96vNemnbnf5fdRgkvowJOQ/5Tsnlo3nnDngo/6q7r1vvOCJpdxJylg2HYZg G/axsTRcgsZFRrieJgwudJbneZ2NGaPrI0LrRvkMBLCvGXqmVSaUqtJ+VqfywK11wcdz 5pIFz9qrC3egk5GBAJ9hHV74mF7rBaRXwd4w76KeeScTCE3embF2MN617Nd/Foo9C41e nkxg== 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=5IpmvxEM0eBtGNW5Bu92nGuqGp4A74340U79zM8mrxo=; b=A0dAQPAYqXDvrOdnuIaG5/w5BUQEc85x3q+WwnmDRPb51s1snXE0/kuG1LScaAj7OW EJGrJxnrhMW3VH0+0l1GAtn2w3fG+pqAf/BLk0zroMeTYtwmBdVJmnJX/G+VgbfE2cVV 6endzKO5bRamKpmzPi1foKYdn4E/+FRSqSHGMd7UdoJJAzW33fLn3Vx/xeNFsgjfkokQ vjjyTdJmwuAAy49cseBvu12LVjNrqGUBko/KlvMTHjr6rislQwmFOQwai3QFtUQ2+qPA ALDCcY33w8GcvA+04zYicw1ibdQxsuYqNvt7UdFdBSjUm4Sou7bC+dRY3FHSRGah0wu2 XnKw== X-Gm-Message-State: APjAAAWWFK5+7SCFbPjohziAmnF9OBqZBMenHn9xrtN/m1ZdiBbFbe4e fd40zeuLxGPWlPqbItuBwnv2X8lLfgiBwAlde68= X-Google-Smtp-Source: APXvYqxzi4xUBC0pXAKlTadznk7e7o4a72fjFBVX05PeCyQ84QLRNS1mr9XExN/Zm2qbXQH8uSKAa2FbO45wwwRafmc= X-Received: by 2002:ac2:5442:: with SMTP id d2mr5816557lfn.70.1565175461459; Wed, 07 Aug 2019 03:57:41 -0700 (PDT) MIME-Version: 1.0 References: <156105440578.3118.4917846383408119793.idtracker@ietfa.amsl.com> <9C5FD3EFA72E1740A3D41BADDE0B461FCFC76069@DGGEMM528-MBX.china.huawei.com> <87y305alt8.wl-jch@irif.fr> In-Reply-To: <87y305alt8.wl-jch@irif.fr> From: Henning Rogge Date: Wed, 7 Aug 2019 12:57:14 +0200 Message-ID: To: Juliusz Chroboczek Cc: "Yemin (Amy)" , antonin.decimo@gmail.com, dschinazi.ietf@gmail.com, Martin Vigoureux , =?UTF-8?Q?LucAndr=C3=A9_Burdet?= , babel@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] rtgdir Last Call Review requested: draft-ietf-babel-dtls 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: Wed, 07 Aug 2019 10:57:46 -0000 On Wed, Aug 7, 2019 at 1:58 AM Juliusz Chroboczek wrote: > > Hi Henning, > > Good to hear from you again. > > The two main authors of this draft appear to be on holiday, so I'll answer > your review to the best of my capacities. > > > Chapter 2.3: > > I wonder if using DTLS protected unicast Hellos should be mandatory... > > using unprotected multicast to determine bidirectional reachability > > looks like a good way to do a cheap denial ofa service attack. > > In Babel, bidirectional reachability is established by a Hello/IHU > exchange. This document requires IHUs to be authenticated, therefore > bidirectional reachability will never be established with an attacker. > > However, this doesn't prevent DoS attacks: > > - an attacker could send cleartext Hellos from spoofed addresses, thus > causing the victim to create unbounded numbers of neighbour entries; > - an attacker could send DTLS ClientHello packets from spoofed > addresses, with a similar effect. As long as this "unverified" links are not used for global routing I would not be worried... you can never prevent a direct neighbor from doing a DoS. > Requiring an authenticated Hello is not workable, since an authenticated > Hello cannot be sent until after the DTLS handshake has completed. And there is also the point that DTLS and Multicast don't mix well... > This is somewhat mitigated by the fact that only packets from link-local > addresses are accepted (see Section 2.1 of this draft and Section 4 of > RFC 6126bis). This is what the draft has to say on the subject (Section 5): > A malicious client might attempt to perform a high number of DTLS > handshakes with a server. As the clients are not uniquely identified > by the protocol and can be obfuscated with IPv6 temporary addresses, > a server needs to mitigate the impact of such an attack. Such > mitigation might involve rate limiting handshakes from a given subnet > or more advanced denial of service avoidance techniques beyond the > scope of this document. > > I'm not happy with this either. I think some parts of this information could be useful for the Security Considerations section. Most people don't know BABEL that deep, so giving them some advise what has already been considered and what no is always good. > > Chapter 2.5: > > What happens when a node starts a new DTLS connection and there is > > already one in the neighbor table? This could both be an attempt to > > attack Babel, a reboot of a node or just a matter of misconfiguration > > of two nodes. > > Section 2.1: > > If a node receives a new DTLS connection from a neighbour to whom it > already has a connection, the node MUST NOT discard the older > connection until it has completed the handshake of the new one and > validated the identity of the peer. Sorry, missed that... good to see it has already dealt with. > > Chapter 3: > > Different pairs of nodes could select different ciphers, resulting in > > different MTUs. I assume this is no problem for Babel (could be > > mentioned in the chapter). > > I am not competent to answer this, we'll need to wait for David or > Antonin to resurface. Sure... I was away fore quite a while too after my post. Henning Rogge From nobody Wed Aug 7 04:29:48 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 EB47B1206CE; Wed, 7 Aug 2019 04:29:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2019 04:29:39 -0700 Archived-At: Subject: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Wed, 07 Aug 2019 11:29:40 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-babel-rfc6126bis-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a couple of points that needs addressing before this document can move forward. Most of them should the straight forward to address. My main point is about network load. Thanks for discussing network load and correctly adding some warnings at the right places, however, for a PS track document I would like to see more than this. Usually it's good provide default values were suitable (as this often is what people will then pick if there is no good reason to diverge) and more important I really like to see min/max values. Note that RFC8085 recommend a minimal interval of 3 seconds which probably is also a good hard boundary here. More concretely I think there are these cases that need more guidance: - Section 3.7.2. (Triggered Updates) advises to send a message multiple times for redundancy in case of loss. 5 and 2 are mentioned as example values. Please provide a normative default value and a normative maximum value here. Moreover the spec should also require to pace out these messages and avoid "tail loss" by overloading the local queue. (See also section 3.8.2.1) - Section 3.8.1.1. (Route Requests) says: "Full route dumps MAY be rate-limited, especially if they are sent over multicast." I think this should at least be a SHOULD. Please also provide further guidance about to appropriately rate limit and think about other cases where a recommend to implement rate-limiting could make sense. - In section 4.1.1 the update interval needs a lower limit (e.g. 3 seconds) and a recommend default value would be could as well (Note that there are other part in section 3 where the update value is discussed as well). - Section 3.8.2.4. mentions network load when requests are sent to all neighbours after reboot. Please provide more guidance about how to pace out these requests. - Section 3.8.1.2. (Seqno Requests) discusses hop count values but could maybe also give more concrete guidance. I would assume that the hop count value of the current active route is usually know. Maybe that knowledge could be used to pick an appropriate value? Two other smaller discuss points/questions/comments: 1) Sec 4.6.8. (Next Hop): If I interpret this correctly, address compression is allowed for the next hop field and therefore this TLV would actually not be self-terminating. What do I miss? 2) This document needs to specify a registration policy also for each of the already existing registries given this document obsoletes RFC7557. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Other comments: 1) While this point might not raise discuss-level, it would probably also be good to provide more concrete advise on how to implement jitter: Sec 3.1.: “ A moderate amount of jitter may be applied to packets sent by a Babel speaker: outgoing TLVs are buffered and SHOULD be sent with a small random delay.” Sec 4: “a Babel node SHOULD buffer every TLV and delay sending a packet by a small, randomly chosen delay [JITTER].” 2) Sec 4.1.2. (Router-Id) should probably state again that the router-id is assumed to be unique within a domain. 3) Sec 4: “The most-significant bit of the sub-TLV, called the mandatory bit, indicates how to handle unknown sub-TLVs.” I would recommend to also indicate this bit in the image. 4) Sec 4.4: “If a TLV has a self-terminating format, then it MAY allow a sequence of sub-TLVs to follow the body.” Initially I wasn’t quite sure what you wanted to say here. I guess you say that the length would indicate a larger value that needed for the body and therefore a subTLV might be present? I recommend to clarify this here a bit. From nobody Wed Aug 7 05:14:54 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 57617120018; Wed, 7 Aug 2019 05:14:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <156518008635.8345.15729917740071737343.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2019 05:14:46 -0700 Archived-At: Subject: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Wed, 07 Aug 2019 12:14:46 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-babel-rfc6126bis-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (Sorry I forgot two points about the appendix; see one in the discuss section and one in the comment section) I have a couple of points that needs addressing before this document can move forward. Most of them should the straight forward to address. My main point is about network load. Thanks for discussing network load and correctly adding some warnings at the right places, however, for a PS track document I would like to see more than this. Usually it's good provide default values were suitable (as this often is what people will then pick if there is no good reason to diverge) and more important I really like to see min/max values. Note that RFC8085 recommend a minimal interval of 3 seconds which probably is also a good hard boundary here. More concretely I think there are these cases that need more guidance: - Section 3.7.2. (Triggered Updates) advises to send a message multiple times for redundancy in case of loss. 5 and 2 are mentioned as example values. Please provide a normative default value and a normative maximum value here. Moreover the spec should also require to pace out these messages and avoid "tail loss" by overloading the local queue. (See also section 3.8.2.1) - Section 3.8.1.1. (Route Requests) says: "Full route dumps MAY be rate-limited, especially if they are sent over multicast." I think this should at least be a SHOULD. Please also provide further guidance about to appropriately rate limit and think about other cases where a recommend to implement rate-limiting could make sense. - In section 4.1.1 the update interval needs a lower limit (e.g. 3 seconds) and a recommend default value would be could as well (Note that there are other part in section 3 where the update value is discussed as well). - Section 3.8.2.4. mentions network load when requests are sent to all neighbours after reboot. Please provide more guidance about how to pace out these requests. - Section 3.8.1.2. (Seqno Requests) discusses hop count values but could maybe also give more concrete guidance. I would assume that the hop count value of the current active route is usually know. Maybe that knowledge could be used to pick an appropriate value? Three other smaller discuss points/questions/comments: 1) Sec 4.6.8. (Next Hop): If I interpret this correctly, address compression is allowed for the next hop field and therefore this TLV would actually not be self-terminating. What do I miss? 2) This document needs to specify a registration policy also for each of the already existing registries given this document obsoletes RFC7557. 3) Appendix D (Stub Implementations) contain normative language and therefore should probably be moved into the body of the draft. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Other comments: 1) While this point might not raise discuss-level, it would probably also be good to provide more concrete advise on how to implement jitter: Sec 3.1.: “ A moderate amount of jitter may be applied to packets sent by a Babel speaker: outgoing TLVs are buffered and SHOULD be sent with a small random delay.” Sec 4: “a Babel node SHOULD buffer every TLV and delay sending a packet by a small, randomly chosen delay [JITTER].” 2) Sec 4.1.2. (Router-Id) should probably state again that the router-id is assumed to be unique within a domain. 3) Sec 4: “The most-significant bit of the sub-TLV, called the mandatory bit, indicates how to handle unknown sub-TLVs.” I would recommend to also indicate this bit in the image. 4) Sec 4.4: “If a TLV has a self-terminating format, then it MAY allow a sequence of sub-TLVs to follow the body.” Initially I wasn’t quite sure what you wanted to say here. I guess you say that the length would indicate a larger value that needed for the body and therefore a subTLV might be present? I recommend to clarify this here a bit. 5) I recommend to move Appendix C (Considerations for protocol extensions) in the body of the document. From nobody Wed Aug 7 05:18:08 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 9063212001B; Wed, 7 Aug 2019 05:18:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-babel-hmac@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <156518028058.8361.10940272410936686016.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2019 05:18:00 -0700 Archived-At: Subject: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-hmac-08=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Wed, 07 Aug 2019 12:18:01 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-babel-hmac-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-hmac/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I would like to quickly discuss the following approach taken in section 4.3.1.1: "Since a challenge may be prompted by a packet replayed by an attacker, a node MUST impose a rate limitation to the challenges it sends; the limit SHOULD default to one challenge request every 300ms, and MAY be configurable." While it is important to limit challenge messages here, there might be a better approach than static rate-limiting given this is a request-response mechanism. Usually the approach is to only allow for one outstanding request (without reply) and apply some kind of loss detect/termination rule. In your case the easiest approach would be when the 30 sec timer is expired, or if the RTT is known (or can be estimated) then a value of e.g. 3xRTT could be appropriate as well. Please consider this alternative approach. Maybe also see RFC8085 for further guidance. Further Appendix A (Incremental deployment and key rotation) contains normative language and therefore should probably be moved into the body of the document. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The shepherd write-up says: "This document updates the rfc6126bis draft as noted on the title page and in the Abstract." However, that seems not to be the case...? This brings me to a separate question I would like to ask: Why is this an extension in a separate document and not an (optional) part of rfc6126bis? From nobody Wed Aug 7 05:40:50 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 43F0312007C; Wed, 7 Aug 2019 05:40:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-babel-dtls@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <156518163926.8337.14198016212015161206.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2019 05:40:39 -0700 Archived-At: Subject: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-dtls-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Wed, 07 Aug 2019 12:40:40 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-babel-dtls-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Unfortunately I need to discuss the port request again. First of all I would like to comment on the shepherd write-up which says: "The document requires only the allocation of a port number for Babel over DTLS. Having such a second port for the secured version of a protocol is a fairly common practice. This is shown in the IANA Considerations section." This is not correct. Having a second port for the secured version of a protocol WAS common practice. However RFC6335 say now "The use of separate service name or port number assignments for secure and insecure variants of the same service is to be avoided in order to discourage the deployment of insecure services." Anyway, in this case I understand that a different port is desired because unencrypted HELLO messages are still received over the default babel port. However, it is not clear to me why a fixed/default port is needed. The neighbour needs to be discovered in some why, no matter what, before a DTLS connection can be established and this discovery procedure could indicate a dynamic port number that the peer is listening on for babel over DTLS. E.g. the multicast HELLO could have a new TLV with this port information. Please clarify why this option is not suitable! Thanks! ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This specification seems to only support babel over DTLS for IPv6. This should be stated clearly in the introduction. From nobody Wed Aug 7 06:25:25 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 ADB36120086 for ; Wed, 7 Aug 2019 06:25:24 -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 fCg_yYHo9wbJ for ; Wed, 7 Aug 2019 06:25:23 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D8F12004E for ; Wed, 7 Aug 2019 06:25:23 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x77DJ7fi040414; Wed, 7 Aug 2019 09:25:21 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 2u7v2tmhg4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Aug 2019 09:25:21 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x77DPKVd028344; Wed, 7 Aug 2019 09:25:21 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x77DPDZx028127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Aug 2019 09:25:13 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 0264B4009E78; Wed, 7 Aug 2019 13:25:13 +0000 (GMT) Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30485.vci.att.com (Service) with ESMTPS id DE3274009E74; Wed, 7 Aug 2019 13:25:12 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0439.000; Wed, 7 Aug 2019 09:25:12 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" , "'Mahesh Jethanandani'" CC: "'Babel at IETF'" Thread-Topic: [babel] Example configuration Thread-Index: AQHVQysP27rmDxHNmE+dOkameIFP66bcIv6AgBKtMoCAAAmwgIAACWOAgAAV/4CAAC8QgIAAC2UAgABwxXA= Date: Wed, 7 Aug 2019 13:25:12 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E257961@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr> <87pnlhaixh.wl-jch@irif.fr> In-Reply-To: <87pnlhaixh.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.248.192] 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-08-07_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908070145 Archived-At: Subject: Re: [babel] Example configuration 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: Wed, 07 Aug 2019 13:25:25 -0000 > >> The protocol doesn't know about interface types. From the point of > >> view of the protocol, there are a number of algorithms that can > >> optionally be selected or enabled on a given interface. These include= : > >> > >> - link-quality estimation (2-out-of-3 or ETX); > >> - split-horizon (on or off); > >> - RTT estimation (draft-ietf-babel-rtt); > >> - use of unicast instead of multicast; > >> - ... >=20 > > In -08 version of the draft, all references to wired, wireless, tunnel > > and others are gone. That in addition to babel-link-properties. If > > they are underlying parameters, they are truly invisible :-). >=20 > Wired, wireless etc. are the UI interface types. The underlying properti= es are > link-quality and split-horizon (in RFC 6126bis) and the RTT estimation > parameters (in draft-ietf-babel-rtt). >=20 > > I understand that it is difficult for an operatori without intimate > > knowledge to know how to configure these properties. And that is why > > these should be optional properties. However, without them, there is > > no way for an operator to influence how the protocol works. "Optional property" has different meanings to different people and differen= t data modeling schemes. I've started trying to be very explicit: (1) Does = a parameter (YANG leaf) have a universally-agreed default value (e.g., the = UDP port)? (2) Can the management system cause an object (YANG leaf-list) i= nstance to be created and some of the parameters (leafs) will be implicitly= set to known default values (e.g., the hmac-keys and dtls-certs Booleans)?= (3) Are the allowed values for some parameters (leafs) constrained to a sp= ecific range, cannot be null, are an enumeration, etc. (e.g., interface met= ric-algorithm)? (4) If an implementation does not include a particular para= meter (leaf), can it still be considered compliant with the info model (in = YANG terms: Can a specific Babel implementation have a YANG deviation state= ment for something and still be compliant with the info model) [this is not= directly reflected in the YANG model]? In the context of interface metric-algorithm and split-horizon, the managem= ent system will never "create" these parameters (because all interface inst= ances are created by the Babel implementation and cannot be created by the = management system), and there are no universally-agreed defaults. So (1) an= d (2) don't apply. The models allow the management system to overwrite the = value the implementation chose for the interface. We're constraining the al= lowed values the management system can use when overwriting these. So (3) a= pplies. The YANG model needs to constrain the value of these sorts of param= eters to being in the enumeration, but doesn't need a default. > I think we're not understanding each other. I am not arguing about hidin= g > any information, quite the opposite, I am in favour of exporting the > underlying properties and leaving the link type to the UI. >=20 > >> I don't think we have the manpower to do a good job. >=20 > > Ok. Let me follow up on the separate e-mail thread that you started > > with describing Babel filtering and routing policies. If it becomes > > too complex, we can drop it. >=20 > Sure, but please keep my comment about manpower in mind. I think the problem we're facing is that Babel implementations are perfectl= y capable of operating well without being explicitly configured (other than= enabling/disabling it). Babel is specifically designed that way. But that = doesn't necessitate "hiding" things. Here is what I think would be common "configuration" scenarios: - The most common "configuration" would be to simply enable Babel.=20 - The next most common configuration would be to enable/disable it on spec= ific interfaces (using the enable parameter in babel-interfaces). This may = be done at the same time Babel is enabled (if the Babel implementation crea= tes the interfaces instances even though Babel isn't enabled). Or later. It= may need to be a separate configuration call, because the Babel implementa= tion may not create the interfaces instances unless it is enabled. If it is= a separate configuration call, the operator will probably need to read the= configuration first, to see what interfaces Babel has identified it can ru= n on, and which of these it has auto-enabled / auto-disabled. - The next thing someone would want to do is not configuration, but just r= eading info about the status of Babel. Some of the expressed status is the = metric-algorithm (not link-quality, which is not a parameter) and split-hor= izon (true/false as to whether it's used) that was selected by the implemen= tation for use on each interface. The Babel model is small enough that the = person would probably find it easiest just to ask for everything. - It's possible that in looking at the status, the operator doesn't like t= he choices the implementation made wrt metric-algorithm or split-horizon, f= or an interface. The operator needs to have the ability to change those cho= ices. The values the operator can change to are constrained.=20 - It's possible that in looking at the status, the operator thinks things = don't look right and wants to troubleshoot by getting more detailed statist= ics and maybe even a message log. So the operator enables statistics and me= ssage log. The operator waits a few seconds and reads statistics and the me= ssage log. Maybe the operator does something that fixes the problem. The op= erator then disables statistics and message log. So maybe the "example configuration" is a sequence of YANG messages: 1. Enable Babel 2. Read the interfaces leaf-list. 3. Enable/disable Babel on specific interfaces, as desired. 4. Read everything. 5. Update metric-algorithm and split-horizon values for a specific interfac= e. For troubleshooting: 6. Enables statistics and message log. 7. Read statistics and message log. 8. Disable statistics and message log. Barbara From nobody Wed Aug 7 06: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 77B0F12015F; Wed, 7 Aug 2019 06:29:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana via Datatracker To: "The IESG" Cc: draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alvaro Retana Message-ID: <156518456148.8400.6644665367614468260.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2019 06:29:21 -0700 Archived-At: Subject: [babel] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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: Wed, 07 Aug 2019 13:29:22 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-babel-rfc6126bis-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I really enjoyed reading this document! Thank you for the work and time that has gone into it. However, I don't think that this specification is ready to be published as a Proposed Standard. In general, I don't think that the document is clear or specific enough to be considered in the Standards Track -- that is the main reason for this DISCUSS. (A) Clear Defaults and Operational Guidance While I appreciate Babel's flexibility in terms of the ability to use different strategies, I believe that both defaults and clear guidance should be provided. Given that "not all...strategies will give good results" and that in most cases these are listed as possible choices, I don't think that this document "has resolved known design choices" [BCP9/rfc7127]. The cost/metric computation and route selection specially concern me because I believe that a robust/clear specification is at the heart of any routing protocol. In general what I am looking for to resolve this part of the DISCUSS are two items: (A1) Clear defaults. For example, Appendix B talks about constants/default values. I would assume that, given the existing experience, that the values there are probably sensible defaults. Is that not the case? (A2) Operational Considerations. Given that Babel can be (and is) used in different environments, I would like to see guidance to operators as they deploy the protocol in their networks. An example of the type of discussion I would like to see expanded is: "a mobile node that is low on battery may choose to use larger time constants (hello and update intervals, etc.) than a node that has access to wall power" (§1.1). Consider §2 in rfc5706 (Operational Considerations - How Will the New Protocol Fit into the Current Environment?). I believe that both items are important, specially in a protocol as flexible as Babel. Some of this guidance could have been included in draft-ietf-babel-applicability -- but this information is not there either. (B) Error Handling Many sections of the document describe functionality, or even Normatively mandate it, but there is no discussion about Error Handling. (B1) Router-Id Setting §4.5: o the current router-id; this is undefined at the start of the packet, and is updated by each Router-ID TLV (Section 4.6.7) and by each Update TLV with Router-Id flag set. It took me some time to figure out the reason for being able to carry the router-id in two different places inside the same packet, which is my interpretation of the "and" above. Let me see if I understood: a packet can carry multiple updates...updates contain routes that were either originated by the local node, OR, learned from other routers...the router-id matches the originator... So...if a packet carries multiple updates, some locally originated and some learned, then it is possible for the packet to first include (for example) a Router-ID TLV (indicating router-id_A), followed by some Update TLVs (without the R-bit set), than then some other Update TLVs (with the R-bit set)... Did I understand correctly? If so, I think there are significant pieces of this operation that are not clearly specified in the document. There is mention of the effect of the Router-ID TLV (or the Update TLV w/R=1) on subsequent Update TLVs...there is an very subtle hint (for my taste) in §4.5 (Parser state) about the state learned for each packet from those TLVs...but there is no explicit text that talks about the need for strict ordering when sending and later when processing...it is all simply implied. What should happen if no Router-Id has been defined? For example, an Update (R = 0) is received but no Router-ID TLV is present... What if the Router-ID TLV is present, but *after* the Update? There are many possible combinations... (B2) Default Prefix Similar comments as above... "P (Prefix) flag...establishes a new default prefix for subsequent Update TLVs with a matching address encoding within the same packet" (§4.6.9). What if an update with an AE that allows compression is received *before* the one that sets the new default prefix? (B3) Next Hop §4.6.9: The next-hop address for this update is taken from the last preceding Next Hop TLV with a matching address family (IPv4 or IPv6) in the same packet even if it was otherwise ignored due to an unknown mandatory sub-TLV; if no such TLV exists, it is taken from the network-layer source address of this packet. What if the Next Hop TLV doesn't exist and the network-layer doesn't correspond to the address family in the Update? For example, let's say IPv6 is used as the network-layer protocol and the Update contains IPv4 prefixes... (B4) For the Normative behavior listed here (I may have missed other instances), I have basically the same question: what should a receiver do if it is not the case? - §3.8.1.2: "A node MUST NOT increase its sequence number by more than 1 in response to a seqno request." - §4: "A Babel packet MUST be sent as the body of a UDP datagram, with network-layer hop count set to 1..." - §4.6.9: "If the metric is finite, AE MUST NOT be 0. If the metric is infinite and AE is 0, Plen and Omitted MUST both be 0." - §4.6.10: "...if AE is 0 (in which case Plen MUST be 0 and Prefix is of length 0)." - §4.6.10/§4.6.11: Is AE 3 a valid value in a request? I assume it isn't. What should a receiver do if AE = 3. (C) Mandatory Bit §4.4: "The most-significant bit of the sub-TLV, called the mandatory bit..." The most significant bit of which part of the sub-TLV? As written, that bit would be the first one in the Type, which corresponds to the text in the IANA section. Please be specific. In the IANA considerations section, please include the whole registry in the table to avoid confusion. Note that because of the mandatory bit, the 128-239 range should be Reserved...but it is currently marked as Unassigned. Even worse, value 128 is assigned already [draft-ietf-babel-source-specific]. The impact may not be too bad because I doubt that Pad1 would need to be mandatory, but it at least causes confusion and inconsistency, and (as currently specified) there would be no way to differentiate between Pad1 and the Source Prefix sub-TLV. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (a) §3.1 introduces the term "urgent TLVs". (1) It might be a good idea to explicitly mention/list which are these TLVs. There are some references in subsequent sentences, which may or may not be enough for most readers. (2) There are some Normative actions applied to them, for example "MUST be sent in a timely manner". While the intent may be ok, the Normative enforcement of "in a timely manner" is not clear at all -- how do you comply with that? Appendix B says: The amount of jitter applied to a packet depends on whether it contains any urgent TLVs or not (Section 3.1). Urgent triggered updates and urgent requests are delayed by no more than 200ms; acknowledgments, by no more than the associated deadline; and other TLVs by no more than one-half the Multicast Hello interval. I think it would help if this text is moved to §3.1 to make it explicitly clear what a timely delay is...and the text was changed to (something like) "MUST NOT be delayed more than 200ms". (b) §3.2.2: "SHOULD NOT increment its sequence number (seqno) spontaneously" When it is ok to increase the seqno spontaneously? IOW, why not use MUST NOT? I think it would be better if there was a clear indication of when the seqno is increased. Scanning the rest of the document, it seems that those indications are in place. (c) There seems to be no specific explanation of how the timers are handled, what happens when they expire, etc.. For example, §3.2.4 includes this text: There are three timers associated with each neighbour entry -- the multicast hello timer, which is initialised from the interval value carried by scheduled Multicast Hello TLVs, the unicast hello timer, which is initialised from the interval value carried by scheduled Unicast Hello TLVs, and the IHU timer, which is initialised to a small multiple of the interval carried in IHU TLVs. But there is no explanation (that I could find) about how to manage those timers. The only place where hello timers are mentioned is in Appendix A.1...but that is just an example. (d) §3.7.2 includes two instances of "SHOULD make a reasonable attempt at ensuring that all [reachable] neighbours receive this update/retraction". What does making "a reasonable attempt" mean? How can that be Normatively enforced? (e) §3.7.2 Finally, a node MAY send a triggered update when the metric for a given prefix changes in a significant manner, due to a received update, because a link's cost has changed, or because a different next hop has been selected. 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). How much is "a significant manner"? What about "a minor fluctuation"? Are the modifiers (next hop change, for example) the only conditions to take into account, or are they just examples of when these significant/minor changes may occur? How can these terms be Normatively enforced? (f) §3.8.1.1: "When a node receives a wildcard route request, it SHOULD send a full route table dump." When is it ok to not send a full table dump? IOW, why is MUST not used? (g) §3.8.2.1: "a node SHOULD repeat such a request a small number of times if no route becomes feasible within a short time." What does "a small number of times" and "within a short time" mean? How can that be Normatively enforced? Please be specific. (h) §4.6.9: "Omitted...that should be taken from a preceding Update TLV in the same address family with the Prefix flag set." What if that Update TLV is not in the packet? (i) Security Considerations The initial vulnerability listed ("attacker can misdirect data traffic by advertising routes with a low metric or a high seqno") is only one of several actions an attacker can take. More importantly, if the attacker happens to be in control of an authenticated node, then the mitigation proposed doesn't help. This type of rogue node can, for example, set the mandatory bit in an unknown TLV (as in completely made up!) to cause whole TLVs to be ignored, resulting in loss of routes, etc.. I am not sure what can be done to mitigate this type of vulnerability...but I think it is important that it is at least called out. (j) Are the appendices intended to be Normative or not? I'm assuming the answer is no...but I can base that only on the references in the text to Appendix A.*, pointing to them as examples. What about the others? They are not even referenced in the text. Some comments: - Appendix B talks about constants/default values. See my DISCUSS comments above. - Appendix C "is intended to guide designers of protocol extensions in chosing a particular encoding." I think is is valuable information. It would be very nice if there was a reference (or perhaps several, from where the different extensibility methods are presented) in the main body of the specification. I can see how this is an informative section. - Appendix D defines a "stub implementation". This is also valuable information. But...there's no reference from the text, and Normative language is used... Why is this type of implementation (which I would think might be relatively common) not normative? - Appendix E simply points to the sample implementation. Personally, I would prefer to see an rfc7942 section instead -- it would have been nice to also mention other implementations. (k) "The length of..." is used everywhere in the document, but no units are mentioned. Some seem to obviously be in octets, but others could easily be in bits... (l) §4: s/SHOULD attempt to maximise the size of the packets/SHOULD maximise the size of the packets (m) §4.1.3: The description of AE 1 and 2 says that "Compression is allowed." -- but it looks like the only place where it can happen is in an Update. It might be nice to indicate that...and avoid indicating that compression is not allowed where it can't be done anyway. (n) rfc8126 should be a Normative reference. (o) Please include Informative references to rfc6126 and rfc7557. (p) s/Bellman-Ford protocol/Bellman-Ford algorithm (q) §2.4: Include an Informative reference to AODV (rfc3561). (r) §2.4: "if A has selected B as its successor" This is the only place where "successor" is used. For clarity, perhaps use a different word/description. From nobody Wed Aug 7 06:49:55 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 9F4AC12006D; Wed, 7 Aug 2019 06:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJm-BU_Ak5ca; Wed, 7 Aug 2019 06:49:45 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) (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 BB18D120041; Wed, 7 Aug 2019 06:49:45 -0700 (PDT) Received: from pirx.irif.fr (unknown [IPv6:2a01:e34:ec22:84a2:40cc:4a9b:caf5:e938]) by smtp4-g21.free.fr (Postfix) with ESMTPS id 8AAD719F5AD; Wed, 7 Aug 2019 15:49:31 +0200 (CEST) Date: Wed, 07 Aug 2019 15:49:31 +0200 Message-ID: <87imr9hyqc.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mirja =?ISO-8859-1?Q?K=FChlewind?= Cc: "The IESG" , draft-ietf-babel-hmac@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156518028058.8361.10940272410936686016.idtracker@ietfa.amsl.com> References: <156518028058.8361.10940272410936686016.idtracker@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 Archived-At: Subject: Re: [babel] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-babel-hmac-08=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Wed, 07 Aug 2019 13:49:48 -0000 Dear Mirja, Thank you for your review. (Please be aware that I cannot check my work mail until Thursday, please copy the list if you desire a timely response.) > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > I would like to quickly discuss the following approach taken in section > 4.3.1.1: [...] > there might be a better approach than static rate-limiting given this is > a request-response mechanism. [...] In your case the easiest approach > would be when the 30 sec timer is expired, or if the RTT is known (or > can be estimated) then a value of e.g. 3xRTT could be appropriate well. > for further guidance. First of all, what we're trying to avoid here is an attacker causing the current node to generate unbounded amounts of traffic. With static rate limiting, we guarantee that an attacker can cause at most n/0.3 packets per second to be sent, where n is the number of distinct source addresses in the attacker's collection of captured packets. No such guarantee exists if the rate limiting is made dynamic. Second, in normal usage the challenge/response mechanism is used when establishing state with a new neighbour. No RTT information is likely to be available at that early stage. Thus, your suggestion would cause a 30s delay whenever a challenge reply is lost. > Further Appendix A (Incremental deployment and key rotation) contains > normative language and therefore should probably be moved into the body > of the document. Is that a hard requirement? It makes sense to me to separate operational requirements from the description of the protocol. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > The shepherd write-up says: "This document updates the rfc6126bis draft > as noted on the title page and in the Abstract." However, that seems not > to be the case...? The "updates" was removed in -05 at the request of Martin Vigoureux. > This brings me to a separate question I would like to ask: Why is this an > extension in a separate document and not an (optional) part of rfc6126bis? I want it to be easily readable by people who are not interested in the specifics of Babel, as this makes it more likely that it will be reviewed by competent security specialists. (In addition, since this protocol was designed to solve some of the issues described in RFC 6039, I have some hope that it will come to the attention of the OSPF community.) Thanks again, -- Juliusz From nobody Wed Aug 7 07:11:38 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 19F4612015B; Wed, 7 Aug 2019 07:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xsh0SIWYpEi; Wed, 7 Aug 2019 07:11:31 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 892BA12017A; Wed, 7 Aug 2019 07:11:31 -0700 (PDT) Received: from 200116b82c9bae003483c528e9ba9b65.dip.versatel-1u1.de ([2001:16b8:2c9b:ae00:3483:c528:e9ba:9b65]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hvMf3-0004wp-0T; Wed, 07 Aug 2019 16:11:29 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <87imr9hyqc.wl-jch@irif.fr> Date: Wed, 7 Aug 2019 16:11:28 +0200 Cc: The IESG , draft-ietf-babel-hmac@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <48D085EC-8B31-47FB-A4E1-05BB5CB30829@kuehlewind.net> References: <156518028058.8361.10940272410936686016.idtracker@ietfa.amsl.com> <87imr9hyqc.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1565187091;a722b5e9; X-HE-SMSGID: 1hvMf3-0004wp-0T Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-hmac-08=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Wed, 07 Aug 2019 14:11:37 -0000 Hi Juliusz, Please see below. > On 7. Aug 2019, at 15:49, Juliusz Chroboczek wrote: >=20 > Dear Mirja, >=20 > Thank you for your review. >=20 > (Please be aware that I cannot check my work mail until Thursday, = please > copy the list if you desire a timely response.) >=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >=20 >> I would like to quickly discuss the following approach taken in = section >> 4.3.1.1: >=20 > [...] >=20 >> there might be a better approach than static rate-limiting given this = is >> a request-response mechanism. [...] In your case the easiest = approach >> would be when the 30 sec timer is expired, or if the RTT is known (or >> can be estimated) then a value of e.g. 3xRTT could be appropriate = well. >> for further guidance. >=20 > First of all, what we're trying to avoid here is an attacker causing = the > current node to generate unbounded amounts of traffic. With static = rate > limiting, we guarantee that an attacker can cause at most n/0.3 = packets > per second to be sent, where n is the number of distinct source = addresses > in the attacker's collection of captured packets. No such guarantee > exists if the rate limiting is made dynamic. >=20 > Second, in normal usage the challenge/response mechanism is used when > establishing state with a new neighbour. No RTT information is likely = to > be available at that early stage. Thus, your suggestion would cause a = 30s > delay whenever a challenge reply is lost. You can also use a different timer e.g. 300s which would also ensure = that a challenge is not send more often than 300s (expect in the case = where you got a challenge reply but in case you are not talking to an = attacker and usually not need to send another challenge request = immediately).=20 Implementation wise there is actually not much difference. You send a = challenge and set a timer. Only that you could cancel the timer if a = reply is received. However, in any case I find 300ms rather low. RFC8085 recommends = basically one active message (in case you have a response-reply pattern) = or not more than one message every 3 seconds. >=20 >> Further Appendix A (Incremental deployment and key rotation) contains >> normative language and therefore should probably be moved into the = body >> of the document. >=20 > Is that a hard requirement? It makes sense to me to separate = operational > requirements from the description of the protocol. Actually not sure but I would say common practice. Usually you have tis = separation but having different sections with meaningful titles. >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >=20 >> The shepherd write-up says: "This document updates the rfc6126bis = draft >> as noted on the title page and in the Abstract." However, that seems = not >> to be the case...? >=20 > The "updates" was removed in -05 at the request of Martin Vigoureux. >=20 >> This brings me to a separate question I would like to ask: Why is = this an >> extension in a separate document and not an (optional) part of = rfc6126bis? >=20 > I want it to be easily readable by people who are not interested in = the > specifics of Babel, as this makes it more likely that it will be = reviewed > by competent security specialists. (In addition, since this protocol = was > designed to solve some of the issues described in RFC 6039, I have = some > hope that it will come to the attention of the OSPF community.) I understand the argument for readability, however, in the IETF we have = put a strong focus on not specifying insecure protocols anymore and = therefore it would make a lot of sense to see this part of the protocol = as an essential part and not as an extension only. It=E2=80=99s about = encouraging people to implement it. Mirja >=20 > Thanks again, >=20 > -- Juliusz >=20 From nobody Wed Aug 7 07:26:17 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 EA958120041; Wed, 7 Aug 2019 07:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 4k9A9ScgeRLh; Wed, 7 Aug 2019 07:26:14 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) (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 83C57120019; Wed, 7 Aug 2019 07:26:14 -0700 (PDT) Received: from pirx.irif.fr (unknown [IPv6:2a01:e34:ec22:84a2:40cc:4a9b:caf5:e938]) by smtp4-g21.free.fr (Postfix) with ESMTPS id 8C86519F5A3; Wed, 7 Aug 2019 16:26:00 +0200 (CEST) Date: Wed, 07 Aug 2019 16:26:00 +0200 Message-ID: <87ef1xhx1j.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mirja Kuehlewind Cc: The IESG , draft-ietf-babel-hmac@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <48D085EC-8B31-47FB-A4E1-05BB5CB30829@kuehlewind.net> References: <156518028058.8361.10940272410936686016.idtracker@ietfa.amsl.com> <87imr9hyqc.wl-jch@irif.fr> <48D085EC-8B31-47FB-A4E1-05BB5CB30829@kuehlewind.net> 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 Archived-At: Subject: Re: [babel] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-babel-hmac-08=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Wed, 07 Aug 2019 14:26:16 -0000 > You can also use a different timer e.g. 300s which would also ensure > that a challenge is not send more often than 300s (expect in the case > where you got a challenge reply but in case you are not talking to an > attacker and usually not need to send another challenge request immediately). If the challenge reply is lost, then the challenge needs to be resent. It would not be acceptable to cause a 5 min blackhole after a single packet loss. > However, in any case I find 300ms rather low. RFC8085 recommends > basically one active message (in case you have a response-reply pattern) > or not more than one message every 3 seconds. This would mean creating a 3 second blackhole after a single packet loss. I'll expand on that further in my reply to your review of 6126bis, but I believe that RFC 8085 speaks about UDP traffic across the Internet. Babel is a link-local protocol -- there are no intermediary nodes to congest. Mirja, if the RFC 8085 limit is to be enforced for link-local protocols, then OSPF cannot possibly work. -- Juliusz From nobody Wed Aug 7 08:21:52 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 93204120397; Wed, 7 Aug 2019 08:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLTVxuWeeVAp; Wed, 7 Aug 2019 08:21:48 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 20587120394; Wed, 7 Aug 2019 08:21:48 -0700 (PDT) Received: from 200116b82c9bae003483c528e9ba9b65.dip.versatel-1u1.de ([2001:16b8:2c9b:ae00:3483:c528:e9ba:9b65]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hvNkz-000631-SG; Wed, 07 Aug 2019 17:21:41 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <87ef1xhx1j.wl-jch@irif.fr> Date: Wed, 7 Aug 2019 17:21:41 +0200 Cc: Donald Eastlake , babel-chairs@ietf.org, The IESG , babel@ietf.org, draft-ietf-babel-hmac@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156518028058.8361.10940272410936686016.idtracker@ietfa.amsl.com> <87imr9hyqc.wl-jch@irif.fr> <48D085EC-8B31-47FB-A4E1-05BB5CB30829@kuehlewind.net> <87ef1xhx1j.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1565191308;26ee02a4; X-HE-SMSGID: 1hvNkz-000631-SG Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-hmac-08=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Wed, 07 Aug 2019 15:21:51 -0000 Hi Juliusz, See below. > On 7. Aug 2019, at 16:26, Juliusz Chroboczek wrote: >=20 >> You can also use a different timer e.g. 300s which would also ensure >> that a challenge is not send more often than 300s (expect in the case >> where you got a challenge reply but in case you are not talking to an >> attacker and usually not need to send another challenge request = immediately). >=20 > If the challenge reply is lost, then the challenge needs to be resent. = It > would not be acceptable to cause a 5 min blackhole after a single = packet > loss. Why 5 mins? If the challenge needs to be retransmitted, then the = mechanism for retransmitting seems to be missing in the draft or what do = I miss? Mirja >=20 >> However, in any case I find 300ms rather low. RFC8085 recommends >> basically one active message (in case you have a response-reply = pattern) >> or not more than one message every 3 seconds. >=20 > This would mean creating a 3 second blackhole after a single packet = loss. >=20 > I'll expand on that further in my reply to your review of 6126bis, but > I believe that RFC 8085 speaks about UDP traffic across the Internet. > Babel is a link-local protocol -- there are no intermediary nodes to > congest. >=20 > Mirja, if the RFC 8085 limit is to be enforced for link-local = protocols, > then OSPF cannot possibly work. >=20 > -- Juliusz >=20 >=20 From nobody Wed Aug 7 08:41:22 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 0DA821203F2; Wed, 7 Aug 2019 08:41: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 G0LgeV3KkWg0; Wed, 7 Aug 2019 08:41:10 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C18CC1203F8; Wed, 7 Aug 2019 08:41:08 -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 x77Ff340023842; Wed, 7 Aug 2019 17:41:03 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id B9BD72A84E; Wed, 7 Aug 2019 17:41: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 mOxKV0tmccDI; Wed, 7 Aug 2019 17:41: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 CA3602A84C; Wed, 7 Aug 2019 17:41:05 +0200 (CEST) Date: Wed, 07 Aug 2019 17:41:05 +0200 Message-ID: <87a7clhtke.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mirja Kuehlewind Cc: Donald Eastlake , babel-chairs@ietf.org, The IESG , babel@ietf.org, draft-ietf-babel-hmac@ietf.org In-Reply-To: References: <156518028058.8361.10940272410936686016.idtracker@ietfa.amsl.com> <87imr9hyqc.wl-jch@irif.fr> <48D085EC-8B31-47FB-A4E1-05BB5CB30829@kuehlewind.net> <87ef1xhx1j.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 [194.254.61.138]); Wed, 07 Aug 2019 17:41:03 +0200 (CEST) X-Miltered: at korolev with ID 5D4AF10F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4AF10F.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 : 5D4AF10F.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] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-babel-hmac-08=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Wed, 07 Aug 2019 15:41:13 -0000 >>> You can also use a different timer e.g. 300s which would also ensure >>> that a challenge is not send more often than 300s (expect in the case >>> where you got a challenge reply but in case you are not talking to an >>> attacker and usually not need to send another challenge request >>> immediately). >> If the challenge reply is lost, then the challenge needs to be resent. It >> would not be acceptable to cause a 5 min blackhole after a single packet >> loss. > Why 5 mins? You're suggesting 300s in the excerpt cited above. > If the challenge needs to be retransmitted, then the mechanism for > retransmitting seems to be missing in the draft or what do I miss? A -> B: Challenge B -> A: Challenge reply gets lost B -> multicast group: normal control packet (At B, the control packet fails the index test (5th bullet point in 4.3).) A -> B: Challenge -- Juliusz From nobody Wed Aug 7 08:44:39 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 F1EE4120429; Wed, 7 Aug 2019 08:44:37 -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 FsFN1AJtcm0C; Wed, 7 Aug 2019 08:44:35 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E19120418; Wed, 7 Aug 2019 08:44:28 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x77FiMDY024538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Aug 2019 17:44:23 +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 x77FiNn0009812; Wed, 7 Aug 2019 17:44:23 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 17B6D2A8A6; Wed, 7 Aug 2019 17:44:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id VVz7zW1e2lMX; Wed, 7 Aug 2019 17:44:25 +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 F26242A8A3; Wed, 7 Aug 2019 17:44:24 +0200 (CEST) Date: Wed, 07 Aug 2019 17:44:24 +0200 Message-ID: <877e7phtev.wl-jch@irif.fr> From: Juliusz Chroboczek To: Alvaro Retana Cc: "The IESG" , draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156518456148.8400.6644665367614468260.idtracker@ietfa.amsl.com> References: <156518456148.8400.6644665367614468260.idtracker@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=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]); Wed, 07 Aug 2019 17:44:23 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 07 Aug 2019 17:44:23 +0200 (CEST) X-Miltered: at korolev with ID 5D4AF1D6.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D4AF1D7.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4AF1D6.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D4AF1D7.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 : 5D4AF1D6.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D4AF1D7.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] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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: Wed, 07 Aug 2019 15:44:38 -0000 Dear Alvaro, Thank you very much for your detailed review, and thank you for the kind words. > (A) Clear Defaults and Operational Guidance > While I appreciate Babel's flexibility in terms of the ability to use > different strategies, I believe that both defaults and clear guidance > should be provided. You'll doubtless agree that we must be careful here. We are in a universe in which there exist perfectly good routing protocols that operators are already comfortable with (notably OSPF and IS-IS). Babel's niche is the ability to adapt to environments where OSPF and IS-IS do not work well; if we restrict this flexibility too much, our niche vanishes. > Given that "not all...strategies will give good results" and that in > most cases these are listed as possible choices, I don't think that this > document "has resolved known design choices" [BCP9/rfc7127]. The > cost/metric computation and route selection specially concern me because > I believe that a robust/clear specification is at the heart of any > routing protocol. The point here is that Babel will still converge and will still behave in a loop-free manner whatever the algorithm chosen, as long as the conditions described in Section 3.5.2 hold. (This is provably true in the case where the metric is left-distributive, and believed to hold even if it is not.) I'll expand on the description of the suggested algorithms in Sections 3.5.2 and 3.6. However, I shall not make it a MUST, for the reasons outlined above. I hope that's okay with you. > (A1) Clear defaults. For example, Appendix B talks about constants/default > values. I would assume that, given the existing experience, that the values > there are probably sensible defaults. Is that not the case? I liken this to BFD. RFC 5880 does not give any default values for its timers, since the suitable values depend so much on the environment. The values suggested in Appendix B are suitable for a reasonably stable network where outages on the order of 6 to 10 seconds are acceptable. In mobile networks, Hello intervals of 0.5 yield better results. To the contrary, people running Babel over stable tunnels have been using much larger intervals. > (A2) Operational Considerations. Given that Babel can be (and is) used > in different environments, I would like to see guidance to operators as > they deploy the protocol in their networks. An example of the type of > discussion I would like to see expanded is: "a mobile node that is low > on battery may choose to use larger time constants (hello and update > intervals, etc.) than a node that has access to wall power" (1.1). > Consider 2 in rfc5706 (Operational Considerations - How Will the New > Protocol Fit into the Current Environment?). This is not clear to me. What exactly are you requesting here? As to your remaining points, I'll work on them, and reply once I've implemented your suggestions. -- Juliusz From nobody Wed Aug 7 08:44:58 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 96A7A120417; Wed, 7 Aug 2019 08:44:45 -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 EeUtmF14H8jF; Wed, 7 Aug 2019 08:44:43 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 704CF12041D; Wed, 7 Aug 2019 08:44:36 -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 x77FiVUg024567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Aug 2019 17:44:31 +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 x77FiVf8009825; Wed, 7 Aug 2019 17:44:31 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 598782A8AB; Wed, 7 Aug 2019 17: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 7Roj_jQmeq3m; Wed, 7 Aug 2019 17: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 449A02A8A8; Wed, 7 Aug 2019 17:44:33 +0200 (CEST) Date: Wed, 07 Aug 2019 17:44:33 +0200 Message-ID: <875zn9htem.wl-jch@irif.fr> From: Juliusz Chroboczek To: Alvaro Retana Cc: "The IESG" , draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156518456148.8400.6644665367614468260.idtracker@ietfa.amsl.com> References: <156518456148.8400.6644665367614468260.idtracker@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=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]); Wed, 07 Aug 2019 17:44:31 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 07 Aug 2019 17:44:31 +0200 (CEST) X-Miltered: at korolev with ID 5D4AF1DF.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D4AF1DF.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4AF1DF.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D4AF1DF.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 : 5D4AF1DF.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D4AF1DF.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] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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: Wed, 07 Aug 2019 15:44:46 -0000 Dear Alvaro, Thank you very much for your detailed review, and thank you for the kind words. > (A) Clear Defaults and Operational Guidance > While I appreciate Babel's flexibility in terms of the ability to use > different strategies, I believe that both defaults and clear guidance > should be provided. You'll doubtless agree that we must be careful here. We are in a universe in which there exist perfectly good routing protocols that operators are already comfortable with (notably OSPF and IS-IS). Babel's niche is the ability to adapt to environments where OSPF and IS-IS do not work well; if we restrict this flexibility too much, our niche vanishes. > Given that "not all...strategies will give good results" and that in > most cases these are listed as possible choices, I don't think that this > document "has resolved known design choices" [BCP9/rfc7127]. The > cost/metric computation and route selection specially concern me because > I believe that a robust/clear specification is at the heart of any > routing protocol. The point here is that Babel will still converge and will still behave in a loop-free manner whatever the algorithm chosen, as long as the conditions described in Section 3.5.2 hold. (This is provably true in the case where the metric is left-distributive, and believed to hold even if it is not.) I'll expand on the description of the suggested algorithms in Sections 3.5.2 and 3.6. However, I shall not make it a MUST, for the reasons outlined above. I hope that's okay with you. > (A1) Clear defaults. For example, Appendix B talks about constants/default > values. I would assume that, given the existing experience, that the values > there are probably sensible defaults. Is that not the case? I liken this to BFD. RFC 5880 does not give any default values for its timers, since the suitable values depend so much on the environment. The values suggested in Appendix B are suitable for a reasonably stable network where outages on the order of 6 to 10 seconds are acceptable. In mobile networks, Hello intervals of 0.5 yield better results. To the contrary, people running Babel over stable tunnels have been using much larger intervals. > (A2) Operational Considerations. Given that Babel can be (and is) used > in different environments, I would like to see guidance to operators as > they deploy the protocol in their networks. An example of the type of > discussion I would like to see expanded is: "a mobile node that is low > on battery may choose to use larger time constants (hello and update > intervals, etc.) than a node that has access to wall power" (1.1). > Consider 2 in rfc5706 (Operational Considerations - How Will the New > Protocol Fit into the Current Environment?). This is not clear to me. What exactly are you requesting here? As to your remaining points, I'll work on them, and reply once I've implemented your suggestions. -- Juliusz From nobody Wed Aug 7 08:51:02 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 8DDB412026E; Wed, 7 Aug 2019 08:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfZujukscU_G; Wed, 7 Aug 2019 08:50:58 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 AE6D812012D; Wed, 7 Aug 2019 08:50:58 -0700 (PDT) Received: from 200116b82c9bae003483c528e9ba9b65.dip.versatel-1u1.de ([2001:16b8:2c9b:ae00:3483:c528:e9ba:9b65]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hvODH-0004sq-Qo; Wed, 07 Aug 2019 17:50:55 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <87a7clhtke.wl-jch@irif.fr> Date: Wed, 7 Aug 2019 17:50:55 +0200 Cc: Donald Eastlake , babel-chairs@ietf.org, The IESG , babel@ietf.org, draft-ietf-babel-hmac@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156518028058.8361.10940272410936686016.idtracker@ietfa.amsl.com> <87imr9hyqc.wl-jch@irif.fr> <48D085EC-8B31-47FB-A4E1-05BB5CB30829@kuehlewind.net> <87ef1xhx1j.wl-jch@irif.fr> <87a7clhtke.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1565193058;93a2ec53; X-HE-SMSGID: 1hvODH-0004sq-Qo Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-hmac-08=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Wed, 07 Aug 2019 15:51:01 -0000 Hi, Inline. > On 7. Aug 2019, at 17:41, Juliusz Chroboczek wrote: >=20 >>>> You can also use a different timer e.g. 300s which would also = ensure >>>> that a challenge is not send more often than 300s (expect in the = case >>>> where you got a challenge reply but in case you are not talking to = an >>>> attacker and usually not need to send another challenge request >>>> immediately). >=20 >>> If the challenge reply is lost, then the challenge needs to be = resent. It >>> would not be acceptable to cause a 5 min blackhole after a single = packet >>> loss. >=20 >> Why 5 mins? >=20 > You're suggesting 300s in the excerpt cited above. Sorry I mean 300ms=E2=80=A6 (one important letter). >=20 >> If the challenge needs to be retransmitted, then the mechanism for >> retransmitting seems to be missing in the draft or what do I miss? >=20 > A -> B: Challenge > B -> A: Challenge reply gets lost >=20 > B -> multicast group: normal control packet But this is usually send every 4 seconds or so=E2=80=A6? So the = important but seem that these two values fit together. >=20 > (At B, the control packet fails the index test (5th bullet point in = 4.3).) >=20 > A -> B: Challenge I wouldn=E2=80=99t call this a retransmission but rather a new = Challenge=E2=80=A6 anyway that=E2=80=99s just naming=E2=80=A6 Mirja >=20 > -- Juliusz >=20 From nobody Wed Aug 7 09:16:49 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 D16C91205F5; Wed, 7 Aug 2019 09:16: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 U6GBXU1SWFkh; Wed, 7 Aug 2019 09:16:36 -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 5D8BA1205E6; Wed, 7 Aug 2019 09:16:27 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x77GGMbJ031570; Wed, 7 Aug 2019 18:16: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 4C2152AA39; Wed, 7 Aug 2019 18:16:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id cc1deQRL4k7r; Wed, 7 Aug 2019 18:16:24 +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 5478F2AA37; Wed, 7 Aug 2019 18:16:24 +0200 (CEST) Date: Wed, 07 Aug 2019 18:16:24 +0200 Message-ID: <87pnlhuf1j.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mirja Kuehlewind Cc: Donald Eastlake , babel-chairs@ietf.org, The IESG , babel@ietf.org, draft-ietf-babel-hmac@ietf.org In-Reply-To: References: <156518028058.8361.10940272410936686016.idtracker@ietfa.amsl.com> <87imr9hyqc.wl-jch@irif.fr> <48D085EC-8B31-47FB-A4E1-05BB5CB30829@kuehlewind.net> <87ef1xhx1j.wl-jch@irif.fr> <87a7clhtke.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 07 Aug 2019 18:16:22 +0200 (CEST) X-Miltered: at korolev with ID 5D4AF956.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4AF956.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 : 5D4AF956.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] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-babel-hmac-08=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Wed, 07 Aug 2019 16:16:40 -0000 > Sorry I mean 300ms… (one important letter). Ah, ok. I think I undestand what you mean now. > But this is usually send every 4 seconds or so…? Not necessarily. The timers are configurable, and there can be multiple packets sent over a single hello interval (e.g. when the routing table doesn't fit in a single packet). The rate limiting here is going to limit how fast we can acquire new neighbours in the presence of packet loss. The value 300ms was chosen as being a compromise between the amount of traffic an attacker can cause with replayed packets, and the hard limit it imposes on neighbour acquisition in the presence of packet loss. This has nothing to do with congestion control, Mirja, it's solely about resistance to DoS. In normal operation (with no evil attacker replaying massive numbers of packets and in the absence of packet loss), there's going to be just two challenge/reply exchanges (one in each direction) for every neighbour acquisition. This implies that there is no opportunity to establish RTT state, and no useful opportunity to reset timers when a reply is received. -- Juliusz From nobody Wed Aug 7 09:55: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 E17C21206A3; Wed, 7 Aug 2019 09:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPxTmfNwNabP; Wed, 7 Aug 2019 09:54:56 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 572891206FA; Wed, 7 Aug 2019 09:54:18 -0700 (PDT) Received: from 200116b82c9bae003483c528e9ba9b65.dip.versatel-1u1.de ([2001:16b8:2c9b:ae00:3483:c528:e9ba:9b65]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hvPCZ-0005Bg-Ll; Wed, 07 Aug 2019 18:54:15 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <87pnlhuf1j.wl-jch@irif.fr> Date: Wed, 7 Aug 2019 18:54:15 +0200 Cc: Donald Eastlake , babel-chairs@ietf.org, The IESG , babel@ietf.org, draft-ietf-babel-hmac@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5166AACD-49D1-4C59-8764-301D6DAF127C@kuehlewind.net> References: <156518028058.8361.10940272410936686016.idtracker@ietfa.amsl.com> <87imr9hyqc.wl-jch@irif.fr> <48D085EC-8B31-47FB-A4E1-05BB5CB30829@kuehlewind.net> <87ef1xhx1j.wl-jch@irif.fr> <87a7clhtke.wl-jch@irif.fr> <87pnlhuf1j.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1565196858;762f3fda; X-HE-SMSGID: 1hvPCZ-0005Bg-Ll Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-hmac-08=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Wed, 07 Aug 2019 16:55:00 -0000 Hi Juliusz, Okay, if I understand you correctly what you want is actually to limit = =E2=80=9Cfailed=E2=80=9D challenge requests only (where no reply is = received or the reply is not valid). Correct? I think then you should = specify it this way. Further if the goal is to not run into the rate = limit if a single packet is lost, then that is also possible with a = token-bucket-like approach, e.g. allow 3 non-confirmed challenges per = 10s (or even larger values depending in the expected loss rate). This = would make more sense to me as that avoids the dependency on the hello = interval. Mirja > On 7. Aug 2019, at 18:16, Juliusz Chroboczek wrote: >=20 >> Sorry I mean 300ms=E2=80=A6 (one important letter). >=20 > Ah, ok. I think I undestand what you mean now. >=20 >> But this is usually send every 4 seconds or so=E2=80=A6? >=20 > Not necessarily. The timers are configurable, and there can be = multiple > packets sent over a single hello interval (e.g. when the routing table > doesn't fit in a single packet). The rate limiting here is going to = limit > how fast we can acquire new neighbours in the presence of packet loss. > The value 300ms was chosen as being a compromise between the amount of > traffic an attacker can cause with replayed packets, and the hard = limit it > imposes on neighbour acquisition in the presence of packet loss. >=20 > This has nothing to do with congestion control, Mirja, it's solely = about > resistance to DoS. In normal operation (with no evil attacker = replaying > massive numbers of packets and in the absence of packet loss), there's > going to be just two challenge/reply exchanges (one in each direction) = for > every neighbour acquisition. This implies that there is no = opportunity > to establish RTT state, and no useful opportunity to reset timers when > a reply is received. >=20 > -- Juliusz >=20 >=20 From nobody Wed Aug 7 09:59: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 5949312068D for ; Wed, 7 Aug 2019 09:59:36 -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 hCslBn_L_5yb for ; Wed, 7 Aug 2019 09:59:33 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35BC61200F8 for ; Wed, 7 Aug 2019 09:59:33 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id i21so6905147ljj.3 for ; Wed, 07 Aug 2019 09:59:33 -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=XHdl0S+yOnon2Ma3jhsdN9YNM9WQsjjFxkK8EubSNZE=; b=qjyw0+8642CCk7AnSoCBin995lhuXm36/qTESUeuYZff98uqBBr9JoC9gUv2yv1lc/ ArzlOwF1oOC8SN40Sw2p9884R3leE6Zj5gQ9OGGCWdG4I/NG64CDi19iFGvoMPqeYlOR +Rnjbrk+Gnqb+kQowRaSMVfRoGWmzN4SjuA7vwbzD5MSVYd5hJPChmjz81GeslQdclLu GhS7rs11ecM3MwKrZLKdE2yxH+g99R3gsjWhsDMzHkYTPpfc8/d09xU4FxP3tk3nD1Qi FHC83/jfZgZDsW6PKgxv/XfE6ED5XeP3Wxwi5RKOIonk0WeEDLEHwv/2lOLXLibzRRgs 48kA== 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=XHdl0S+yOnon2Ma3jhsdN9YNM9WQsjjFxkK8EubSNZE=; b=oHUR64KBpi2OdsOQOQR1hWuv4GtDn+95dG75wmVQgZY5dwr5vhYb/UQp7TqEoCx841 KUAvg9b6uXnnQfLUQJp8Hq/3ykTWIox8eLC8g+Ys5woh9qLmkdD/ICn1d7hThA6qNNOG dEI0ul/JBwtOAa2Oxw+ukjEU1N6ROf84n0VHA6FtNnnfuyosXy8bFOmyFTDRs9500fw+ 5RimBxhKfiTvgQV8CqRwXUkhYO3csGnV5gCalmSwSpLTIz7F7hnDNx3nsTvbcLXCaKNz ah6ySTRru+sgvsObDezgj1sbQVoFzzxCaOKNi3JSI5CQgf9VIH9VF5+nsAvt9ObV+o4k vIpQ== X-Gm-Message-State: APjAAAWISVbC/8zYPz5XDg3c0VL44eVK9EpO/M4YcrU2qM4jCWlS0ob2 ashbaT94TKaCl5vRRLidnz5HuKd9qbZ1gvaItDE= X-Google-Smtp-Source: APXvYqxXeqq1DrhCoIOEdhB0aN4I9Cc9POPWiSgeS4w5K3zOL1RYdePr/nMJ3ya/21Cm1LoAs97tJ2zX5bIxKLbr9Ds= X-Received: by 2002:a2e:89c8:: with SMTP id c8mr5579117ljk.70.1565197171285; Wed, 07 Aug 2019 09:59:31 -0700 (PDT) MIME-Version: 1.0 References: <156105440578.3118.4917846383408119793.idtracker@ietfa.amsl.com> <9C5FD3EFA72E1740A3D41BADDE0B461FCFC76069@DGGEMM528-MBX.china.huawei.com> <87y305alt8.wl-jch@irif.fr> In-Reply-To: From: David Schinazi Date: Wed, 7 Aug 2019 09:59:20 -0700 Message-ID: To: Henning Rogge Cc: Juliusz Chroboczek , "Yemin (Amy)" , =?UTF-8?Q?Antonin_D=C3=A9cimo?= , Martin Vigoureux , =?UTF-8?Q?LucAndr=C3=A9_Burdet?= , Babel at IETF Content-Type: multipart/alternative; boundary="00000000000065e129058f89ddd0" Archived-At: Subject: Re: [babel] rtgdir Last Call Review requested: draft-ietf-babel-dtls 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: Wed, 07 Aug 2019 16:59:36 -0000 --00000000000065e129058f89ddd0 Content-Type: text/plain; charset="UTF-8" I think this thread may have forked... Henning's original email from July 5: https://mailarchive.ietf.org/arch/msg/babel/_Jt5gfUMQbnPJFdfvR7HhqO6vSc Juliusz and I replied shortly after: https://mailarchive.ietf.org/arch/msg/babel/yNGgOauQHCp5EyMj8ivQxdTcdJI https://mailarchive.ietf.org/arch/msg/babel/wZOOhPjOBK1xF6EsuxLTCdctcQE And Juliusz sent a new reply yesterday to which Henning responded: https://mailarchive.ietf.org/arch/msg/babel/vaJowPOfLBKblh5LYpwSstS7Ins https://mailarchive.ietf.org/arch/msg/babel/cDvi0BzZoJXUo3TOpkq4YlfZvcY To summarize the discussions in all these threads. (1) Bidirectional reachability is protected by DTLS by requiring IHU to be sent protected, this reduces the security boundary of the protocol. (2) We've added text documenting what to do when a node receives a new connection, this prevents attackers from impacting the neighbor table (3) We've added text discussing that different ciphers can have different overheads and that needs to be taken into account when computing MTU (4) An attacker can create state on a victim by creating many DTLS connection attempts. We rely on DTLS's DoS prevention mechanisms (such as cookies) to avoid these issues. We've made changes to the draft from these comments, and they landed in draft -07: https://tools.ietf.org/html/draft-ietf-babel-dtls-07 Please let me know if I missed anything. Thanks, David On Wed, Aug 7, 2019 at 3:57 AM Henning Rogge wrote: > On Wed, Aug 7, 2019 at 1:58 AM Juliusz Chroboczek wrote: > > > > Hi Henning, > > > > Good to hear from you again. > > > > The two main authors of this draft appear to be on holiday, so I'll > answer > > your review to the best of my capacities. > > > > > Chapter 2.3: > > > I wonder if using DTLS protected unicast Hellos should be mandatory... > > > using unprotected multicast to determine bidirectional reachability > > > looks like a good way to do a cheap denial ofa service attack. > > > > In Babel, bidirectional reachability is established by a Hello/IHU > > exchange. This document requires IHUs to be authenticated, therefore > > bidirectional reachability will never be established with an attacker. > > > > However, this doesn't prevent DoS attacks: > > > > - an attacker could send cleartext Hellos from spoofed addresses, thus > > causing the victim to create unbounded numbers of neighbour entries; > > - an attacker could send DTLS ClientHello packets from spoofed > > addresses, with a similar effect. > > As long as this "unverified" links are not used for global routing I > would not be worried... > > you can never prevent a direct neighbor from doing a DoS. > > > Requiring an authenticated Hello is not workable, since an authenticated > > Hello cannot be sent until after the DTLS handshake has completed. > > And there is also the point that DTLS and Multicast don't mix well... > > > This is somewhat mitigated by the fact that only packets from link-local > > addresses are accepted (see Section 2.1 of this draft and Section 4 of > > RFC 6126bis). This is what the draft has to say on the subject (Section > 5): > > > A malicious client might attempt to perform a high number of DTLS > > handshakes with a server. As the clients are not uniquely identified > > by the protocol and can be obfuscated with IPv6 temporary addresses, > > a server needs to mitigate the impact of such an attack. Such > > mitigation might involve rate limiting handshakes from a given subnet > > or more advanced denial of service avoidance techniques beyond the > > scope of this document. > > > > I'm not happy with this either. > > I think some parts of this information could be useful for the > Security Considerations section. > > Most people don't know BABEL that deep, so giving them some advise > what has already been considered and what no is always good. > > > > Chapter 2.5: > > > > What happens when a node starts a new DTLS connection and there is > > > already one in the neighbor table? This could both be an attempt to > > > attack Babel, a reboot of a node or just a matter of misconfiguration > > > of two nodes. > > > > Section 2.1: > > > > If a node receives a new DTLS connection from a neighbour to whom it > > already has a connection, the node MUST NOT discard the older > > connection until it has completed the handshake of the new one and > > validated the identity of the peer. > > Sorry, missed that... good to see it has already dealt with. > > > > Chapter 3: > > > Different pairs of nodes could select different ciphers, resulting in > > > different MTUs. I assume this is no problem for Babel (could be > > > mentioned in the chapter). > > > > I am not competent to answer this, we'll need to wait for David or > > Antonin to resurface. > > Sure... I was away fore quite a while too after my post. > > Henning Rogge > --00000000000065e129058f89ddd0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this thread may have forked...

= Henning's original email from July 5:

Juliusz and I replied shortly after:

And Juliusz sent a new r= eply yesterday to which Henning responded:
https://mailarchive.ietf.org/arch/msg/babel/cDvi0BzZoJXUo3TOpkq4= YlfZvcY

To summarize the discussions in al= l these threads.

(1) Bidirectional reachability is= protected by DTLS by requiring IHU to be sent
protected, this re= duces the security boundary of the protocol.

(2) W= e've added text documenting what to do when a node receives a new
=
connection, this prevents attackers from impacting the neighbor table<= /div>

(3) We've added text discussing that different= ciphers can have different
overheads and that needs to be taken = into account when computing MTU

(4) An attacker ca= n create state on a victim by creating many DTLS
connection attem= pts. We rely on DTLS's DoS prevention mechanisms
(such as coo= kies) to avoid these issues.

We've made change= s to the draft from these comments, and=C2=A0they landed in draft -07:

Please let me know if I missed anything.

Th= anks,
David



On Wed, Aug 7, 201= 9 at 3:57 AM Henning Rogge <hrogge@g= mail.com> wrote:
On Wed, Aug 7, 2019 at 1:58 AM Juliusz Chroboczek <jch@irif.fr> wrote:
>
> Hi Henning,
>
> Good to hear from you again.
>
> The two main authors of this draft appear to be on holiday, so I'l= l answer
> your review to the best of my capacities.
>
> > Chapter 2.3:
> > I wonder if using DTLS protected unicast Hellos should be mandato= ry...
> > using unprotected multicast to determine bidirectional reachabili= ty
> > looks like a good way to do a cheap denial ofa service attack. >
> In Babel, bidirectional reachability is established by a Hello/IHU
> exchange.=C2=A0 This document requires IHUs to be authenticated, there= fore
> bidirectional reachability will never be established with an attacker.=
>
> However, this doesn't prevent DoS attacks:
>
>=C2=A0 =C2=A0- an attacker could send cleartext Hellos from spoofed add= resses, thus
>=C2=A0 =C2=A0 =C2=A0causing the victim to create unbounded numbers of n= eighbour entries;
>=C2=A0 =C2=A0- an attacker could send DTLS ClientHello packets from spo= ofed
>=C2=A0 =C2=A0 =C2=A0addresses, with a similar effect.

As long as this "unverified" links are not used for global routin= g I
would not be worried...

you can never prevent a direct neighbor from doing a DoS.

> Requiring an authenticated Hello is not workable, since an authenticat= ed
> Hello cannot be sent until after the DTLS handshake has completed.

And there is also the point that DTLS and Multicast don't mix well...
> This is somewhat mitigated by the fact that only packets from link-loc= al
> addresses are accepted (see Section 2.1 of this draft and Section 4 of=
> RFC 6126bis).=C2=A0 This is what the draft has to say on the subject (= Section 5):

>=C2=A0 =C2=A0 A malicious client might attempt to perform a high number= of DTLS
>=C2=A0 =C2=A0 handshakes with a server.=C2=A0 As the clients are not un= iquely identified
>=C2=A0 =C2=A0 by the protocol and can be obfuscated with IPv6 temporary= addresses,
>=C2=A0 =C2=A0 a server needs to mitigate the impact of such an attack.= =C2=A0 Such
>=C2=A0 =C2=A0 mitigation might involve rate limiting handshakes from a = given subnet
>=C2=A0 =C2=A0 or more advanced denial of service avoidance techniques b= eyond the
>=C2=A0 =C2=A0 scope of this document.
>
> I'm not happy with this either.

I think some parts of this information could be useful for the
Security Considerations section.

Most people don't know BABEL that deep, so giving them some advise
what has already been considered and what no is always good.

> > Chapter 2.5:

> > What happens when a node starts a new DTLS connection and there i= s
> > already one in the neighbor table? This could both be an attempt = to
> > attack Babel, a reboot of a node or just a matter of misconfigura= tion
> > of two nodes.
>
> Section 2.1:
>
>=C2=A0 =C2=A0 If a node receives a new DTLS connection from a neighbour= to whom it
>=C2=A0 =C2=A0 already has a connection, the node MUST NOT discard the o= lder
>=C2=A0 =C2=A0 connection until it has completed the handshake of the ne= w one and
>=C2=A0 =C2=A0 validated the identity of the peer.

Sorry, missed that... good to see it has already dealt with.

> > Chapter 3:
> > Different pairs of nodes could select different ciphers, resultin= g in
> > different MTUs. I assume this is no problem for Babel (could be > > mentioned in the chapter).
>
> I am not competent to answer this, we'll need to wait for David or=
> Antonin to resurface.

Sure... I was away fore quite a while too after my post.

Henning Rogge
--00000000000065e129058f89ddd0-- From nobody Wed Aug 7 10:46:21 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 314D11204AE; Wed, 7 Aug 2019 10:46:20 -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 6NGOlUoUm8eh; Wed, 7 Aug 2019 10:46:17 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 91A201200F8; Wed, 7 Aug 2019 10:46:16 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id 62so59796812lfa.8; Wed, 07 Aug 2019 10:46:16 -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=7s9QQVLEvI1ekJKL6ePi1lHnloOmKw/fe+3KTySZ4Yg=; b=NOmlUywoCI2Y61hp/AthE0SsTE7LDhroS3t5ybdyU32MwjNS1S/3zW2UmdCbbo/Y87 NDK+G+PobYWzX/1O7Q5B9n0AhWM6rKg3r2FD8Q10FN0ZDxjRV8j+Bg5GOozrzDGAsQ8z ybnou6jV+SxgTN1j9zgr+us243roGwVD6dP3X19vWE1VxNIBBda4nZM0Y0G+rAn4ITEx pDEeHod1nHpk/ZDLwyR37FZWqjU06VRMYhO5TFGu4EJqdWCRWtuy3NeqF5f5bnFHaCUJ YRz1NAq5XTfMjT6BrA3PF7Z2aoo6qG3J4w2L7NFR8M0Yo30woS7hK5PaJxfklPinxSF1 LH+Q== 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=7s9QQVLEvI1ekJKL6ePi1lHnloOmKw/fe+3KTySZ4Yg=; b=WrVyjW0xNupQJ3KI0JQUZf41RzBOKezdv+cSBqnkeHzRizDJtEG6EIRGxbZM9hCKMK chMaDuoQnJOFHc3cTTKoFCSmzZTUaDDGGQMxBLEJClzNkmXjZ5T25o9/jHpk+e2ZG/wq ZQ4moBiujuZEPYUbZjajvgoWeqgiMQ5vzsjBpfClJsMUmT51DFj/WqdMWunLN0R3O2Xv OeT2xGtjCIvduvI+tLPvTO5Z2vQP/Gw9TC+S5TZsWH/yksHgAzTYZLDgIdgJ2Q+dHrC1 tcL4w2ydOAfDvyEyLNogtCQKGhz0kRqUh2f0l3bUlhCpd/pdwpOMZhN2ZdZS7UcOZXf7 dMlw== X-Gm-Message-State: APjAAAX9M9tmefCLnGOu4/x4KDY3u8fagjdEwI85OJ1Nxzm/LckrsHAy GShgI2JOPiQVxppU0fZzBlKPiekQ/gPPT3HduTg= X-Google-Smtp-Source: APXvYqxE6LeeNIAuwYYi70Tghw1SnKN2Nx1JtC2kLZF7gbz9WvYin/Sppnq+RA9wVsF23rDGgnCPyGby1WAjyNg7VI4= X-Received: by 2002:a19:428c:: with SMTP id p134mr5996508lfa.166.1565199974604; Wed, 07 Aug 2019 10:46:14 -0700 (PDT) MIME-Version: 1.0 References: <156105440578.3118.4917846383408119793.idtracker@ietfa.amsl.com> <9C5FD3EFA72E1740A3D41BADDE0B461FCFC76069@DGGEMM528-MBX.china.huawei.com> <87y305alt8.wl-jch@irif.fr> In-Reply-To: From: David Schinazi Date: Wed, 7 Aug 2019 10:46:03 -0700 Message-ID: To: Henning Rogge , iesg@ietf.org Cc: Juliusz Chroboczek , "Yemin (Amy)" , =?UTF-8?Q?Antonin_D=C3=A9cimo?= , Martin Vigoureux , =?UTF-8?Q?LucAndr=C3=A9_Burdet?= , Babel at IETF Content-Type: multipart/alternative; boundary="0000000000007d23d9058f8a8449" Archived-At: Subject: Re: [babel] rtgdir Last Call Review requested: draft-ietf-babel-dtls 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: Wed, 07 Aug 2019 17:46:20 -0000 --0000000000007d23d9058f8a8449 Content-Type: text/plain; charset="UTF-8" [Adding the IESG to this thread since there might be overlap between conversations] On Wed, Aug 7, 2019 at 9:59 AM David Schinazi wrote: > I think this thread may have forked... > > Henning's original email from July 5: > https://mailarchive.ietf.org/arch/msg/babel/_Jt5gfUMQbnPJFdfvR7HhqO6vSc > > Juliusz and I replied shortly after: > https://mailarchive.ietf.org/arch/msg/babel/yNGgOauQHCp5EyMj8ivQxdTcdJI > https://mailarchive.ietf.org/arch/msg/babel/wZOOhPjOBK1xF6EsuxLTCdctcQE > > And Juliusz sent a new reply yesterday to which Henning responded: > https://mailarchive.ietf.org/arch/msg/babel/vaJowPOfLBKblh5LYpwSstS7Ins > https://mailarchive.ietf.org/arch/msg/babel/cDvi0BzZoJXUo3TOpkq4YlfZvcY > > To summarize the discussions in all these threads. > > (1) Bidirectional reachability is protected by DTLS by requiring IHU to be > sent > protected, this reduces the security boundary of the protocol. > > (2) We've added text documenting what to do when a node receives a new > connection, this prevents attackers from impacting the neighbor table > > (3) We've added text discussing that different ciphers can have different > overheads and that needs to be taken into account when computing MTU > > (4) An attacker can create state on a victim by creating many DTLS > connection attempts. We rely on DTLS's DoS prevention mechanisms > (such as cookies) to avoid these issues. > > We've made changes to the draft from these comments, and they landed in > draft -07: > https://tools.ietf.org/html/draft-ietf-babel-dtls-07 > > Please let me know if I missed anything. > > Thanks, > David > > > > On Wed, Aug 7, 2019 at 3:57 AM Henning Rogge wrote: > >> On Wed, Aug 7, 2019 at 1:58 AM Juliusz Chroboczek wrote: >> > >> > Hi Henning, >> > >> > Good to hear from you again. >> > >> > The two main authors of this draft appear to be on holiday, so I'll >> answer >> > your review to the best of my capacities. >> > >> > > Chapter 2.3: >> > > I wonder if using DTLS protected unicast Hellos should be mandatory... >> > > using unprotected multicast to determine bidirectional reachability >> > > looks like a good way to do a cheap denial ofa service attack. >> > >> > In Babel, bidirectional reachability is established by a Hello/IHU >> > exchange. This document requires IHUs to be authenticated, therefore >> > bidirectional reachability will never be established with an attacker. >> > >> > However, this doesn't prevent DoS attacks: >> > >> > - an attacker could send cleartext Hellos from spoofed addresses, thus >> > causing the victim to create unbounded numbers of neighbour entries; >> > - an attacker could send DTLS ClientHello packets from spoofed >> > addresses, with a similar effect. >> >> As long as this "unverified" links are not used for global routing I >> would not be worried... >> >> you can never prevent a direct neighbor from doing a DoS. >> >> > Requiring an authenticated Hello is not workable, since an authenticated >> > Hello cannot be sent until after the DTLS handshake has completed. >> >> And there is also the point that DTLS and Multicast don't mix well... >> >> > This is somewhat mitigated by the fact that only packets from link-local >> > addresses are accepted (see Section 2.1 of this draft and Section 4 of >> > RFC 6126bis). This is what the draft has to say on the subject >> (Section 5): >> >> > A malicious client might attempt to perform a high number of DTLS >> > handshakes with a server. As the clients are not uniquely identified >> > by the protocol and can be obfuscated with IPv6 temporary addresses, >> > a server needs to mitigate the impact of such an attack. Such >> > mitigation might involve rate limiting handshakes from a given subnet >> > or more advanced denial of service avoidance techniques beyond the >> > scope of this document. >> > >> > I'm not happy with this either. >> >> I think some parts of this information could be useful for the >> Security Considerations section. >> >> Most people don't know BABEL that deep, so giving them some advise >> what has already been considered and what no is always good. >> >> > > Chapter 2.5: >> >> > > What happens when a node starts a new DTLS connection and there is >> > > already one in the neighbor table? This could both be an attempt to >> > > attack Babel, a reboot of a node or just a matter of misconfiguration >> > > of two nodes. >> > >> > Section 2.1: >> > >> > If a node receives a new DTLS connection from a neighbour to whom it >> > already has a connection, the node MUST NOT discard the older >> > connection until it has completed the handshake of the new one and >> > validated the identity of the peer. >> >> Sorry, missed that... good to see it has already dealt with. >> >> > > Chapter 3: >> > > Different pairs of nodes could select different ciphers, resulting in >> > > different MTUs. I assume this is no problem for Babel (could be >> > > mentioned in the chapter). >> > >> > I am not competent to answer this, we'll need to wait for David or >> > Antonin to resurface. >> >> Sure... I was away fore quite a while too after my post. >> >> Henning Rogge >> > --0000000000007d23d9058f8a8449 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[Adding the IESG to this thread since the= re might be overlap between conversations]

On Wed, Aug 7, 2019 at 9:59 AM Da= vid Schinazi <dschinazi.ietf= @gmail.com> wrote:
I think this thread may have forked...

=
Henning's original email from July 5:

Juliusz and I replied shortly = after:

And Juliusz sent a new reply yest= erday to which Henning responded:

To summ= arize the discussions in all these threads.

(1) Bi= directional reachability is protected by DTLS by requiring IHU to be sent
protected, this reduces the security boundary of the protocol.

(2) We've added text documenting what to do when = a node receives a new
connection, this prevents attackers from im= pacting the neighbor table

(3) We've added tex= t discussing that different ciphers can have different
overheads = and that needs to be taken into account when computing MTU

(4) An attacker can create state on a victim by creating many DTLS=
connection attempts. We rely on DTLS's DoS prevention mechan= isms
(such as cookies) to avoid these issues.

We've made changes to the draft from these comments, and=C2=A0the= y landed in draft -07:

Please let me know if I= missed anything.

Thanks,
David



On Wed, Aug 7, 2019 at 3:57 AM Henning Rogge <= ;hrogge@gmail.com= > wrote:
On W= ed, Aug 7, 2019 at 1:58 AM Juliusz Chroboczek <jch@irif.fr> wrote:
>
> Hi Henning,
>
> Good to hear from you again.
>
> The two main authors of this draft appear to be on holiday, so I'l= l answer
> your review to the best of my capacities.
>
> > Chapter 2.3:
> > I wonder if using DTLS protected unicast Hellos should be mandato= ry...
> > using unprotected multicast to determine bidirectional reachabili= ty
> > looks like a good way to do a cheap denial ofa service attack. >
> In Babel, bidirectional reachability is established by a Hello/IHU
> exchange.=C2=A0 This document requires IHUs to be authenticated, there= fore
> bidirectional reachability will never be established with an attacker.=
>
> However, this doesn't prevent DoS attacks:
>
>=C2=A0 =C2=A0- an attacker could send cleartext Hellos from spoofed add= resses, thus
>=C2=A0 =C2=A0 =C2=A0causing the victim to create unbounded numbers of n= eighbour entries;
>=C2=A0 =C2=A0- an attacker could send DTLS ClientHello packets from spo= ofed
>=C2=A0 =C2=A0 =C2=A0addresses, with a similar effect.

As long as this "unverified" links are not used for global routin= g I
would not be worried...

you can never prevent a direct neighbor from doing a DoS.

> Requiring an authenticated Hello is not workable, since an authenticat= ed
> Hello cannot be sent until after the DTLS handshake has completed.

And there is also the point that DTLS and Multicast don't mix well...
> This is somewhat mitigated by the fact that only packets from link-loc= al
> addresses are accepted (see Section 2.1 of this draft and Section 4 of=
> RFC 6126bis).=C2=A0 This is what the draft has to say on the subject (= Section 5):

>=C2=A0 =C2=A0 A malicious client might attempt to perform a high number= of DTLS
>=C2=A0 =C2=A0 handshakes with a server.=C2=A0 As the clients are not un= iquely identified
>=C2=A0 =C2=A0 by the protocol and can be obfuscated with IPv6 temporary= addresses,
>=C2=A0 =C2=A0 a server needs to mitigate the impact of such an attack.= =C2=A0 Such
>=C2=A0 =C2=A0 mitigation might involve rate limiting handshakes from a = given subnet
>=C2=A0 =C2=A0 or more advanced denial of service avoidance techniques b= eyond the
>=C2=A0 =C2=A0 scope of this document.
>
> I'm not happy with this either.

I think some parts of this information could be useful for the
Security Considerations section.

Most people don't know BABEL that deep, so giving them some advise
what has already been considered and what no is always good.

> > Chapter 2.5:

> > What happens when a node starts a new DTLS connection and there i= s
> > already one in the neighbor table? This could both be an attempt = to
> > attack Babel, a reboot of a node or just a matter of misconfigura= tion
> > of two nodes.
>
> Section 2.1:
>
>=C2=A0 =C2=A0 If a node receives a new DTLS connection from a neighbour= to whom it
>=C2=A0 =C2=A0 already has a connection, the node MUST NOT discard the o= lder
>=C2=A0 =C2=A0 connection until it has completed the handshake of the ne= w one and
>=C2=A0 =C2=A0 validated the identity of the peer.

Sorry, missed that... good to see it has already dealt with.

> > Chapter 3:
> > Different pairs of nodes could select different ciphers, resultin= g in
> > different MTUs. I assume this is no problem for Babel (could be > > mentioned in the chapter).
>
> I am not competent to answer this, we'll need to wait for David or=
> Antonin to resurface.

Sure... I was away fore quite a while too after my post.

Henning Rogge
--0000000000007d23d9058f8a8449-- From nobody Wed Aug 7 11:01:14 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 1FE8C1206B5 for ; Wed, 7 Aug 2019 11:01:13 -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 i-ICCySbNWXy for ; Wed, 7 Aug 2019 11:01:11 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 669E61206DC for ; Wed, 7 Aug 2019 11:00:55 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id c14so41849484plo.0 for ; Wed, 07 Aug 2019 11:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6odln8MLVW09IGkc/9zFwIhLq5az8x8pGFINdgIh3rw=; b=oGWzLoq+jibfevSyoudoiFsD8lsmzffKuCvkY+TMOqIdzEuBV6xzoFbyOt0XPL9vYL JBcmQGtqV+wwqQs7K34KYf38jC5CMlU3dNLIxT5sLRWzYSgSDmkvq/49xnfczrfmO6py upeqHL/7zYjKrmUT0OocuNNtooHzM8VplpXRVfEaj3TyIQyOyLX86LxFC2pbtbuMJgWY XWBw8xF+2in48ezp7s3LgOZCbdvSK6GgpcLzMSa3+/PixFMfKCojQnSkYyD6jkmvfE79 2kBaveRG3G3o/rxgQ7/s/0rJFj7EBJxkhXjREcwY5B4YqgEJK7tIFyERF+f0m4YWU9an pafA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6odln8MLVW09IGkc/9zFwIhLq5az8x8pGFINdgIh3rw=; b=jG51l98hkKdknZ0MXdohWC0KT1NpkVLtVec5pxFny7osMDQOZTMQbk0iJCcHabgJBI JZaIjfmo9Ntr0DbAJ+TR2vVZRXv7jSHpVCeHAa+BZB1rzHhm5ESNm0jrZTrrGyYodZvC rhrwmORZsfZG7HLtOcCHiaV0DpeB9LEzFiCwkVeI9DbkP2LYs0PFBnIaDQQPRstOViha cBJRvXMBMv2L8Hh2Kh6MPAoPaNyNMa7L47Hww8p6yDvu/d12qNPtRotmJNE3GRTpAE/Z MV+UCCGqQMG/VtNWT1Qf5AadeJjGaF9FS/t2edarrkmE4dxhEOXLU1aCqANT4aGP8iql AaDQ== X-Gm-Message-State: APjAAAUwdjggmH4fTTRhcfsw0/KdCBt1bB/YirzXz2nRY+YYBoI5b0Hr Q9nd2Czs6aeBTOl4TtJ7NoZoahJiEXY= X-Google-Smtp-Source: APXvYqx2j5nORjGcWHKwKZgqrR7nxnef3omj6g/5nN/zDmKjKMUcks5WeoqX7prRupy+NMy+K8JQaQ== X-Received: by 2002:a63:5162:: with SMTP id r34mr8477060pgl.229.1565200854611; Wed, 07 Aug 2019 11:00:54 -0700 (PDT) Received: from [10.33.122.240] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id o13sm560077pje.28.2019.08.07.11.00.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Aug 2019 11:00:53 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <77A2E411-0F0B-4988-9A2D-2A53815CD164@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E4BF334E-C969-4552-8B65-2607BEF0AB39" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 7 Aug 2019 11:00:52 -0700 In-Reply-To: <87pnlhaixh.wl-jch@irif.fr> Cc: Babel at IETF To: Juliusz Chroboczek References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr> <87pnlhaixh.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Example configuration 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: Wed, 07 Aug 2019 18:01:13 -0000 --Apple-Mail=_E4BF334E-C969-4552-8B65-2607BEF0AB39 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Juliusz, > On Aug 6, 2019, at 6:00 PM, Juliusz Chroboczek wrote: >=20 > I think we're not understanding each other. I am not arguing about = hiding > any information, quite the opposite, I am in favour of exporting the > underlying properties and leaving the link type to the UI. My bad. My understanding from the changes that Barbara made in -08 (by = removing the UI and the underlying properties) was that they were not = desired. Are you be ok with the changes I suggested yesterday on the additions to = the information model, that exposes both the underlying property and the = UI associated with it? Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_E4BF334E-C969-4552-8B65-2607BEF0AB39 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Juliusz,

On Aug 6, 2019, at 6:00 PM, Juliusz = Chroboczek <jch@irif.fr> wrote:

I think we're not understanding = each other.  I am not arguing about hiding
any information, quite the = opposite, I am in favour of exporting the
underlying properties and leaving the link type to the = UI.

My bad. My = understanding from the changes that Barbara made in -08 (by removing the = UI and the underlying properties) was that they were not = desired.

Are you be ok with the = changes I suggested yesterday on the additions to the information model, = that exposes both the underlying property and the UI associated with = it?

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_E4BF334E-C969-4552-8B65-2607BEF0AB39-- From nobody Wed Aug 7 11:05: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 7F04612068D for ; Wed, 7 Aug 2019 11:05:13 -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 uzwA2VIt-_nU for ; Wed, 7 Aug 2019 11:05:11 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 208881202E1 for ; Wed, 7 Aug 2019 11:05:11 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id y8so41964264plr.12 for ; Wed, 07 Aug 2019 11:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2T554cNh3Smu726jqBKhhD8R/KMMbx2k79EaPeRnWvA=; b=IVoHYad7lwzobZYKiMIcgPVax97eK1wFLdV+moSm/l+kIiqMBg4JlF9NVCpFbpU8Eg XEgiCIPrC7Dt15VprE4ImKeNBrz+I7FjK/nfiBY2eWDEkX38HZSFD06+t1AGBsMA3POq KrlUikEpLml9QAtqJiMB9QKK+rQpcyQs//yKcEhPATRLtTMLUcf23KoPja2DVSVraLmj Do6ueviHnDdIYXdbliFbN2JWElAnz5qkMkjELkLC9yPaVApSUl9zV6gOBi8p5A7a12+I um7X0x3bH7OYVg90XEulKH0NaIp8aKCNlo8TRo3hI0wSBsaA+lDCKD+TA67jcJ7WjA83 Zi3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2T554cNh3Smu726jqBKhhD8R/KMMbx2k79EaPeRnWvA=; b=bhrl2660QsW9/Qrpw+AevLCNCGe9S87X4qkTS17YzomZJjO/FgmnGjBB8978W1lWvR ua5HpKCJ+YjWQvUDrC2jpnbSs2KGwfUqNt85LDRUVH0SkZ2UHXtP38tg1Mc+UfBHvpFW U8eReyXnB9M3XPmJVrDN7dtR+HZQuEPTs4pcYOYpnQQ2geHVYQC6dT7LbECAlAOHp87U W/48SPeZJRCjUVPD7jQRU7CheSztKrT6776gp4/OTZXAJ4RiLKwagvtvmSGRh9RlbT3c IVjiXTsY6MiiYYHg1FbTm5joRn744O75QrtM0FHoLldArvFcfGccim3MPULkqCrGYPpY D+1A== X-Gm-Message-State: APjAAAVX4aUmbqR3uHdBIyTg+Vwkg6974c8vVl+VdukCYvHwOMAHM6P6 gIMAcosluU7yqnBgINI//zE= X-Google-Smtp-Source: APXvYqzINgGw3Ei4rcwTOpgB8Gi4R5bAazkX5Hf3hPkJQ7KgRDDZA5ho6asaTNI/D2xRUIQrSnBSNA== X-Received: by 2002:aa7:92cb:: with SMTP id k11mr10786029pfa.126.1565201110586; Wed, 07 Aug 2019 11:05:10 -0700 (PDT) Received: from [10.33.122.240] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id z4sm140386177pfg.166.2019.08.07.11.05.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Aug 2019 11:05:10 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <0B28A1FA-32B4-41E6-B646-C6A3907E9CCC@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F79A4954-00C2-40C8-BDFC-7801F2BE450D" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 7 Aug 2019 11:05:09 -0700 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E257961@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: Juliusz Chroboczek , Babel at IETF To: "STARK, BARBARA H" References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr> <87pnlhaixh.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E257961@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Example configuration 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: Wed, 07 Aug 2019 18:05:14 -0000 --Apple-Mail=_F79A4954-00C2-40C8-BDFC-7801F2BE450D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Barbara, > On Aug 7, 2019, at 6:25 AM, STARK, BARBARA H wrote: >=20 >>>> The protocol doesn't know about interface types. =46rom the point = of >>>> view of the protocol, there are a number of algorithms that can >>>> optionally be selected or enabled on a given interface. These = include: >>>>=20 >>>> - link-quality estimation (2-out-of-3 or ETX); >>>> - split-horizon (on or off); >>>> - RTT estimation (draft-ietf-babel-rtt); >>>> - use of unicast instead of multicast; >>>> - ... >>=20 >>> In -08 version of the draft, all references to wired, wireless, = tunnel >>> and others are gone. That in addition to babel-link-properties. If >>> they are underlying parameters, they are truly invisible :-). >>=20 >> Wired, wireless etc. are the UI interface types. The underlying = properties are >> link-quality and split-horizon (in RFC 6126bis) and the RTT = estimation >> parameters (in draft-ietf-babel-rtt). >>=20 >>> I understand that it is difficult for an operatori without intimate >>> knowledge to know how to configure these properties. And that is why >>> these should be optional properties. However, without them, there is >>> no way for an operator to influence how the protocol works. >=20 > "Optional property" has different meanings to different people and = different data modeling schemes. I've started trying to be very = explicit: (1) Does a parameter (YANG leaf) have a universally-agreed = default value (e.g., the UDP port)? (2) Can the management system cause = an object (YANG leaf-list) instance to be created and some of the = parameters (leafs) will be implicitly set to known default values (e.g., = the hmac-keys and dtls-certs Booleans)? (3) Are the allowed values for = some parameters (leafs) constrained to a specific range, cannot be null, = are an enumeration, etc. (e.g., interface metric-algorithm)? (4) If an = implementation does not include a particular parameter (leaf), can it = still be considered compliant with the info model (in YANG terms: Can a = specific Babel implementation have a YANG deviation statement for = something and still be compliant with the info model) [this is not = directly reflected in the YANG model]? >=20 > In the context of interface metric-algorithm and split-horizon, the = management system will never "create" these parameters (because all = interface instances are created by the Babel implementation and cannot = be created by the management system), and there are no = universally-agreed defaults. So (1) and (2) don't apply. The models = allow the management system to overwrite the value the implementation = chose for the interface. We're constraining the allowed values the = management system can use when overwriting these. So (3) applies. The = YANG model needs to constrain the value of these sorts of parameters to = being in the enumeration, but doesn't need a default. What I was referring to as =E2=80=9Coptional property=E2=80=9D is more = like (4), minus the need to deviate away from the YANG model. They are = optional in the sense that a particular Babel implementation will work = just fine without having to configure the optional parameters. As an = example, if the user/operator wants to change the particular behavior on = a particular interface would they need to configure the (optional) link = properties.=20 BTW, leafs such as link properties are optional to configure, but not = optional to support/implement. If the implementation does not want to = support/implement, e.g. a particular link property, they would need to = deviate what they do not support from the model.=20 Hope the distinction between =E2=80=9Coptional property=E2=80=9D and = deviation is clear. >=20 >> I think we're not understanding each other. I am not arguing about = hiding >> any information, quite the opposite, I am in favour of exporting the >> underlying properties and leaving the link type to the UI. >>=20 >>>> I don't think we have the manpower to do a good job. >>=20 >>> Ok. Let me follow up on the separate e-mail thread that you started >>> with describing Babel filtering and routing policies. If it becomes >>> too complex, we can drop it. >>=20 >> Sure, but please keep my comment about manpower in mind. >=20 > I think the problem we're facing is that Babel implementations are = perfectly capable of operating well without being explicitly configured = (other than enabling/disabling it). Babel is specifically designed that = way. But that doesn't necessitate "hiding" things. >=20 > Here is what I think would be common "configuration" scenarios: > - The most common "configuration" would be to simply enable Babel.=20 > - The next most common configuration would be to enable/disable it on = specific interfaces (using the enable parameter in babel-interfaces). = This may be done at the same time Babel is enabled (if the Babel = implementation creates the interfaces instances even though Babel isn't = enabled). Or later. It may need to be a separate configuration call, = because the Babel implementation may not create the interfaces instances = unless it is enabled. If it is a separate configuration call, the = operator will probably need to read the configuration first, to see what = interfaces Babel has identified it can run on, and which of these it has = auto-enabled / auto-disabled. > - The next thing someone would want to do is not configuration, but = just reading info about the status of Babel. Some of the expressed = status is the metric-algorithm (not link-quality, which is not a = parameter) and split-horizon (true/false as to whether it's used) that = was selected by the implementation for use on each interface. The Babel = model is small enough that the person would probably find it easiest = just to ask for everything. > - It's possible that in looking at the status, the operator doesn't = like the choices the implementation made wrt metric-algorithm or = split-horizon, for an interface. The operator needs to have the ability = to change those choices. The values the operator can change to are = constrained.=20 > - It's possible that in looking at the status, the operator thinks = things don't look right and wants to troubleshoot by getting more = detailed statistics and maybe even a message log. So the operator = enables statistics and message log. The operator waits a few seconds and = reads statistics and the message log. Maybe the operator does something = that fixes the problem. The operator then disables statistics and = message log. >=20 > So maybe the "example configuration" is a sequence of YANG messages: > 1. Enable Babel > 2. Read the interfaces leaf-list. > 3. Enable/disable Babel on specific interfaces, as desired. > 4. Read everything. > 5. Update metric-algorithm and split-horizon values for a specific = interface. This is a perfectly valid sequence of RPC (not YANG) messages that are = exchanged.=20 What I had in mind for the updates to the information model are step 5. = If the operator needs to update link-quality, or flip on split-horizon, = or set a RTT estimate value, or specify whether they want to use unicast = instead of multicast, or any combination thereof for a particular = interface, they would create a new babel-link-properties object and = associate that with the interface. Can we agree on the changes to the information model I suggested = yesterday? >=20 > For troubleshooting: > 6. Enables statistics and message log. > 7. Read statistics and message log. > 8. Disable statistics and message log. >=20 > Barbara Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_F79A4954-00C2-40C8-BDFC-7801F2BE450D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Barbara,

On Aug 7, 2019, at 6:25 AM, STARK, BARBARA H = <bs7652@att.com> = wrote:

The protocol doesn't know about interface types.  =46rom = the point of
view of the protocol, there are a number of = algorithms that can
optionally be selected or enabled on a = given interface.  These include:

- = link-quality estimation (2-out-of-3 or ETX);
- = split-horizon (on or off);
- RTT estimation = (draft-ietf-babel-rtt);
- use of unicast instead of = multicast;
- ...
In -08 version of the = draft, all references to wired, wireless, tunnel
and = others are gone. That in addition to babel-link-properties. If
they are underlying parameters, they are truly invisible = :-).

Wired, wireless etc. are = the UI interface types.  The underlying properties are
link-quality and split-horizon (in RFC 6126bis) and the RTT = estimation
parameters (in draft-ietf-babel-rtt).

I = understand that it is difficult for an operatori without intimate
knowledge to know how to configure these properties. And that = is why
these should be optional properties. However, = without them, there is
no way for an operator to influence = how the protocol works.

"Optional property" has = different meanings to different people and different data modeling = schemes. I've started trying to be very explicit: (1) Does a parameter = (YANG leaf) have a universally-agreed default value (e.g., the UDP = port)? (2) Can the management system cause an object (YANG leaf-list) = instance to be created and some of the parameters (leafs) will be = implicitly set to known default values (e.g., the hmac-keys and = dtls-certs Booleans)? (3) Are the allowed values for some parameters = (leafs) constrained to a specific range, cannot be null, are an = enumeration, etc. (e.g., interface metric-algorithm)? (4) If an = implementation does not include a particular parameter (leaf), can it = still be considered compliant with the info model (in YANG terms: Can a = specific Babel implementation have a YANG deviation statement for = something and still be compliant with the info model) [this is not = directly reflected in the YANG = model]?

In the context of interface = metric-algorithm and split-horizon, the management system will never = "create" these parameters (because all interface instances are created = by the Babel implementation and cannot be created by the management = system), and there are no universally-agreed defaults. So (1) and (2) = don't apply. The models allow the management system to overwrite the = value the implementation chose for the interface. We're constraining the = allowed values the management system can use when overwriting these. So = (3) applies. The YANG model needs to constrain the value of these sorts = of parameters to being in the enumeration, but doesn't need a = default.

What = I was referring to as =E2=80=9Coptional property=E2=80=9D is more like = (4), minus the need to deviate away from the YANG model. They are = optional in the sense that a particular Babel implementation will work = just fine without having to configure the optional parameters. As an = example, if the user/operator wants to change the particular behavior on = a particular interface would they need to configure the (optional) link = properties. 

BTW, leafs such as = link properties are optional to configure, but not optional to = support/implement. If the implementation does not want to = support/implement, e.g. a particular link property, they would need to = deviate what they do not support from the model. 

Hope the distinction between =E2=80=9Coptional = property=E2=80=9D and deviation is clear.


I think we're not understanding each = other.  I am not arguing about hiding
any = information, quite the opposite, I am in favour of exporting the
underlying properties and leaving the link type to the UI.

I don't think we have the manpower to do a = good job.

Ok. Let me follow up on = the separate e-mail thread that you started
with = describing Babel filtering and routing policies. If it becomes
too complex, we can drop it.

Sure, but please keep my comment about manpower in mind.

I think the problem we're facing is that Babel = implementations are perfectly capable of operating well without being = explicitly configured (other than enabling/disabling it). Babel is = specifically designed that way. But that doesn't necessitate "hiding" = things.

Here is what = I think would be common "configuration" scenarios:
- The most common = "configuration" would be to simply enable Babel. 
- The next most common = configuration would be to enable/disable it on specific interfaces = (using the enable parameter in babel-interfaces). This may be done at = the same time Babel is enabled (if the Babel implementation creates the = interfaces instances even though Babel isn't enabled). Or later. It may = need to be a separate configuration call, because the Babel = implementation may not create the interfaces instances unless it is = enabled. If it is a separate configuration call, the operator will = probably need to read the configuration first, to see what interfaces = Babel has identified it can run on, and which of these it has = auto-enabled / auto-disabled.
- The next thing someone would want to do is not = configuration, but just reading info about the status of Babel. Some of = the expressed status is the metric-algorithm (not link-quality, which is = not a parameter) and split-horizon (true/false as to whether it's used) = that was selected by the implementation for use on each interface. The = Babel model is small enough that the person would probably find it = easiest just to ask for everything.
- It's possible that in looking at the status, the operator = doesn't like the choices the implementation made wrt metric-algorithm or = split-horizon, for an interface. The operator needs to have the ability = to change those choices. The values the operator can change to are = constrained. 
- It's possible that in looking = at the status, the operator thinks things don't look right and wants to = troubleshoot by getting more detailed statistics and maybe even a = message log. So the operator enables statistics and message log. The = operator waits a few seconds and reads statistics and the message log. = Maybe the operator does something that fixes the problem. The operator = then disables statistics and message log.

So maybe the "example configuration" is a sequence of YANG = messages:
1. Enable = Babel
2. Read the = interfaces leaf-list.
3. Enable/disable Babel on specific interfaces, as = desired.
4. Read = everything.
5. Update = metric-algorithm and split-horizon values for a specific = interface.

This = is a perfectly valid sequence of RPC (not YANG) messages that are = exchanged. 

What I had in mind = for the updates to the information model are step 5. If the operator = needs to update link-quality, or flip on split-horizon, or set a RTT = estimate value, or specify whether they want to use unicast instead of = multicast, or any combination thereof for a particular interface, they = would create a new babel-link-properties object and associate that with = the interface.

Can we agree on the = changes to the information model I suggested yesterday?


For troubleshooting:
6. Enables statistics and message log.
7. Read statistics and message = log.
8. Disable = statistics and message log.

Barbara

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_F79A4954-00C2-40C8-BDFC-7801F2BE450D-- From nobody Wed Aug 7 11:09: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 49C081205D4; Wed, 7 Aug 2019 11:09:22 -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 HLMPfq_fW_nb; Wed, 7 Aug 2019 11:09:20 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 42E491202E1; Wed, 7 Aug 2019 11:09:20 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id c9so64664671lfh.4; Wed, 07 Aug 2019 11:09:20 -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=ipieD2NF4WtCrtLvBV5qIIoxe3ivVWDMQDz8VERsGoc=; b=CRd3Lp28mt5gM2q1IOgggMoffaKbOfAG1rBX5xxTPoxzwouC/KtU7VI4Rd7ieWm1Xi uCBlzrGQmbWT6eTfkdqeqy87yZ1HATq9YNVorarOJqDa7JNSPT2/YUiWb/YuhUs2kx5w wOA3PSn7LkY1hU6+5To1UP2lJTEDkZ/VCmzol0lNW1JScHH+VDOuAX8oxGZk7JfOKnfz ryEHp/5UYcVnwayQdOixNjxpyboTvYIQjkiYZ54xFhhxZS6trj/2Xm0wo7sp4QHVmtu5 9ZEKT17f/ihrMNRgaJ7BKV7QhLOzLpdm8OChJqJNEkK6lj3L8LTY4ZZ2NzaF1yqff58V TMOQ== 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=ipieD2NF4WtCrtLvBV5qIIoxe3ivVWDMQDz8VERsGoc=; b=q+3OMXC89XPO/9unTXf1SyfAMzfGUkqRaapzzCehz6yDCVKGyfiBkqJqiQpIuMuvYH BLoOd1f9KMZDFOGB/5iMiqfWdawtsYDav+9LW7EduWAjoiiesmdswcqFAY/Qx62bYRXK HNiyOI0anOjSjBsw8bRNz9zFvH779JeVlRvYdMZuexmkI1ty4xkVTotJf1MY+6F4J66Q npiR7NFsP6S5esl1PlQhR2gvFTh9oDwTZOfdNiBa/iXKVFYPXm9hoiv0HBc7fi6LcMY3 oJlQqZfOfGElVNV8BLjGE2J9VS8ALqx/e1Qwx+rIIcj0BVCU6sGmIaREh+7EjnKFELym 37OA== X-Gm-Message-State: APjAAAU/re9gyEnDmYKD9fqx2jpFQOivM5RQBEBiZJqrmtBzVuoi6KjQ IygWN3PoUAplWOym7V9NhQdxXBcBP3/b4cg2/Wc= X-Google-Smtp-Source: APXvYqzma+VoVxE81cyUTrKSOG1axQvHCUbwv+GPbT9qrCe1z+EoMCZGu0r0PNHciCWr/9FUqncr2LnRcNfHa5k9hQg= X-Received: by 2002:a05:6512:403:: with SMTP id u3mr6712891lfk.10.1565201358345; Wed, 07 Aug 2019 11:09:18 -0700 (PDT) MIME-Version: 1.0 References: <156518163926.8337.14198016212015161206.idtracker@ietfa.amsl.com> In-Reply-To: <156518163926.8337.14198016212015161206.idtracker@ietfa.amsl.com> From: David Schinazi Date: Wed, 7 Aug 2019 11:09:07 -0700 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , draft-ietf-babel-dtls@ietf.org, Donald Eastlake , babel-chairs , Babel at IETF Content-Type: multipart/alternative; boundary="000000000000f75bd8058f8ad624" Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-dtls-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Wed, 07 Aug 2019 18:09:22 -0000 --000000000000f75bd8058f8ad624 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Mirja, and thank you for your review. (1) Discuss - port number Using an ephemeral port that is discovered at runtime would add a failure mode to the protocol and make it less robust. Implementors in the working group felt strongly that a separate port is simpler, safer and more reliable. (2) Comment on IPv4/IPv6 Thanks for catching this! We've allowed IPv4 in this commit: https://github.com/jech/babel-drafts/commit/335e3edf06ac58853e33475e32f2d45= 2022e04e0 It'll be included in the next revision of the draft. Thanks, David On Wed, Aug 7, 2019 at 5:40 AM Mirja K=C3=BChlewind via Datatracker < noreply@ietf.org> wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-babel-dtls-07: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Unfortunately I need to discuss the port request again. > > First of all I would like to comment on the shepherd write-up which says: > "The document requires only the allocation of a port number for Babel > over DTLS. Having such a second port for the secured version of a > protocol is a fairly common practice. This is shown in the IANA > Considerations section." > This is not correct. Having a second port for the secured version of a > protocol > WAS common practice. However RFC6335 say now "The use of separate > service name or port number assignments for secure and insecure > variants of the same service is to be avoided in order to discourage > the deployment of insecure services." > > Anyway, in this case I understand that a different port is desired becaus= e > unencrypted HELLO messages are still received over the default babel port= . > However, it is not clear to me why a fixed/default port is needed. The > neighbour needs to be discovered in some why, no matter what, before a DT= LS > connection can be established and this discovery procedure could indicate= a > dynamic port number that the peer is listening on for babel over DTLS. > E.g. the > multicast HELLO could have a new TLV with this port information. Please > clarify > why this option is not suitable! Thanks! > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This specification seems to only support babel over DTLS for IPv6. This > should > be stated clearly in the introduction. > > > --000000000000f75bd8058f8ad624 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Mirja, and thank you for your review.

=
(1) Discuss - port number

Using an ephemeral = port that is discovered at runtime would add a failure mode
to th= e protocol and make it less robust. Implementors in the working group
=
felt strongly that a separate port is simpler, safer and more reliable= .

(2) Comment on IPv4/IPv6

Thanks for catching this! We've allowed IPv4 in this commit:
https://github.com/jech/babel-drafts/commit/335e3ed= f06ac58853e33475e32f2d452022e04e0
It'll be included i= n the next revision of the draft.

Thanks,
David


On Wed, Aug 7, 2019 at 5:40 AM Mirja K=C3=BCh= lewind via Datatracker <noreply@ietf= .org> wrote:
Mirja K=C3=BChlewind has entered the following ballot position for
draft-ietf-babel-dtls-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-b= abel-dtls/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Unfortunately I need to discuss the port request again.

First of all I would like to comment on the shepherd write-up which says: "The document requires only the allocation of a port number for Babel<= br> over DTLS. Having such a second port for the secured version of a
protocol is a fairly common practice. This is shown in the IANA
Considerations section."
This is not correct. Having a second port for the secured version of a prot= ocol
WAS common practice. However RFC6335 say now "The use of separate
=C2=A0 =C2=A0service name or port number assignments for secure and insecur= e
=C2=A0 =C2=A0variants of the same service is to be avoided in order to disc= ourage
=C2=A0 =C2=A0the deployment of insecure services."

Anyway, in this case I understand that a different port is desired because<= br> unencrypted HELLO messages are still received over the default babel port.<= br> However, it is not clear to me why a fixed/default port is needed. The
neighbour needs to be discovered in some why, no matter what, before a DTLS=
connection can be established and this discovery procedure could indicate a=
dynamic port number that the peer is listening on for babel over DTLS. E.g.= the
multicast HELLO could have a new TLV with this port information. Please cla= rify
why this option is not suitable! Thanks!


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This specification seems to only support babel over DTLS for IPv6. This sho= uld
be stated clearly in the introduction.


--000000000000f75bd8058f8ad624-- From nobody Wed Aug 7 11:18:52 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 76B1A1206B4; Wed, 7 Aug 2019 11:18:50 -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 jnoft8eXXPBb; Wed, 7 Aug 2019 11:18:48 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 317191205DC; Wed, 7 Aug 2019 11:18:48 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id r9so86372351ljg.5; Wed, 07 Aug 2019 11:18:48 -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=6L6kf9srT6XUcG9rbJ05MzinEJwjx9yyyQfqA2QBJf4=; b=OUt1LZUw3EAw6kJtd8A3zqXPtwd2dy9H6TGbBT/1nb2eSdNwvPMLpVtY7a2ehrWSBU 6KbQ4gkak/YPhNhVB+NQrx6PJ1YBwSEzoWNXzVHhYiupG/a3RBs6CJEiiqObapRKUNbD YaY4BtnLxTMMZb4e3c3jhAgO7EX8xR5gUCXudpAYtdLtsTYwqIjPfGBdb1lIfrmMJVPo S7egaxhFi2NsawGiZrpjqci1lhMc675wdA5exMn16iyU2yo5SzzPSGZ43HGirPt06sFe S1ZVNo+Q3nm8DU4uZHfoshNvdvbQ1T7E1ctbblnd8gvsMCsxzp8Av3n0UgA++CZusiUZ YXlA== 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=6L6kf9srT6XUcG9rbJ05MzinEJwjx9yyyQfqA2QBJf4=; b=ZlFd/7zEvmiSHXxPMr8V+7Q0x1aQD4oPqV0KY8p0gL+Wi3LrNxP4Z03jfNUY2p9jgn fg4MFrNfRosidFwjQMydgkktA4p1DbswyyVeP0ZvpIozKMDI4hLbMBlZXqd1GABCU87P hftFcJuHLSXDTSYnppHR3yqOhuS+Q6e36vnJEHip0LmsoGJqV0Im8f2JLJS+yqmYmIk8 C1z1achaBOudKhtjyG6m1HV9Io1MM8CgF0Y3cFHot5WfQtA+eblTPr2kH0WMn5T370nT 8Ep7MH/Zp9/8WqYnWfjTXVamn9XOtIm1ze1ouBIuqk545QIuuXxdx9EQeyK/9SxT0h+8 iprw== X-Gm-Message-State: APjAAAUkRl4JxiuY7Hg8Fl2GMRCEdfzopjzp/rKSnVVSl3qDB49KdPmn NNBmMLT++FflcN5egSDbENTSYGu/ATkqJQHhHoc= X-Google-Smtp-Source: APXvYqwFRUaTjhmHwdCivx3XRtY22XdcZr5r+MvfQgVlr166Sbb88sntb0DxkYyqMHhepH6RqHeuNvbzTWIs++FjhFs= X-Received: by 2002:a2e:2d12:: with SMTP id t18mr5737967ljt.175.1565201926414; Wed, 07 Aug 2019 11:18:46 -0700 (PDT) MIME-Version: 1.0 References: <156499066627.24529.10259312583734398168.idtracker@ietfa.amsl.com> In-Reply-To: <156499066627.24529.10259312583734398168.idtracker@ietfa.amsl.com> From: David Schinazi Date: Wed, 7 Aug 2019 11:18:35 -0700 Message-ID: To: =?UTF-8?B?w4lyaWMgVnluY2tl?= Cc: The IESG , draft-ietf-babel-dtls@ietf.org, Donald Eastlake , babel-chairs , Babel at IETF Content-Type: multipart/alternative; boundary="000000000000d36540058f8af88d" Archived-At: Subject: Re: [babel] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-babel-dtls-07=3A_=28with_COMMENT=29?= 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: Wed, 07 Aug 2019 18:18:51 -0000 --000000000000d36540058f8af88d Content-Type: text/plain; charset="UTF-8" Hello Eric, and thanks for your review! Responses inline: -- Section 1.2 -- > > The text refers to the security consideration of RFC6121bis for an extended > comparison of HMAC & DTLS except that there is no additional information > in RFC > 6121bis. > babel-dtls states "A comparison of Babel security mechanisms and their applicability can be found in [RFC6126bis]." The Security Considerations section of RFC6126bis does have such a comparison: https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-12#section-6 The comparison is pretty short: in a nutshell use HMAC if it fits your needs because it's simpler, otherwise use DTLS because it has more features. The text is laid out this way because we thought it was best to have the main Babel document discuss the properties of the security solutions and have the security documents simply point to that instead of repeating the text. > -- Section 2.1 -- > > It is a little unclear to me whether a mix of DTLS and non-DTLS Babel > nodes can > exist on the same layer-2 network. I guess no (as implied later) but a > clear > sentence would help. > Technically you could run a mix of DTLS and non-DTLS Babel nodes on the same layer 2 network, but they would behave as "ships in the night" and ignore each other because they wouldn't be able to establish bidirectional reachability. That is also true of running Babel and any other routing protocol on the same network. This seems pretty standard as far as routing goes, but if you could suggest some text we could add it? Thanks, David --000000000000d36540058f8af88d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Eric, and thanks for your review! R= esponses inline:

-- Section 1.2 --

The text refers to the security consideration of RFC6121bis for an extended=
comparison of HMAC & DTLS except that there is no additional informatio= n in RFC
6121bis.

babel-dtls states "A comp= arison of Babel security mechanisms and
=C2=A0 =C2=A0their applic= ability can be found in [RFC6126bis]."

The Se= curity Considerations section of RFC6126bis does have such a comparison:

The comparison is pretty short= : in a nutshell use HMAC if it fits your needs because
it's s= impler, otherwise use DTLS because it has more features.

The text is laid out this way because we thought it was best to have= the main Babel
document discuss the properties of the security s= olutions and have the security
documents simply point to that ins= tead of repeating the text.
=C2=A0
-- Section 2.1 --

It is a little unclear to me whether a mix of DTLS and non-DTLS Babel nodes= can
exist on the same layer-2 network. I guess no (as implied later) but a clea= r
sentence would help.

Technically you co= uld run=C2=A0a mix of DTLS and non-DTLS Babel nodes on the same
l= ayer 2 network, but they would behave as "ships in the night" and= ignore each other
because they wouldn't be able to establish= bidirectional reachability. That is also true
of running Babel a= nd any other routing protocol on the same network. This seems
pre= tty standard as far as routing goes, but if you could suggest some text we = could
add it?

Thanks,
David
=C2=A0
--000000000000d36540058f8af88d-- From nobody Wed Aug 7 11:56:10 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 2144012028B for ; Wed, 7 Aug 2019 11:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Ll2CaRR8duhN for ; Wed, 7 Aug 2019 11:56:05 -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 5EFF0120275 for ; Wed, 7 Aug 2019 11:56:05 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x77IokZY009505; Wed, 7 Aug 2019 14:56:02 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2u849dr5ty-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Aug 2019 14:56:02 -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 x77Iu11B024342; Wed, 7 Aug 2019 14:56:01 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x77Itvmg024280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Aug 2019 14:55:57 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 0B114400A0AA; Wed, 7 Aug 2019 18:55:57 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30488.vci.att.com (Service) with ESMTPS id E6955400A0A8; Wed, 7 Aug 2019 18:55:56 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0439.000; Wed, 7 Aug 2019 14:55:56 -0400 From: "STARK, BARBARA H" To: "'Mahesh Jethanandani'" CC: "'Juliusz Chroboczek'" , "'Babel at IETF'" Thread-Topic: [babel] Example configuration Thread-Index: AQHVQysP27rmDxHNmE+dOkameIFP66bcIv6AgBKtMoCAAAmwgIAACWOAgAAV/4CAAC8QgIAAC2UAgABwxXCAAK2IgP//vsCA Date: Wed, 7 Aug 2019 18:55:55 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E258CF7@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr> <87pnlhaixh.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E257961@GAALPA1MSGUSRBF.ITServices.sbc.com> <0B28A1FA-32B4-41E6-B646-C6A3907E9CCC@gmail.com> In-Reply-To: <0B28A1FA-32B4-41E6-B646-C6A3907E9CCC@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.248.192] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114E258CF7GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-07_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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908070170 Archived-At: Subject: Re: [babel] Example configuration 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: Wed, 07 Aug 2019 18:56:08 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114E258CF7GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCg0KSSB0aGluayB0aGUgcHJvYmxlbSB3ZSdyZSBmYWNpbmcgaXMgdGhhdCBCYWJlbCBpbXBs ZW1lbnRhdGlvbnMgYXJlIHBlcmZlY3RseSBjYXBhYmxlIG9mIG9wZXJhdGluZyB3ZWxsIHdpdGhv dXQgYmVpbmcgZXhwbGljaXRseSBjb25maWd1cmVkIChvdGhlciB0aGFuIGVuYWJsaW5nL2Rpc2Fi bGluZyBpdCkuIEJhYmVsIGlzIHNwZWNpZmljYWxseSBkZXNpZ25lZCB0aGF0IHdheS4gQnV0IHRo YXQgZG9lc24ndCBuZWNlc3NpdGF0ZSAiaGlkaW5nIiB0aGluZ3MuDQoNCkhlcmUgaXMgd2hhdCBJ IHRoaW5rIHdvdWxkIGJlIGNvbW1vbiAiY29uZmlndXJhdGlvbiIgc2NlbmFyaW9zOg0KLSBUaGUg bW9zdCBjb21tb24gImNvbmZpZ3VyYXRpb24iIHdvdWxkIGJlIHRvIHNpbXBseSBlbmFibGUgQmFi ZWwuDQotIFRoZSBuZXh0IG1vc3QgY29tbW9uIGNvbmZpZ3VyYXRpb24gd291bGQgYmUgdG8gZW5h YmxlL2Rpc2FibGUgaXQgb24gc3BlY2lmaWMgaW50ZXJmYWNlcyAodXNpbmcgdGhlIGVuYWJsZSBw YXJhbWV0ZXIgaW4gYmFiZWwtaW50ZXJmYWNlcykuIFRoaXMgbWF5IGJlIGRvbmUgYXQgdGhlIHNh bWUgdGltZSBCYWJlbCBpcyBlbmFibGVkIChpZiB0aGUgQmFiZWwgaW1wbGVtZW50YXRpb24gY3Jl YXRlcyB0aGUgaW50ZXJmYWNlcyBpbnN0YW5jZXMgZXZlbiB0aG91Z2ggQmFiZWwgaXNuJ3QgZW5h YmxlZCkuIE9yIGxhdGVyLiBJdCBtYXkgbmVlZCB0byBiZSBhIHNlcGFyYXRlIGNvbmZpZ3VyYXRp b24gY2FsbCwgYmVjYXVzZSB0aGUgQmFiZWwgaW1wbGVtZW50YXRpb24gbWF5IG5vdCBjcmVhdGUg dGhlIGludGVyZmFjZXMgaW5zdGFuY2VzIHVubGVzcyBpdCBpcyBlbmFibGVkLiBJZiBpdCBpcyBh IHNlcGFyYXRlIGNvbmZpZ3VyYXRpb24gY2FsbCwgdGhlIG9wZXJhdG9yIHdpbGwgcHJvYmFibHkg bmVlZCB0byByZWFkIHRoZSBjb25maWd1cmF0aW9uIGZpcnN0LCB0byBzZWUgd2hhdCBpbnRlcmZh Y2VzIEJhYmVsIGhhcyBpZGVudGlmaWVkIGl0IGNhbiBydW4gb24sIGFuZCB3aGljaCBvZiB0aGVz ZSBpdCBoYXMgYXV0by1lbmFibGVkIC8gYXV0by1kaXNhYmxlZC4NCi0gVGhlIG5leHQgdGhpbmcg c29tZW9uZSB3b3VsZCB3YW50IHRvIGRvIGlzIG5vdCBjb25maWd1cmF0aW9uLCBidXQganVzdCBy ZWFkaW5nIGluZm8gYWJvdXQgdGhlIHN0YXR1cyBvZiBCYWJlbC4gU29tZSBvZiB0aGUgZXhwcmVz c2VkIHN0YXR1cyBpcyB0aGUgbWV0cmljLWFsZ29yaXRobSAobm90IGxpbmstcXVhbGl0eSwgd2hp Y2ggaXMgbm90IGEgcGFyYW1ldGVyKSBhbmQgc3BsaXQtaG9yaXpvbiAodHJ1ZS9mYWxzZSBhcyB0 byB3aGV0aGVyIGl0J3MgdXNlZCkgdGhhdCB3YXMgc2VsZWN0ZWQgYnkgdGhlIGltcGxlbWVudGF0 aW9uIGZvciB1c2Ugb24gZWFjaCBpbnRlcmZhY2UuIFRoZSBCYWJlbCBtb2RlbCBpcyBzbWFsbCBl bm91Z2ggdGhhdCB0aGUgcGVyc29uIHdvdWxkIHByb2JhYmx5IGZpbmQgaXQgZWFzaWVzdCBqdXN0 IHRvIGFzayBmb3IgZXZlcnl0aGluZy4NCi0gSXQncyBwb3NzaWJsZSB0aGF0IGluIGxvb2tpbmcg YXQgdGhlIHN0YXR1cywgdGhlIG9wZXJhdG9yIGRvZXNuJ3QgbGlrZSB0aGUgY2hvaWNlcyB0aGUg aW1wbGVtZW50YXRpb24gbWFkZSB3cnQgbWV0cmljLWFsZ29yaXRobSBvciBzcGxpdC1ob3Jpem9u LCBmb3IgYW4gaW50ZXJmYWNlLiBUaGUgb3BlcmF0b3IgbmVlZHMgdG8gaGF2ZSB0aGUgYWJpbGl0 eSB0byBjaGFuZ2UgdGhvc2UgY2hvaWNlcy4gVGhlIHZhbHVlcyB0aGUgb3BlcmF0b3IgY2FuIGNo YW5nZSB0byBhcmUgY29uc3RyYWluZWQuDQotIEl0J3MgcG9zc2libGUgdGhhdCBpbiBsb29raW5n IGF0IHRoZSBzdGF0dXMsIHRoZSBvcGVyYXRvciB0aGlua3MgdGhpbmdzIGRvbid0IGxvb2sgcmln aHQgYW5kIHdhbnRzIHRvIHRyb3VibGVzaG9vdCBieSBnZXR0aW5nIG1vcmUgZGV0YWlsZWQgc3Rh dGlzdGljcyBhbmQgbWF5YmUgZXZlbiBhIG1lc3NhZ2UgbG9nLiBTbyB0aGUgb3BlcmF0b3IgZW5h YmxlcyBzdGF0aXN0aWNzIGFuZCBtZXNzYWdlIGxvZy4gVGhlIG9wZXJhdG9yIHdhaXRzIGEgZmV3 IHNlY29uZHMgYW5kIHJlYWRzIHN0YXRpc3RpY3MgYW5kIHRoZSBtZXNzYWdlIGxvZy4gTWF5YmUg dGhlIG9wZXJhdG9yIGRvZXMgc29tZXRoaW5nIHRoYXQgZml4ZXMgdGhlIHByb2JsZW0uIFRoZSBv cGVyYXRvciB0aGVuIGRpc2FibGVzIHN0YXRpc3RpY3MgYW5kIG1lc3NhZ2UgbG9nLg0KDQpTbyBt YXliZSB0aGUgImV4YW1wbGUgY29uZmlndXJhdGlvbiIgaXMgYSBzZXF1ZW5jZSBvZiBZQU5HIG1l c3NhZ2VzOg0KMS4gRW5hYmxlIEJhYmVsDQoyLiBSZWFkIHRoZSBpbnRlcmZhY2VzIGxlYWYtbGlz dC4NCjMuIEVuYWJsZS9kaXNhYmxlIEJhYmVsIG9uIHNwZWNpZmljIGludGVyZmFjZXMsIGFzIGRl c2lyZWQuDQo0LiBSZWFkIGV2ZXJ5dGhpbmcuDQo1LiBVcGRhdGUgbWV0cmljLWFsZ29yaXRobSBh bmQgc3BsaXQtaG9yaXpvbiB2YWx1ZXMgZm9yIGEgc3BlY2lmaWMgaW50ZXJmYWNlLg0KDQpUaGlz IGlzIGEgcGVyZmVjdGx5IHZhbGlkIHNlcXVlbmNlIG9mIFJQQyAobm90IFlBTkcpIG1lc3NhZ2Vz IHRoYXQgYXJlIGV4Y2hhbmdlZC4NCg0KPGJocz4gTm90IG5lY2Vzc2FyaWx5IFJQQy4gSSB3YXMg dGhpbmtpbmcgb2YgaXQgbW9yZSBpbiB0ZXJtcyBvZiB3aGF0IGEgdXNlciBtaWdodCBiZSB0cnlp bmcgdG8gZG8sIGluZGVwZW5kZW50IG9mIGhvdyB0aGUgdGhpbmcgdGhlIHVzZXIgd2FudHMgdG8g ZG8gaXMgY29tbXVuaWNhdGVkIG9yIHRyYW5zcG9ydGVkLg0KDQpXaGF0IEkgaGFkIGluIG1pbmQg Zm9yIHRoZSB1cGRhdGVzIHRvIHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBhcmUgc3RlcCA1LiBJZiB0 aGUgb3BlcmF0b3IgbmVlZHMgdG8gdXBkYXRlIGxpbmstcXVhbGl0eSwgb3IgZmxpcCBvbiBzcGxp dC1ob3Jpem9uLCBvciBzZXQgYSBSVFQgZXN0aW1hdGUgdmFsdWUsIG9yIHNwZWNpZnkgd2hldGhl ciB0aGV5IHdhbnQgdG8gdXNlIHVuaWNhc3QgaW5zdGVhZCBvZiBtdWx0aWNhc3QsIG9yIGFueSBj b21iaW5hdGlvbiB0aGVyZW9mIGZvciBhIHBhcnRpY3VsYXIgaW50ZXJmYWNlLCB0aGV5IHdvdWxk IGNyZWF0ZSBhIG5ldyBiYWJlbC1saW5rLXByb3BlcnRpZXMgb2JqZWN0IGFuZCBhc3NvY2lhdGUg dGhhdCB3aXRoIHRoZSBpbnRlcmZhY2UuDQoNCkNhbiB3ZSBhZ3JlZSBvbiB0aGUgY2hhbmdlcyB0 byB0aGUgaW5mb3JtYXRpb24gbW9kZWwgSSBzdWdnZXN0ZWQgeWVzdGVyZGF5Pw0KDQo8YmhzPiBM ZXQgbWUgc2VlIGlmIEkgdW5kZXJzdGFuZC4uLiBEb2VzIGl0IGhhdmUgdG8gYmUgYSDigJxuZXfi gJ0gYmFiZWwtbGluay1wcm9wZXJ0aWVzIGluc3RhbmNlLCBvciBjYW4gaXQgYmUgb25lIHRoYXQg ZXhpc3RzPw0KDQpUaGF0IGlzLCBpZiB3ZSBoYWQgYW4gb2JqZWN0IGNhbGxlZCBiYWJlbC1saW5r LXByb3BlcnRpZXMNCiAgICAgb2JqZWN0IHsNCiAgICAgICAgICBzdHJpbmcgICAgICAgICAgICAg ICAgcncgYmFiZWwtbGluay1wcm9wZXJ0aWVzLW5hbWU7DQogICAgICAgICAgc3RyaW5nICAgICAg ICAgICAgICAgIHJ3IGJhYmVsLWludGVyZmFjZS1tZXRyaWMtYWxnb3JpdGhtOw0KICAgICAgICAg IGJvb2xlYW4gICAgICAgICAgICAgICBydyBiYWJlbC1pbnRlcmZhY2Utc3BsaXQtaG9yaXpvbjsN CiAgICAgICAgICBib29sZWFuICAgICAgICAgICAgICAgcncgYmFiZWwtaW50ZXJmYWNlLXJ0dDsN CiAgICAgICAgICBib29sZWFuICAgICAgICAgICAgICAgcncgYmFiZWwtaW50ZXJmYWNlLXVuaWNh c3QNCiAgICAgIH0gYmFiZWwtaG1hYy1rZXlzLW9iajsNCg0KV2hlcmUgdGhlIGltcGxlbWVudGF0 aW9uIG1heSBjcmVhdGUgc29tZSBzZXQgb2YgaW5pdGlhbCBlbnRyaWVzIHRoYXQgaXRzIGRldmVs b3BlcnMgaGF2ZSBkZWNpZGVkIHRvIGUuZy4gbmFtZSDigJx3aXJlZOKAnSwg4oCcd2lyZWxlc3Pi gJ0sIOKAnHR1bm5lbOKAnSAoYnV0IHNvbWUgb3RoZXIgaW1wbGVtZW50YXRpb24gbWF5IGdpdmUg YSBkaWZmZXJlbnQgbmFtZSB0byB0aGUgc2FtZSBncm91cCBvZiBwYXJhbWV0ZXIgdmFsdWVzKS4g bGluay1wcm9wZXJ0aWVzLW5hbWUgbXVzdCBiZSB1bmlxdWUgKGFuZCBub3QgZW1wdHkgb3IgTlVM TCksIGJ1dCBhbHNvIG5vIDIgaW5zdGFuY2VzIGFyZSBhbGxvd2VkIHRvIGhhdmUgdGhlIHNhbWUg c2V0IG9mIHZhbHVlcyBmb3IgdGhlIGxhdHRlciA0IHBhcmFtZXRlcnMuIE9uY2UgYW4gaW5zdGFu Y2UgaXMgY3JlYXRlZCBpdCBjYW5ub3QgYmUgbW9kaWZpZWQuIElmIGl0IGlzIHJlZmVyZW5jZWQg ZnJvbSBhbiBpbnRlcmZhY2Ugb3Igd2FzIGNyZWF0ZWQgYnkgdGhlIGltcGxlbWVudGF0aW9uLCBp dCBjYW5ub3QgYmUgZGVsZXRlZC4gVGhpcyBtYWtlcyBpbnN0YW5jZXMgY3JlYXRlZCBieSB0aGUg aW1wbGVtZW50YXRpb24gaW1tdXRhYmxlLg0KVGhpcyBvYmplY3QgY2FuIGJlIHdyaXR0ZW4gKG5l dyBpbnN0YW5jZXMgY3JlYXRlZCB3aXRoIGRpZmZlcmVudCBjb21iaW5hdGlvbnMgb2YgdmFsdWVz IGFuZCBhIGRpZmZlcmVudCBuYW1lLCBsaWtlIOKAnHVuaWNhc3Qtd2lyZWTigJ0pLg0KQW4gaW50 ZXJmYWNlIHdpbGwgaGF2ZSBhIHJlZmVyZW5jZSB0byBvbmUgb2YgdGhlc2UgaW5zdGFuY2VzLCB0 byBpZGVudGlmeSB0aGUgc2V0IG9mIGxpbmstcHJvcGVydGllcyBpdCB1c2VzLiBJdOKAmXMgYWxs b3dlZCB0byBtb2RpZnkgd2hpY2ggc2V0IG9mIGxpbmstcHJvcGVydGllcyBpcyB1c2VkL3JlZmVy ZW5jZWQgYnkgYW4gaW50ZXJmYWNlLg0KDQpJcyB0aGF0IHJpZ2h0PyBBbmQgZGlkIHlvdSBzYXkg eW91IHdhbnRlZCBpdCB1bmRlciBpbnRlcmZhY2Ugb3IgdW5kZXIgdGhlIGJhc2U/IEkgdGhpbmsg aXQgd291bGQgbWFrZSBzZW5zZSB1bmRlciBiYXNlLiBKdWxpdXN6LCBJIHRoaW5rIHRoaXMgYXBw cm9hY2ggKGlmIGl04oCZcyB3aGF0IE1haGVzaCBtZWFudCkgd291bGQgcHJvdmlkZSB0aGUgYmVu ZWZpdHMgb2YgYWxsb3dpbmcgdXNlcnMgdG8gdXNlIG1vcmUgbWVhbmluZ2Z1bCBuYW1lcyBmb3Ig Z3JvdXBzIG9mIGxpbmsgcHJvcGVydGllcywgYWxsb3cgdXNlIG9mIG5hbWVzIHRoYXQgYmFiZWxk IGhhcyBhbHJlYWR5IHBvcHVsYXJpemVkIGFtb25nIGl0cyB1c2VycyB3aGlsZSBhbGxvd2luZyBv dGhlciBpbXBsZW1lbnRhdGlvbnMgdG8gdXNlIGRpZmZlcmVudCBuYW1lcyAobmFtZXMgYXJlbuKA mXQgc3RhbmRhcmRpemVkKSwgYW5kIGlzbuKAmXQgdmVyeSBjb21wbGljYXRlZC4gSXQgZG9lcyBt YWtlIGl0IGhhcmRlciBpZiB0aGUgdXNlciB3YW50cyB0byBqdXN0IGNoYW5nZSBvbmUgb2YgdGhl IGxpbmsgcHJvcGVydGllcyBhbmQgbm90IG90aGVycyAodGhleSBtaWdodCBoYXZlIHRvIGNyZWF0 ZSBhIG5ldyBpbnN0YW5jZSkuIEJ1dCBpdCBtYWtlcyBpdCBlYXNpZXIgZm9yIHRoZSB1c2VyIHdo byB3YW50cyB0byBjaGFuZ2UgZnJvbSBvbmUgZ3JvdXBpbmcgb2YgcHJvcGVydGllcyB0byBhbm90 aGVyLg0KQmFyYmFyYQ0KDQoNCg== --_000_2D09D61DDFA73D4C884805CC7865E6114E258CF7GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZl cnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KSSB0aGluayB0aGUgcHJv YmxlbSB3ZSdyZSBmYWNpbmcgaXMgdGhhdCBCYWJlbCBpbXBsZW1lbnRhdGlvbnMgYXJlIHBlcmZl Y3RseSBjYXBhYmxlIG9mIG9wZXJhdGluZyB3ZWxsIHdpdGhvdXQgYmVpbmcgZXhwbGljaXRseSBj b25maWd1cmVkIChvdGhlciB0aGFuIGVuYWJsaW5nL2Rpc2FibGluZyBpdCkuIEJhYmVsIGlzIHNw ZWNpZmljYWxseSBkZXNpZ25lZCB0aGF0IHdheS4gQnV0IHRoYXQgZG9lc24ndCBuZWNlc3NpdGF0 ZSAmcXVvdDtoaWRpbmcmcXVvdDsgdGhpbmdzLjxicj4NCjxicj4NCkhlcmUgaXMgd2hhdCBJIHRo aW5rIHdvdWxkIGJlIGNvbW1vbiAmcXVvdDtjb25maWd1cmF0aW9uJnF1b3Q7IHNjZW5hcmlvczo8 YnI+DQotIFRoZSBtb3N0IGNvbW1vbiAmcXVvdDtjb25maWd1cmF0aW9uJnF1b3Q7IHdvdWxkIGJl IHRvIHNpbXBseSBlbmFibGUgQmFiZWwuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCi0gVGhlIG5leHQgbW9zdCBjb21tb24gY29uZmlndXJhdGlv biB3b3VsZCBiZSB0byBlbmFibGUvZGlzYWJsZSBpdCBvbiBzcGVjaWZpYyBpbnRlcmZhY2VzICh1 c2luZyB0aGUgZW5hYmxlIHBhcmFtZXRlciBpbiBiYWJlbC1pbnRlcmZhY2VzKS4gVGhpcyBtYXkg YmUgZG9uZSBhdCB0aGUgc2FtZSB0aW1lIEJhYmVsIGlzIGVuYWJsZWQgKGlmIHRoZSBCYWJlbCBp bXBsZW1lbnRhdGlvbiBjcmVhdGVzIHRoZSBpbnRlcmZhY2VzIGluc3RhbmNlcyBldmVuDQogdGhv dWdoIEJhYmVsIGlzbid0IGVuYWJsZWQpLiBPciBsYXRlci4gSXQgbWF5IG5lZWQgdG8gYmUgYSBz ZXBhcmF0ZSBjb25maWd1cmF0aW9uIGNhbGwsIGJlY2F1c2UgdGhlIEJhYmVsIGltcGxlbWVudGF0 aW9uIG1heSBub3QgY3JlYXRlIHRoZSBpbnRlcmZhY2VzIGluc3RhbmNlcyB1bmxlc3MgaXQgaXMg ZW5hYmxlZC4gSWYgaXQgaXMgYSBzZXBhcmF0ZSBjb25maWd1cmF0aW9uIGNhbGwsIHRoZSBvcGVy YXRvciB3aWxsIHByb2JhYmx5IG5lZWQgdG8NCiByZWFkIHRoZSBjb25maWd1cmF0aW9uIGZpcnN0 LCB0byBzZWUgd2hhdCBpbnRlcmZhY2VzIEJhYmVsIGhhcyBpZGVudGlmaWVkIGl0IGNhbiBydW4g b24sIGFuZCB3aGljaCBvZiB0aGVzZSBpdCBoYXMgYXV0by1lbmFibGVkIC8gYXV0by1kaXNhYmxl ZC48YnI+DQotIFRoZSBuZXh0IHRoaW5nIHNvbWVvbmUgd291bGQgd2FudCB0byBkbyBpcyBub3Qg Y29uZmlndXJhdGlvbiwgYnV0IGp1c3QgcmVhZGluZyBpbmZvIGFib3V0IHRoZSBzdGF0dXMgb2Yg QmFiZWwuIFNvbWUgb2YgdGhlIGV4cHJlc3NlZCBzdGF0dXMgaXMgdGhlIG1ldHJpYy1hbGdvcml0 aG0gKG5vdCBsaW5rLXF1YWxpdHksIHdoaWNoIGlzIG5vdCBhIHBhcmFtZXRlcikgYW5kIHNwbGl0 LWhvcml6b24gKHRydWUvZmFsc2UgYXMgdG8gd2hldGhlciBpdCdzDQogdXNlZCkgdGhhdCB3YXMg c2VsZWN0ZWQgYnkgdGhlIGltcGxlbWVudGF0aW9uIGZvciB1c2Ugb24gZWFjaCBpbnRlcmZhY2Uu IFRoZSBCYWJlbCBtb2RlbCBpcyBzbWFsbCBlbm91Z2ggdGhhdCB0aGUgcGVyc29uIHdvdWxkIHBy b2JhYmx5IGZpbmQgaXQgZWFzaWVzdCBqdXN0IHRvIGFzayBmb3IgZXZlcnl0aGluZy48YnI+DQot IEl0J3MgcG9zc2libGUgdGhhdCBpbiBsb29raW5nIGF0IHRoZSBzdGF0dXMsIHRoZSBvcGVyYXRv ciBkb2Vzbid0IGxpa2UgdGhlIGNob2ljZXMgdGhlIGltcGxlbWVudGF0aW9uIG1hZGUgd3J0IG1l dHJpYy1hbGdvcml0aG0gb3Igc3BsaXQtaG9yaXpvbiwgZm9yIGFuIGludGVyZmFjZS4gVGhlIG9w ZXJhdG9yIG5lZWRzIHRvIGhhdmUgdGhlIGFiaWxpdHkgdG8gY2hhbmdlIHRob3NlIGNob2ljZXMu IFRoZSB2YWx1ZXMgdGhlIG9wZXJhdG9yIGNhbg0KIGNoYW5nZSB0byBhcmUgY29uc3RyYWluZWQu PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCi0g SXQncyBwb3NzaWJsZSB0aGF0IGluIGxvb2tpbmcgYXQgdGhlIHN0YXR1cywgdGhlIG9wZXJhdG9y IHRoaW5rcyB0aGluZ3MgZG9uJ3QgbG9vayByaWdodCBhbmQgd2FudHMgdG8gdHJvdWJsZXNob290 IGJ5IGdldHRpbmcgbW9yZSBkZXRhaWxlZCBzdGF0aXN0aWNzIGFuZCBtYXliZSBldmVuIGEgbWVz c2FnZSBsb2cuIFNvIHRoZSBvcGVyYXRvciBlbmFibGVzIHN0YXRpc3RpY3MgYW5kIG1lc3NhZ2Ug bG9nLiBUaGUgb3BlcmF0b3Igd2FpdHMgYSBmZXcNCiBzZWNvbmRzIGFuZCByZWFkcyBzdGF0aXN0 aWNzIGFuZCB0aGUgbWVzc2FnZSBsb2cuIE1heWJlIHRoZSBvcGVyYXRvciBkb2VzIHNvbWV0aGlu ZyB0aGF0IGZpeGVzIHRoZSBwcm9ibGVtLiBUaGUgb3BlcmF0b3IgdGhlbiBkaXNhYmxlcyBzdGF0 aXN0aWNzIGFuZCBtZXNzYWdlIGxvZy48YnI+DQo8YnI+DQpTbyBtYXliZSB0aGUgJnF1b3Q7ZXhh bXBsZSBjb25maWd1cmF0aW9uJnF1b3Q7IGlzIGEgc2VxdWVuY2Ugb2YgWUFORyBtZXNzYWdlczo8 YnI+DQoxLiBFbmFibGUgQmFiZWw8YnI+DQoyLiBSZWFkIHRoZSBpbnRlcmZhY2VzIGxlYWYtbGlz dC48YnI+DQozLiBFbmFibGUvZGlzYWJsZSBCYWJlbCBvbiBzcGVjaWZpYyBpbnRlcmZhY2VzLCBh cyBkZXNpcmVkLjxicj4NCjQuIFJlYWQgZXZlcnl0aGluZy48YnI+DQo1LiBVcGRhdGUgbWV0cmlj LWFsZ29yaXRobSBhbmQgc3BsaXQtaG9yaXpvbiB2YWx1ZXMgZm9yIGEgc3BlY2lmaWMgaW50ZXJm YWNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgYSBwZXJmZWN0bHkgdmFsaWQgc2VxdWVu Y2Ugb2YgUlBDIChub3QgWUFORykgbWVzc2FnZXMgdGhhdCBhcmUgZXhjaGFuZ2VkLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7YmhzJmd0OyBOb3QgbmVjZXNzYXJpbHkgUlBDLiBJ IHdhcyB0aGlua2luZyBvZiBpdCBtb3JlIGluIHRlcm1zIG9mIHdoYXQgYSB1c2VyIG1pZ2h0IGJl IHRyeWluZyB0byBkbywgaW5kZXBlbmRlbnQgb2YgaG93IHRoZSB0aGluZyB0aGUgdXNlciB3YW50 cyB0byBkbyBpcyBjb21tdW5pY2F0ZWQgb3IgdHJhbnNwb3J0ZWQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgSSBoYWQgaW4gbWluZCBm b3IgdGhlIHVwZGF0ZXMgdG8gdGhlIGluZm9ybWF0aW9uIG1vZGVsIGFyZSBzdGVwIDUuIElmIHRo ZSBvcGVyYXRvciBuZWVkcyB0byB1cGRhdGUgbGluay1xdWFsaXR5LCBvciBmbGlwIG9uIHNwbGl0 LWhvcml6b24sIG9yIHNldCBhIFJUVCBlc3RpbWF0ZSB2YWx1ZSwgb3Igc3BlY2lmeSB3aGV0aGVy IHRoZXkgd2FudCB0byB1c2UgdW5pY2FzdCBpbnN0ZWFkIG9mIG11bHRpY2FzdCwNCiBvciBhbnkg Y29tYmluYXRpb24gdGhlcmVvZiBmb3IgYSBwYXJ0aWN1bGFyIGludGVyZmFjZSwgdGhleSB3b3Vs ZCBjcmVhdGUgYSBuZXcgYmFiZWwtbGluay1wcm9wZXJ0aWVzIG9iamVjdCBhbmQgYXNzb2NpYXRl IHRoYXQgd2l0aCB0aGUgaW50ZXJmYWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KQ2FuIHdlIGFncmVlIG9uIHRoZSBjaGFuZ2VzIHRv IHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBJIHN1Z2dlc3RlZCB5ZXN0ZXJkYXk/PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZsdDtiaHMmZ3Q7IExldCBtZSBzZWUgaWYgSSB1bmRlcnN0YW5kLi4uIERv ZXMgaXQgaGF2ZSB0byBiZSBhIOKAnG5ld+KAnSBiYWJlbC1saW5rLXByb3BlcnRpZXMgaW5zdGFu Y2UsIG9yIGNhbiBpdCBiZSBvbmUgdGhhdCBleGlzdHM/DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhhdCBpcywgaWYgd2UgaGFkIGFuIG9iamVjdCBjYWxsZWQgYmFiZWwtbGluay1wcm9wZXJ0 aWVzIDxvOnA+DQo8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7b2JqZWN0IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0cmluZyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBydyBiYWJlbC1saW5rLXByb3BlcnRpZXMtbmFtZTs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0cmluZyAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtydyBiYWJlbC1pbnRlcmZhY2UtbWV0cmljLWFsZ29yaXRo bTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJv b2xlYW4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcncgYmFiZWwtaW50ZXJmYWNlLXNwbGl0 LWhvcml6b247PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBib29sZWFuJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3J3IGJhYmVsLWludGVyZmFj ZS1ydHQ7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBib29sZWFuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJ3IGJhYmVsLWludGVyZmFjZS11 bmljYXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9IGJhYmVsLWhtYWMta2V5cy1vYmo7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5XaGVyZSB0aGUgaW1wbGVtZW50YXRpb24gbWF5IGNyZWF0ZSBzb21lIHNldCBvZiBpbml0aWFs IGVudHJpZXMgdGhhdCBpdHMgZGV2ZWxvcGVycyBoYXZlIGRlY2lkZWQgdG8gZS5nLiBuYW1lIOKA nHdpcmVk4oCdLCDigJx3aXJlbGVzc+KAnSwg4oCcdHVubmVs4oCdIChidXQgc29tZSBvdGhlciBp bXBsZW1lbnRhdGlvbiBtYXkgZ2l2ZQ0KIGEgZGlmZmVyZW50IG5hbWUgdG8gdGhlIHNhbWUgZ3Jv dXAgb2YgcGFyYW1ldGVyIHZhbHVlcykuIGxpbmstcHJvcGVydGllcy1uYW1lIG11c3QgYmUgdW5p cXVlIChhbmQgbm90IGVtcHR5IG9yIE5VTEwpLCBidXQgYWxzbyBubyAyIGluc3RhbmNlcyBhcmUg YWxsb3dlZCB0byBoYXZlIHRoZSBzYW1lIHNldCBvZiB2YWx1ZXMgZm9yIHRoZSBsYXR0ZXIgNCBw YXJhbWV0ZXJzLiBPbmNlIGFuIGluc3RhbmNlIGlzIGNyZWF0ZWQgaXQgY2Fubm90IGJlIG1vZGlm aWVkLg0KIElmIGl0IGlzIHJlZmVyZW5jZWQgZnJvbSBhbiBpbnRlcmZhY2Ugb3Igd2FzIGNyZWF0 ZWQgYnkgdGhlIGltcGxlbWVudGF0aW9uLCBpdCBjYW5ub3QgYmUgZGVsZXRlZC4gVGhpcyBtYWtl cyBpbnN0YW5jZXMgY3JlYXRlZCBieSB0aGUgaW1wbGVtZW50YXRpb24gaW1tdXRhYmxlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGlzIG9i amVjdCBjYW4gYmUgd3JpdHRlbiAobmV3IGluc3RhbmNlcyBjcmVhdGVkIHdpdGggZGlmZmVyZW50 IGNvbWJpbmF0aW9ucyBvZiB2YWx1ZXMgYW5kIGEgZGlmZmVyZW50IG5hbWUsIGxpa2Ug4oCcdW5p Y2FzdC13aXJlZOKAnSkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+QW4gaW50ZXJmYWNlIHdpbGwgaGF2ZSBhIHJlZmVyZW5jZSB0byBvbmUg b2YgdGhlc2UgaW5zdGFuY2VzLCB0byBpZGVudGlmeSB0aGUgc2V0IG9mIGxpbmstcHJvcGVydGll cyBpdCB1c2VzLiBJdOKAmXMgYWxsb3dlZCB0byBtb2RpZnkgd2hpY2ggc2V0IG9mIGxpbmstcHJv cGVydGllcyBpcyB1c2VkL3JlZmVyZW5jZWQNCiBieSBhbiBpbnRlcmZhY2UuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyB0aGF0IHJpZ2h0PyBBbmQgZGlkIHlvdSBzYXkgeW91IHdh bnRlZCBpdCB1bmRlciBpbnRlcmZhY2Ugb3IgdW5kZXIgdGhlIGJhc2U/IEkgdGhpbmsgaXQgd291 bGQgbWFrZSBzZW5zZSB1bmRlciBiYXNlLiBKdWxpdXN6LCBJIHRoaW5rIHRoaXMgYXBwcm9hY2gg KGlmIGl04oCZcyB3aGF0IE1haGVzaCBtZWFudCkgd291bGQgcHJvdmlkZSB0aGUgYmVuZWZpdHMg b2YgYWxsb3dpbmcgdXNlcnMgdG8gdXNlIG1vcmUNCiBtZWFuaW5nZnVsIG5hbWVzIGZvciBncm91 cHMgb2YgbGluayBwcm9wZXJ0aWVzLCBhbGxvdyB1c2Ugb2YgbmFtZXMgdGhhdCBiYWJlbGQgaGFz IGFscmVhZHkgcG9wdWxhcml6ZWQgYW1vbmcgaXRzIHVzZXJzIHdoaWxlIGFsbG93aW5nIG90aGVy IGltcGxlbWVudGF0aW9ucyB0byB1c2UgZGlmZmVyZW50IG5hbWVzIChuYW1lcyBhcmVu4oCZdCBz dGFuZGFyZGl6ZWQpLCBhbmQgaXNu4oCZdCB2ZXJ5IGNvbXBsaWNhdGVkLiBJdCBkb2VzIG1ha2Ug aXQgaGFyZGVyDQogaWYgdGhlIHVzZXIgd2FudHMgdG8ganVzdCBjaGFuZ2Ugb25lIG9mIHRoZSBs aW5rIHByb3BlcnRpZXMgYW5kIG5vdCBvdGhlcnMgKHRoZXkgbWlnaHQgaGF2ZSB0byBjcmVhdGUg YSBuZXcgaW5zdGFuY2UpLiBCdXQgaXQgbWFrZXMgaXQgZWFzaWVyIGZvciB0aGUgdXNlciB3aG8g d2FudHMgdG8gY2hhbmdlIGZyb20gb25lIGdyb3VwaW5nIG9mIHByb3BlcnRpZXMgdG8gYW5vdGhl ci4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFyYmFyYTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2D09D61DDFA73D4C884805CC7865E6114E258CF7GAALPA1MSGUSRBF_-- From nobody Wed Aug 7 12:19:59 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 7A1641201C9; Wed, 7 Aug 2019 12:19:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <156520559749.8305.9821179209918519561.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2019 12:19:57 -0700 Archived-At: Subject: [babel] Roman Danyliw's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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: Wed, 07 Aug 2019 19:19:57 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-babel-rfc6126bis-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Security Considerations. While the high level statement of Babel being “an insecure protocol” is accurate and clear, precisely enumerating the threats is needed to motivate the selection of the appropriate mitigations. (1) Per “Any attacker can misdirect data traffic by advertising routes with a low metric or a high seqno.”: -- Can the "any" of the attacker be scoped any more? -- Explain why this is possible – because Babel peers are not authenticated and Babel messages aren’t integrity/replay protected -- Discuss the impact of this misdirection: denial of service (dropping the traffic and against a given target), eavesdropping, or allowing for the possibility of traffic modification (depending on upper level security mechanisms) – RFC4593 covers a number of them -- Note that because Babel messages aren’t encrypted any on-path attacker can gather the routing topology (2) The rest of this paragraph describes the security properties conveyed by link-layer security, IPSec, BABEL-HMAC and BABEL-TLS. They all make sense. Please be explicit that IPSec or BABEL-TLS address all of the above described attacks. BABEL-HMAC addresses only somet. (3) Per “HMAC is simpler and does not depend on DTLS, and therefore its use is RECOMMENDED whenever both mechanisms are applicable”, can you explain this recommendation and the circumstances where “both mechanisms are applicable”. If one wants to ensure confidentiality, it can’t be realized with HMAC – they aren’t equal. (4) Per “The privacy issues that this causes can be mitigated somewhat by using randomly chosen router-ids and randomly chosen IP addresses, and changing them periodically, who’s IP address should be randomly chosen the Babel node or the mobile device? In other sections: (5) Appendix C: Per the last paragraph, “The packet trailer is intended to carry cryptographic signatures …”, to what security mechanism is that referring? Where is that defined? (6) Appendix D: Is the stub implementation guidance normative? If so, will it satisfy all of the RFC2119 language in this document? (7) Appendix E. Please explicitly state that the sample implementation is non-normative. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (8) Section 1.1. What is a “network diameter”? Calculated how? (9) Section 3.6. Recommend avoiding the phrase “protocol’s correctness” (10) Section 3.7.2, Per the guidance to send updates with acknowledgement requests to a small, but not a large number of neighbors. Is there guidance to provide on what is a large number? (11) Section 3.8.2.4. Is there any guidance on what a “small number of multicast” requests constitutes? (12) Section 4. Per “Both the source and destination UDP port are set to a well-known port number”, the same one? (13) Section 4.2. What is the “carefully chosen” rational for the magic number being 42 (unless this is a Hitchhikers Guide reference)? (14) Section 4.6.4. What are the properties needed for this nonce? (15) Section 6. Per the concern that Babel packets might escape into the wild and “No such natural protection exists when Babel packets are carried over IPv4”, doesn’t setting the TTL=1 per Section 4 help? (16) Appendix D: Per “Nonetheless, in some very constrained environments, such as … abacuses”, what does it mean to implement Babel on an analog device? (17) Did the WG consider renaming the title of this draft “Babel Routing Protocol v2” (as this is a distinct and new protocol)? (18) Editorial nits: -- Section 1.1. Editorial. s/Babel never/Babel does not/ -- Section 1.2 Editorial. s/Babel does impose/Babel imposes/ -- Section 2. Editorial. s/venerable RIP/RIP/ -- Section 2.3. Editorial. s/It is well known that a/A/ -- Section 4.1.2. Typo. s/ones ones/ones/ From nobody Wed Aug 7 12:26:06 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 6CDF41206A2; Wed, 7 Aug 2019 12:26:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-babel-dtls@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <156520596444.8244.649940515091541992.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2019 12:26:04 -0700 Archived-At: Subject: [babel] Roman Danyliw's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT) 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: Wed, 07 Aug 2019 19:26:05 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-babel-dtls-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) Section 1. These are different than the ones listed in Section 6 of draft-ietf-babel-rfc6126bis and Section 1 of draft-ietf-babel-dtls. As DTLS and HMAC are mitigations for attacks in draft-ietf-babel-rfc6126bis, they really should be harmonized. (2) Section 2.1. Per “Implementations MUST support authenticating peers against a local store of credentials”, what does that credentialing look like? Is it certificates, PSK, etc? What validation procedure is being used for this authentication? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (3) Abstract. Per “Babel does not contain any means … [to] protect messages”, be more precise in the definition of protect (i.e., integrity and confidentiality) (4) Section 1.2. Per “A comparison of Babel security mechanisms and their applicability can be found in [RFC6126bis]”, where in draft-ietf-babel-rfc6126bis does this comparison occur. The references to HMAC and TLS are in a single paragraph in in Section 6/Security Considerations which roughly reiterate the one sentence statements written here. (5) Section 2.1. Per “When a node receives a new DTLS connection, it MUST verify that the source IP address is an IPv6 link-local address …”, what happens if IPv4 is in use? (6) Section 2.1. Per “Nodes MUST only negotiate DTLS version 1.2 or higher”, this is stricter than RFC7525 cited in the Security Consideration later in the draft. That’s fine, but please reiterate that in Section 5. (7) Section 2.6 Suggest being clearer that this is a deployment not an implementation issue. s/Implementations MAY implement both Babel over DTLS and unprotected Babel./ /A node MAY run both Babel over DTLS and unprotected Babel./ (8) Section 2.6, Per “However, accepting unprotected Babel packets … loses the security properties of Babel over DTLS”. This seems misleading. The security properties of “Babel over DTLS” as a protocol are stated in Section 1.2. In this section there is discussion of the security properties of the node (and the resulting neighbor table). These are different. The issue seems to be that a node is building a neighbor table with updates from sources which need to be trusted to different degrees. (9) Section 5. Per “Confidential interaction between two Babel peers requires Datagram Transport Layer Security (DTLS) with a cipher suite offering confidentiality protection. The guidance given in [RFC7525] MUST be followed to avoid attacks on DTLS.”, the first sentence is true, but incomplete, in that we’d also want cipher suites with a strong key exchange algorithm, etc. Section 4.2 of RFC7525, which is cited as a MUST, provides a list of recommended ciphers suites. Do we need this first sentence? (10) Editorial -- Section 2.1. Expand “IHU” on first use -- Section 3. Nit. s/ciphers/ciphersuites/ From nobody Wed Aug 7 12:34: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 B0FD0120694; Wed, 7 Aug 2019 12:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 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, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Y8CumcGv6CMo; Wed, 7 Aug 2019 12:34:33 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 8D62B120693; Wed, 7 Aug 2019 12:34:33 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id s49so52771905edb.1; Wed, 07 Aug 2019 12:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=kgW9TU7+aLljogBqjLpXWjbF2sJ2fecLWkiiLKrH8lE=; b=Y7JXO629ZtTv1WIHaASyvhPr910/fQHQ4JjJDsawnvpr0g6ONshJ0dUyoWab3Km6ZP N7VPsGsn+L3YB/AErQNRwpW6tz62djHKwTXw9fhJwKcphrgkpbCJHTBeN3MUWuruymSP jzKvMFxGYdox3GMsYSbCl9iRWq8bjsITnFwrRMq6DRmh5QdWcQdVdXGJt8Nu0QTntenb ImXHeOTAiWxEFMWOkfslgYTFB9ZQ+0hAbVwcQAtrR7G0u3jbeMDesvkosnZ+txqRQTpz fV1cy5NhQK7uzYNEXC+iPc2MUYdFjAbYZVZthEJBhdRlzjj4YldHwKl3WBIq2oEHjrN3 ZcMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=kgW9TU7+aLljogBqjLpXWjbF2sJ2fecLWkiiLKrH8lE=; b=meu1hzmh6mrOnnyWyuMlCN97uzsX5bONrJ0SctG8TJvkuVsfoVsmQItGYAELuPSoAu 7OL5XX9rLRzzlTQ1/8W/urg+dOHZUtlsiYmc8QZ7eOMotkJFPggxHJN+78hNjzCAPFxQ HDTZNj2nEQx/SSAEVt3zfexq+6XWm8VpJJSM5S2ZR3hRDIWskcTAeracXahG1SS9cKmI VB/av+HwydaYXIqRHreLhMXcrztY1mjxg6PT/OX1MQSV8wce9UX1AoXucGvaDnvLsy1c lBwQbEmNATZFlBpHXhiOQdP4Y5i89xwg1Q2WNXdH2eUDZK5CNzqdQpmkId1bVpFe27bc 0Qbw== X-Gm-Message-State: APjAAAVvpmkjF1Mvrcu48nG7m+iz7NF/4Zh0W2+VU7tzlND45lprs8yG CQ1wlC1b5axN1ZTic4yE4w2rT7l2AyUmCb3dO9HaFMW1 X-Google-Smtp-Source: APXvYqwC4mtmkq94l8MVkptO7Qee4uO2j2EWJM9Qz8ATeX9TfwlDcNMe4K+28xCFrKrWjGFXTB4QC3i0k4AAIFr/eNg= X-Received: by 2002:a17:906:264a:: with SMTP id i10mr9979970ejc.10.1565206472010; Wed, 07 Aug 2019 12:34:32 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 7 Aug 2019 12:34:30 -0700 From: Alvaro Retana In-Reply-To: <875zn9htem.wl-jch@irif.fr> References: <156518456148.8400.6644665367614468260.idtracker@ietfa.amsl.com> <875zn9htem.wl-jch@irif.fr> MIME-Version: 1.0 Date: Wed, 7 Aug 2019 12:34:30 -0700 Message-ID: To: Juliusz Chroboczek Cc: babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , The IESG , draft-ietf-babel-rfc6126bis@ietf.org Content-Type: multipart/alternative; boundary="000000000000c3b06b058f8c0762" Archived-At: Subject: Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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: Wed, 07 Aug 2019 19:34:36 -0000 --000000000000c3b06b058f8c0762 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On August 7, 2019 at 11:44:34 AM, Juliusz Chroboczek (jch@irif.fr) wrote: Dear Juliusz: Hi! > (A) Clear Defaults and Operational Guidance > While I appreciate Babel's flexibility in terms of the ability to use > different strategies, I believe that both defaults and clear guidance > should be provided. You'll doubtless agree that we must be careful here. We are in a universe in which there exist perfectly good routing protocols that operators are already comfortable with (notably OSPF and IS-IS). Babel's niche is the ability to adapt to environments where OSPF and IS-IS do not work well; if we restrict this flexibility too much, our niche vanishes. > Given that "not all...strategies will give good results" and that in > most cases these are listed as possible choices, I don't think that this > document "has resolved known design choices" [BCP9/rfc7127]. The > cost/metric computation and route selection specially concern me because > I believe that a robust/clear specification is at the heart of any > routing protocol. The point here is that Babel will still converge and will still behave in a loop-free manner whatever the algorithm chosen, as long as the conditions described in Section 3.5.2 hold. (This is provably true in the case where the metric is left-distributive, and believed to hold even if it is not.) I'll expand on the description of the suggested algorithms in Sections 3.5.= 2 and 3.6. However, I shall not make it a MUST, for the reasons outlined above. I hope that's okay with you. It doesn=E2=80=99t have to be a MUST, but I would really want to see someth= ing RECOMMENDED. > (A1) Clear defaults. For example, Appendix B talks about constants/defaul= t > values. I would assume that, given the existing experience, that the values > there are probably sensible defaults. Is that not the case? I liken this to BFD. RFC 5880 does not give any default values for its timers, since the suitable values depend so much on the environment. Look at rfc7419; it Updates rfc5880 to define a set of Common Intervals. >From the Shepherd writeup: "While the draft recommends a number of timer values, they are suggested for interoperability while not mandating that any particular value be supported." The values suggested in Appendix B are suitable for a reasonably stable network where outages on the order of 6 to 10 seconds are acceptable. In mobile networks, Hello intervals of 0.5 yield better results. To the contrary, people running Babel over stable tunnels have been using much larger intervals. This is exactly what I=E2=80=99m looking for. You don=E2=80=99t need to ab= solutely mandate (MUST) specific settings, but can say =E2=80=9Cfor these conditions (just l= ike above) then the RECOMMENDED settings are...=E2=80=9D. This opens the door= because =E2=80=9Cthere may exist valid reasons in particular circumstances to ignor= e a particular item, but the full implications must be understood and carefully weighed before choosing a different course=E2=80=9D [rfc2119], which is whe= re the second part (below) comes in. > (A2) Operational Considerations. Given that Babel can be (and is) used > in different environments, I would like to see guidance to operators as > they deploy the protocol in their networks. An example of the type of > discussion I would like to see expanded is: "a mobile node that is low > on battery may choose to use larger time constants (hello and update > intervals, etc.) than a node that has access to wall power" (=C2=A71.1). > Consider =C2=A72 in rfc5706 (Operational Considerations - How Will the Ne= w > Protocol Fit into the Current Environment?). This is not clear to me. What exactly are you requesting here? What should be the Operational Considerations for different environments that (without explicitly mandating anything) will guide the operator to change the recommended defaults? For example, you mentioned above that "people running Babel over stable tunnels have been using much larger intervals=E2=80=9D=E2=80=A6ok, that=E2=80=99s good=E2=80=A6why? What are t= he characteristics of that type of deployment that would make an operator consider different values? Specifically, what would make them consider much larger intervals? What are the advantages? What are possible disadvantages of not doing so? IOW, if someone other than the implementers decide to deploy Babel, what should they take into account when selecting a strategy or setting? I hope this makes sense. Thanks! Alvaro. --000000000000c3b06b058f8c0762 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On August 7, 2019 at 11:44:34 AM, Juliusz Chrobo= czek (jch@irif.fr) wrote:

Dear Juliusz:

Hi!<= /div>


= > (A) Clear Defaults and Operational Guidance=C2=A0

> While I appreciate Babel's flexibi= lity in terms of the ability to use= =C2=A0
> different strategies, I believe that both defaults an= d clear guidance=C2=A0
>= should be provided.=C2=A0
=
You'll doubtless agree that we must be careful here. We are in a un= iverse=C2=A0
in which there= exist perfectly good routing protocols that operators are=C2=A0
already comfortable with (notably OSP= F and IS-IS). Babel's niche is the=C2=A0
ability to adapt to environments where OSPF and IS-IS do = not work well; if=C2=A0
we = restrict this flexibility too much, our niche vanishes.=C2=A0

> Given that "not all...stra= tegies will give good results" and that in=C2=A0
> most cases these are listed as possible cho= ices, I don't think that this=C2= =A0
> document "has resolved known design choices" [= BCP9/rfc7127]. The=C2=A0
&g= t; cost/metric computation and route selection specially concern me because= =C2=A0
> I believe that = a robust/clear specification is at the heart of any=C2=A0
> routing protocol.=C2=A0

The point here is that Babel will stil= l converge and will still behave in= =C2=A0
a loop-free manner whatever the algorithm chosen, as long = as the conditions=C2=A0
des= cribed in Section 3.5.2 hold. (This is provably true in the case where=C2=A0
the metric is left-distri= butive, and believed to hold even if it is not.)=C2=A0

I'll expand on the description of the s= uggested algorithms in Sections 3.5.2= =C2=A0
and 3.6. However, I shall not make it a MUST, for the reas= ons outlined above.=C2=A0
I= hope that's okay with you.=C2=A0=

It doesn=E2=80=99t have to = be a MUST, but I would really want to see something RECOMMENDED.


=

> (A1) Clear defaults. For example, Appendix B talks about constants/de= fault=C2=A0
> values. I = would assume that, given the existing experience, that the values=C2=A0
> there are probably sensib= le defaults. Is that not the case?=C2= =A0

I liken this to BFD. RFC 5880 does not give any default v= alues for its=C2=A0
timers,= since the suitable values depend so much on the environment.=C2=A0
=

Look at rfc7419; it Updates rfc5880 to define a set of Common Intervals.= =C2=A0 From the Shepherd writeup: "While the draft recommends a number= of timer values, they are suggested for interoperability while not mandati= ng that any particular value be supported."



The values suggested = in Appendix B are suitable for a reasonably stable=C2=A0
network where outages on the order of 6 to 10= seconds are acceptable. In=C2=A0
mobile networks, Hello intervals of 0.5 yield better results. To the= =C2=A0
contrary, people run= ning Babel over stable tunnels have been using much=C2=A0
larger intervals.=C2=A0
<= p>This is exactly what I=E2=80=99m looking for.=C2=A0 You don=E2=80=99t nee= d to absolutely mandate (MUST) specific settings, but can say =E2=80=9Cfor = these conditions (just like above) then the RECOMMENDED settings are...=E2= =80=9D. =C2=A0 This opens the door because =E2=80=9Cthere may exist valid r= easons in particular circumstances to ignore a particular item, but the ful= l implications must be understood and carefully weighed before choosing a d= ifferent course=E2=80=9D [rfc2119], which is where the second part (below) = comes in.

> (A2) Operational Considerations. Given that Babel can be (= and is) used=C2=A0
> in = different environments, I would like to see guidance to operators as=C2=A0
> they deploy the protoc= ol in their networks. An example of the type of=C2=A0
> discussion I would like to see expanded is:= "a mobile node that is low=C2= =A0
> on battery may choose to use larger time constants (hell= o and update=C2=A0
> int= ervals, etc.) than a node that has access to wall power" (=C2=A71.1).<= span class=3D"Apple-converted-space">=C2=A0
> Consider =C2=A72= in rfc5706 (Operational Considerations - How Will the New=C2=A0
> Protocol Fit into the Current En= vironment?).=C2=A0

This= is not clear to me. What exactly are you requesting here?=C2=A0

= What should be the Operational Considerations for different environments th= at (without explicitly mandating anything) will guide the operator to chang= e the recommended defaults?=C2=A0 For example, you mentioned above that &qu= ot;people running Babel over stable tunnels have been using much larger int= ervals=E2=80=9D=E2=80=A6ok, that=E2=80=99s good=E2=80=A6why?=C2=A0 What are= the characteristics of that type of deployment that would make an operator= consider different values?=C2=A0 Specifically, what would make them consid= er much larger intervals?=C2=A0 What are the advantages?=C2=A0 What are pos= sible disadvantages of not doing so?

IOW, if someone other than the i= mplementers decide to deploy Babel, what should they take into account when= selecting a strategy or setting?


I hope this makes sense.=

Thanks!

Alvaro.

--000000000000c3b06b058f8c0762-- From nobody Wed Aug 7 12:35:15 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 CD41E120693; Wed, 7 Aug 2019 12:35:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-babel-hmac@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <156520650683.8432.7109781814790904901.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2019 12:35:06 -0700 Archived-At: Subject: [babel] Roman Danyliw's Discuss on draft-ietf-babel-hmac-08: (with DISCUSS and COMMENT) 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: Wed, 07 Aug 2019 19:35:07 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-babel-hmac-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-hmac/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- A few minor clarifications needed for implementation/precision in the security claims: (1) Section 1.2. Per “any packet accepted as authentic is the exactly copy of a packet originally sent”, this text can be read two ways – packet as Babel packet or as an IP packet. I think mean the former. Recommend making this clearer as s/any packet/any Babel packet/ (2) Section 2, Per the paragraph, “By itself, this mechanism is safe against replay …”, please reiterate that for the attack by C to work: A and B must have both lost state; that C is replaying packets with PC previously sent by B (e.g., n+2). (3) Section 4.1. Per “The node takes the concatenation of the pseudo-header and the packet including the packet header but excluding the packet trailer (from octet 0 inclusive up to (Body Length + 4) exclusive)”, as input for the HMAC. “packet” is used to sometimes mean IP packet and sometimes a Babel packet carried in an IP packet. As such, the above sentence could be interpretation as: Option #1: HMAC(pseudo-header + the IP header + Babel packet header + Babel packet body) Option #2: HMAC(pseudo-header + Babel packet header + Babel packet body) I believe it is option #2. Please be very clear in this text. Other items: (4) Section 2. This section suggests that “one or more HMACs can be appended to the packet”. Under what conditions would it be more than one? What happens if only some of the HMACs are valid? Is use of the same key assumed? (5) Section 4.1. The hash algorithm appears to be negotiated/set out of band (rather than negotiated). The text should explicitly state that somewhere. (6) Section 6. Per “In particular, reception of a packet with no correct HMAC creates no local state whatsoever (Section 4.3)”, unless this HMAC verification is happening on the NIC, this doesn’t seem sufficiently precise. The “no local state” claim is likely true only as it relates to the tables data structures describes in Section 3. However, the IP and DTLS stack certainly have to account for the packet. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (7) Section 1 enumerates a series of attacks. These are different than the ones listed in Section 6 of draft-ietf-babel-rfc6126bis and Section 1 of draft-ietf-babel-dtls. As HMAC and DTLS are mitigations for attacks in draft-ietf-babel-rfc6126bis, they really should be harmonized. (8) Section 1. Per the “spoof of a malformed packet”, how would an HMAC address this? Even assuming that a node discards the message without processing if the HMAC is bad, this would still be a problem from a malicious peer. (9) Editorial nits: -- Section 1. “seqno” is commonly used in Babel text but it needs to be cited of explained here on for used -- s/seqno/sequence number/ -- Section 1.2. Editorial. s/serious effort/effort/ -- Section 3.1. Typo. s/authentified/authenticated/ -- Section 5.3. Typo. s/minumum/minimum/ From nobody Wed Aug 7 12:38:11 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 259A3120694; Wed, 7 Aug 2019 12:38:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-babel-applicability@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <156520668914.8405.11909335529336925535.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2019 12:38:09 -0700 Archived-At: Subject: [babel] Roman Danyliw's No Objection on draft-ietf-babel-applicability-09: (with COMMENT) 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: Wed, 07 Aug 2019 19:38:09 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-babel-applicability-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-applicability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Section 2.1. This section makes a number strong claims that I would recommend be tempered: -- Per the sentence, “Given a sufficiently friendly audience, the principles behind Babel can be explained in 15 minutes, and a full description of the protocol can be done in 52 minutes (one microcentury)”, what does this mean? If this is to suggest to the reader that they too can learn Babel in 15 minutes, it is unconvincing and reads like a marketing statement. -- Per the phrase, “…including one that was reportedly written and debugged in just two nights“, this statement is not convincing without context. -- Per the sentence, “In addition to the above, our implementation experience indicates that Babel tends to be robust with respect to bugs: more often than not, an implementation bug …”, this text is an improvement over -07 (thank you), but I still view this as a high risk, anecdotal claim. I strongly recommend it be removed. (2) Section 2.2. This section uses the designation of “strong” vs. a “weak” property. Where are those defined? (3) Section 2.2. Per the sub-bullets of “These weak requirements make Babel a robust protocol …”, what assurance does the phrase “does most likely not” suggest? Furthermore, the claim that implementation bugs won’t collapse the network based on an uncited “extensive” experience seems too strong of claim. (4) Per Section 3.1. How big is a “medium-sized hybrid network”? (5) Per Section 3.1. What are “meshy wireless bits”? (6) Section 3.2. Is there a citation for the successful deployment in “large scale overlay networks, built out of thousands of tunnels spanning continents”? (7) Section 3.4. The utility of Babel in small and home offices surprised me as I wasn't expecting such networks to mix IPv4 and v6; and use an IGP. (8) Section 5. Per the sentence “Due to its simplicity, Babel-HMAC …”, I’m not sure that simplicity should be driving the choice of the security properties. It seems like it should be the security requirements. From nobody Wed Aug 7 12:51:14 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 9C65D120152 for ; Wed, 7 Aug 2019 12:51:12 -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 V-8xIddU8R3w for ; Wed, 7 Aug 2019 12:51:10 -0700 (PDT) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 216DA120073 for ; Wed, 7 Aug 2019 12:51:10 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id ay6so42382327plb.9 for ; Wed, 07 Aug 2019 12:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Y3IqXhIpGSHFEoCRp0oGOjoiA7XiRn7nxN7mM3zNE7g=; b=MbVP6qehtP6qw9MkfQzBt//KmxnmEbdX07Pg3zZNu2gDMyUFJPBvQXrO1aafcvySxC TTmSWgslaMKX3NqaUTDJRR+lVV704Q0o8s4UD/8pAbmrwOU47Ez/0Dp6bYcsPiuqYkAJ OQAuT0KvOXfmpVjBVpu+hgSmm3pT6OeCAQbpac+aKUmWyNOAwg6O/P4uMs94NnEYYT79 JGhln5LFQ+J65WsfHRQ3hHLro7koeIxxe/ImVjpUjIgqjYSM2L39jSF0auN6VB8j2OdZ /Iz6/uGCLapIuGkRNmV8GcDkWhTyPwUxxrHYbf22PZMYJxolL1VDxgt+8v7hdoanoh3L qGpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Y3IqXhIpGSHFEoCRp0oGOjoiA7XiRn7nxN7mM3zNE7g=; b=Yc1Mmo/N2tlSM2qJOXkDzXjtLo3LmE5tUOkisxxoyZPz+bKYPTfoaVUItfSO71mEgG r1h44mbGn+siuos9eGJV6HH66xS0dyipPxqda/kUgeh4iLP86g7sWEJersj0BpMa/npl r4WxOnGbpjlx9bWDJOlFKydkP/XOySY1jP2KGAuNgv4ujqHTYOKTsD04ZKhrJQJQXpFe peP/Qi+HbqN87Qdv5lYS4voxwmAk4ToKM4K4uK6XYWDY+pSSClP54sGDXkYgYgQEQ8B3 8WGc+2kDOsqQiCqeRSTqVyMb5gS1ye0fruMFV8XnDU9jiXEMrPemnXKr557vHKLb1iC1 6pPg== X-Gm-Message-State: APjAAAVrQ+qn2wwVwNIseHZ6CFRHzxaBvx2eX904wdnmtz5pwip7EEkC r4tD/DAAg1sAyXagkA4c7tw= X-Google-Smtp-Source: APXvYqw/MMSVbLLW+dPBlJzL0zOP6f2Yp4Y6fxR4ANCCf8L5Q7hFEIzEPl11l6dktiPzGe3LYUxw9g== X-Received: by 2002:a17:902:9f93:: with SMTP id g19mr9604214plq.223.1565207469531; Wed, 07 Aug 2019 12:51:09 -0700 (PDT) Received: from [10.33.122.240] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id a3sm94325352pfo.49.2019.08.07.12.51.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Aug 2019 12:51:08 -0700 (PDT) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3C4960D2-C31C-4F53-8CE5-D0610D32CD30" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 7 Aug 2019 12:51:07 -0700 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E258CF7@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: Juliusz Chroboczek , Babel at IETF To: "STARK, BARBARA H" References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr> <87pnlhaixh.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E257961@GAALPA1MSGUSRBF.ITServices.sbc.com> <0B28A1FA-32B4-41E6-B646-C6A3907E9CCC@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114E258CF7@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Example configuration 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: Wed, 07 Aug 2019 19:51:13 -0000 --Apple-Mail=_3C4960D2-C31C-4F53-8CE5-D0610D32CD30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 7, 2019, at 11:55 AM, STARK, BARBARA H wrote: >=20 > =20 >=20 > =20 > What I had in mind for the updates to the information model are step = 5. If the operator needs to update link-quality, or flip on = split-horizon, or set a RTT estimate value, or specify whether they want = to use unicast instead of multicast, or any combination thereof for a = particular interface, they would create a new babel-link-properties = object and associate that with the interface. >=20 > Can we agree on the changes to the information model I suggested = yesterday? > =20 > Let me see if I understand... Does it have to be a =E2=80=9Cnew=E2= =80=9D babel-link-properties instance, or can it be one that exists? > =20 > That is, if we had an object called babel-link-properties=20 > object { > string rw babel-link-properties-name; > [string rw babel-interface-metric-algorithm;] > [boolean rw babel-interface-split-horizon;] > [boolean rw babel-interface-rtt;] > [boolean rw babel-interface-unicast;] > } babel-hmac-keys-obj babel-link-properties; [mj] with the corrections marked in red. > =20 > Where the implementation may create some set of initial entries that = its developers have decided to e.g. name =E2=80=9Cwired=E2=80=9D, = =E2=80=9Cwireless=E2=80=9D, =E2=80=9Ctunnel=E2=80=9D (but some other = implementation may give a different name to the same group of parameter = values). link-properties-name must be unique (and not empty or NULL), = but also no 2 instances are allowed to have the same set of values for = the latter 4 parameters. Once an instance is created it cannot be = modified. If it is referenced from an interface or was created by the = implementation, it cannot be deleted. This makes instances created by = the implementation immutable. > This object can be written (new instances created with different = combinations of values and a different name, like =E2=80=9Cunicast-wired=E2= =80=9D). > An interface will have a reference to one of these instances, to = identify the set of link-properties it uses. It=E2=80=99s allowed to = modify which set of link-properties is used/referenced by an interface. > =20 > Is that right? And did you say you wanted it under interface or under = the base? I think it would make sense under base. Juliusz, I think this = approach (if it=E2=80=99s what Mahesh meant) would provide the benefits = of allowing users to use more meaningful names for groups of link = properties, allow use of names that babeld has already popularized among = its users while allowing other implementations to use different names = (names aren=E2=80=99t standardized), and isn=E2=80=99t very complicated. = It does make it harder if the user wants to just change one of the link = properties and not others (they might have to create a new instance). = But it makes it easier for the user who wants to change from one = grouping of properties to another. [mj] Yes, that is what the intention of the change was. Note, I did want = instances of babel-link-properties to exist under the base = (babel-informtion-obj). In babel-interface-obj we only reference one of = those instances: object { =E2=80=A6. [babel-link-properties rw babel-link-properties<0..*>;] } babel-information-obj; object { [reference rw babel-link-properties;] =E2=80=A6.. } babel-interface-obj; > Barbara Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_3C4960D2-C31C-4F53-8CE5-D0610D32CD30 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 7, 2019, at 11:55 AM, STARK, BARBARA H <bs7652@att.com> = wrote:

 

 
What I = had in mind for the updates to the information model are step 5. If the = operator needs to update link-quality, or flip on split-horizon, or set = a RTT estimate value, or specify whether they want to use unicast = instead of multicast, or any combination thereof for a particular = interface, they would create a new babel-link-properties object and = associate that with the interface.

Can we agree on the changes to the information = model I suggested yesterday?
 
<bhs> Let me see if I understand... Does = it have to be a =E2=80=9Cnew=E2=80=9D babel-link-properties instance, or = can it be one that exists?
 
That is, if we had an object called = babel-link-properties 
     object {
          = string           &n= bsp;    rw babel-link-properties-name;
          = [string       =         rw babel-interface-metric-algorithm;]
          = [boolean        =        rw = babel-interface-split-horizon;]
          [boolean    =            rw = babel-interface-rtt;]
          = [boolean        =        rw babel-interface-unicast;]
      } babel-hmac-keys-obj babel-link-properties;=

[mj] with the corrections marked in red.

 
Where the implementation may create = some set of initial entries that its developers have decided to e.g. = name =E2=80=9Cwired=E2=80=9D, =E2=80=9Cwireless=E2=80=9D, =E2=80=9Ctunnel=E2= =80=9D (but some other implementation may give a different name to the = same group of parameter values). link-properties-name must be unique = (and not empty or NULL), but also no 2 instances are allowed to have the = same set of values for the latter 4 parameters. Once an instance is = created it cannot be modified. If it is referenced from an interface or = was created by the implementation, it cannot be deleted. This makes = instances created by the implementation immutable.
This object can be written (new = instances created with different combinations of values and a different = name, like =E2=80=9Cunicast-wired=E2=80=9D).
An interface will have a reference = to one of these instances, to identify the set of link-properties it = uses. It=E2=80=99s allowed to modify which set of link-properties is = used/referenced by an interface.
 
Is that right? And did you say you wanted it = under interface or under the base? I think it would make sense under = base. Juliusz, I think this approach (if it=E2=80=99s what Mahesh meant) = would provide the benefits of allowing users to use more meaningful = names for groups of link properties, allow use of names that babeld has = already popularized among its users while allowing other implementations = to use different names (names aren=E2=80=99t standardized), and isn=E2=80=99= t very complicated. It does make it harder if the user wants to just = change one of the link properties and not others (they might have to = create a new instance). But it makes it easier for the user who wants to = change from one grouping of properties to = another.

[mj] Yes, that is what the intention of the change was. = Note, I did want instances of babel-link-properties to exist under the = base (babel-informtion-obj). In babel-interface-obj we only reference = one of those instances:

object {
          =E2= =80=A6.
          [ba= bel-link-properties   rw babel-link-properties<0..*>;]

} babel-information-obj;

object = {
         [reference =             &n= bsp;        rw =  babel-link-properties;]
          =E2= =80=A6..
} babel-interface-obj;

Barbara

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_3C4960D2-C31C-4F53-8CE5-D0610D32CD30-- From nobody Wed Aug 7 13:10: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 1C3A312030A for ; Wed, 7 Aug 2019 13:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 AJ4bGMunxaGU for ; Wed, 7 Aug 2019 13:09:55 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6CD12069F for ; Wed, 7 Aug 2019 13:09:55 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x77JveFV020177; Wed, 7 Aug 2019 16:09:54 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2u848ea94g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Aug 2019 16:09:53 -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 x77K9p8I023973; Wed, 7 Aug 2019 16:09:52 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x77K9gh2023646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Aug 2019 16:09:42 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 5775D4009E78; Wed, 7 Aug 2019 20:09:42 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30485.vci.att.com (Service) with ESMTPS id 3FEE34009E74; Wed, 7 Aug 2019 20:09:42 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0439.000; Wed, 7 Aug 2019 16:09:42 -0400 From: "STARK, BARBARA H" To: "'Mahesh Jethanandani'" CC: "'Juliusz Chroboczek'" , "'Babel at IETF'" Thread-Topic: [babel] Example configuration Thread-Index: AQHVQysP27rmDxHNmE+dOkameIFP66bcIv6AgBKtMoCAAAmwgIAACWOAgAAV/4CAAC8QgIAAC2UAgABwxXCAAK2IgP//vsCAgABe24D//71TQA== Date: Wed, 7 Aug 2019 20:09:41 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E25905B@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr> <87pnlhaixh.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E257961@GAALPA1MSGUSRBF.ITServices.sbc.com> <0B28A1FA-32B4-41E6-B646-C6A3907E9CCC@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114E258CF7@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.248.192] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114E25905BGAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-07_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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908070178 Archived-At: Subject: Re: [babel] Example configuration 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: Wed, 07 Aug 2019 20:10:04 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114E25905BGAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCldoYXQgSSBoYWQgaW4gbWluZCBmb3IgdGhlIHVwZGF0ZXMgdG8gdGhlIGluZm9ybWF0aW9u IG1vZGVsIGFyZSBzdGVwIDUuIElmIHRoZSBvcGVyYXRvciBuZWVkcyB0byB1cGRhdGUgbGluay1x dWFsaXR5LCBvciBmbGlwIG9uIHNwbGl0LWhvcml6b24sIG9yIHNldCBhIFJUVCBlc3RpbWF0ZSB2 YWx1ZSwgb3Igc3BlY2lmeSB3aGV0aGVyIHRoZXkgd2FudCB0byB1c2UgdW5pY2FzdCBpbnN0ZWFk IG9mIG11bHRpY2FzdCwgb3IgYW55IGNvbWJpbmF0aW9uIHRoZXJlb2YgZm9yIGEgcGFydGljdWxh ciBpbnRlcmZhY2UsIHRoZXkgd291bGQgY3JlYXRlIGEgbmV3IGJhYmVsLWxpbmstcHJvcGVydGll cyBvYmplY3QgYW5kIGFzc29jaWF0ZSB0aGF0IHdpdGggdGhlIGludGVyZmFjZS4NCg0KQ2FuIHdl IGFncmVlIG9uIHRoZSBjaGFuZ2VzIHRvIHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBJIHN1Z2dlc3Rl ZCB5ZXN0ZXJkYXk/DQoNCjxiaHM+IExldCBtZSBzZWUgaWYgSSB1bmRlcnN0YW5kLi4uIERvZXMg aXQgaGF2ZSB0byBiZSBhIOKAnG5ld+KAnSBiYWJlbC1saW5rLXByb3BlcnRpZXMgaW5zdGFuY2Us IG9yIGNhbiBpdCBiZSBvbmUgdGhhdCBleGlzdHM/DQoNClRoYXQgaXMsIGlmIHdlIGhhZCBhbiBv YmplY3QgY2FsbGVkIGJhYmVsLWxpbmstcHJvcGVydGllcw0KICAgICBvYmplY3Qgew0KICAgICAg ICAgIHN0cmluZyAgICAgICAgICAgICAgICBydyBiYWJlbC1saW5rLXByb3BlcnRpZXMtbmFtZTsN CiAgICAgICAgICBbc3RyaW5nICAgICAgICAgICAgICAgcncgYmFiZWwtaW50ZXJmYWNlLW1ldHJp Yy1hbGdvcml0aG07XQ0KICAgICAgICAgIFtib29sZWFuICAgICAgICAgICAgICAgcncgYmFiZWwt aW50ZXJmYWNlLXNwbGl0LWhvcml6b247XQ0KICAgICAgICAgIFtib29sZWFuICAgICAgICAgICAg ICAgcncgYmFiZWwtaW50ZXJmYWNlLXJ0dDtdDQogICAgICAgICAgW2Jvb2xlYW4gICAgICAgICAg ICAgICBydyBiYWJlbC1pbnRlcmZhY2UtdW5pY2FzdDtdDQogICAgICB9IGJhYmVsLWhtYWMta2V5 cy1vYmogYmFiZWwtbGluay1wcm9wZXJ0aWVzOw0KDQpbbWpdIHdpdGggdGhlIGNvcnJlY3Rpb25z IG1hcmtlZCBpbiByZWQuDQo8YmhzPiBJIHRoaW5rIGJhYmVsLWludGVyZmFjZS1tZXRyaWMtYWxn b3JpdGhtIGlzIOKAnG1hbmRhdG9yeSBpbiB0aGUgc2Vuc2UgaXQgbXVzdCBiZSBpbXBsZW1lbnRl ZCBhbmQgZXhwcmVzc2VkIHRvIGJlIGNvbXBsaWFudCB3aXRoIHRoZSBpbmZvIG1vZGVs4oCdLiBT byBJIGRpc2FncmVlIHdpdGggdGhlIHNxdWFyZSBicmFja2V0cyBmb3IgdGhhdCBvbmUuIFRoZSBl eGlzdGVuY2Ugb2YgdGhlIG1ldHJpYy1hbGdvcml0aG0gaXMgcmVhc29uYWJseSBub3JtYXRpdmUg aW4gcmZjNjEyNmJpcy4gVGhlIHBvc3NpYmxlIGVudW1lcmF0aW9ucyBhcmVu4oCZdCBub3JtYXRp dmUsIGJ1dCB0aGF04oCZcyBub3Qgd2hhdCB0aGUgc3F1YXJlIGJyYWNrZXRzIG1lYW4uIEF0IGxl YXN0IG9uZSBtZXRyaWMgY2FsY3VsYXRpb24gYWxnb3JpdGhtIG11c3QgYmUgaW1wbGVtZW50ZWQg YW5kIGl0IG11c3QgYmUgZ2l2ZW4gYSBuYW1lIGFuZCBleHByZXNzZWQgdG8gYmUgY29tcGxpYW50 IHdpdGggdGhlIGluZm8gbW9kZWwuIEkgc2VlIHJmYzYxMjZiaXMgaGFzIHNwbGl0IGhvcml6b24g YXMg4oCcU0hPVUxE4oCdIChCYWJlbCBub2RlIFNIT1VMRCB1c2UgYW4gb3B0aW1pc2F0aW9uIGtu b3duIGFzIHNwbGl0IGhvcml6b24pLCBzbyBJIGFncmVlIHdpdGggc3F1YXJlIGJyYWNrZXRzIGZv ciB0aGF0LiBUaGUgb3RoZXIgMiBhcmVu4oCZdCBhY3R1YWxseSBnb2luZyBpbiBhdCB0aGlzIHRp bWUsIHNvIHRoZXJl4oCZcyBubyBkZXBlbmRlbmN5IG9uIHRoZWlyIGRyYWZ0cy4gVGhleSBuZWVk IHRvIG1lbnRpb24gd2hhdCBkYXRhIGVsZW1lbnRzIHRoZXkgbmVlZCBpbiB0aG9zZSBkcmFmdHMu IEFuZCwgeWVhaCwgSeKAmW0gc2xvcHB5IHdpdGggY3V0IGFuZCBwYXN0ZS4NCg0KV2hlcmUgdGhl IGltcGxlbWVudGF0aW9uIG1heSBjcmVhdGUgc29tZSBzZXQgb2YgaW5pdGlhbCBlbnRyaWVzIHRo YXQgaXRzIGRldmVsb3BlcnMgaGF2ZSBkZWNpZGVkIHRvIGUuZy4gbmFtZSDigJx3aXJlZOKAnSwg 4oCcd2lyZWxlc3PigJ0sIOKAnHR1bm5lbOKAnSAoYnV0IHNvbWUgb3RoZXIgaW1wbGVtZW50YXRp b24gbWF5IGdpdmUgYSBkaWZmZXJlbnQgbmFtZSB0byB0aGUgc2FtZSBncm91cCBvZiBwYXJhbWV0 ZXIgdmFsdWVzKS4gbGluay1wcm9wZXJ0aWVzLW5hbWUgbXVzdCBiZSB1bmlxdWUgKGFuZCBub3Qg ZW1wdHkgb3IgTlVMTCksIGJ1dCBhbHNvIG5vIDIgaW5zdGFuY2VzIGFyZSBhbGxvd2VkIHRvIGhh dmUgdGhlIHNhbWUgc2V0IG9mIHZhbHVlcyBmb3IgdGhlIGxhdHRlciA0IHBhcmFtZXRlcnMuIE9u Y2UgYW4gaW5zdGFuY2UgaXMgY3JlYXRlZCBpdCBjYW5ub3QgYmUgbW9kaWZpZWQuIElmIGl0IGlz IHJlZmVyZW5jZWQgZnJvbSBhbiBpbnRlcmZhY2Ugb3Igd2FzIGNyZWF0ZWQgYnkgdGhlIGltcGxl bWVudGF0aW9uLCBpdCBjYW5ub3QgYmUgZGVsZXRlZC4gVGhpcyBtYWtlcyBpbnN0YW5jZXMgY3Jl YXRlZCBieSB0aGUgaW1wbGVtZW50YXRpb24gaW1tdXRhYmxlLg0KVGhpcyBvYmplY3QgY2FuIGJl IHdyaXR0ZW4gKG5ldyBpbnN0YW5jZXMgY3JlYXRlZCB3aXRoIGRpZmZlcmVudCBjb21iaW5hdGlv bnMgb2YgdmFsdWVzIGFuZCBhIGRpZmZlcmVudCBuYW1lLCBsaWtlIOKAnHVuaWNhc3Qtd2lyZWTi gJ0pLg0KQW4gaW50ZXJmYWNlIHdpbGwgaGF2ZSBhIHJlZmVyZW5jZSB0byBvbmUgb2YgdGhlc2Ug aW5zdGFuY2VzLCB0byBpZGVudGlmeSB0aGUgc2V0IG9mIGxpbmstcHJvcGVydGllcyBpdCB1c2Vz LiBJdOKAmXMgYWxsb3dlZCB0byBtb2RpZnkgd2hpY2ggc2V0IG9mIGxpbmstcHJvcGVydGllcyBp cyB1c2VkL3JlZmVyZW5jZWQgYnkgYW4gaW50ZXJmYWNlLg0KDQpJcyB0aGF0IHJpZ2h0PyBBbmQg ZGlkIHlvdSBzYXkgeW91IHdhbnRlZCBpdCB1bmRlciBpbnRlcmZhY2Ugb3IgdW5kZXIgdGhlIGJh c2U/IEkgdGhpbmsgaXQgd291bGQgbWFrZSBzZW5zZSB1bmRlciBiYXNlLiBKdWxpdXN6LCBJIHRo aW5rIHRoaXMgYXBwcm9hY2ggKGlmIGl04oCZcyB3aGF0IE1haGVzaCBtZWFudCkgd291bGQgcHJv dmlkZSB0aGUgYmVuZWZpdHMgb2YgYWxsb3dpbmcgdXNlcnMgdG8gdXNlIG1vcmUgbWVhbmluZ2Z1 bCBuYW1lcyBmb3IgZ3JvdXBzIG9mIGxpbmsgcHJvcGVydGllcywgYWxsb3cgdXNlIG9mIG5hbWVz IHRoYXQgYmFiZWxkIGhhcyBhbHJlYWR5IHBvcHVsYXJpemVkIGFtb25nIGl0cyB1c2VycyB3aGls ZSBhbGxvd2luZyBvdGhlciBpbXBsZW1lbnRhdGlvbnMgdG8gdXNlIGRpZmZlcmVudCBuYW1lcyAo bmFtZXMgYXJlbuKAmXQgc3RhbmRhcmRpemVkKSwgYW5kIGlzbuKAmXQgdmVyeSBjb21wbGljYXRl ZC4gSXQgZG9lcyBtYWtlIGl0IGhhcmRlciBpZiB0aGUgdXNlciB3YW50cyB0byBqdXN0IGNoYW5n ZSBvbmUgb2YgdGhlIGxpbmsgcHJvcGVydGllcyBhbmQgbm90IG90aGVycyAodGhleSBtaWdodCBo YXZlIHRvIGNyZWF0ZSBhIG5ldyBpbnN0YW5jZSkuIEJ1dCBpdCBtYWtlcyBpdCBlYXNpZXIgZm9y IHRoZSB1c2VyIHdobyB3YW50cyB0byBjaGFuZ2UgZnJvbSBvbmUgZ3JvdXBpbmcgb2YgcHJvcGVy dGllcyB0byBhbm90aGVyLg0KDQpbbWpdIFllcywgdGhhdCBpcyB3aGF0IHRoZSBpbnRlbnRpb24g b2YgdGhlIGNoYW5nZSB3YXMuIE5vdGUsIEkgZGlkIHdhbnQgaW5zdGFuY2VzIG9mIGJhYmVsLWxp bmstcHJvcGVydGllcyB0byBleGlzdCB1bmRlciB0aGUgYmFzZSAoYmFiZWwtaW5mb3JtdGlvbi1v YmopLiBJbiBiYWJlbC1pbnRlcmZhY2Utb2JqIHdlIG9ubHkgcmVmZXJlbmNlIG9uZSBvZiB0aG9z ZSBpbnN0YW5jZXM6DQoNCm9iamVjdCB7DQogICAgICAgICAg4oCmLg0KICAgICAgICAgIFtiYWJl bC1saW5rLXByb3BlcnRpZXMgICBydyBiYWJlbC1saW5rLXByb3BlcnRpZXM8MC4uKj47XQ0KDQp9 IGJhYmVsLWluZm9ybWF0aW9uLW9iajsNCg0Kb2JqZWN0IHsNCiAgICAgICAgIFtyZWZlcmVuY2Ug ICAgICAgICAgICAgICAgICAgICAgcncgIGJhYmVsLWxpbmstcHJvcGVydGllcztdDQogICAgICAg ICAg4oCmLi4NCn0gYmFiZWwtaW50ZXJmYWNlLW9iajsNCg0KPGJocz4gT0suIEkgd2FzIHRvbyBs YXp5IHRvIHNlYXJjaCBmb3IgdGhlIGV4YWN0IHByb3Bvc2FsLCBzbyBJIHdhcyBqdXN0IGdvaW5n IGJ5IG1lbW9yeS4gQnV0IEkgdGhpbmsgYmFiZWwtbGluay1wcm9wZXJ0aWVzIG5lZWRzIHRvIGJl IDwxLi4qPi4gQmFiZWwgaXMgZGVhZCBpbiB0aGUgd2F0ZXIgaWYgaXQgZG9lc27igJl0IGhhdmUg YXQgbGVhc3Qgb25lIG1lYW5zIG9mIGNhbGN1bGF0aW5nIG1ldHJpY3MuDQpKdWxpdXN6LCBkb2Vz IHRoaXMgbWFrZSBzZW5zZSBhbmQgYXJlIHlvdSBvayB3aXRoIGl0Pw0KDQoNCkJhcmJhcmENCg0K TWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRo YW5hbmRhbmlAZ21haWwuY29tPg0KDQoNCg0K --_000_2D09D61DDFA73D4C884805CC7865E6114E25905BGAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNw YWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWls U3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IEkg aGFkIGluIG1pbmQgZm9yIHRoZSB1cGRhdGVzIHRvIHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBhcmUg c3RlcCA1LiBJZiB0aGUgb3BlcmF0b3IgbmVlZHMgdG8gdXBkYXRlIGxpbmstcXVhbGl0eSwgb3Ig ZmxpcCBvbiBzcGxpdC1ob3Jpem9uLCBvciBzZXQgYSBSVFQgZXN0aW1hdGUgdmFsdWUsIG9yIHNw ZWNpZnkgd2hldGhlciB0aGV5IHdhbnQgdG8gdXNlIHVuaWNhc3QgaW5zdGVhZCBvZiBtdWx0aWNh c3QsDQogb3IgYW55IGNvbWJpbmF0aW9uIHRoZXJlb2YgZm9yIGEgcGFydGljdWxhciBpbnRlcmZh Y2UsIHRoZXkgd291bGQgY3JlYXRlIGEgbmV3IGJhYmVsLWxpbmstcHJvcGVydGllcyBvYmplY3Qg YW5kIGFzc29jaWF0ZSB0aGF0IHdpdGggdGhlIGludGVyZmFjZS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkNh biB3ZSBhZ3JlZSBvbiB0aGUgY2hhbmdlcyB0byB0aGUgaW5mb3JtYXRpb24gbW9kZWwgSSBzdWdn ZXN0ZWQgeWVzdGVyZGF5PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbHQ7YmhzJmd0OyBMZXQgbWUgc2VlIGlmIEkgdW5kZXJzdGFuZC4uLiBE b2VzIGl0IGhhdmUgdG8gYmUgYSDigJxuZXfigJ0gYmFiZWwtbGluay1wcm9wZXJ0aWVzIGluc3Rh bmNlLCBvciBjYW4gaXQgYmUgb25lIHRoYXQgZXhpc3RzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGlzLCBpZiB3ZSBoYWQgYW4gb2Jq ZWN0IGNhbGxlZCBiYWJlbC1saW5rLXByb3BlcnRpZXM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7b2JqZWN0IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0cmluZyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBydyBiYWJlbC1saW5rLXByb3BlcnRpZXMtbmFtZTs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KPHNwYW4gc3R5bGU9ImNvbG9yOiNGRjI2MDAiPls8 L3NwYW4+c3RyaW5nICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBydyBiYWJlbC1pbnRlcmZhY2UtbWV0cmljLWFsZ29yaXRobTs8c3BhbiBzdHlsZT0iY29s b3I6I0ZGMjYwMCI+XTwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KPHNwYW4gc3R5bGU9ImNvbG9yOiNGRjI2MDAiPls8L3NwYW4+Ym9vbGVhbiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBydyBiYWJlbC1pbnRlcmZhY2Utc3BsaXQtaG9yaXpv bjs8c3BhbiBzdHlsZT0iY29sb3I6I0ZGMjYwMCI+XTwvc3Bhbj48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KPHNwYW4gc3R5bGU9ImNvbG9yOiNGRjI2MDAi Pls8L3NwYW4+Ym9vbGVhbiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtydyBiYWJlbC1pbnRl cmZhY2UtcnR0OzxzcGFuIHN0eWxlPSJjb2xvcjojRkYyNjAwIj5dPC9zcGFuPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQo8c3BhbiBzdHlsZT0iY29sb3I6 I0ZGMjYwMCI+Wzwvc3Bhbj5ib29sZWFuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJ3IGJh YmVsLWludGVyZmFjZS11bmljYXN0OzxzcGFuIHN0eWxlPSJjb2xvcjojRkYyNjAwIj5dPC9zcGFu Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfQ0KPHM+PHNwYW4g c3R5bGU9ImNvbG9yOiNGRjI2MDAiPmJhYmVsLWhtYWMta2V5cy1vYmo8L3NwYW4+PC9zPjxzcGFu IHN0eWxlPSJjb2xvcjojRkYyNjAwIj4mbmJzcDtiYWJlbC1saW5rLXByb3BlcnRpZXM8L3NwYW4+ Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bbWpdIHdpdGggdGhlIGNvcnJl Y3Rpb25zIG1hcmtlZCBpbiByZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbHQ7YmhzJmd0OyBJIHRoaW5rIGJhYmVsLWludGVyZmFjZS1tZXRyaWMtYWxnb3JpdGhtIGlz IOKAnG1hbmRhdG9yeSBpbiB0aGUgc2Vuc2UgaXQgbXVzdCBiZSBpbXBsZW1lbnRlZCBhbmQgZXhw cmVzc2VkIHRvIGJlIGNvbXBsaWFudCB3aXRoIHRoZSBpbmZvIG1vZGVs4oCdLiBTbyBJIGRpc2Fn cmVlIHdpdGggdGhlIHNxdWFyZSBicmFja2V0cyBmb3IgdGhhdCBvbmUuIFRoZSBleGlzdGVuY2Ug b2YgdGhlIG1ldHJpYy1hbGdvcml0aG0NCiBpcyByZWFzb25hYmx5IG5vcm1hdGl2ZSBpbiByZmM2 MTI2YmlzLiBUaGUgcG9zc2libGUgZW51bWVyYXRpb25zIGFyZW7igJl0IG5vcm1hdGl2ZSwgYnV0 IHRoYXTigJlzIG5vdCB3aGF0IHRoZSBzcXVhcmUgYnJhY2tldHMgbWVhbi4gQXQgbGVhc3Qgb25l IG1ldHJpYyBjYWxjdWxhdGlvbiBhbGdvcml0aG0gbXVzdCBiZSBpbXBsZW1lbnRlZCBhbmQgaXQg bXVzdCBiZSBnaXZlbiBhIG5hbWUgYW5kIGV4cHJlc3NlZCB0byBiZSBjb21wbGlhbnQgd2l0aCB0 aGUNCiBpbmZvIG1vZGVsLiBJIHNlZSByZmM2MTI2YmlzIGhhcyBzcGxpdCBob3Jpem9uIGFzIOKA nFNIT1VMROKAnSAoQmFiZWwgbm9kZSBTSE9VTEQgdXNlIGFuIG9wdGltaXNhdGlvbiBrbm93biBh cyBzcGxpdCBob3Jpem9uKSwgc28gSSBhZ3JlZSB3aXRoIHNxdWFyZSBicmFja2V0cyBmb3IgdGhh dC4gVGhlIG90aGVyIDIgYXJlbuKAmXQgYWN0dWFsbHkgZ29pbmcgaW4gYXQgdGhpcyB0aW1lLCBz byB0aGVyZeKAmXMgbm8gZGVwZW5kZW5jeSBvbiB0aGVpciBkcmFmdHMuDQogVGhleSBuZWVkIHRv IG1lbnRpb24gd2hhdCBkYXRhIGVsZW1lbnRzIHRoZXkgbmVlZCBpbiB0aG9zZSBkcmFmdHMuIEFu ZCwgeWVhaCwgSeKAmW0gc2xvcHB5IHdpdGggY3V0IGFuZCBwYXN0ZS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1 LjI1cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldoZXJl IHRoZSBpbXBsZW1lbnRhdGlvbiBtYXkgY3JlYXRlIHNvbWUgc2V0IG9mIGluaXRpYWwgZW50cmll cyB0aGF0IGl0cyBkZXZlbG9wZXJzIGhhdmUgZGVjaWRlZCB0byBlLmcuIG5hbWUg4oCcd2lyZWTi gJ0sIOKAnHdpcmVsZXNz4oCdLCDigJx0dW5uZWzigJ0gKGJ1dCBzb21lIG90aGVyIGltcGxlbWVu dGF0aW9uIG1heSBnaXZlDQogYSBkaWZmZXJlbnQgbmFtZSB0byB0aGUgc2FtZSBncm91cCBvZiBw YXJhbWV0ZXIgdmFsdWVzKS4gbGluay1wcm9wZXJ0aWVzLW5hbWUgbXVzdCBiZSB1bmlxdWUgKGFu ZCBub3QgZW1wdHkgb3IgTlVMTCksIGJ1dCBhbHNvIG5vIDIgaW5zdGFuY2VzIGFyZSBhbGxvd2Vk IHRvIGhhdmUgdGhlIHNhbWUgc2V0IG9mIHZhbHVlcyBmb3IgdGhlIGxhdHRlciA0IHBhcmFtZXRl cnMuIE9uY2UgYW4gaW5zdGFuY2UgaXMgY3JlYXRlZCBpdCBjYW5ub3QgYmUgbW9kaWZpZWQuDQog SWYgaXQgaXMgcmVmZXJlbmNlZCBmcm9tIGFuIGludGVyZmFjZSBvciB3YXMgY3JlYXRlZCBieSB0 aGUgaW1wbGVtZW50YXRpb24sIGl0IGNhbm5vdCBiZSBkZWxldGVkLiBUaGlzIG1ha2VzIGluc3Rh bmNlcyBjcmVhdGVkIGJ5IHRoZSBpbXBsZW1lbnRhdGlvbiBpbW11dGFibGUuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PlRoaXMgb2JqZWN0IGNhbiBiZSB3cml0dGVuIChuZXcgaW5zdGFuY2VzIGNyZWF0ZWQgd2l0aCBk aWZmZXJlbnQgY29tYmluYXRpb25zIG9mIHZhbHVlcyBhbmQgYSBkaWZmZXJlbnQgbmFtZSwgbGlr ZSDigJx1bmljYXN0LXdpcmVk4oCdKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QW4gaW50ZXJmYWNlIHdpbGwgaGF2 ZSBhIHJlZmVyZW5jZSB0byBvbmUgb2YgdGhlc2UgaW5zdGFuY2VzLCB0byBpZGVudGlmeSB0aGUg c2V0IG9mIGxpbmstcHJvcGVydGllcyBpdCB1c2VzLiBJdOKAmXMgYWxsb3dlZCB0byBtb2RpZnkg d2hpY2ggc2V0IG9mIGxpbmstcHJvcGVydGllcyBpcyB1c2VkL3JlZmVyZW5jZWQNCiBieSBhbiBp bnRlcmZhY2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JcyB0aGF0IHJpZ2h0PyBBbmQgZGlkIHlvdSBzYXkgeW91IHdhbnRlZCBp dCB1bmRlciBpbnRlcmZhY2Ugb3IgdW5kZXIgdGhlIGJhc2U/IEkgdGhpbmsgaXQgd291bGQgbWFr ZSBzZW5zZSB1bmRlciBiYXNlLiBKdWxpdXN6LCBJIHRoaW5rIHRoaXMgYXBwcm9hY2ggKGlmIGl0 4oCZcyB3aGF0IE1haGVzaCBtZWFudCkgd291bGQgcHJvdmlkZSB0aGUgYmVuZWZpdHMgb2YgYWxs b3dpbmcgdXNlcnMgdG8gdXNlIG1vcmUNCiBtZWFuaW5nZnVsIG5hbWVzIGZvciBncm91cHMgb2Yg bGluayBwcm9wZXJ0aWVzLCBhbGxvdyB1c2Ugb2YgbmFtZXMgdGhhdCBiYWJlbGQgaGFzIGFscmVh ZHkgcG9wdWxhcml6ZWQgYW1vbmcgaXRzIHVzZXJzIHdoaWxlIGFsbG93aW5nIG90aGVyIGltcGxl bWVudGF0aW9ucyB0byB1c2UgZGlmZmVyZW50IG5hbWVzIChuYW1lcyBhcmVu4oCZdCBzdGFuZGFy ZGl6ZWQpLCBhbmQgaXNu4oCZdCB2ZXJ5IGNvbXBsaWNhdGVkLiBJdCBkb2VzIG1ha2UgaXQgaGFy ZGVyDQogaWYgdGhlIHVzZXIgd2FudHMgdG8ganVzdCBjaGFuZ2Ugb25lIG9mIHRoZSBsaW5rIHBy b3BlcnRpZXMgYW5kIG5vdCBvdGhlcnMgKHRoZXkgbWlnaHQgaGF2ZSB0byBjcmVhdGUgYSBuZXcg aW5zdGFuY2UpLiBCdXQgaXQgbWFrZXMgaXQgZWFzaWVyIGZvciB0aGUgdXNlciB3aG8gd2FudHMg dG8gY2hhbmdlIGZyb20gb25lIGdyb3VwaW5nIG9mIHByb3BlcnRpZXMgdG8gYW5vdGhlci48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bbWpdIFllcywgdGhhdCBpcyB3aGF0IHRoZSBpbnRl bnRpb24gb2YgdGhlIGNoYW5nZSB3YXMuIE5vdGUsIEkgZGlkIHdhbnQgaW5zdGFuY2VzIG9mIGJh YmVsLWxpbmstcHJvcGVydGllcyB0byBleGlzdCB1bmRlciB0aGUgYmFzZSAoYmFiZWwtaW5mb3Jt dGlvbi1vYmopLiBJbiBiYWJlbC1pbnRlcmZhY2Utb2JqIHdlIG9ubHkgcmVmZXJlbmNlIG9uZSBv ZiB0aG9zZSBpbnN0YW5jZXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPm9iamVjdCB7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A74oCmLjxicj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1tiYWJlbC1saW5r LXByb3BlcnRpZXMgJm5ic3A7Jm5ic3A7cncgYmFiZWwtbGluay1wcm9wZXJ0aWVzPHNwYW4gc3R5 bGU9ImNvbG9yOiNGRjI2MDAiPiZsdDswLi4qJmd0Ozwvc3Bhbj47XTxicj4NCjxicj4NCn0gYmFi ZWwtaW5mb3JtYXRpb24tb2JqOzxicj4NCjxicj4NCm9iamVjdCB7PGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7WzxzcGFuIHN0eWxlPSJj b2xvcjojRkYyNjAwIj5yZWZlcmVuY2U8L3NwYW4+ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3J3ICZuYnNwO2JhYmVs LWxpbmstcHJvcGVydGllcztdPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A74oCmLi48YnI+DQp9IGJhYmVsLWludGVyZmFjZS1v Ymo7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtiaHMmZ3Q7IE9LLiBJIHdhcyB0b28gbGF6 eSB0byBzZWFyY2ggZm9yIHRoZSBleGFjdCBwcm9wb3NhbCwgc28gSSB3YXMganVzdCBnb2luZyBi eSBtZW1vcnkuIEJ1dCBJIHRoaW5rIGJhYmVsLWxpbmstcHJvcGVydGllcyBuZWVkcyB0byBiZSAm bHQ7MS4uKiZndDsuIEJhYmVsIGlzIGRlYWQgaW4gdGhlIHdhdGVyIGlmIGl0IGRvZXNu4oCZdCBo YXZlIGF0IGxlYXN0IG9uZSBtZWFucyBvZiBjYWxjdWxhdGluZyBtZXRyaWNzLg0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdWxpdXN6LCBkb2VzIHRoaXMgbWFrZSBzZW5z ZSBhbmQgYXJlIHlvdSBvayB3aXRoIGl0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5CYXJiYXJhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1haGVzaCBK ZXRoYW5hbmRhbmk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFu ZGFuaUBnbWFpbC5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_2D09D61DDFA73D4C884805CC7865E6114E25905BGAALPA1MSGUSRBF_-- From nobody Wed Aug 7 14:03:52 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 445041200DF; Wed, 7 Aug 2019 14:03: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 unzOFLN_ualS; Wed, 7 Aug 2019 14:03: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 2B296120059; Wed, 7 Aug 2019 14:03:48 -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 x77L3gqO017260; Wed, 7 Aug 2019 23:03:42 +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 1F3F62B572; Wed, 7 Aug 2019 23:03:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 5s-R_Mcm5G_w; Wed, 7 Aug 2019 23:03:45 +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 3489E2B56B; Wed, 7 Aug 2019 23:03:44 +0200 (CEST) Date: Wed, 07 Aug 2019 23:03:43 +0200 Message-ID: <87lfw4u1qo.wl-jch@irif.fr> From: Juliusz Chroboczek To: Alvaro Retana Cc: babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , The IESG , draft-ietf-babel-rfc6126bis@ietf.org In-Reply-To: References: <156518456148.8400.6644665367614468260.idtracker@ietfa.amsl.com> <875zn9htem.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 [194.254.61.138]); Wed, 07 Aug 2019 23:03:42 +0200 (CEST) X-Miltered: at korolev with ID 5D4B3CAE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4B3CAE.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 : 5D4B3CAE.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] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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: Wed, 07 Aug 2019 21:03:50 -0000 > I hope this makes sense. I'll take my pen and my inkpot, and see what comes out. Thanks for your patience, Alvaro. Your explanations are helpful. -- Juliusz From nobody Wed Aug 7 14:29: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 018E21200DF; Wed, 7 Aug 2019 14:29:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-babel-dtls@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156521337799.8333.13258734665763149206.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2019 14:29:38 -0700 Archived-At: Subject: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT) 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: Wed, 07 Aug 2019 21:29:38 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-babel-dtls-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support Roman's Discuss point (1) (and basically cover the same as his (2) below). Let's have a discussion about (DTLS) identity. Section 2.1 says that we use mutual authentication and that implementations "MUST support authenticating peers against a local store of credentials"; also that "if a node receives a new DTLS connection from a neighbour to whom it already has a connection, the node MUST NOT discard the older connection until it has completed the handshake of the new one and validated the identity of the peer". But how does this authentication occur, and what constitutes the identity of the peer. We will frequently have (D)TLS consumers cite RFC 6125 and say that (e.g.) DNS-ID or SRV-ID must match the name obtained in some fashion. But for Babel, we are authenticating routers -- router identity is usually in the form of just an IP address on a loopback interface! Are we expected to get certificates that certify IP addresses as identity, or use some sort of PSK or password-based TLS authentication? (The last two are not really compatible with the "MUST send a CertificateRequest", BTW.) Raw public keys? I think we can give a more clear picture of how to build a secure system. Relatedly, once DTLS authenticates an identity, what level of authorization checks are performed? Are we still in a single authorization domain, where any router that authenticates as being part of a given domain is implictily authorized to be a babel peer and convey any and all routing information? We should also give some guidance on ciphers and algorithms where we discuss the DTLS details (BCP 195 is probably the safest bet here, even if it's a little in need of an update). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1.2 The protocol described in this document protects Babel packets with DTLS. As such, it inherits the features offered by DTLS, notably authentication, integrity, replay protection, confidentiality and asymmetric keying. It is therefore expected to be applicable in a replay protection is not an inherent feature of DTLS, so I suggest "optional replay protection" to emphasize that an implementation of babel may need to explicitly configure it. There exists another mechanism for securing Babel, namely Babel HMAC authentication [BABEL-HMAC]. HMAC only offers basic features, namely authentication, integrity and replay protection with a small number of symmetric keys. A comparison of Babel security mechanisms and Even the authentication is limited, as it is group authentication, not true per-entity authentication. Section 2.1 information last longer. If a node receives a new DTLS connection from a neighbour to whom it already has a connection, the node MUST NOT discard the older connection until it has completed the handshake of the new one and validated the identity of the peer. (Does the validated identity of the peer have to match the one from the previous handshake?) Section 2.3 I agree with the RtgDir reviewer that unprotected (multicast) Hellos are at risk of tampering by an attacker, who could drop them or modify the seqno/interval, for DoS purposes. I see the text about use of multicast Hellos for discovery and the acknowledgment that an out-of-band neighbor discovery mechanism may be available. Are there any such discovery mechanism under development? Regardless, I think we should consider mandating/suggesting (to some strength; maybe SHOULD is enough) the use of protected unicast Hellos instead of just stating that nodes can either rely on multicast or send protected unicast Hellos. When unicast (protected) Hellos are in use, even tampering with multicast Hellos will not be enough to cause a DoS attack, since a node must be detected as down on both unicast and multicast to be considered gone. (Of course, a sufficiently powerful attacker can still just drop all traffic and cause DoS.) Section 2.4 Note that receiving an unprotected packet can still be used to discover new neighbours, even when all TLVs in that packet are silently ignored. Is this going to cause a lot of spurious DTLS handshake attempts if we ever end up with a babel-dtls implementation adjacent to a classic-babel-only implementation? Is there any rate limiting on that? Section 2.5 Do we want to talk about the potential consequences of an attacker arbitrarily delaying valid content (to justify the need for a timeout)? Section 2.6 A node MAY allow configuration options to allow unprotected Babel on some interfaces but not others; this effectively gives nodes on that interface the same access as authenticated nodes, and SHOULD NOT be done unless that interface has a mechanism to authenticate nodes at a lower layer (e.g., IPsec). I'm unhappy that this SHOULD NOT is not a MUST NOT, but cannot quite justify making it a Discuss-level point. Section 3 IP, UDP and DTLS. Nodes MUST NOT send Babel packets larger than the attached interface's MTU adjusted for known lower-layer headers (at least UDP and IP) or 512 octets, whichever is larger, but not exceeding 2^16 - 1 adjusted for lower-layer headers. Every Babel speaker MUST be able to receive packets that are as large as any Aren't these requirements just duplicating what's in 6126bis? We probably don't need to repeat the normative language, at least, even if there's a desire to repeat the content. Note that distinct DTLS connections can use different ciphers, which can have different amounts of overhead per packet. Therefore, the nit: I think the intention here was "per-packet overhead", though the statement is true as currently written (due to variable length padding for block ciphers). Section 5 The RFC 7525 ref is probably better spelled as BCP 195, and arguably moved earlier in the text (i.e., where I mentioned it previously). A malicious client might attempt to perform a high number of DTLS handshakes with a server. As the clients are not uniquely identified by the protocol and can be obfuscated with IPv6 temporary addresses, a server needs to mitigate the impact of such an attack. Such nit: they're not uniquely identified by the protocol *until the handshake completes* -- our requirement for mutual authentication will cause all valid clients to be identified. However, the DoS risk does not require the client to let the handshake complete, so the core statement here remains valid. It may also be worth mentioning "Slowloris"-style attacks that keep handshake state active for as long as possible to increase resource consumption. Section 6.2 DTLS-CID needs to be normative if it is a MAY-level feature. (See https://www6.ietf.org/iesg/statement/normative-informative.html .) RFC 7525 (i.e., BCP 195) definitely needs to be normative, as a MUST-level requirement! From nobody Wed Aug 7 14:44:53 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 5F3CF12007A; Wed, 7 Aug 2019 14:44:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-babel-hmac@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156521429138.8333.12124544758210076970.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2019 14:44:51 -0700 Archived-At: Subject: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-hmac-08: (with DISCUSS and COMMENT) 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: Wed, 07 Aug 2019 21:44:52 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-babel-hmac-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-hmac/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Are the HMAC keys required to be the hash function's block size or its output size? Section 3.1 says just "the length of each key is exactly the hash size of the associated HMAC algorithm", and "hash size" conventionally refers to the output length. The referenced Section 2 of RFC 2104 concerns itself with the hash's compression function's block size B, which is generally different. Also in Section 3.1, if we are going to claim that a "random string of sufficient length" suffices to initialize a fresh index, we need to provide guidance on what constitutes "sufficient length" to achieve the needed property. Blake2s is a keyed MAC, but is not an HMAC construction. If we are to allow its usage for providing integrity protection of babel packets directly, we therefore cannot refer to the preotection scheme as "HMAC" generically. Fixing this will, unfortunately, be somewhat invasive to the document, since we mention HMAC all over the place. I believe that "Keyed Message Authentication Code (Keyed MAC)" is an appropriate replacement description. The suggestion that the large challenge nonce size admits storage of state in a secure "cookie" in the nonce is true, however, implementing this properly presents some subtleties, and it seems like something of an attractive nuisance to suggest that it is possible without giving adequate guidance at how to do it safely. Unfortunately, the best reference I can think of, offhand, is the obsoleted RFC 5077. Let's also have a discussion about whether 64 bits of randomness is always sufficient; I left a longer note down in the Comment since I don't expect this to end up being a blocking point. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the clear introduction and applicability statement; they really help to lay out a clear picture of the scenarios in which we operate! This is a symmetric-keyed scenario, so most attacks that involve a compromised node will be "uninteresting", in that once the key is exposed all guarantees are lost. However, it may still be worth noting that a compromised node can cause disruption on multi-access links without detection since there is no "end of generation" signal when a node changes its index. That is, if node B reboots or otherwise resets its index/pc, then compromised node C can spoof packets from B with the previous index and honest node A will accept them, and B will be unable to detect that it has been spoofed. On the flip side, we may want to discuss that B can watch for messages that spoof its source address to detect compromised nodes. Is there any need for initial PC value randomization? Do we want to recommend starting at 0 or 1 (or prohibit recipients from assuming that the initial value for an index will be that)? Section 1 "This document obsoletes RFC 7298" should be in the Introduction as well as the abstract. Is the capability for an attacker to modify/spoof Babel packets in order to cause data to get dropped or cause a routing loop worth mentioning here? Section 1.2 o that the Hashed Message Authentication Code (HMAC) being used is invulnerable to pre-image attacks, i.e., that an attacker is unable to generate a packet with a correct HMAC; I think it's more conventional to include the caveat "without [access to/knowledge of] the secret key" for this sort of statement about HMAC. The first assumption is a property of the HMAC being used. The second assumption can be met either by using a robust random number generator [RFC4086] and sufficiently large indices and nonces, by using a reliable hardware clock, or by rekeying whenever a collision becomes likely. Does this rekeying option require an external operation/management actor to trigger it? It might be worth mentioning with some operational considerations. o among different nodes, it is only vulnerable to immediate replay: if a node A has accepted a packet from C as valid, then a node B will only accept a copy of that packet as authentic if B has accepted an older packet from C and B has received no later packet from C. nit: I don't think "A has accepted a packet from C" is quite the right precondition; it seems to be more like "A has received a valid packet from C", since whether or not A (as an attacker) considers it valid is irrelevant to whether (honest) B will. Section 4.1 If we had identifiers for symmetric keys or HMAC algorithms, we could include those identifiers in the pseudo-header and thereby gain some protection from downgrade/HMAC-stripping attacks in the presence of a weak keyed MAC algorithm. (I think we have to include both what we are sending and what we think the peer can do in order to get substantial protection, though, which diminishes the appeal for multicast scenarios.) nit: I don't think the past tense is correct for "packet was carried over IPvN", since we're talking about a pseudo-header used in computations before the packet is sent. Section 4.2 It might be worth reiterating that every time a packet goes on the wire, it gets a fresh PC, regardless of whether it's a "retransmit" after a timeout or a new message. interface MTU (Section 4 of [RFC6126bis]). For an interface on which HMAC protection is configured, the TLV aggregation logic MUST take into account the overhead due to PC TLVs (one in each packet) and HMAC TLVs (one per configured key). (per configured key, and also per packet, right?) Does it matter whether the sender increments the PC before or after inserting it in the PC TLV? (I think the only potential impact would be as it relates to the value sent in response to a challenge nonce, but the "increment by a positive not-necessarily-one amount" property may provide all the flexibility we need.) Section 4.3 Validating the HMACs is the sort of operation that we tend to recommend be done in constnt-time to avoid side channel attacks. I don't have a concrete attack handy here at the moment, though. When a PC TLV is encountered, the enclosed PC and Index are saved for later processing; if multiple PCs are found (which should not happen, see Section 4.2 above), only the first one is processed, the remaining ones MUST be silently ignored. If a Challenge Any reason to not just drop the whole packet if there are multiple PCs present? I see this is not rfc7298bis but don't know what level of breaking change is reasonable. o The preparse phase above has yielded two pieces of data: the PC and Index from the first PC TLV, and a bit indicating whether the packet contains a successful Challenge Reply. If the packet does not contain a PC TLV, the packet MUST be dropped and processing stops at this point. If the packet contains a successful Challenge Reply, then the PC and Index contained in the PC TLV MUST be stored in the Neighbour Table entry corresponding to the sender (which already exists in this case), and the packet is accepted. I'd suggest explicitly stating that if there is a challenge reply that doesn't validate, the packet should be discarded. Or are there multicast scenarios where that is not the case? The key point being to emphasize that just the presence of a challenge reply doesn't mean anything, it has to be valid in order to have significance. o At this stage, the packet contains no successful challenge reply and the Index contained in the PC TLV is equal to the Index in the Neighbour Table entry corresponding to the sender. The receiver compares the received PC with the PC contained in the Neighbour Table; if the received PC is smaller or equal than the PC contained in the Neighbour Table, the packet MUST be dropped and processing stops (no challenge is sent in this case, since the mismatch might be caused by harmless packet reordering on the link). Otherwise, the PC contained in the Neighbour Table entry is set to the received PC, and the packet is accepted. Does this mean that if packet reordering is encountered, we will just not process packets that get reordered later? (AFAIK babel will still work fine in such conditions, so I'm just checking my understanding.) it MAY ignore a challenge request in the case where it it contained nit: s/it it/it is/ The same is true of challenge replies. However, since validating a challenge reply is extremely cheap (it's just a bitwise comparison of two strings of octets), a similar optimisation for challenge replies is not worthwile. Er, challenge reply validation still requires the HMAC validation step, right? Section 4.3.1.1 When it encounters a mismatched Index during the preparse phase, a node picks a nonce that it has never used with any of the keys currently configured on the relevant interface, for example by drawing a sufficiently large random string of bytes or by consulting (same comment as above about "sufficiently large") Section 4.3.1.2 buffered TLVs in the same packet as the Challenge Reply. However, it MUST arrange for the Challenge Reply to be sent in a timely manner (within a few seconds), and SHOULD NOT send any other packets over the same interface before sending the Challenge Reply, as those would be dropped by the challenger. I think this "SHOULD NOT" (or rather, "would be dropped by the challenger") is predicated on the challenge request having not been a replay, but I do not see anything requiring the recipient to do nonce uniqueness validation. Section 4.3.1.3 neighbour that sent the Challenge Reply. If no challenge is in progress, i.e., if there is no Nonce stored in the Neighbour Table entry or the Challenge timer has expired, the Challenge Reply MUST be silently ignored and the challenge has failed. I think "the challenge has failed" is predicated on the challenge reply being in response to a challenge sent by this node. The previous section's "send the Challenge Reply to the unicast address" seems to imply that there are no multicast scenarios which would make that not the case, but I just wanted to check my understanding. Section 5 Do we need to say whether sub-TLVs are allowed in any of these TLVs? (Presumably they are not, since the length is needed in order to identify the length of the variable-length fields, but being explicit can be useful.) Section 5.1 This [HMAC] TLV is allowed in the packet trailer (see Section 4.2 of [RFC6126bis]), and MUST be ignored if it is found in the packet body. side note: Using "MUST ignore" vs. "discard the packet" has some protocol evolution consequences -- it in practice then becomes an alternative padding technique for use in packet bodies, and if ever used as such then could lead to a way to fingerprint an implementation or be used as a hidden channel for sending other data. But, I see that ignoring at the TLV level is something of a core babel design choice, and I don't see any serious consequences that would merit revisiting that decision. Section 6 This mechanism relies on two assumptions, as described in Section 1.2. First, it assumes that the hash being used is s/hash/MAC/ enough entropy (64-bit values are believed to be large enough for all practical applications), or by using a reliably monotonic hardware It would require a bit more thought to convince me that 64-bit indices are sufficient for *all* cases. Specifically, if we want full 64-bit strength, then the 64-bit space cannot be controlled or affected by the attacker to cause collisions. But I think there will be a reasonable risk that an attacker can cause a given node to need to regenerate its index on demand (e.g,. but triggering a bug that crashes it, or power cycling it), at which point the random selection falls back to the 32-bit birthday bound on uniqueness over time. Granted, the consequences of that particular attack would be limited, as the attacker could only replay the limited number of packets sent using the colliding index the first time it was used, but this is only intended as an example of ways in which 64-bit random values can be degraded to 32 bits of security. present at the receiver. If the attacker is able to cause the (Index, PC) pair to persist for arbitrary amounts of time (e.g., by repeatedly causing failed challenges), then it is able to delay the packet by arbitrary amounts of time, even after the sender has left the network. I'd suggest adding another sentence describing the potential consequences of selectively delayed input (i.e., messing up the routing). protocol (the data structures described in Section 3.2 of [RFC6126bis] are conceptual, any data structure that yields the same result may be used). Implementers might also consider using the fact nit: that's a comma splice in the parenthetical; a semicolon would be better. From nobody Wed Aug 7 14:47: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 0822112007A; Wed, 7 Aug 2019 14:47:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-babel-applicability@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156521443702.8388.9968706791861758093.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2019 14:47:17 -0700 Archived-At: Subject: [babel] Benjamin Kaduk's No Objection on draft-ietf-babel-applicability-09: (with COMMENT) 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: Wed, 07 Aug 2019 21:47:17 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-babel-applicability-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-applicability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- When a use case calls for all nodes to participate in the IGP (as opposed to just connecting to a local point of access and letting that router run the IGP, there may be privacy considerations regarding the mobility/connectivity of individual nodes in the information conveyed over the routing protocol. It would be good to acknowledge that such use cases may exist (or disclaim applicability to them) in this document. Section 1.1 It's probably worth expanding DSDV on first use. Section 2.2 (side note: this is probably just me coming from an abstract math/topology background and not a routing background, but the term "non-transitive link" puzzles me a little bit. My understanding of the non-transitivity property is that if A has a link to B, and B has a link to C, then it's not necessarily the case that A can get traffic to/from C via B. But that seems like more of a property of the node policy or other constraints on B than of any particular link. I can live with being puzzled, here, but if there's a quick explanation, I'd be interested in hearing it.) Section 2.3 All of the extensions designed to date interoperate with the base protocol and with each other. This, again, is a consequence of the protocol design: in order to check that two extensions to the Babel protocol are interoperable, it is enough to verify that the interaction of the two does not violate the base protocol's assumptions. As another reviewer noted, "interoperable" doesn't seem like quite the right word; "compatible" seems potentially more appropriate, or perhaps "usable with each other". Section 2.4.3 Babel's loop-avoidance mechanism relies on making a route unreachable after a retraction until all neighbours have been guaranteed to have acted upon the retraction, even in the presence of packet loss. Unless the optional algorithm described in Section 3.5.5 of [RFC6126bis] is implemented, this entails that a node is unreachable for a few minutes after the most specific route to it has been retracted. [...] Section 3.5.5 of draft-ietf-babel-rfc6126bis-07 seems to discuss two different mechanismis to guarantee that no neighbor is using the current node as next-hop for prefix P. (1) is that the operation being referred to here, and (2) if so, should this be "one of the mechanisms"? Basically, I'm not sure I'm chasing the reference in the way intended. Section 5 I think we need to couch the "most deployments" language with something like "at the time of this writing" -- there's no guarantee that it will remain true in perpetuity. Given, e.g., https://www.krackattacks.com/, it's unclear to me that it's reasonable to continue to claim that WPA2 provides a way to secure a link layer. (WPA3 is not shaping up to do much better, given https://www.schneier.com/blog/archives/2019/04/vulnerabilities_7.html .) From nobody Wed Aug 7 15:13: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 E84DC1200DF; Wed, 7 Aug 2019 15:13:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156521599894.8313.13827924927219698158.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2019 15:13:18 -0700 Archived-At: Subject: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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: Wed, 07 Aug 2019 22:13:19 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-babel-rfc6126bis-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I don't think that all of the arithmetic specified in Section 3.2.1 is well defined. Specifcally, the formulations involving bitwise AND assume that the input to the bitwise AND is nonnegative, which does not seem to be implied by the other stated constraints. (For example, an "integer n" may well be negative.) Some discussion of the representation of negative integers would then be needed, and then whether the mathematical operation is performed in an abstract infinite-precision machine or in a realizable approximation, etc.. It might be simpler to just use the modular arithmetic flavor and avoid any of the issues that can arise when providing two alternative definitions that are intended to be equivalent (since there is always a risk of edge cases). Section 3.5.2 needs to explicitly say that the c and m arguments to M() are the local link cost and the advertised metric, e.g., "the function M(c, m) used for computing a metric from a locally computed link cost c and the metric m advertised by a neighbor". Section 3.8.2.1 notes that "[d]ue to duplicate suppression, only a small number of such requests will actually reach the source." (for seqno requests intending to avoid starvation). But Section 3.8.1.2 only has a SHOULD-level requirement to suppress duplicate seqno requests, so I think there is an internal inconsistency. I think we may need to have a discussion about the feasibility of multicast acknowledgment requests with only a 16-bit nonce. With random assignment of nonces the risk of birthday collisions becomes uncomfortably large, and non-random assignments are likely to have worse pathologies. (A pointer to a previous discussion of this topic would, of course, short-circuit a lot of it if not all of it.) Are we willing to make hard assumptions about the maximum size of a multicast domain and the risk of collision we are willing to accept? The discussion in Section 4.6.9 of computing the prefix from an Update message (and parser state) seems a little underspecified when the prefix length is not a multiple of 8 bits. (Additionally, "Plen" is not described as measuring bits, explicitly, for any of the PDU descriptions that I remember.) Specifically, the "Prefix" description does not mention that any trailing bits must be set to zero, but the subsequent discussion about the prefix is "computed as follows" refers to assembling the prefix as a collection of octets, including trailing zero octets, implying that the computed prefix is the full length of the address type. I appreciate that we have some discussion in Section 4.5 about the need for a stateful parser for the babel packet body; this seems like one of the riskiest areas of the protocol from the implementation perspective. However, I think it would be even more helpful to explicitly call out what pieces of state are needed, what protocol elements affect the state, and what ordering requirements (or non-requirements) there are for the interactions between the different protocol elements that affect parser state. Can we have a discussion about whether it's appropriate to add some text along these lines? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Should there be a "changes since RFC 6126" section that is retained in the published RFC? (I assume that Appendix F is going to be dropped.) The secdir review has some good thoughts (e.g., tracking "link-local" IPv4 addresses, discussion of non-protection from hostile insiders), but I don't see a response to it. We use the phrase "a small multiple of" a few times, but I don't remember seeing any concrete guidance for what factor to use. Is it intended to be closer to 1.1 or to 4? In a related vein, there are many places in the document where the precise details of processing are left intentionally underspecified (e.g., computing a link's cost). I understand that due to the protocol guarantees the needed routing will still be achieved even if nodes use different parameters and algorithms in these cases, but do we expect the details to be chosen on a per-implementation basis, or in profile documents, or even left up to operator configuration on a per-node basis? Section 1 The introduction should mention obsoleting 6126 and 7557, in addition to doing so in the abstract. Section 1.1 Finally, Babel is a hybrid routing protocol, in the sense that it can carry routes for multiple network-layer protocols (IPv4 and IPv6), whichever protocol the Babel packets are themselves being carried over. nit: I think "regardless of which" is better than "whichever", since the latter might erroneously imply that there is a consistency requirement of the carried routes and the carrying protocol. Section 1.2 Second, unless the optional algorithm described in Section 3.5.5 is implemented, Babel does impose a hold time when a prefix is Similarly to my comment on the applicability doc, I'm not sure if there's one or two things in Section 3.5.5 that would match this description. Section 2 Conceptually, Bellman-Ford is executed in parallel for every source of routing information (destination of data traffic). In the following discussion, we fix a source S; the reader will recall that the same algorithm is executed for all sources. Just to check my understanding: this "source S" is a source of routing information, not a source of data-plane traffic being routed? Section 2.4 Is there a reference for AODV? To show that this feasibility condition still guarantees loop- freedom, recall that at the time when A accepts an update from B, the metric D(B) announced by B is no smaller than FD(B); since it is smaller than FD(A), at that point in time FD(B) < FD(A). Since this property is preserved when A sends updates, it remains true at all times, which ensures that the forwarding graph has no loops. I'm trying to walk through this and missing a step or two. "the metric D(B) announced by B is no smaller than FD(B)" is pretty clear, since FD(B) is just the minimum value of D(B) over time thus far. But I'm not sure I follow how A can preserve the property FD(B) < FD(A) when A sends updates. Clearly FD(B(T')) <= FD(B(T0)) for any time T' after T0, but suppose FD(B) remains constant but A is off interacting with some other node C and finds a great path via C, which correspondingly causes D(A) to reduce. Can I get into a situation where D(A) < FD(B) <= D(A) + C(A,B) (and thus, the subsequent FD(A) < FD(B) <= FD(A) + C(A,B)) if A does not interact with B during that time? Section 2.5 Using the minusculeu and majuscule forms of the same letter to mean different things (e.g., source S and sequence number s) is something of a readability anti-pattern. Section 3.2.6 It would probably be helpful to readers to note that "neighbor that advertised" and "next-hop" can be different due to being different address families. (For the same address family, they are generally going to be the same, modulo weird network-layer technologies, right?) Section 3.5.1 (side note: I got a bit confused reading this section and had to go double-check several definitions, due to the qualitative difference between the "metric" and "metric'" under comparison. Namely, the "metric" is for the path from neighbor to S, but the "metric'" is for the path from the current node to S, and so in some sense they are "measuring different things". Perhaps using "FD" instead of "metric'" would help disambiguate. I understand that this a fairly common pattern for routing protocols, though, so don't necessarily expect any change to the text.) router-id. Feasibility distances are maintained in the source table, the exact procedure is given in Section 3.7.3. nit: this is a comma splice. Section 3.5.2 Note that while strict monotonicity is essential to the integrity of the network (persistent routing loops may arise if it is not satisfied), left distributivity is not: if it is not satisfied, Babel will still converge to a loop-free configuration, but might not reach a global optimum (in fact, a global optimum may not even exist). I might even go so far as to say that a global optimum "will likely not exist", though this is fairly qualitative/intuitive since we don't define a configuration space or metric over it in which to evaluate the probability. Section 3.5.4 We don't seem to use the "link cost value equal to cost" anywhere in this section, so maybe it is superfluous. If such an entry exists: o if the entry is currently selected, the update is unfeasible, and the router-id of the update is equal to the router-id of the entry, then the update MAY be ignored; I guess the idea is that we can keep the old one around until it would time out, since the initial timeout value for it means it should still be workable until our timer expires, but it's only a MAY in case we want to be more proactive about noticing that the advertised metric is now unfeasible? It might be worth saying a bit about when we might/might not want to heed the MAY. Section 3.5.5 o sending a retraction with an acknowledgment request (Section 3.3) to every reachable neighbour that has not explicitly retracted prefix P and waiting for all acknowledgments. nit(?): I'd suggest a comma before "and waiting for all acknowledgments", since that's the final gating factor to achieve the goal. The former option is simpler and ensures that at that point, any routes for prefix P pointing at the current node have expired. However, since the expiry time can be as high as a few minutes, doing that prevents automatic aggregation by creating spurious black-holes for aggregated routes. The latter option is RECOMMENDED as it dramatically reduces the time for which a prefix is unreachable in the presence of aggregated routes. nit: I don't think this "prevents automatic aggregation" at a technical level, but rather that it "makes automatic aggregation rather unusable in practice" since if automatic aggregation is used, any route retraction will result in a spurious blackhole for the (minutes) expiry time, which is unacceptable for most environments. Section 3.7 Additionally, in order to ensure that any black-holes are reliably cleared in a timely manner, a Babel node sends retractions (updates with an infinite metric) for any recently retracted prefixes. Is the sending of retractions the one described by the SHOULDs in 3.7.2? If so, I'm not sure that "a Babel node sends retractions for any recently retracted prefixes" is quite accurate (since SHOULD is not a mandatory requirement); "can send" or "will generally send" might be better. Section 3.7.1 Every Babel speaker periodically advertises all of its selected routes on all of its interfaces, including any recently retracted routes. Since Babel doesn't suffer from routing loops (there is no "counting to infinity") and relies heavily on triggered updates (Section 3.7.2), this full dump only needs to happen infrequently. Part of the need for the full dump stems from the potential for unreliable links, right? Do we want to mention that relationship here, (and that if there are particularly unreliable links the frequency may need to be more often)? Section 3.8.1.2 We haven't introduced "hop count" yet and just mention it in passing here as "[if the] hop count is 2 or more". Intuitively, it seems like the routr should send an update if the router-ids match and the requested seqno is equal to the route entry's seqno, but I don't see this case covered in the current text. o otherwise, if the node has one or more (not necessarily feasible) routes to the requested prefix with a next hop that is not the nit: I think the parenthetical can just be "not feasible", as any feasible routes in question would have matched the previous bullet point. neighbours. However, if a seqno request is resent by its originator, the subsequent copies MAY be forwarded to a different neighbour than the initial one. Is MAY the appropriate level of strength? Trying the same neighbor would be effective if the original was unsuccessful due to packet loss, but is it possible for a routing pathology to occur that directs the request in the "wrong direction" with respect to a link or node failure? Section 3.8.2.4 Is it worth giving some informal guidance about not sending multicast wildcard requests if a node observes others doing the same around the same time (or similar) to avoid the "serious congestion" issues? Section 4.2 A Babel packet consists of a 4-octet header, followed by a sequence of TLVs (the packet body), optionally followed by a second sequence of TLVs (the packet trailer). Without mention of the 'body length' field here, a reader might be confused at what distinguishes the body TLVs from the trailer TLVs. The packet body and trailer are both sequences of TLVs. The packet Ibody is the normal place to store TLVs; the packet trailer only contains specialised TLVs that do not need to be protected by cryptographic security mechanisms. I think we need a more explicit statement that the body structure is subject to change when security mechanisms are in use, to allow for potential confidentiality-protecting cryptographic mechanisms. Section 4.3 Length is still in octets, right? Section 4.4 Every TLV carries an explicit length in its header; however, most TLVs are self-terminating, in the sense that it is possible to determine the length of the body without reference to the explicit Length field. If a TLV has a self-terminating format, then it MAY allow a sequence of sub-TLVs to follow the body. This seems like a statement of fact, for which a lowercase "may" is perfectly adequate. Sub-TLVs have the same structure as TLVs. With the exception of PAD1, all TLVs have the following structure: I was going to complain that it's somewhat unfortunate to use the same name for a thing that's a TLV and a thing that's a sub-TLV, even if they have identical encodings. But then I noticed that in this (sub-TLV) section we spell it "PAD1" and in the previous (TLV) section we spell it "Pad1", which are different. On the gripping hand, Sections 4.6.1 and 4.7.1 both spell it "Pad1", which are the same. So a little bit of effort rationalizing things would go a long way. The most-significant bit of the sub-TLV, called the mandatory bit, Just to be clear: this is the MSB of the 'type' octet? Also, for similar features in other protocols I've suggested the clarifying language of "comprehension-mandatory" which seems to more accurately reflect the corresponding behavior. Section 4.5 Since the parser state is separate from the bulk of Babel's state, and since for correct parsing it must be identical across implementations, it is updated before checking for mandatory TLVs: nit: "mandatory sub-TLVs" (right?) Section 4.6.2 MBZ Set to 0 on transmission. Is it legal for a receiver to check and abort if any bits are nonzero? Section 4.6.3 Sixteen bits of nonce does not provide much unguessability (I note that LISP's rfc6830bis is recommending that their 24-bit nonce echo functionality not be relied on for return-routability checks over the public Internet). However, since these acknowledgment exchanges are only between direct neighbors, it seems that they are only needed for correlating responses to requests and not for unguessability. (In this case it seems a sequence number would work just as well as a random number, and we might want to discourage random assignment in the text to avoid the risk of birthday collisions.) On the other hand, multicast acknowledgment requests could be problematic (and especially so when sequential nonces are used), and if they are intended to be allowed then we may need to consider using a larger and random nonce. Section 4.6.6 I'm getting some sever cognitive dissonance between the "Rxcost" field and the "carrying a link's transmission cost" statement. Also, in Rxcost The rxcost according to the sending node of the interface whose address is specified in the Address field. The value FFFF hexadecimal (infinity) indicates that this interface is unreachable. if I insert commas to get "The rxcost, according to the sending node [of the TLV], of the interface whose address is specified in the Address field", does that preserve the intended meaning? nit/aside: It also feels like there's a bit of a mismatch here, in that the "rxcost of the interface" probably means the local interface (from the perspective of the sender), but that interface is being identified by the *remote* address (again, from the perspective of the sender of the TLV). So maybe "whose remote address" could resolve the mismatch I'm perceiving? (Or maybe I'm completely misunderstanding, of course.) Interval An upper bound, expressed in centiseconds, on the time after which the sending node will send a new IHU; this MUST NOT be 0. [...] To check my understanding: are the IHUs conceptually a reply to Hellos, such that if the Hellos stopped arriving then the peer would stop sending IHUs in response? I understand that their intervals are set completely independently, so there is not a direct causal relationship, but I'm trying to check whether the quoted sentence is a strict commitment by the sender of the IHU or could be rescinded due to external events. Section 4.6.9 If the Metric field is finite, the router-id of the originating node for this announcement is taken from the prefix advertised by this Update if the Router-Id flag is set, computed as described above. Otherwise, it is taken either from the preceding Router-Id packet, or the preceding Update packet with the Router-Id flag set, whichever comes last, even if that TLV is otherwise ignored due to an unknown mandatory sub-TLV. Both cases of "packet" here should be "TLV", right? Otherwise we have to scope what set of previous packets are applicable to this route (since we get a lot of packets, for a lot of different routes). Section 5 "Specification Required" also requires Expert Review. What guidance can we provide to the experts for making registration decisions? Section 6 It's a little disappointing that we provide four different PDUs for padding but then have no discussion of privacy considerations related to (potentially encrypted) packet length, and when (else) one might want to pad, and what padding policy might look like. I understand that padding policy remains something of an open research question, but even acknowledging that can still be useful. Is an attacker's capability limited to misdirecting traffic? Can it cause traffic to be blackholed or cause routing loops by falsifying protocol data either modified in transit or originating false data? What are the effects of an attacker completely or selectively dropping protocol data? In essence, please flesh out "completely insecure" with a bit more detail. The information that a Babel node announces to the whole routing domain is often sufficient to determine a mobile node's physical location with reasonable precision. The privacy issues that this causes can be mitigated somewhat by using randomly chosen router-ids and randomly chosen IP addresses, and changing them periodically. "periodically" may not be the best advice; coupling such changes to mobility events is likely to be more effective at preserving privacy. (QUIC has discussed related topics quite extensively, though there's enough traffic in the archives that I can neither point you at a specific thread or recommend searching for it.) Section 8.2 I think at least BABEL-HMAC needs to be normative, since it is RECOMMENDED. Section A.1 If we're talking about "appending bits" to the history fields, maybe describing them as fixed-length queues or something makes more sense than vectors. If the field is maintained in a 16-bit integer, what is done for the previously erased bits when we "undo history"? Whenever either Hello timer associated to a neighbour expires, the local node adds a 0 bit to this neighbour's Hello history, and We keep two hello histories; we should clarify that the one in question is the one corresponding to the timer that expired. Section A.2.2 I don't understand the origin of the '256' in the MIN(1, 256/txcost) formula (described as a probability estimate). I think a lot more work is needed to convince me that the two given formulae for "cost" are equivalent (especially given that 'rxcost' only appears once in the entire section, in the second formula). Section A.3.2 Is k "allowed to" (I know this section is just informative) vary on non-external data, such as the route or link in question? Appendix C I could see this content in the main body of the document. From nobody Wed Aug 7 20:36:57 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 8D645120091; Wed, 7 Aug 2019 20:36:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-babel-applicability@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <156523541556.8428.14664793919655430943.idtracker@ietfa.amsl.com> Date: Wed, 07 Aug 2019 20:36:55 -0700 Archived-At: Subject: [babel] Barry Leiba's No Objection on draft-ietf-babel-applicability-09: (with COMMENT) 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, 08 Aug 2019 03:36:56 -0000 Barry Leiba has entered the following ballot position for draft-ietf-babel-applicability-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-applicability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with several other ADs that the document tries too hard to be a marketing brochure. I do not find that sufficiently objectionable to interfere, but it would be nice to tone it down a bit. From nobody Thu Aug 8 03:25: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 55129120122; Thu, 8 Aug 2019 03:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Pmd7ql7YOpf; Thu, 8 Aug 2019 03:25:35 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 9B1B012011B; Thu, 8 Aug 2019 03:25:35 -0700 (PDT) Received: from 200116b82cfdec0099e7fb8bcda09050.dip.versatel-1u1.de ([2001:16b8:2cfd:ec00:99e7:fb8b:cda0:9050]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hvfbx-00073f-B8; Thu, 08 Aug 2019 12:25:33 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Thu, 8 Aug 2019 12:25:32 +0200 Cc: The IESG , draft-ietf-babel-dtls@ietf.org, Donald Eastlake , babel-chairs , Babel at IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <156518163926.8337.14198016212015161206.idtracker@ietfa.amsl.com> To: David Schinazi X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1565259935;4c0ec1a3; X-HE-SMSGID: 1hvfbx-00073f-B8 Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-dtls-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Thu, 08 Aug 2019 10:25:39 -0000 Hi David, Please see below. > On 7. Aug 2019, at 20:09, David Schinazi = wrote: >=20 > Hello Mirja, and thank you for your review. >=20 > (1) Discuss - port number >=20 > Using an ephemeral port that is discovered at runtime would add a = failure mode > to the protocol and make it less robust. Implementors in the working = group > felt strongly that a separate port is simpler, safer and more = reliable. Can you please explain why that would make it less robust? I would = actually think that is would make it more robust. In any case you need = to somehow discovery the neighbour. Usually the babel HELLO would be = used for that. When you add an new TLV to that HELLO that indicates a = port that should be used for DTLS, this also gives you and additional = indication that the peer sending the hello actually supports DTLS which = I believe would make it more robust. Further with respect to security and topics probably recently discussed, = not having a default port would make it harder for an attacker to flood = a route with DTLS handshakes on that port. I think that=E2=80=99s an = additional benefit that should be seriously considered. Was this specific proposal discussed in the working group? >=20 > (2) Comment on IPv4/IPv6 >=20 > Thanks for catching this! We've allowed IPv4 in this commit: > = https://github.com/jech/babel-drafts/commit/335e3edf06ac58853e33475e32f2d4= 52022e04e0 > It'll be included in the next revision of the draft. Thanks! Mirja >=20 > Thanks, > David >=20 >=20 > On Wed, Aug 7, 2019 at 5:40 AM Mirja K=C3=BChlewind via Datatracker = wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-babel-dtls-07: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Unfortunately I need to discuss the port request again. >=20 > First of all I would like to comment on the shepherd write-up which = says: > "The document requires only the allocation of a port number for Babel > over DTLS. Having such a second port for the secured version of a > protocol is a fairly common practice. This is shown in the IANA > Considerations section." > This is not correct. Having a second port for the secured version of a = protocol > WAS common practice. However RFC6335 say now "The use of separate > service name or port number assignments for secure and insecure > variants of the same service is to be avoided in order to = discourage > the deployment of insecure services." >=20 > Anyway, in this case I understand that a different port is desired = because > unencrypted HELLO messages are still received over the default babel = port. > However, it is not clear to me why a fixed/default port is needed. The > neighbour needs to be discovered in some why, no matter what, before a = DTLS > connection can be established and this discovery procedure could = indicate a > dynamic port number that the peer is listening on for babel over DTLS. = E.g. the > multicast HELLO could have a new TLV with this port information. = Please clarify > why this option is not suitable! Thanks! >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > This specification seems to only support babel over DTLS for IPv6. = This should > be stated clearly in the introduction. >=20 >=20 From nobody Thu Aug 8 04:17: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 8C7B9120178; Thu, 8 Aug 2019 04:17:14 -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 1sHRFXIoh2sO; Thu, 8 Aug 2019 04:17: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 25C8A120177; Thu, 8 Aug 2019 04:17: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 x78BH6iS003695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Aug 2019 13:17:06 +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 x78BH7Ph015743; Thu, 8 Aug 2019 13:17: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 BB72B2E251; Thu, 8 Aug 2019 13:17:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id XAIX47vkyPVo; Thu, 8 Aug 2019 13:17: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 C66242E24F; Thu, 8 Aug 2019 13:17:08 +0200 (CEST) Date: Thu, 08 Aug 2019 13:17:08 +0200 Message-ID: <87a7cjq53f.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mirja Kuehlewind Cc: David Schinazi , The IESG , draft-ietf-babel-dtls@ietf.org, Donald Eastlake , babel-chairs , Babel at IETF In-Reply-To: References: <156518163926.8337.14198016212015161206.idtracker@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]); Thu, 08 Aug 2019 13:17:06 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 08 Aug 2019 13:17:07 +0200 (CEST) X-Miltered: at korolev with ID 5D4C04B2.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D4C04B3.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4C04B2.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D4C04B3.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 : 5D4C04B2.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D4C04B3.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] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-babel-dtls-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Thu, 08 Aug 2019 11:17:15 -0000 >> Using an ephemeral port that is discovered at runtime would add a failure mode >> to the protocol and make it less robust. > Can you please explain why that would make it less robust? I would > actually think that is would make it more robust. In any case you need > to somehow discovery the neighbour. Usually the babel HELLO would be > used for that. When you add an new TLV to that HELLO that indicates > a port that should be used for DTLS, this also gives you and additional > indication that the peer sending the hello actually supports DTLS which > I believe would make it more robust. That's an intruiguing idea. > Further with respect to security and topics probably recently discussed, not having a default port would make it harder for an attacker to flood a route with DTLS handshakes on that port. Could you please explain what happens if an attacker sends out 65535 spoofed multicast Hellos indicating 65535 distinct ports? -- Juliusz From nobody Thu Aug 8 04:45:10 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 7310712006F; Thu, 8 Aug 2019 04:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGfDteDz17dC; Thu, 8 Aug 2019 04:45:02 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 691541200D6; Thu, 8 Aug 2019 04:45:02 -0700 (PDT) Received: from 200116b82cfdec0099e7fb8bcda09050.dip.versatel-1u1.de ([2001:16b8:2cfd:ec00:99e7:fb8b:cda0:9050]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hvgqp-000206-2u; Thu, 08 Aug 2019 13:44:59 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <87a7cjq53f.wl-jch@irif.fr> Date: Thu, 8 Aug 2019 13:44:58 +0200 Cc: babel-chairs , Babel at IETF , Donald Eastlake , The IESG , David Schinazi , draft-ietf-babel-dtls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <110AD4FB-186C-4C87-8BAF-7D8F4A04BC6F@kuehlewind.net> References: <156518163926.8337.14198016212015161206.idtracker@ietfa.amsl.com> <87a7cjq53f.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1565264702;a0e91bb2; X-HE-SMSGID: 1hvgqp-000206-2u Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-dtls-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Thu, 08 Aug 2019 11:45:08 -0000 > On 8. Aug 2019, at 13:17, Juliusz Chroboczek wrote: >=20 >>> Using an ephemeral port that is discovered at runtime would add a = failure mode >>> to the protocol and make it less robust. >=20 >> Can you please explain why that would make it less robust? I would >> actually think that is would make it more robust. In any case you = need >> to somehow discovery the neighbour. Usually the babel HELLO would be >> used for that. When you add an new TLV to that HELLO that indicates >> a port that should be used for DTLS, this also gives you and = additional >> indication that the peer sending the hello actually supports DTLS = which >> I believe would make it more robust. >=20 > That's an intruiguing idea. >=20 >> Further with respect to security and topics probably recently = discussed, not having a default port would make it harder for an = attacker to flood a route with DTLS handshakes on that port. >=20 > Could you please explain what happens if an attacker sends out 65535 > spoofed multicast Hellos indicating 65535 distinct ports? You maybe rate limit DTLS connection attempts=E2=80=A6? I didn=E2=80=99t = fully design the protocol here but would like the wg to consider such an = approach. However, I guess it might make sense to even rate limit in the = proposed approach, or cache for a certain time that a connection attempt = to a certain peer failed before trying again. Mirja >=20 > -- Juliusz >=20 >=20 From nobody Thu Aug 8 05:48:12 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 78754120181; Thu, 8 Aug 2019 05:48:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan via Datatracker To: "The IESG" Cc: draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Suresh Krishnan Message-ID: <156526849047.7502.1019049975377859421.idtracker@ietfa.amsl.com> Date: Thu, 08 Aug 2019 05:48:10 -0700 Archived-At: Subject: [babel] Suresh Krishnan's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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, 08 Aug 2019 12:48:11 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-babel-rfc6126bis-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for your work on this well written document. Most of the issues I found have been covered in the ballot positions of my esteemed colleagues. I did have one major concern that I would like to see addressed though. This is in regard to backward compatibility with RFC6126 implementations. Due to the addition of the mandatory bit and the processing associated with it, I would think that the new implementations will not be able to properly interoperate with the existing RFC6126 implementations. Is my understanding correct? If so, I would like to see some text explaining what is the expected behavior when deploying into legacy environments. If not, I would greatly appreciate an explanation and I will clear. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Appendix F I think a consolidated change log from RFC6126 would be more helpful in the finished RFC for existing implementers. From nobody Thu Aug 8 05:59:21 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 3DA6412017C; Thu, 8 Aug 2019 05:59:20 -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 9V0nGwDf9eLw; Thu, 8 Aug 2019 05:59:18 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13C1E12016C; Thu, 8 Aug 2019 05:59:17 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x78CxCXO005522; Thu, 8 Aug 2019 14:59:12 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id E6E622EA76; Thu, 8 Aug 2019 14:59:15 +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 xx69QVuQ6Wdp; Thu, 8 Aug 2019 14:59:14 +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 BBBE42EA74; Thu, 8 Aug 2019 14:59:14 +0200 (CEST) Date: Thu, 08 Aug 2019 14:59:14 +0200 Message-ID: <87y303x17h.wl-jch@irif.fr> From: Juliusz Chroboczek To: Alvaro Retana Cc: "The IESG" , draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156518456148.8400.6644665367614468260.idtracker@ietfa.amsl.com> References: <156518456148.8400.6644665367614468260.idtracker@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=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]); Thu, 08 Aug 2019 14:59:12 +0200 (CEST) X-Miltered: at korolev with ID 5D4C1CA0.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4C1CA0.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 : 5D4C1CA0.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] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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: Thu, 08 Aug 2019 12:59:21 -0000 Dear Alvaro, This mail deals with your Discuss points (B) and (C). I haven't decided what to do about (A) yet. > (B) Error Handling > Many sections of the document describe functionality, or even Normatively > mandate it, but there is no discussion about Error Handling. In most cases, no explicit check is necessary, or even possible. In other cases, the TLV is ignored, which is the general approach taken in Babel with unparseable TLVs. I've added explicit error handling in cases where I find it suitable. > (B1) Router-Id Setting > 4.5: > o the current router-id; this is undefined at the start of the > packet, and is updated by each Router-ID TLV (Section 4.6.7) and > by each Update TLV with Router-Id flag set. > It took me some time to figure out the reason for being able to carry the > router-id in two different places inside the same packet, [...] > Did I understand correctly? ...it is all simply implied. You appear to have missed Section 3.5.3 "Encoding of updates", which probably indicates that it was at the wrong sport. I have now expanded this section, merged it into Section 4.5 "Parser state", and added backward references at suitable points. > What should happen if no Router-Id has been defined? Clarified requirement to ignore the Update TLV. > (B2) Default Prefix As above. > (B3) Next Hop As above. > (B4) For the Normative behavior listed here (I may have missed other > instances), I have basically the same question: what should a receiver > do if it is not the case? Most of these require no check on the receiver side, in may cases a receiver-side check is impossible. > - 3.8.1.2: "A node MUST NOT increase its sequence number by more than 1 in > response to a seqno request." This is a requirement for the sender. When the receiver notices that the seqno has increased, it cannot possibly know how many requests the sender has reaceived in the meantime. > - 4: "A Babel packet MUST be sent as the body of a UDP datagram, with > network-layer hop count set to 1..." This is a requirement for the sender. No receiver side check is required or even possible. > - 4.6.9: "If the metric is finite, AE MUST NOT be 0. If the metric is > infinite and AE is 0, Plen and Omitted MUST both be 0." Added requirement to drop the Update TLV if violated. > - 4.6.10: "...if AE is 0 (in which case Plen MUST be 0 and Prefix is of > length 0)." No clarification is necessary here, just like no clarification is necessary that for an IPv4 address, plen <= 32. > - 4.6.10/4.6.11: Is AE 3 a valid value in a request? I assume it isn't. > What should a receiver do if AE = 3. This case is allowed -- there's nothing in the protocol that disallows announcing routes within fe80::/64. Of course, it would be silly to do so. > (C) Mandatory Bit > 4.4: "The most-significant bit of the sub-TLV, called the mandatory bit..." > The most significant bit of which part of the sub-TLV? As written, that bit > would be the first one in the Type, which corresponds to the text in the IANA > section. Please be specific. This was a typo, noticed by ric Vyncke. The most-significant bit of the sub-TLV *Type*. The sub-TLV value consists of the whole 8 bits. TLV numbers 0 through 127 are non-mandatory, 128 through 255 are mandatory. > In the IANA considerations section, please include the whole registry in the > table to avoid confusion. I'm confused. Wouldn't that force me to do a number of downrefs? > Note that because of the mandatory bit, the 128-239 range should be > Reserved...but it is currently marked as Unassigned. No, this range is unassigned. Mandatory but unassigned. > Even worse, value 128 is assigned already [draft-ietf-babel-source-specific]. That is correct. The source prefix is a mandatory TLV. Value 128 has nothing to do with Pad1, which has value 0. -- Juliusz From nobody Thu Aug 8 06:06: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 80E01120075; Thu, 8 Aug 2019 06:06:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <156526956251.7467.592630566164228470.idtracker@ietfa.amsl.com> Date: Thu, 08 Aug 2019 06:06:02 -0700 Archived-At: Subject: [babel] Alissa Cooper's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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, 08 Aug 2019 13:06:03 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-babel-rfc6126bis-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support Roman's DISCUSS. I'm also unclear on the over-arching recommendation this document is making for securely deploying this protocol. Given that the protocol itself is insecure, I would have expected some normative requirement for correcting that (e.g., Minimally, Babel deployments MUST be secured using a lower-layer security mechanism, Babel over DTLS, or HMAC-based authentication.) This still would not bring it into line with BCP 61 Section 7, but perhaps there is some argument for making an exception for this protocol. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Suresh's DISCUSS. An explanation of why this document obsoletes RFC 6126 and RFC 7557 needs to appear in the introduction of this document. Section 3.2.3: It's a bit odd that the Multicast Hello is introduced here but the difference between the two kinds of hellos is not explained until Section 3.4.1. It makes me wonder if 3.2 should come after 3.4. Section 3.6: s/is not left-distributive Section 3.5.2/is not left-distributive (Section 3.5.2)/ Appendix C: This section should be in the body of the document. From nobody Thu Aug 8 06:07: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 020341200CD; Thu, 8 Aug 2019 06:07:23 -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 (2048-bit key) header.d=cooperw.in header.b=sRQi7G9y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ETdv8UK5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f36Gk3KXwvrE; Thu, 8 Aug 2019 06:07:21 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33BB120075; Thu, 8 Aug 2019 06:07:21 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id B2B29481; Thu, 8 Aug 2019 09:07:20 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 08 Aug 2019 09:07:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=w gShN5Zo0Rum4UQ/UZtJ1PLRqZH/SIHEkt62/2F3Aho=; b=sRQi7G9yErJa4TnKR 17zBYM5bB98UkDusSJ+3OalxOq00fbsoshBo0wZwklOz8r1Z6rUrh02FA7QCKQaH xwy5v+5D5QXUL49YMoCd+OnMWcr2wsX5sjTQiAdoI4ojiceisGChmBzFW/Hc6hya shzgEbOcrdNm+0aO7EwfOPkF9o707qx7nP5x8Xowflvhp/kqZUGNdOWHExepHQA0 154MsX8uF7KpaVxhwjSeEgICddWhBCZgwhBM0Tt1YjsPyNOP5JMTV16n//l2TQnS QF8qgi4DTjkhQ5PLR8KBvobda3T7U+meCYjOk+up4bJx4W4WkwiidhXjZVnleT7w LVwew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=wgShN5Zo0Rum4UQ/UZtJ1PLRqZH/SIHEkt62/2F3A ho=; b=ETdv8UK52snN23y04e7KvpYOQGNOnDe9Yl3lsM2SDzKQk5r0uAlRWtUWD pM79OOAG7HCLpG3bGLjzGwtkGjwO3TVCpWKdYyAegxTnG0anfwX/pspA3HqwDiHa Wf3pngnuywAU9AKjtBEmEfI7aeYvpa1aAOlkc3aSf1yQEQ9XVbA29erI3FzJ8skg de0gzehmUVRrnoF/FQmhZCo9bDuSnJbLK5ytUr009kxyD1j3B0SRBVwiQRYbvAK5 /PMHi2hnXpSkhgVnMRld7eKlCD5s3xdDxNQJd2uIkMv0+ls7fvBLTcwkD6rKpJHO QU8EN4FxlJ5dfZsvZrvLFm3dhWyQg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduhedgieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrjeefnecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.73]) by mail.messagingengine.com (Postfix) with ESMTPA id 7A3668005A; Thu, 8 Aug 2019 09:07:19 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <878stk1y77.wl-jch@irif.fr> Date: Thu, 8 Aug 2019 09:07:18 -0400 Cc: draft-ietf-babel-rfc6126bis.all@ietf.org, IETF Gen-ART , IETF , babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156122420684.16418.15464371573444699739@ietfa.amsl.com> <87woh6a6hr.wl-jch@irif.fr> <514CAB4A-FADD-4C5C-A653-1C6953BB2F1E@vigilsec.com> <878stk1y77.wl-jch@irif.fr> To: Juliusz Chroboczek , Russ Housley X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] [Gen-art] 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: Thu, 08 Aug 2019 13:07:23 -0000 Russ, thanks for your review. Juliusz, thanks for making updates. I = entered a DISCUSS ballot to chat about the security considerations. Alissa > On Jun 29, 2019, at 6:29 AM, Juliusz Chroboczek wrote: >=20 > Done in -11. Thanks again for your review. >=20 > -- Juliusz >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Aug 8 06:13:10 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 C5093120075; Thu, 8 Aug 2019 06:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=1zI2hptd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UTRTLPa0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olZTtexWBv0r; Thu, 8 Aug 2019 06:13:00 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3C5A12001B; Thu, 8 Aug 2019 06:12:56 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id ECD0B3FD; Thu, 8 Aug 2019 09:12:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 08 Aug 2019 09:12:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm3; bh=yfncU4XsQLUA10MnGeSu5dU EXTPgjpXsNWWrf+BQ+N0=; b=1zI2hptdwoGXeHNMJInvAYMrz1P8EO5FDKNUl43 AXVkP4loQ9VyDnMwca1kzENzzExikYzyfsxfw1rphhcpgzt69kMjwX8K50mG4r+0 nMc7NckU1/lobkyhp/US4Gb5Dj5egh18JQm2YLjiPZcqCge/V03Vwd0OyyfGd7bx hdGkm953CymDSVa6xJ59FsQ+2xp873C0nmdaefia1SCow+1ZxsD8yX85ciQK0q1F RPlG5sNCYlULzO9Y1n4kcXm0uBLSmCdUYXqNRN+odvr0+aQsHtII4uxJ086ldqu0 v+SYqueH0HFELspjo7zymloKy+4+/RFikhcZ62JjkEAk5Sg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=yfncU4 XsQLUA10MnGeSu5dUEXTPgjpXsNWWrf+BQ+N0=; b=UTRTLPa0oj2w+EkX20xlz/ YHPJh4GIq0aK4mb4FpEo625B4K7BRnIwYMwN/I/0WH3vyapoueoCkoz1sHChVCPk svEDa6Z7Q0NU+qM6LxVrlL5PMoPYxGV1NUSqHXi1pUS47mJ/cQzc1Lc0hBPw4YpP If8waqqH4X/A7Y947MFBdkZ5OY/yw+HYME1+F4iXpPHGg1DTsq4DOZJtWE75pzvs jcuaUC9IUs7kwUNP268Jp0Ccy81W+jV269+IehZssPWpYoqYn24JHP56XRjRGPtG au7aWIloNVXvH8OuipW6exOLF2J24bpxMbxm4ETSH6CTNVmMTgeemqKM9Al2X3Fw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduhedgiedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehgihhthhhusgdrtghomhdpihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddu jedrjeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfi drihhnnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.73]) by mail.messagingengine.com (Postfix) with ESMTPA id A92F9380086; Thu, 8 Aug 2019 09:12:54 -0400 (EDT) From: Alissa Cooper Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_11E64E68-54FF-4C1E-A105-348142153C20" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 8 Aug 2019 09:12:53 -0400 In-Reply-To: Cc: draft-ietf-babel-dtls.all@ietf.org, gen-art , IETF Discussion , Babel at IETF To: David Schinazi , Dan Romascanu References: <156148141106.31261.11148445355862352575@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] [Gen-art] 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: Thu, 08 Aug 2019 13:13:02 -0000 --Apple-Mail=_11E64E68-54FF-4C1E-A105-348142153C20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dan, thanks for your review. David, thanks for the update. I entered a = No Objection ballot. Alissa > On Jun 25, 2019, at 3:19 PM, David Schinazi = wrote: >=20 > Thanks Dan. I've pushed a commit with your suggestions: > = https://github.com/jech/babel-drafts/commit/8d6a6fc05ce4c621b38d2c7621c415= 7300380078 = >=20 > We'll upload -06 at the end of this round of comments. >=20 > David >=20 > On Tue, Jun 25, 2019 at 11:41 AM Dan Romascanu > wrote: > Thanks for the quick reply.=20 >=20 > See in-line.=20 >=20 > regards, >=20 > Dan >=20 >=20 > On Tue, Jun 25, 2019 at 9:29 PM David Schinazi = > wrote: > Hello Dan, and thanks for your review. Comments inline. >=20 > 1. In section 2.1: >=20 > > 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). >=20 > A reference would be desirable here. >=20 > What reference do you have in mind? This paragraph already has a > reference to Section 4 (IANA Considerations). >=20 > the section in the Babel spec that defines the "babel" port (UDP port = 6696, see ....) >=20 >=20 > =20 > 2. In section 2.4 >=20 > > 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. >=20 > Is the last sentence necessary? Is this case not covered by the = statement in > the first sentence? >=20 > 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. >=20 > Thanks for the clarification.=20 >=20 >=20 > Thanks, > David > =20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_11E64E68-54FF-4C1E-A105-348142153C20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dan, = thanks for your review. David, thanks for the update. I entered a No = Objection ballot.

Alissa


On Jun = 25, 2019, at 3:19 PM, David Schinazi <dschinazi.ietf@gmail.com> wrote:

Thanks Dan. I've pushed a commit with your suggestions:
https://github.com/jech/babel-drafts/commit/8d6a6fc05ce4c621b38= d2c7621c4157300380078

We'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:
Thanks for the quick reply.

See = in-line.

regards,

Dan


On Tue, Jun 25, 2019 at 9:29 PM David Schinazi = <dschinazi.ietf@gmail.com> 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
 
_______________________________________________
Gen-art = mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_11E64E68-54FF-4C1E-A105-348142153C20-- From nobody Thu Aug 8 06:13:49 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 3FD541200CD; Thu, 8 Aug 2019 06:13: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 0seE7Jb5SDia; Thu, 8 Aug 2019 06:13: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 59BE3120230; Thu, 8 Aug 2019 06:13:37 -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 x78DDWn7010570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Aug 2019 15:13:32 +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 x78DDWOc014510; Thu, 8 Aug 2019 15:13: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 44CC62ECFB; Thu, 8 Aug 2019 15:13: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 tcOSF3mxKB5L; Thu, 8 Aug 2019 15:13: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 5F6042ECF9; Thu, 8 Aug 2019 15:13:34 +0200 (CEST) Date: Thu, 08 Aug 2019 15:13:34 +0200 Message-ID: <87wofnx0jl.wl-jch@irif.fr> From: Juliusz Chroboczek To: Suresh Krishnan Cc: "The IESG" , draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156526849047.7502.1019049975377859421.idtracker@ietfa.amsl.com> References: <156526849047.7502.1019049975377859421.idtracker@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]); Thu, 08 Aug 2019 15:13:32 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 08 Aug 2019 15:13:32 +0200 (CEST) X-Miltered: at korolev with ID 5D4C1FFC.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D4C1FFC.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4C1FFC.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D4C1FFC.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 : 5D4C1FFC.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D4C1FFC.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] Suresh Krishnan's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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: Thu, 08 Aug 2019 13:13:47 -0000 Dear Suresh, > I did have one major concern that I would like to see addressed > though. This is in regard to backward compatibility with RFC6126 > implementations. Due to the addition of the mandatory bit and the > processing associated with it, I would think that the new > implementations will not be able to properly interoperate with the > existing RFC6126 implementations. Is my understanding correct? Short version: - a 6126bis implementation that does not send either mandatory sub-TLVs or Unicast Hellos fully interoperates with 6126. - an implementation of 6126 can be made compatible with 6126bis with the addition of 20 lines of code (ignore Unicast Hellos and TLVs with mandatory sub-TLVs). Long version: The WG discussed this issue at length, both at face-to-face meetings and over the ML. We had three possibilities: (1) remain 100% backwards-compatible; (2) add *optional* features that break compatibility; (3) make a new, incompatible version of the protocol. Solution (3) was considered as being the death of Babel. Solution (1) was rejected after we realised how much mandatory sub-TLVs simplify the protocol encoding. Thus, we came up with the following transition plan: - make the incompatible features optional, and don't send them by default; - teach all the implementations in the wild to silently ignore the new features; - wait one year; - start sending the new features by default. > If so, I would like to see some text explaining what is the expected behavior > when deploying into legacy environments [...] > I think a consolidated change log from RFC6126 would be more helpful in the > finished RFC for existing implementers. I'll seriously consider it. -- Juliusz From nobody Thu Aug 8 06:15: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 0EB4E120075; Thu, 8 Aug 2019 06:15:49 -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 (2048-bit key) header.d=cooperw.in header.b=wHkYMI5q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZjBb+pY8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giYs6TEc67Mq; Thu, 8 Aug 2019 06:15:47 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F285E120044; Thu, 8 Aug 2019 06:15:46 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 0AFA145C; Thu, 8 Aug 2019 09:15:45 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 08 Aug 2019 09:15:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=U 9lZ/TlPE1cOsso260mHIasZhjdHNEs66rLtRC2fDAU=; b=wHkYMI5qLV5BzPKat QgHa67XhMhDwT7d8IZyxQojEAC6e00YB3YSVvHC7km4IkWqRk+9io6OZiVYrDGtE k7MfPPtjQcVh/PZHhxejLx6kKa8qYuKMn9Cx+wV/VCrTN5DvYAEFPY1y/5wAPKwO SBYwHv6qTsn+v1Wtz7bjqmSGMFH2LZWXNTe9vIKYtXsdEWGBmqrymFJXDt6j48V0 VhPf0O43bhCSHgaa2G+l+nSY1jkqCWtZYzakjvIeXc/GATHbTd8cdPF12EbRNQBp RUp5QI7O3iZzTGwd+TAg4RBPRm5qDoN8LZsGSM0O5/4z4edwsRbXXpN/0aQ5vOYZ rolSQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=U9lZ/TlPE1cOsso260mHIasZhjdHNEs66rLtRC2fD AU=; b=ZjBb+pY8nR635cDjXyqz+8TAP1yfyfORSzcghKZ2EnkGh9awKdFMdNz71 t5GLHj0pzjFbnbaCXEkl+pAmuURLZPQBsP3S1aW46iVU98ejXxBjSW2FW4RoBwqp TGy3GNA3/U6n4faMm/bphJBPU1ixJaSbn6OM99omIWl/e0NGkkwwchqjfFzIhqbs DbdDNmfWip8bj0+SFgFDozWsMITGpcoPoWcGyCfbpUIPs9aqG0QD4WhVTVEfOCyO qUEyb+qBS7CWVWQ35lAhvpRk70PjMtp/91OHa9H5rESJolCV9yPboRYshJfU5CSg kyvL4hwoppeAWQ74XlaBOOtPlfoAQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduhedgiedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtddvnecuhfhrohhmpeetlhhishhsrgcuvehoohhpvghruceorghlihhsshgrsegt ohhophgvrhifrdhinheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepudejfe drfeekrdduudejrdejfeenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgrsegt ohhophgvrhifrdhinhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.73]) by mail.messagingengine.com (Postfix) with ESMTPA id 12FC3380075; Thu, 8 Aug 2019 09:15:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <156106898665.12408.8788016399506415627@ietfa.amsl.com> Date: Thu, 8 Aug 2019 09:15:44 -0400 Cc: gen-art@ietf.org, draft-ietf-babel-hmac.all@ietf.org, ietf@ietf.org, babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156106898665.12408.8788016399506415627@ietfa.amsl.com> To: David Schinazi X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] [Gen-art] Genart 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: Thu, 08 Aug 2019 13:15:49 -0000 David, thanks for your review. I entered a No Objection ballot. Alissa > On Jun 20, 2019, at 6:16 PM, David Schinazi via Datatracker = wrote: >=20 > Reviewer: David Schinazi > Review result: Ready >=20 > 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. >=20 > For more information, please see the FAQ at >=20 > . >=20 > 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 >=20 > Summary: Document is ready for publication. It is concise and = well-written. >=20 > Major issues: None >=20 > Minor issues: None >=20 > 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]" >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Aug 8 06:47:21 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 76B291200B6; Thu, 8 Aug 2019 06:47:11 -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 mMAAzbzz3s9p; Thu, 8 Aug 2019 06:47:09 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70D5E120044; Thu, 8 Aug 2019 06:47:09 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x78DkwAx019332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Aug 2019 15:46:58 +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 x78DkuCU026804; Thu, 8 Aug 2019 15:46:58 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 561642EF21; Thu, 8 Aug 2019 15:46:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id SX8rfU7O16Tm; Thu, 8 Aug 2019 15:46:58 +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 421A52EF1F; Thu, 8 Aug 2019 15:46:56 +0200 (CEST) Date: Thu, 08 Aug 2019 15:46:56 +0200 Message-ID: <87v9v7wyzz.wl-jch@irif.fr> From: Juliusz Chroboczek To: Roman Danyliw Cc: "The IESG" , draft-ietf-babel-hmac@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156520650683.8432.7109781814790904901.idtracker@ietfa.amsl.com> References: <156520650683.8432.7109781814790904901.idtracker@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=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 08 Aug 2019 15:46:58 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 08 Aug 2019 15:46:58 +0200 (CEST) X-Miltered: at korolev with ID 5D4C27D2.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D4C27D0.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4C27D2.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D4C27D0.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 : 5D4C27D2.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D4C27D0.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] Roman Danyliw's Discuss on draft-ietf-babel-hmac-08: (with DISCUSS and COMMENT) 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: Thu, 08 Aug 2019 13:47:12 -0000 Dear Roman, Thank you for your review. > (1) Section 1.2. Per “any packet accepted as authentic is the exactly copy of > a packet originally sent”, this text can be read two ways – packet as Babel > packet or as an IP packet. I think mean the former. Recommend making this > clearer as s/any packet/any Babel packet/ Done. > (2) Section 2, Per the paragraph, “By itself, this mechanism is safe > against replay …”, please reiterate that for the attack by C to work: > A and B must have both lost state; that C is replaying packets with PC > previously sent by B (e.g., n+2). Only A needs to have lost its state. Clarified. > (3) Section 4.1. Per “The node takes the concatenation of the pseudo-header > and the packet including the packet header but excluding the packet trailer > (from octet 0 inclusive up to (Body Length + 4) exclusive)”, as input for the > HMAC. “packet” is used to sometimes mean IP packet and sometimes a Babel > packet carried in an IP packet. Clarified. > (4) Section 2. This section suggests that “one or more HMACs can be > appended to the packet”. Under what conditions would it be more than > one? What happens if only some of the HMACs are valid? Is use of the > same key assumed? This section is a conceptual overview, and is optimised for easy readability. The exact details are given in 4.3. I've added the paranthetical remark "(one per key)", but refuse to overload this section any further. > (5) Section 4.1. The hash algorithm appears to be negotiated/set out of band > (rather than negotiated). The text should explicitly state that somewhere. Section 3.1. > (6) Section 6. Per “In particular, reception of a packet with no > correct HMAC creates no local state whatsoever (Section 4.3)”, unless > this HMAC verification is happening on the NIC, this doesn’t seem > sufficiently precise. The “no local state” claim is likely true only as > it relates to the tables data structures describes in Section 3. > However, the IP and DTLS stack certainly have to account for the packet. There is no DTLS in this protocol. I'm leaving this sentence as is -- after trying it out, I don't think that mentioning the small amount of state caused by reception of a UDP packet (an ND entry) is informative. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > (7) Section 1 enumerates a series of attacks. These are different than the > ones listed in Section 6 of draft-ietf-babel-rfc6126bis and Section 1 of > draft-ietf-babel-dtls. As HMAC and DTLS are mitigations for attacks in > draft-ietf-babel-rfc6126bis, they really should be harmonized. I'll look at making this uniform between the three drafts. > (8) Section 1. Per the “spoof of a malformed packet”, how would an HMAC > address this? Even assuming that a node discards the message without > processing if the HMAC is bad, this would still be a problem from > a malicious peer. Please explain. > (9) Editorial nits: Fixed, thanks. -- Juliusz From nobody Thu Aug 8 07:04:14 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 6214F120052 for ; Thu, 8 Aug 2019 07:04:12 -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 6PblbNh3rLlx for ; Thu, 8 Aug 2019 07:04:09 -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 936C7120044 for ; Thu, 8 Aug 2019 07:04:09 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1565273046; bh=1Jnq40OQfBFGgvIytKob19tPR2BGXmpYGE9HzYggbfs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=KeOeyZdyzMqquQkq8dZo8WxUBj+eK3h+62Z3A8mNON/3boKkW5iono9oPI1mzFBiQ fO0j1wxcpccYVBNIrQcNj20+BBnJRV1IAe6LxBBx8T+EsO+L5suI43bTarF8Nz+gJx nDTyGVB3QEG7xEokSc5ROo6taETMX5zLMsu1vOshSRNMR2wZU5HopW0whCs2qehZPJ DtjgaW5GnIctcHYeOtXfDZrJ6P6nZCCjocaxqK/MBfoQsU7CBxtwJ9NLmG9EmEY2Mc Fa0I30qns2Qqw3Q0lpwbksLBIKXStNxvh5gzrFkPOK0Is8I1rrNz/fNlbYoM2qQUTY 0nudqz08Xxzxw== To: "STARK\, BARBARA H" , 'Mahesh Jethanandani' Cc: 'Babel at IETF' , 'Juliusz Chroboczek' In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E25905B@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr> <87pnlhaixh.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E257961@GAALPA1MSGUSRBF.ITServices.sbc.com> <0B28A1FA-32B4-41E6-B646-C6A3907E9CCC@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114E258CF7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E25905B@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Thu, 08 Aug 2019 16:04:05 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87lfw3u52i.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Example configuration 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: Thu, 08 Aug 2019 14:04:13 -0000 "STARK, BARBARA H" writes: > What I had in mind for the updates to the information model are step 5. I= f the operator needs to update link-quality, or flip on split-horizon, or s= et a RTT estimate value, or specify whether they want to use unicast instea= d of multicast, or any combination thereof for a particular interface, they= would create a new babel-link-properties object and associate that with th= e interface. > > Can we agree on the changes to the information model I suggested yesterda= y? > > Let me see if I understand... Does it have to be a =E2=80=9Cnew=E2= =80=9D babel-link-properties instance, or can it be one that exists? > > That is, if we had an object called babel-link-properties > object { > string rw babel-link-properties-name; > [string rw babel-interface-metric-algorithm;] > [boolean rw babel-interface-split-horizon;] > [boolean rw babel-interface-rtt;] > [boolean rw babel-interface-unicast;] > } babel-hmac-keys-obj babel-link-properties; > > [mj] with the corrections marked in red. > I think babel-interface-metric-algorithm is =E2=80=9Cmandatory in t= he sense it must be implemented and expressed to be compliant with the info= model=E2=80=9D. So I disagree with the square brackets for that one. The e= xistence of the metric-algorithm is reasonably normative in rfc6126bis. The= possible enumerations aren=E2=80=99t normative, but that=E2=80=99s not wha= t the square brackets mean. At least one metric calculation algorithm must = be implemented and it must be given a name and expressed to be compliant wi= th the info model. I see rfc6126bis has split horizon as =E2=80=9CSHOULD=E2= =80=9D (Babel node SHOULD use an optimisation known as split horizon), so I= agree with square brackets for that. The other 2 aren=E2=80=99t actually g= oing in at this time, so there=E2=80=99s no dependency on their drafts. The= y need to mention what data elements they need in those drafts. And, yeah, = I=E2=80=99m sloppy with cut and paste. > > Where the implementation may create some set of initial entries that its = developers have decided to e.g. name =E2=80=9Cwired=E2=80=9D, =E2=80=9Cwire= less=E2=80=9D, =E2=80=9Ctunnel=E2=80=9D (but some other implementation may = give a different name to the same group of parameter values). link-properti= es-name must be unique (and not empty or NULL), but also no 2 instances are= allowed to have the same set of values for the latter 4 parameters. Once a= n instance is created it cannot be modified. If it is referenced from an in= terface or was created by the implementation, it cannot be deleted. This ma= kes instances created by the implementation immutable. > This object can be written (new instances created with different combinat= ions of values and a different name, like =E2=80=9Cunicast-wired=E2=80=9D). > An interface will have a reference to one of these instances, to identify= the set of link-properties it uses. It=E2=80=99s allowed to modify which s= et of link-properties is used/referenced by an interface. > > Is that right? And did you say you wanted it under interface or under the= base? I think it would make sense under base. Juliusz, I think this approa= ch (if it=E2=80=99s what Mahesh meant) would provide the benefits of allowi= ng users to use more meaningful names for groups of link properties, allow = use of names that babeld has already popularized among its users while allo= wing other implementations to use different names (names aren=E2=80=99t sta= ndardized), and isn=E2=80=99t very complicated. It does make it harder if t= he user wants to just change one of the link properties and not others (the= y might have to create a new instance). But it makes it easier for the user= who wants to change from one grouping of properties to another. > > [mj] Yes, that is what the intention of the change was. Note, I did want = instances of babel-link-properties to exist under the base (babel-informtio= n-obj). In babel-interface-obj we only reference one of those instances: > > object { > =E2=80=A6. > [babel-link-properties rw babel-link-properties<0..*>;] > > } babel-information-obj; > > object { > [reference rw babel-link-properties;] > =E2=80=A6.. > } babel-interface-obj; > > OK. I was too lazy to search for the exact proposal, so I was just = going by memory. But I think babel-link-properties needs to be <1..*>. Babe= l is dead in the water if it doesn=E2=80=99t have at least one means of cal= culating metrics. > Juliusz, does this make sense and are you ok with it? Why is this complexity needed? Couldn't it just be solved in the user interface, something like: An input form contains these four entries: [string rw babel-interface-metric-algorithm;] [boolean rw babel-interface-split-horizon;] [boolean rw babel-interface-rtt;] [boolean rw babel-interface-unicast;] Underneath those four input boxes is another dropdown box (or whatever) with the presets ("wireless", "wired", "tunnel", etc). Selecting one of these just fills in the preset values into the four input boxes above it, which the user can then either just accept, or change individual values as he or she pleases. This way, the information model doesn't need to know anything about the groups or preset names, it just carries the values... -Toke From nobody Thu Aug 8 07:35:14 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 CAB9D12006D for ; Thu, 8 Aug 2019 07:35:10 -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 7XioMK12-STt for ; Thu, 8 Aug 2019 07:35:09 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 655401200E6 for ; Thu, 8 Aug 2019 07:34:56 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id n9so37947508pgc.1 for ; Thu, 08 Aug 2019 07:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=K3Q1r4jvBPjX7S9zPSWibIkW46+k9hzkjyTUYJemsEo=; b=neF0lQVtJcR3y/qD3AZkDAYm1eAo9j3O+L2SeMLivQGJsFUMLc3pjRzyOgAwB/minD CewVC8QYg4/+ZQuTWrSgFLdU63wMSu75nigCUwlHv8K99Os06tYxXTKDWs5K+E6R7i6W zi2bfgnby1M27k6uQMtS1u0NiOr385V7Jv5vA7u3Y3NLTIJ7aS8RWZKVCZpRXaUmYewH 7dq7xwR4fSLhMO0b+lYPLqR/s/pPgQ7yWlU+7DLY0EGQoXmoesNp9jLGt6smjvceIiCH 1Dxbmez2tYh96co/TvSDFCUFEklNndl3inYevcCznqmQG3ZObsye5cMmeKvoIr/gv7C4 aFCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=K3Q1r4jvBPjX7S9zPSWibIkW46+k9hzkjyTUYJemsEo=; b=t2IBofHJXoi3ABexi+W462DpkBZanIB6aGEwQR7z/gKZoqqpvoAvmpw8MnU7xQnNDJ dvjRuObyNuXtu4b0OGWe8rvy95oo2hacPdlC3dHVo3QPfLthTySwaLm3/jqTAfYF8Jy6 kVOtPm0t4mIsG1Go9FgqvIVnQzgBzAgiSIlFIP+IARRy1qYPrrvijZ89YpBvClb/qllM CW9py0K0MoCg8VwDe/TJ0d3u4uqiVLjgFY5rbVM/XEqg2PbrIuTFuDC4aQLGfGyCQ+5o 1CnlFlAcWVtGnDX2VjBBM6+cTztxIRQOf3jkWpznH80HZSQdZX8ER7b82WQMyOknshul eZ9w== X-Gm-Message-State: APjAAAXG8Ou9VilhPDIPxmav2ZlLXgcCsC1Gwc0MrC7KntifIP/KxPoa RUQIT/u77seJihp1FaBhd5zzz62c X-Google-Smtp-Source: APXvYqxmPK5SqlMnBqKIrbhm+xd9AVySAGZyolSylI1c70waBsBftxTcQXQzb2M14m8hD0Yxq+iT1A== X-Received: by 2002:aa7:92d2:: with SMTP id k18mr15808683pfa.153.1565274895828; Thu, 08 Aug 2019 07:34:55 -0700 (PDT) Received: from [192.168.1.122] (c-73-93-49-153.hsd1.ca.comcast.net. [73.93.49.153]) by smtp.gmail.com with ESMTPSA id o128sm102235373pfb.42.2019.08.08.07.34.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Aug 2019 07:34:52 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <110D87BA-BBA1-417B-9BC3-77BAD4B201D1@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6C3DA098-3EC0-4528-93C4-7360C10C4EF0" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 8 Aug 2019 07:34:50 -0700 In-Reply-To: <87lfw3u52i.fsf@toke.dk> Cc: "STARK, BARBARA H" , Babel at IETF , Juliusz Chroboczek To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr> <87pnlhaixh.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E257961@GAALPA1MSGUSRBF.ITServices.sbc.com> <0B28A1FA-32B4-41E6-B646-C6A3907E9CCC@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114E258CF7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E25905B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87lfw3u52i.fsf@toke.dk> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Example configuration 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: Thu, 08 Aug 2019 14:35:11 -0000 --Apple-Mail=_6C3DA098-3EC0-4528-93C4-7360C10C4EF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Toke, > On Aug 8, 2019, at 7:04 AM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Why is this complexity needed? Couldn't it just be solved in the user > interface, something like: >=20 > An input form contains these four entries: > [string rw babel-interface-metric-algorithm;] > [boolean rw babel-interface-split-horizon;] > [boolean rw babel-interface-rtt;] > [boolean rw babel-interface-unicast;] While seemingly more complex, it is not. First of all, with your = proposed schema, if you need the same presets for multiple interfaces, = you would be having to repeat them for multiple interfaces. Secondly, = there is no way in YANG to define a set of presets, so there will be no = drop down menu to select from. We were going to document the three or = four well known presets. Thirdly, while these names and values may make = sense to us, they may not to an operator, who might want to configure = their own set of presets. Cheers. >=20 > Underneath those four input boxes is another dropdown box (or = whatever) > with the presets ("wireless", "wired", "tunnel", etc). Selecting one = of > these just fills in the preset values into the four input boxes above > it, which the user can then either just accept, or change individual > values as he or she pleases. >=20 > This way, the information model doesn't need to know anything about = the > groups or preset names, it just carries the values... >=20 > -Toke Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_6C3DA098-3EC0-4528-93C4-7360C10C4EF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Toke,

On Aug 8, 2019, at 7:04 AM, Toke = H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:

Why is this complexity needed? = Couldn't it just be solved in the user
interface, something like:

An input form contains these four entries:
         [string =             &n= bsp; rw babel-interface-metric-algorithm;]
         [boolean =             &n= bsp; rw babel-interface-split-horizon;]
         [boolean =             &n= bsp; rw babel-interface-rtt;]
         [boolean =             &n= bsp; rw babel-interface-unicast;]

While seemingly more complex, it is not. First of all, = with your proposed schema,  if you need the same presets for = multiple interfaces, you would be having to repeat them for multiple = interfaces. Secondly, there is no way in YANG to define a set of = presets, so there will be no drop down menu to select from. We were = going to document the three or four well known presets. Thirdly, while = these names and values may make sense to us, they may not to an = operator, who might want to configure their own set of = presets.

Cheers.


Underneath those four input = boxes is another dropdown box (or whatever)
with the presets ("wireless", = "wired", "tunnel", etc). Selecting one of
these just fills in the preset values into the four input = boxes above
it, which the = user can then either just accept, or change individual
values as he or she = pleases.

This way, the = information model doesn't need to know anything about the
groups or preset names, it just = carries the values...

-Toke

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_6C3DA098-3EC0-4528-93C4-7360C10C4EF0-- From nobody Thu Aug 8 09:44: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 36E2F1200C5; Thu, 8 Aug 2019 09:44:45 -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 vcw77O7txCm5; Thu, 8 Aug 2019 09:44:42 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BAB11200C4; Thu, 8 Aug 2019 09:44:42 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id z28so35299334ljn.4; Thu, 08 Aug 2019 09:44:42 -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=qro+uc8ULij+3o/wxYHNNgmHv8WcTicT1AQuJSd3aXs=; b=SIgOhkGpi2byjhGyd/IdfUIrrCbbLt+iE1Fq3iLVJdmWv0MYfGMbQvW1vhjPb4hIMc kJbvs80UyY8QkeHuR4orEyvM7qmgRfDtdmofJHextMREYjC4DsMyNjkOEqJqLybLK80O kBY5eLk06BMB/Q1DabwBi/vbV4bSl4JhNmc109wDWK+UdS1Ud/YGPDx6PK68zkPFQ+O6 j8gGkWzEAXMCaOwZLlZgZekwHdRc0ueea5vUEKGLItIiE5Fgz1GR1JFQmEbpEHeaafQY MGL+Cr9Gt+ypXN/HQeQuycTKCAw3uN/KO3LmDshlqe9Z5QLp3TpfTdZMAOiQ+/UQaeCf X73w== 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=qro+uc8ULij+3o/wxYHNNgmHv8WcTicT1AQuJSd3aXs=; b=fq4DzFQlw1pa7sEJwoTaCTB1GB7JuoY8YYEt3z+CyLw2Ff4uGnkDTYfln0yr7HmMKr ry7e13VLglkqFXP5hA9rfOPTwy3IuSVlFVDV83x3gA22kiMBDiGbhE1O7Qfb6X8yV0ch UG3iLzBRvHsgD3yAvLsEgrg+biIfNRxD7eMywtrnSLetkkKACLuTNo3P+l8AyEHEj7PU oj1a8SmGwaf6/O0sf3J9L2+0huahi5hAWTNXZMe5s2+5sFpprbf5wEbutTCFXiuLzyNc pfqyx0fm/Ay/sM512JF5PJ5SU3WhnhQk71h8yDbFB7CoTiDodcoxS52TVarQg431IW2v 6Spg== X-Gm-Message-State: APjAAAVhFb5AVtH8I9DNs2aE0628SZ2ZjCnBmnd2wOBRTI7KdrvcJSpb QmnRziS1iY5IsVbeHnA8LuLoo3GG04JhDbxq/AI= X-Google-Smtp-Source: APXvYqw6Ixn+iD/UUQjMj7+uCHCnvI6NXDU7P9Omj2mb9lNRsKE0d0vASJ+Vj5tpCGjF6ohT27YHoO72R7QkENEXTPo= X-Received: by 2002:a2e:2c14:: with SMTP id s20mr8767386ljs.54.1565282680446; Thu, 08 Aug 2019 09:44:40 -0700 (PDT) MIME-Version: 1.0 References: <156518163926.8337.14198016212015161206.idtracker@ietfa.amsl.com> <87a7cjq53f.wl-jch@irif.fr> <110AD4FB-186C-4C87-8BAF-7D8F4A04BC6F@kuehlewind.net> In-Reply-To: <110AD4FB-186C-4C87-8BAF-7D8F4A04BC6F@kuehlewind.net> From: David Schinazi Date: Thu, 8 Aug 2019 09:44:29 -0700 Message-ID: To: Mirja Kuehlewind Cc: Juliusz Chroboczek , babel-chairs , Babel at IETF , Donald Eastlake , The IESG , draft-ietf-babel-dtls@ietf.org Content-Type: multipart/alternative; boundary="0000000000002427c7058f9dc6e5" Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-dtls-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Thu, 08 Aug 2019 16:44:45 -0000 --0000000000002427c7058f9dc6e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mirja, Negotiated parameters are generally less robust than hard-coded ones because they open us up to state mismatch bugs. That said, I'm not certain we want to redesign protocol fundamentals in this review thread. You had previously asked us to investigate the feasibility of not having an assigned port within the working group. The authors took that advice and brought the discussion to the working group: https://mailarchive.ietf.org/arch/msg/babel/Mo4wxCQbgcNK8rPcKuNvOqxCopU The outcome of that discussion appeared to be clear consensus on requesting another port. I understand your rationale for pushing back on port allocations, and I'm glad we had a conversation about alternatives, but the discussion of pros and cons lead us to the conclusion that a second port will improve the protocol's chances of success. Thanks, David On Thu, Aug 8, 2019 at 4:45 AM Mirja Kuehlewind wrote= : > > > > On 8. Aug 2019, at 13:17, Juliusz Chroboczek wrote: > > > >>> Using an ephemeral port that is discovered at runtime would add a > failure mode > >>> to the protocol and make it less robust. > > > >> Can you please explain why that would make it less robust? I would > >> actually think that is would make it more robust. In any case you need > >> to somehow discovery the neighbour. Usually the babel HELLO would be > >> used for that. When you add an new TLV to that HELLO that indicates > >> a port that should be used for DTLS, this also gives you and additiona= l > >> indication that the peer sending the hello actually supports DTLS whic= h > >> I believe would make it more robust. > > > > That's an intruiguing idea. > > > >> Further with respect to security and topics probably recently > discussed, not having a default port would make it harder for an attacker > to flood a route with DTLS handshakes on that port. > > > > Could you please explain what happens if an attacker sends out 65535 > > spoofed multicast Hellos indicating 65535 distinct ports? > > You maybe rate limit DTLS connection attempts=E2=80=A6? I didn=E2=80=99t = fully design the > protocol here but would like the wg to consider such an approach. However= , > I guess it might make sense to even rate limit in the proposed approach, = or > cache for a certain time that a connection attempt to a certain peer fail= ed > before trying again. > > Mirja > > > > > > -- Juliusz > > > > > > --0000000000002427c7058f9dc6e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mirja,

Negotiated parameters are gen= erally less robust than hard-coded ones because they open us up to state mi= smatch bugs.

That said, I'm not certain we wan= t to redesign protocol fundamentals in this review thread. You had previous= ly asked us
to investigate the feasibility of not having an assig= ned port within the working group. The authors took that advice and
brought the discussion to the working group:
https://= mailarchive.ietf.org/arch/msg/babel/Mo4wxCQbgcNK8rPcKuNvOqxCopU
The outcome of that discussion appeared to be clear consensus on req= uesting another port.

I understand your rationale = for pushing back on port allocations, and I'm glad we had a conversatio= n about alternatives,
but the discussion of pros and cons lead us= to the conclusion that a second port will improve the protocol's chanc= es of success.

Thanks,
David
<= br>


On Thu, Aug 8, 2019 at 4:45 AM Mirja Kuehlewind <= ;ietf@kuehlewind.net> wrote:<= br>


> On 8. Aug 2019, at 13:17, Juliusz Chroboczek <jch@irif.fr> wrote:
>
>>> Using an ephemeral port that is discovered at runtime would ad= d a failure mode
>>> to the protocol and make it less robust.
>
>> Can you please explain why that would make it less robust? I would=
>> actually think that is would make it more robust. In any case you = need
>> to somehow discovery the neighbour. Usually the babel HELLO would = be
>> used for that. When you add an new TLV to that HELLO that indicate= s
>> a port that should be used for DTLS, this also gives you and addit= ional
>> indication that the peer sending the hello actually supports DTLS = which
>> I believe would make it more robust.
>
> That's an intruiguing idea.
>
>> Further with respect to security and topics probably recently disc= ussed, not having a default port would make it harder for an attacker to fl= ood a route with DTLS handshakes on that port.
>
> Could you please explain what happens if an attacker sends out 65535 > spoofed multicast Hellos indicating 65535 distinct ports?

You maybe rate limit DTLS connection attempts=E2=80=A6? I didn=E2=80=99t fu= lly design the protocol here but would like the wg to consider such an appr= oach. However, I guess it might make sense to even rate limit in the propos= ed approach, or cache for a certain time that a connection attempt to a cer= tain peer failed before trying again.

Mirja


>
> -- Juliusz
>
>

--0000000000002427c7058f9dc6e5-- From nobody Thu Aug 8 10:16: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 763241200C5; Thu, 8 Aug 2019 10:16:28 -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 MVNXqRbS4dMS; Thu, 8 Aug 2019 10:16:26 -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 3E50312006D; Thu, 8 Aug 2019 10:16:26 -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 x78HGK6a003800; Thu, 8 Aug 2019 19:16:20 +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 0E8C02FB06; Thu, 8 Aug 2019 19:16: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 FryxoWft-j5U; Thu, 8 Aug 2019 19:16: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 571282FB04; Thu, 8 Aug 2019 19:16:21 +0200 (CEST) Date: Thu, 08 Aug 2019 19:16:21 +0200 Message-ID: <87mugjo9wa.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mirja Kuehlewind Cc: babel-chairs , Babel at IETF , Donald Eastlake , The IESG , David Schinazi , draft-ietf-babel-dtls@ietf.org In-Reply-To: <110AD4FB-186C-4C87-8BAF-7D8F4A04BC6F@kuehlewind.net> References: <156518163926.8337.14198016212015161206.idtracker@ietfa.amsl.com> <87a7cjq53f.wl-jch@irif.fr> <110AD4FB-186C-4C87-8BAF-7D8F4A04BC6F@kuehlewind.net> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 08 Aug 2019 19:16:20 +0200 (CEST) X-Miltered: at korolev with ID 5D4C58E4.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4C58E4.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 : 5D4C58E4.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] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-babel-dtls-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Thu, 08 Aug 2019 17:16:29 -0000 >> Could you please explain what happens if an attacker sends out 65535 >> spoofed multicast Hellos indicating 65535 distinct ports? > You maybe rate limit DTLS connection attempts…? That's not the issue I had in mind. What I'm concerned about is that you're suggesting to use an unauthentifed TLV to negotiate DTLS connection parameters. That cannot go well. Let A and B be honest nodes, and C an attacker. In the current protocol: A -> multicast: Hello C spoofing A -> multicast: Hello B -> A(well-known port): DTLS ClientHello The DTLS connection succeeds even though C spoofed a Hello from A -- a Hello is a Hello, even if it was spoofed. In your suggested protocol: A -> multicast: Hello, port=1234 C spoofing A -> multicast: Hello, port = 1235 C spoofing A -> multicast: Hello, port = 1236 C spoofing A -> multicast: Hello, port = 1237 ... B -> A(which port?) Since B has received a bunch of Hellos ostensiby from A announcing different ports, it cannot reliably locate the one that's correct. An on-link attacker can trivially DoS any node of its choosing. What is more: - You can no longer identify Babel traffic -- it's just encrypted DTLS with random ports. What does that mean from a management point of view? - An attacker can cause any Babel node to send a DTLS ClientHello to an arbitrary IP and port. What consequences does that have for the security and DoS-resistance of unrelated protocols? Mirja, in the light of the above, you'll doubtless understand that we feel little motivation to spend time implementing your suggested protocol and experimenting with it. (And this working group has been following the policy of implementing everythig and listening to implementation experience, a policy that we like and do not wish to change.) -- Juliusz From nobody Thu Aug 8 13:01:52 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 6C1251200A3; Thu, 8 Aug 2019 13:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.493 X-Spam-Level: X-Spam-Status: No, score=-0.493 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, HTML_OBFUSCATE_05_10=0.26, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 TV0En2OATIQU; Thu, 8 Aug 2019 13:01:48 -0700 (PDT) Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) (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 9600D1200E7; Thu, 8 Aug 2019 13:01:47 -0700 (PDT) Received: by mail-ed1-x542.google.com with SMTP id h8so4081080edv.7; Thu, 08 Aug 2019 13:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=r96OOLfUm4hgLPOUwnYdHfJTQWyfVfXkI1SPhI95pAQ=; b=Jdm2xD/501XSlZ64tL/11FUynynQgjLYeKHYapIKIFOgfPDLu6yHbjPOM79d0r1fkY kOQxGJPXKy0Bf8nEPwZU7GOWwFYZL9xfU+ZiCwYLfaoemDfUWqFqh1XXDmSYy3QpnYyn jje4IDR5mpuBAVCxhlt2sBTkke0JdvErCi6l64h8omGyOVXF/Pph+EK5mjCgo6jV0wz1 5f3Knkoq4vm+haF58+0BOIbrk2ry0EqihQ6fxWan7d9UL9cwiRrifmMAgu/SQaSaqhEn jEEeF4apGE/W59PFzFJNKI329LExqrMGKhl7Rk7Oe/im7sJId1lRmsDL/mhYbitMkCXD 6ecA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=r96OOLfUm4hgLPOUwnYdHfJTQWyfVfXkI1SPhI95pAQ=; b=ubPzMcnjvAxVDRtNujVikKg9SHCD7/+KxlPr9CchG/IscTNj5R7igLThvb2jlIzxC4 JlN9mCIf0eBPgPjwQvRxmsxUiFWSGcf6YjRW76ezpoobnJipdKOnFLf96DvvNanLLniY m592QOn6dazTCjatKCykFIhckmP4bunTza+b3e8LOfRvdvScGysVTtENT1fXbpwCr2iX Gwp8WUEx25eKqehHwJUGtLMJfaxdwNOONwFV+daCB1lXgRXgAUoDwNKP879KiXoHuaiR LRsE7XKo2ooGT11fEC902XTwQkOpscy1DiZuOQw20n8rIrl9/vaNkUe+w72DidZL7Kje sJqQ== X-Gm-Message-State: APjAAAWFkn47oZ5OYnYlt/l/9Y06UsDvlKHDDs/uiahkUxhdo2e5Rh9U VIhRPirQvvaKMfWHfCEZK4wrXgEbSN17GxM/0yg= X-Google-Smtp-Source: APXvYqxaNSezLflMLCiEUPzYhYUVo3TYrpc5WkaYedECCs86xDqObpFI6g4Be5CwfXFck48cxsuEggVy5N35IpFbozc= X-Received: by 2002:a50:86bb:: with SMTP id r56mr7201220eda.217.1565294506153; Thu, 08 Aug 2019 13:01:46 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 8 Aug 2019 13:01:44 -0700 From: Alvaro Retana In-Reply-To: <87y303x17h.wl-jch@irif.fr> References: <156518456148.8400.6644665367614468260.idtracker@ietfa.amsl.com> <87y303x17h.wl-jch@irif.fr> MIME-Version: 1.0 Date: Thu, 8 Aug 2019 13:01:44 -0700 Message-ID: To: Juliusz Chroboczek Cc: babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , The IESG , draft-ietf-babel-rfc6126bis@ietf.org Content-Type: multipart/alternative; boundary="000000000000021ac2058fa087db" Archived-At: Subject: Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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: Thu, 08 Aug 2019 20:01:51 -0000 --000000000000021ac2058fa087db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On August 8, 2019 at 8:59:16 AM, Juliusz Chroboczek (jch@irif.fr) wrote: Juliusz: Hi! Thank you for being so responsive! In some cases below you=E2=80=99re indicating actions you=E2=80=99ve taken = (clarified, merged the text, etc.). I=E2=80=99ll wait for the updated document. :-) > (B) Error Handling > Many sections of the document describe functionality, or even Normatively > mandate it, but there is no discussion about Error Handling. In most cases, no explicit check is necessary, or even possible. In other cases, the TLV is ignored, which is the general approach taken in Babel with unparseable TLVs. I've added explicit error handling in cases where I find it suitable. Unparseable (as in unreadable, unrecognized, etc.) TLVs are not the same as what I=E2=80=99m pointing to here. The case I=E2=80=99m pointing out is wh= ere the behavior is not as expected: the text mandates something, but the receiver gets something else. ... > - =C2=A73.8.1.2: "A node MUST NOT increase its sequence number by more th= an 1 in > response to a seqno request." This is a requirement for the sender. When the receiver notices that the seqno has increased, it cannot possibly know how many requests the sender has reaceived in the meantime. Ahh=E2=80=A6I see. The increase MUST NOT be more than 1 per request. That= part was not clear to me. > - =C2=A74: "A Babel packet MUST be sent as the body of a UDP datagram, wi= th > network-layer hop count set to 1..." This is a requirement for the sender. No receiver side check is required or even possible. Well, if the received TTL > 1 then the receiver knows something is wrong. Please take a look at rfc5082 and consider using that mechanism instead. ... > - =C2=A74.6.10: "...if AE is 0 (in which case Plen MUST be 0 and Prefix i= s of > length 0)." No clarification is necessary here, just like no clarification is necessary that for an IPv4 address, plen <=3D 32. What do you mean by =E2=80=9Cno clarification is necessary=E2=80=9D? I understand why the values are 0. What I=E2=80=99m asking for is what sho= uld the receiver do if AE =3D 0 and Plen =3D n (any number other than 0)? > - =C2=A74.6.10/=C2=A74.6.11: Is AE 3 a valid value in a request? I assume= it isn't. > What should a receiver do if AE =3D 3. This case is allowed -- there's nothing in the protocol that disallows announcing routes within fe80::/64. Of course, it would be silly to do so. Silly doesn=E2=80=99t mean that someone won=E2=80=99t try it=E2=80=A6and ma= y end up filling up someone else=E2=80=99s table with garbage. I think this is a vulnerability= . As a point of reference, OSPFv3 doesn=E2=80=99t allow the advertisement of link-local addresses as destinations. I strongly suggest Babel do the same thing. > (C) Mandatory Bit > =C2=A74.4: "The most-significant bit of the sub-TLV, called the mandatory bit..." > The most significant bit of which part of the sub-TLV? As written, that bit > would be the first one in the Type, which corresponds to the text in the IANA > section. Please be specific. This was a typo, noticed by =C3=89ric Vyncke. The most-significant bit of t= he sub-TLV *Type*. The sub-TLV value consists of the whole 8 bits. TLV numbers 0 through 127 are non-mandatory, 128 through 255 are mandatory. > In the IANA considerations section, please include the whole registry in the > table to avoid confusion. I'm confused. Wouldn't that force me to do a number of downrefs? No=E2=80=A6I think the references to draft-chroboczek-babel-diversity-routi= ng (and the other drafts) can be Informative. > Note that because of the mandatory bit, the 128-239 range should be > Reserved...but it is currently marked as Unassigned. No, this range is unassigned. Mandatory but unassigned. > Even worse, value 128 is assigned already [draft-ietf-babel-source-specific]. That is correct. The source prefix is a mandatory TLV. Value 128 has nothing to do with Pad1, which has value 0. This was not clear to me either=E2=80=A6thanks for clarifying! Because the use of the bit is explained as a bit then my interpretation was that any sub-TLV could set the bit=E2=80=A6 I think it would be better if in =C2=A74.4 the text described a mandatory sub-TLV, not just a mandatory bit. Perhaps: The most-significant bit of the sub-TLV type (the bit with value 80 hexadecimal), called the mandatory bit, determines if the sub-TLV is mandatory or not. An unknown sub-TLV MUST be silently ignored, and the rest of the TLV is processed normally. If an unknown mandatory sub-TLV is received, then the whole enclosing TLV MUST be silently ignored (except for updating the parser state by a Router-Id, Next-Hop or Update TLV, see Section 4.6.7, Section 4.6.8, and Section 4.6.9). Also, please label the registry so that it is easier for everyone going forward to identify the range for mandatory sub-TLVs. I know you=E2=80=99r= e the Designated Expert in the registry=E2=80=A6but better to cover all the bases= . ;-) Thanks! Alvaro. --000000000000021ac2058fa087db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On August 8, 2019 at 8:59:16 AM, Juliusz Chroboc= zek (jch@irif.fr) wrote:

Juliusz:

Hi!

Thank you for being so responsive!
In some cases below you=E2=80=99re indicat= ing actions you=E2=80=99ve taken (clarified, merged the text, etc.).=C2=A0 = I=E2=80=99ll wait for the updated document. :-)

> (B) Error Handling=C2=A0

> Many sections of the document describe functi= onality, or even Normatively=C2=A0
> mandate it, but there is no discussion about Error Handling.=C2=A0

In most cases, no = explicit check is necessary, or even possible. In other=C2=A0
cases, the TLV is ignored, which is the = general approach taken in Babel=C2=A0=
with unparseable TLVs. I've added explicit error handling in= cases where=C2=A0
I find i= t suitable.=C2=A0
<= /span>

Unparseable (as in unreadable, unrecognized, et= c.) TLVs are not the same as what I=E2=80=99m pointing to here.=C2=A0 The c= ase I=E2=80=99m pointing out is where the behavior is not as expected: the = text mandates something, but the receiver gets something else.


...

> - =C2=A73.8.1.2: "A = node MUST NOT increase its sequence number by more than 1 in=C2=A0
> response to a seqno request.&q= uot;=C2=A0

This is a re= quirement for the sender. When the receiver notices that the=C2=A0
seqno has increased, it cannot poss= ibly know how many requests the sender=C2=A0
has reaceived in the meantime.=C2=A0

Ahh=E2=80= =A6I see.=C2=A0 The increase MUST NOT be more than 1 per request.=C2=A0 Tha= t part was not clear to me.



> - =C2=A74:= "A Babel packet MUST be sent as the body of a UDP datagram, with=C2=A0
> network-layer hop co= unt set to 1..."=C2=A0
This is a requirement for the sender. No receiver side check is requir= ed=C2=A0
or even possible.<= span class=3D"Apple-converted-space">=C2=A0

Well, if the received TTL > 1 then the receiver knows so= mething is wrong. =C2=A0

Please take a look at rfc5082 and consider u= sing that mechanism instead.


...
> - =C2=A74.6.10: ".= ..if AE is 0 (in which case Plen MUST be 0 and Prefix is of=C2=A0
> length 0)."=C2=A0

No clarification is necessary h= ere, just like no clarification is=C2= =A0
necessary that for an IPv4 address, plen <=3D 32.=C2=A0
<= /div>

What do you mean by =E2=80=9Cno clarification is necessary=E2=80=9D= ?

I understand why the values are 0.=C2=A0 What I=E2=80=99m asking fo= r is what should the receiver do if AE =3D 0 and Plen =3D n (any number oth= er than 0)?


> - =C2=A74.6.10/=C2=A74.6.11: Is AE 3 a valid va= lue in a request? I assume it isn't.=C2=A0
> What should a receiver do if AE =3D 3.=C2=A0

This case is allowed -- the= re's nothing in the protocol that disallows=C2=A0
announcing routes within fe80::/64. Of course, i= t would be silly to do so.=C2=A0

Silly doesn=E2=80=99t mean that = someone won=E2=80=99t try it=E2=80=A6and may end up filling up someone else= =E2=80=99s table with garbage.=C2=A0 I think this is a vulnerability.

As a point of reference, OSPFv3 doesn=E2=80=99t allow the advertisement of= link-local addresses as destinations.=C2=A0 I strongly suggest Babel do th= e same thing.


> (C) Mandatory Bit=C2=A0

> =C2=A74.4: "The most-significant b= it of the sub-TLV, called the mandatory bit..."=C2=A0
> The most significant bit of which part= of the sub-TLV? As written, that bit= =C2=A0
> would be the first one in the Type, which corresponds= to the text in the IANA=C2=A0=
> section. Please be specific.= =C2=A0

This was a typo, noticed by =C3=89ric Vyncke. The most= -significant bit of the=C2=A0<= br>sub-TLV *Type*.=C2=A0
The sub-TLV value consists of the whole 8 bits. TLV numbers 0 through 127= =C2=A0
are non-mandatory, 1= 28 through 255 are mandatory.=C2=A0

> In the IANA considerations section, please include the wh= ole registry in the=C2=A0
&= gt; table to avoid confusion.=C2=A0

I'm confused. Wouldn't that force me to do a number of= downrefs?=C2=A0

No=E2=80=A6I think the references to=C2=A0draft-= chroboczek-babel-diversity-routing (and the other drafts) can be Informativ= e.


> Note that because of the mandatory bit, the 128-239 rang= e should be=C2=A0
> Rese= rved...but it is currently marked as Unassigned.=C2=A0

No, this range is unassigned. Mandatory but= unassigned.=C2=A0

>= Even worse, value 128 is assigned already [draft-ietf-babel-source-specifi= c].=C2=A0

That is corre= ct. The source prefix is a mandatory TLV. Value 128 has=C2=A0
nothing to do with Pad1, which has value= 0.=C2=A0

This was not clear to me either=E2=80=A6thanks for clar= ifying!=C2=A0

Because the use of the bit is explained as a bit then m= y interpretation was that any sub-TLV could set the bit=E2=80=A6

I th= ink it would be better if in =C2=A74.4 the text described a mandatory sub-T= LV, not just a mandatory bit.=C2=A0 Perhaps:

=C2=A0 =C2=A0The most-si= gnificant bit of the sub-TLV type (the bit with value 80=C2=A0

=C2=A0= =C2=A0hexadecimal), called the mandatory bit, determines if the sub-TLV is= =C2=A0

=C2=A0 =C2=A0mandatory or not.=C2=A0 An unknown sub-TLV MUST b= e silently ignored, and the rest=C2=A0

=C2=A0 =C2=A0of the TLV is pro= cessed normally.=C2=A0 If an unknown mandatory sub-TLV is=C2=A0

=C2= =A0 =C2=A0received, then the whole enclosing TLV MUST be silently ignored (= except for=C2=A0

=C2=A0 =C2=A0updating the parser state by a Router-I= d, Next-Hop or Update TLV, see=C2=A0

=C2=A0 =C2=A0Section 4.6.7, Sect= ion 4.6.8, and Section 4.6.9).


Also, please label th= e registry so that it is easier for everyone going forward to identify the = range for mandatory sub-TLVs.=C2=A0 I know you=E2=80=99re the Designated Ex= pert in the registry=E2=80=A6but better to cover all the bases. ;-)

Thanks!

Alvaro.
--000000000000021ac2058fa087db-- From nobody Thu Aug 8 13:20: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 B1C2C1200A3 for ; Thu, 8 Aug 2019 13:20:46 -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 4GXJtcdiVYQM for ; Thu, 8 Aug 2019 13:20:44 -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 B12B512002F for ; Thu, 8 Aug 2019 13:20:44 -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=1565295641; bh=pkoZcpAnaUo6nYaId1kZswdBVa/N2uXOHEkTiEcM58o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=BrB8gHLsiLr0x89Qs6Bf3v8Umq9pDL6sZkm18S4rFciJyX8qH5A/4LCSXPVX3ueBU 4QjaNG+EePoYBkyzahrB/n4CGQ9YT3JhtEADAFMHx7h0ifhnH/xg9cn0iTK8DV3Axj WO4v5U0g3aMKVv53uQ7p2ErSYX5RUttJN1LhctUS/Na0vjSKnF5hocTKhrIjM489ha c3u7qrfmYGGWAENvIOZDYIQckjGMsq3wjGnAg0SVRGeE3S7/ihQi8xvZx4XDFLCKjL gG8YFTQOPgZgbnDgkIc7CEzLTZbHGtC4Islhb6FQ4GBqaOT5ae8a2qWRFzZC3yVxs8 WmcXnq7yvT9Ag== To: Mahesh Jethanandani Cc: "STARK\, BARBARA H" , Babel at IETF , Juliusz Chroboczek In-Reply-To: <110D87BA-BBA1-417B-9BC3-77BAD4B201D1@gmail.com> References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr> <87pnlhaixh.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E257961@GAALPA1MSGUSRBF.ITServices.sbc.com> <0B28A1FA-32B4-41E6-B646-C6A3907E9CCC@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114E258CF7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E25905B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87lfw3u52i.fsf@toke.dk> <110D87BA-BBA1-417B-9BC3-77BAD4B201D1@gmail.com> Date: Thu, 08 Aug 2019 22:20:40 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87ftmbs92f.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Example configuration 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: Thu, 08 Aug 2019 20:20:47 -0000 Mahesh Jethanandani writes: > Hi Toke, > >> On Aug 8, 2019, at 7:04 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >> Why is this complexity needed? Couldn't it just be solved in the user >> interface, something like: >>=20 >> An input form contains these four entries: >> [string rw babel-interface-metric-algorithm;] >> [boolean rw babel-interface-split-horizon;] >> [boolean rw babel-interface-rtt;] >> [boolean rw babel-interface-unicast;] > > While seemingly more complex, it is not. First of all, with your > proposed schema, if you need the same presets for multiple interfaces, > you would be having to repeat them for multiple interfaces. Secondly, > there is no way in YANG to define a set of presets, so there will be > no drop down menu to select from. These both sound like UI issues rather than configuration protocol issues. I'm not familiar with how YANG works, but from this it sounds like a UI cannot deviate from what is defined in the YANG model? > We were going to document the three or four well known presets. > Thirdly, while these names and values may make sense to us, they may > not to an operator, who might want to configure their own set of > presets. But how does this work in the case where nothing is set on the management interface, the implementation auto-detect the interface type, and fills out the defaults based on the type? As Juliusz explained, the preset keyword cannot generally be inferred from the set values, so what is the info model / management interface supposed to do in this case? -Toke From nobody Thu Aug 8 13:37:33 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 C4BAB1201E2; Thu, 8 Aug 2019 13:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 u4A2x4ycIfxU; Thu, 8 Aug 2019 13:37:28 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 90298120224; Thu, 8 Aug 2019 13:37:09 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x78Kb1p9002702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 8 Aug 2019 16:37:03 -0400 Date: Thu, 8 Aug 2019 15:37:01 -0500 From: Benjamin Kaduk To: "STARK, BARBARA H" Cc: "'Juliusz Chroboczek'" , "'babel@ietf.org'" , "'homenet@ietf.org'" Message-ID: <20190808203700.GG59807@kduck.mit.edu> References: <156500498261.24571.204581663078651704.idtracker@ietfa.amsl.com> <87tvavlqrt.wl-jch@irif.fr> <20190806152958.GE59807@kduck.mit.edu> <87ef1yb6s8.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E25674D@GAALPA1MSGUSRBF.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E25674D@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [babel] =?iso-8859-1?q?=C9ric_Vyncke=27s_Discuss_on_draft-ietf-b?= =?iso-8859-1?q?abel-applicability-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Thu, 08 Aug 2019 20:37:30 -0000 On Tue, Aug 06, 2019 at 06:13:25PM +0000, STARK, BARBARA H wrote: > Removing unnecessary participants from the discussion (I don't think its relevant to the IESG review of babel-applicability?), and adding homenet... > > > > How does the HOMENET usage of babel fit into this? I would be > > > surprised if they were expecting secure link layers to be used inside > > > the home, but it does seem like the threat model for HOMENET includes > > > hostile or compromised devices in the home. > > > > Barbara will correct me if I'm wrong, but as far as I know, the Homenet > > working group hasn't decided on a security mechanism yet. I have heard > > opinions to the effect that Homenet requires asymmetric authentication, in > > which case Babel-DTLS would be necessary, but I wouldn't presume to judge > > whether these opinions represent WG consensus. > > Homenet WG hasn't documented its security requirements -- for anything. > The current model for securing home networks is to secure the physical layers. > The normal practice for dealing with compromised devices in the home is to remove or fix them when someone figures out they're compromised. > My personal (individual) opinion is it's extremely important to have tools to discover when a device is causing trouble. On-going protection against such devices (so they can be safely(?) left on the home network indefinitely and people can feel secure????) isn't important or even necessarily a good idea. > > Babel-HMAC could identify anything trying to talk Babel without a key. If the compromised device has been given the keys (because the user thought it could be trusted and didn't know it was compromised), then neither HMAC nor DTLS will be of any protection. Hmm, so do you think it's possible that HOMENET could land in the "uses secure link layers" bucket? (It sounds like it's also possible it would use babel-hmac or babel-dtls.) I can readjust my expectations accordingly... Thanks, Ben From nobody Thu Aug 8 14:50: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 4C0A71200E5; Thu, 8 Aug 2019 14:50: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 LmfLOEinU-Y5; Thu, 8 Aug 2019 14:50: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 CB7C11200C5; Thu, 8 Aug 2019 14:49:59 -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 x78LnqHm018390; Thu, 8 Aug 2019 23:49:52 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 40F5A3072C; Thu, 8 Aug 2019 23:49:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 7zaVGnqBgd1C; Thu, 8 Aug 2019 23:49:54 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1A0883072A; Thu, 8 Aug 2019 23:49:54 +0200 (CEST) Date: Thu, 08 Aug 2019 23:49:53 +0200 Message-ID: <87wofnminy.wl-jch@irif.fr> From: Juliusz Chroboczek To: Benjamin Kaduk Cc: "STARK, BARBARA H" , "'babel@ietf.org'" , "'homenet@ietf.org'" In-Reply-To: <20190808203700.GG59807@kduck.mit.edu> References: <156500498261.24571.204581663078651704.idtracker@ietfa.amsl.com> <87tvavlqrt.wl-jch@irif.fr> <20190806152958.GE59807@kduck.mit.edu> <87ef1yb6s8.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E25674D@GAALPA1MSGUSRBF.ITServices.sbc.com> <20190808203700.GG59807@kduck.mit.edu> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 08 Aug 2019 23:49:52 +0200 (CEST) X-Miltered: at korolev with ID 5D4C9900.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4C9900.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 : 5D4C9900.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] =?iso-8859-1?q?=C9ric_Vyncke=27s_Discuss_on_draft-ietf-b?= =?iso-8859-1?q?abel-applicability-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Thu, 08 Aug 2019 21:50:03 -0000 > Hmm, so do you think it's possible that HOMENET could land in the "uses > secure link layers" bucket? No opinion on the above. I'll only state that HNCP supports running over DTLS (this is implemented in hnetd, the reference implementation of HNCP). Section 8.3 of RFC 7787 describes a distributed algorithm for semi-autonomously choosing a set of trusted DTLS keys. > (It sounds like it's also possibl e it would use babel-hmac or babel-dtls.) If Homenet ends up running HNCP in a secure mode, then it could be used as a trust anchor for Babel. We could do either of the following: - use HNCP to elect a single Babel-HMAC key for the network; - generate random Babel-DTLS keypairs and flood the public part over HNCP; - reuse HNCP keypairs in Babel-DTLS. Of course, if HNCP runs insecure, then it would be somewhat doubtful to use it for key distribution. -- Juliusz From nobody Thu Aug 8 14:56: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 6F8AB120073 for ; Thu, 8 Aug 2019 14:56:11 -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 P66yQAqjgRjo for ; Thu, 8 Aug 2019 14:56:07 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 7D9DD12002F for ; Thu, 8 Aug 2019 14:56:07 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id q10so44830417pff.9 for ; Thu, 08 Aug 2019 14:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=oKYGfAsdSi58iumP5hUuORo+guVyhaklREgPgcLTiA4=; b=Z+EZG8S4AOpEOF8/SZSiCOk8Gej5jlxrUKLdmVDIin5uouSIp7kOFQOyJHGDvSpW69 Imw3ov3cTmnWuN7jJx/ZddOppIikogPcUJkxTMYsZsZIwv1HQ8DQ32TGHnvdkSGnIlTp 7uaLrt6QRkteiBeJRFoC4Hewj4OPSfpqj6LOBzdqaJ5UeIO8ugdJ0YkFWoYX5lDyhGr8 8qAbFOZOAqfiEcLFyOAGoucRwQw8wgByR9fXYgeAMxjMxOwyj0B2/X0M/11iOofM0cM9 tcp4+ZJCQOWaSjVyipRD/0Bm0D5tzA41TcaGwDP58EDBKtzBB/2ZKIZdN7NpMD0vQH0H YGEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=oKYGfAsdSi58iumP5hUuORo+guVyhaklREgPgcLTiA4=; b=BFVwnFlCJOvHpAfEIdRijUEUODhNZd/tPPYF3EZwGh3wASxB+ps3DBQO0xeQE/Pr+g t4Jium2wID81hXA1Qv3RRwzc6xh+dXgchKYgiBthBHeheXYi5J6dBT3dwVYsBO9YlbYr TdlVrBSpLYQe2Xzr9KFMTpxI/zkns3tPsHKvhXWxl1cU+M8GmvChaOqRffqU5jZUI184 UqDnzQ6eEmjUrGH4o+4h+HxUkr9VumxZt+yOd85RG4xPKHuaqcVDSUmEbpj01DYJIyo9 kfNl5TiagZHJnRq/YAlmdcGfkd62vzIz7KtWKcofxx/FZrnT0gnWcsojh8nNYQRH3Avy CNcA== X-Gm-Message-State: APjAAAWY4X8cCoeZ+ICrMQXn9+iFP3AOY1cUvMeRGRCcSKhg8HBiMyXN kDQYLOeagb1kaiKKVkJ+5xE= X-Google-Smtp-Source: APXvYqzpOXLp40ZCjncaZywOTaCzpSpG1gtHxSawDOvgpsJA7LLX9jLIoSrIEcA95nJ8cImcAwq9qw== X-Received: by 2002:a63:29c4:: with SMTP id p187mr14885658pgp.330.1565301366664; Thu, 08 Aug 2019 14:56:06 -0700 (PDT) Received: from [10.1.244.27] ([66.170.99.95]) by smtp.gmail.com with ESMTPSA id v13sm108815504pfe.105.2019.08.08.14.56.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Aug 2019 14:56:05 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <26F1A0CD-1FD2-456E-B295-8A60D93CF8E0@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B0C3707D-A46B-4235-84DC-0913055AC0DF" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 8 Aug 2019 14:55:59 -0700 In-Reply-To: <87ftmbs92f.fsf@toke.dk> Cc: "STARK, BARBARA H" , Babel at IETF , Juliusz Chroboczek To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr> <87pnlhaixh.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E257961@GAALPA1MSGUSRBF.ITServices.sbc.com> <0B28A1FA-32B4-41E6-B646-C6A3907E9CCC@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114E258CF7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E25905B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87lfw3u52i.fsf@toke.dk> <110D87BA-BBA1-417B-9BC3-77BAD4B201D1@gmail.com> <87ftmbs92f.fsf@toke.dk> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Example configuration 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: Thu, 08 Aug 2019 21:56:12 -0000 --Apple-Mail=_B0C3707D-A46B-4235-84DC-0913055AC0DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tote, > On Aug 8, 2019, at 1:20 PM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >>=20 >> While seemingly more complex, it is not. First of all, with your >> proposed schema, if you need the same presets for multiple = interfaces, >> you would be having to repeat them for multiple interfaces. Secondly, >> there is no way in YANG to define a set of presets, so there will be >> no drop down menu to select from. >=20 > These both sound like UI issues rather than configuration protocol > issues. I'm not familiar with how YANG works, but from this it sounds > like a UI cannot deviate from what is defined in the YANG model? YANG is a data modeling language. It models configuration and = operational parameters, defining what type of value a particular = parameter is. It does not specify a value for them. For example, it = models babel-interace-split-horizon parameter as a boolean. Unless a = default is desired, it will not even tell you whether the value for = split horizon is true or false. That is for the operator or whoever = wants to manage the Babel protocol on the device to configure. That is = why I said, YANG will not define preset values, for example =E2=80=9Cwired= =E2=80=9D, =E2=80=9Cwireless=E2=80=9D or =E2=80=9Cother" UI. That is up = to the operator to define. >=20 >> We were going to document the three or four well known presets. >> Thirdly, while these names and values may make sense to us, they may >> not to an operator, who might want to configure their own set of >> presets. >=20 > But how does this work in the case where nothing is set on the > management interface, the implementation auto-detect the interface = type, > and fills out the defaults based on the type? As Juliusz explained, = the > preset keyword cannot generally be inferred from the set values, so = what > is the info model / management interface supposed to do in this case? Let us take two concrete examples. One where the operator has a eth0 = interface which is connected to a wired network and does not need any = link properties defined, as the implementation knows what to do with a = wired interface. The second where it needs to set split horizon to false = because the eth1 interface is connected via a bridge to the radio = network. In the first example, and assuming the model Barbara and I suggested, = the operator does not need to anything to specify any link properties = for eth0. The implementation can pick out the defaults based on the = interface type (wired in this case) and use it.=20 In the second example, the operator will define a = babel-link-properties-obj, call it =E2=80=9Cradio=E2=80=9D or = =E2=80=9Cwireless=E2=80=9D or anything they want, and within that object = set the babel-interface-metric-algorithm (because it a mandatory = parameter), and set the babel-split-horizon to false. They will then = associate =E2=80=9Cradio=E2=80=9D object with eth1 interface. Does that help? >=20 > -Toke Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_B0C3707D-A46B-4235-84DC-0913055AC0DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Tote,

On Aug 8, 2019, at 1:20 PM, Toke = H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:

While = seemingly more complex, it is not. First of all, with your
proposed schema, if you need the same presets for multiple = interfaces,
you would be having to repeat them for = multiple interfaces. Secondly,
there is no way in YANG to = define a set of presets, so there will be
no drop down = menu to select from.

These = both sound like UI issues rather than configuration protocol
issues. I'm not familiar with how YANG works, but from this = it sounds
like a UI cannot deviate from what is defined in = the YANG model?

YANG is a data modeling language. It = models configuration and operational parameters, defining what type of value a particular parameter is. It does not = specify a value for them. For example, it models = babel-interace-split-horizon parameter as a boolean. Unless a default is = desired, it will not even tell you whether the value for split horizon = is true or false. That is for the operator or whoever wants to manage = the Babel protocol on the device to configure. That is why I said, YANG = will not define preset values, for example =E2=80=9Cwired=E2=80=9D, = =E2=80=9Cwireless=E2=80=9D or =E2=80=9Cother" UI. That is up to the = operator to define.


We were going to document the three or four = well known presets.
Thirdly, while these names and values = may make sense to us, they may
not to an operator, who = might want to configure their own set of
presets.

But how does this work in the = case where nothing is set on the
management interface, the = implementation auto-detect the interface type,
and fills = out the defaults based on the type? As Juliusz explained, the
preset keyword cannot generally be inferred from the set = values, so what
is the info model / management interface = supposed to do in this case?

Let us = take two concrete examples. One where the operator has a eth0 interface = which is connected to a wired network and does not need any link = properties defined, as the implementation knows what to do with a wired = interface. The second where it needs to set split horizon to false = because the eth1 interface is connected via a bridge to the radio = network.

In the first example, and = assuming the model Barbara and I suggested, the operator does not need = to anything to specify any link properties for eth0. The implementation = can pick out the defaults based on the interface type (wired in this = case) and use it. 

In the = second example, the operator will define a babel-link-properties-obj, = call it =E2=80=9Cradio=E2=80=9D or =E2=80=9Cwireless=E2=80=9D or = anything they want, and within that object set the = babel-interface-metric-algorithm (because it a mandatory parameter), and = set the babel-split-horizon to false. They will then associate = =E2=80=9Cradio=E2=80=9D object with eth1 interface.

Does that help?


-Toke

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_B0C3707D-A46B-4235-84DC-0913055AC0DF-- From nobody Thu Aug 8 15:04: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 1F5101200A3; Thu, 8 Aug 2019 15:03:55 -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, 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 (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZFFqwamWfNP; Thu, 8 Aug 2019 15:03:52 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 9C3B612002F; Thu, 8 Aug 2019 15:03:52 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x78M3mbv009788; Thu, 8 Aug 2019 18:03:48 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x78M3mbv009788 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1565301829; bh=5PqN5LBZJ8WuLsLyyhijVFJJITSrVM/GAXk467KGOgs=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=MYgQYYB1SEYf86jwj6/RUR7l3r87HOmPzNYRguZmo2PK92Ry6RhZ2WlbL5qaBuf1n 4oO0V2mQhc32tcUbqcfwR3va5K17r0V8pvl+DjpL33H/ik9hBmc7Vi7L9MEUmQwlQO hrHFG2wjpdobEnRbk4/euCrtFLimEQC1enMPlOhE= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x78M3j69013680; Thu, 8 Aug 2019 18:03:45 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0468.000; Thu, 8 Aug 2019 18:03:45 -0400 From: Roman Danyliw To: Juliusz Chroboczek CC: Donald Eastlake , "babel-chairs@ietf.org" , The IESG , "babel@ietf.org" , "draft-ietf-babel-hmac@ietf.org" Thread-Topic: Roman Danyliw's Discuss on draft-ietf-babel-hmac-08: (with DISCUSS and COMMENT) Thread-Index: AQHVTVc7EhiAo9Vjs0mVXthEfhPXuKbxh9sAgAAnvwA= Date: Thu, 8 Aug 2019 22:03:44 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B3402CA5@marchand> References: <156520650683.8432.7109781814790904901.idtracker@ietfa.amsl.com> <87v9v7wyzz.wl-jch@irif.fr> In-Reply-To: <87v9v7wyzz.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [babel] Roman Danyliw's Discuss on draft-ietf-babel-hmac-08: (with DISCUSS and COMMENT) 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: Thu, 08 Aug 2019 22:03:56 -0000 SGkgSnVsaXVzeiENCg0KVGhhbmtzIGZvciB0aGUgcXVpY2sgcmVzcG9uc2UuICBSZXNwb25zZXMg aW5saW5lIC4uLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGllc2cg W21haWx0bzppZXNnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdWxpdXN6IENocm9i b2N6ZWsNCj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCA4LCAyMDE5IDk6NDcgQU0NCj4gVG86IFJv bWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz4NCj4gQ2M6IERvbmFsZCBFYXN0bGFrZSA8ZDNlM2Uz QGdtYWlsLmNvbT47IGJhYmVsLWNoYWlyc0BpZXRmLm9yZzsgVGhlIElFU0cNCj4gPGllc2dAaWV0 Zi5vcmc+OyBiYWJlbEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1iYWJlbC1obWFjQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBSb21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWJhYmVs LWhtYWMtMDg6ICh3aXRoDQo+IERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBEZWFyIFJvbWFu LA0KPiANCj4gVGhhbmsgeW91IGZvciB5b3VyIHJldmlldy4NCj4gDQo+ID4gKDEpIFNlY3Rpb24g MS4yLiAgUGVyIOKAnGFueSBwYWNrZXQgYWNjZXB0ZWQgYXMgYXV0aGVudGljIGlzIHRoZSBleGFj dGx5DQo+ID4gY29weSBvZiBhIHBhY2tldCBvcmlnaW5hbGx5IHNlbnTigJ0sIHRoaXMgdGV4dCBj YW4gYmUgcmVhZCB0d28gd2F5cyDigJMNCj4gPiBwYWNrZXQgYXMgQmFiZWwgcGFja2V0IG9yIGFz IGFuIElQIHBhY2tldC4gIEkgdGhpbmsgIG1lYW4gdGhlIGZvcm1lci4NCj4gPiBSZWNvbW1lbmQg bWFraW5nIHRoaXMgY2xlYXJlciBhcyBzL2FueSBwYWNrZXQvYW55IEJhYmVsIHBhY2tldC8NCj4g DQo+IERvbmUuDQo+IA0KPiA+ICgyKSBTZWN0aW9uIDIsIFBlciB0aGUgcGFyYWdyYXBoLCDigJxC eSBpdHNlbGYsIHRoaXMgbWVjaGFuaXNtIGlzIHNhZmUNCj4gPiBhZ2FpbnN0IHJlcGxheSDigKbi gJ0sIHBsZWFzZSByZWl0ZXJhdGUgdGhhdCBmb3IgdGhlIGF0dGFjayBieSBDIHRvIHdvcms6DQo+ ID4gQSBhbmQgQiBtdXN0IGhhdmUgYm90aCBsb3N0IHN0YXRlOyB0aGF0IEMgaXMgcmVwbGF5aW5n IHBhY2tldHMgd2l0aCBQQw0KPiA+IHByZXZpb3VzbHkgc2VudCBieSBCIChlLmcuLCBuKzIpLg0K PiANCj4gT25seSBBIG5lZWRzIHRvIGhhdmUgbG9zdCBpdHMgc3RhdGUuICBDbGFyaWZpZWQuDQo+ IA0KPiA+ICgzKSBTZWN0aW9uIDQuMS4gIFBlciDigJxUaGUgbm9kZSB0YWtlcyB0aGUgY29uY2F0 ZW5hdGlvbiBvZiB0aGUNCj4gPiBwc2V1ZG8taGVhZGVyIGFuZCB0aGUgcGFja2V0IGluY2x1ZGlu ZyB0aGUgcGFja2V0IGhlYWRlciBidXQgZXhjbHVkaW5nDQo+ID4gdGhlIHBhY2tldCB0cmFpbGVy IChmcm9tIG9jdGV0IDAgaW5jbHVzaXZlIHVwIHRvIChCb2R5IExlbmd0aCArIDQpDQo+ID4gZXhj bHVzaXZlKeKAnSwgYXMgaW5wdXQgZm9yIHRoZSBITUFDLiAg4oCccGFja2V04oCdIGlzIHVzZWQg dG8gc29tZXRpbWVzDQo+ID4gbWVhbiBJUCBwYWNrZXQgYW5kIHNvbWV0aW1lcyBhIEJhYmVsIHBh Y2tldCBjYXJyaWVkIGluIGFuIElQIHBhY2tldC4NCj4gDQo+IENsYXJpZmllZC4NCg0KVGhhbmtz Lg0KDQo+ID4gKDQpIFNlY3Rpb24gMi4gIFRoaXMgc2VjdGlvbiBzdWdnZXN0cyB0aGF0IOKAnG9u ZSBvciBtb3JlIEhNQUNzIGNhbiBiZQ0KPiA+IGFwcGVuZGVkIHRvIHRoZSBwYWNrZXTigJ0uICBV bmRlciB3aGF0IGNvbmRpdGlvbnMgd291bGQgaXQgYmUgbW9yZSB0aGFuDQo+ID4gb25lPyAgV2hh dCBoYXBwZW5zIGlmIG9ubHkgc29tZSBvZiB0aGUgSE1BQ3MgYXJlIHZhbGlkPyAgSXMgdXNlIG9m IHRoZQ0KPiA+IHNhbWUga2V5IGFzc3VtZWQ/DQo+IA0KPiBUaGlzIHNlY3Rpb24gaXMgYSBjb25j ZXB0dWFsIG92ZXJ2aWV3LCBhbmQgaXMgb3B0aW1pc2VkIGZvciBlYXN5IHJlYWRhYmlsaXR5Lg0K PiBUaGUgZXhhY3QgZGV0YWlscyBhcmUgZ2l2ZW4gaW4gNC4zLiAgSSd2ZSBhZGRlZCB0aGUgcGFy YW50aGV0aWNhbCByZW1hcmsgIihvbmUNCj4gcGVyIGtleSkiLA0KDQpBaCwgSSBzZWUgaXQgbm93 IGluIFNlY3Rpb24gNC4zICBUaGFua3MgZm9yIHRoZSBwb2ludGVyLiAgVGhpcyB0ZXh0IGV4cGxh aW5zIHRoZSBpc3N1ZXMgb2YgYXJvdW5kIGtleXMgcHJvY2Vzc2luZy4gIEkgY291bGRuJ3QgZXhw bGljaXRseSBmaW5kIHRleHQgZXhwbGFpbmluZyB3aGVuIG11bHRpcGxlIEhNQUMgVExWcyBzaG91 bGQgYmUgc2VudC4gIFdoZXJlIHNob3VsZCBJIGJlIGxvb2tpbmc/DQoNCj4gYnV0IHJlZnVzZSB0 byBvdmVybG9hZCB0aGlzIHNlY3Rpb24gYW55IGZ1cnRoZXIuDQoNCk5vIHdvcnJpZXMuICBJJ20g bm90IHN1Z2dlc3RpbmcgdGhhdC4gIEZXSVcsIEkgdGhpbmsgdGhpcyBuYXJyYXRpdmUgc2VjdGlv biB3b3JrcyByZWFsbHkgd2VsbC4NCg0KPiA+ICg1KSBTZWN0aW9uIDQuMS4gIFRoZSBoYXNoIGFs Z29yaXRobSBhcHBlYXJzIHRvIGJlIG5lZ290aWF0ZWQvc2V0IG91dA0KPiA+IG9mIGJhbmQgKHJh dGhlciB0aGFuIG5lZ290aWF0ZWQpLiBUaGUgdGV4dCBzaG91bGQgZXhwbGljaXRseSBzdGF0ZSB0 aGF0DQo+IHNvbWV3aGVyZS4NCj4gDQo+IFNlY3Rpb24gMy4xLg0KDQpHb3QgaXQuICBUaGFua3Mu DQoNCj4gPiAoNikgU2VjdGlvbiA2LiAgUGVyIOKAnEluIHBhcnRpY3VsYXIsIHJlY2VwdGlvbiBv ZiBhIHBhY2tldCB3aXRoIG5vDQo+ID4gY29ycmVjdCBITUFDIGNyZWF0ZXMgbm8gbG9jYWwgc3Rh dGUgd2hhdHNvZXZlciAoU2VjdGlvbiA0LjMp4oCdLCB1bmxlc3MNCj4gPiB0aGlzIEhNQUMgdmVy aWZpY2F0aW9uIGlzIGhhcHBlbmluZyBvbiB0aGUgTklDLCB0aGlzIGRvZXNu4oCZdCBzZWVtDQo+ ID4gc3VmZmljaWVudGx5IHByZWNpc2UuICBUaGUg4oCcbm8gbG9jYWwgc3RhdGXigJ0gY2xhaW0g aXMgbGlrZWx5IHRydWUgb25seQ0KPiA+IGFzIGl0IHJlbGF0ZXMgdG8gdGhlIHRhYmxlcyBkYXRh IHN0cnVjdHVyZXMgZGVzY3JpYmVzIGluIFNlY3Rpb24gMy4NCj4gPiBIb3dldmVyLCB0aGUgSVAg YW5kIERUTFMgc3RhY2sgY2VydGFpbmx5IGhhdmUgdG8gYWNjb3VudCBmb3IgdGhlIHBhY2tldC4N Cj4gDQo+IFRoZXJlIGlzIG5vIERUTFMgaW4gdGhpcyBwcm90b2NvbC4NCg0KUmlnaHQuICBTb3Jy eSBhYm91dCB0aGF0LiAgSSBoYXZlIGJvdGggZG9jdW1lbnRzIG9wZW4uDQoNCj4gSSdtIGxlYXZp bmcgdGhpcyBzZW50ZW5jZSBhcyBpcyAtLSBhZnRlciB0cnlpbmcgaXQgb3V0LCBJIGRvbid0IHRo aW5rIHRoYXQNCj4gbWVudGlvbmluZyB0aGUgc21hbGwgYW1vdW50IG9mIHN0YXRlIGNhdXNlZCBi eSByZWNlcHRpb24gb2YgYSBVRFAgcGFja2V0DQo+IChhbiBORCBlbnRyeSkgaXMgaW5mb3JtYXRp dmUuDQoNCkknbSBub3QgdHJhY2tpbmcuICAiV2hhdHNvZXZlciIgaXMgYW4gYWJzb2x1dGUgc3Rh dGVtZW50LiAgQnkgYWxsIG1lYW5zIGNhdmVhdCB0aGUgc2VudGVuY2UgYnkgc2F5aW5nIG5vIGxv Y2FsIEJhYmVsIHN0YXRlIChvciBzb21ldGhpbmcgdG8gdGhhdCBlZmZlY3QpLg0KDQo+ID4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiA+IENPTU1FTlQ6DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gPiAoNykg U2VjdGlvbiAxIGVudW1lcmF0ZXMgYSBzZXJpZXMgb2YgYXR0YWNrcy4gIFRoZXNlIGFyZSBkaWZm ZXJlbnQNCj4gPiB0aGFuIHRoZSBvbmVzIGxpc3RlZCBpbiBTZWN0aW9uIDYgb2YgZHJhZnQtaWV0 Zi1iYWJlbC1yZmM2MTI2YmlzIGFuZA0KPiA+IFNlY3Rpb24gMSBvZiBkcmFmdC1pZXRmLWJhYmVs LWR0bHMuICBBcyBITUFDIGFuZCBEVExTIGFyZSBtaXRpZ2F0aW9ucw0KPiA+IGZvciBhdHRhY2tz IGluIGRyYWZ0LWlldGYtYmFiZWwtcmZjNjEyNmJpcywgdGhleSByZWFsbHkgc2hvdWxkIGJlDQo+ IGhhcm1vbml6ZWQuDQo+IA0KPiBJJ2xsIGxvb2sgYXQgbWFraW5nIHRoaXMgdW5pZm9ybSBiZXR3 ZWVuIHRoZSB0aHJlZSBkcmFmdHMuDQoNClRoYW5rcyBmb3IgY29vcmRpbmF0aW5nIGFjcm9zcyBk b2N1bWVudHMuICBZb3VyIGNhbGwsIGJ1dCBhbiBhbHRlcm5hdGl2ZSB0byBtYWtpbmcgdGhlIHRl eHQgbW9yZSB1bmlmb3JtIG1pZ2h0IGJlIHRvIGhhdmUgdGhlIEhNQUMgYW5kIERUTFMgZHJhZnRz IGp1c3QgcmVmZXJlbmNlIHRoZSBjb3JlIEJhYmVsIGRyYWZ0cyBpbiBzb21lIHdheS4NCg0KPiA+ ICg4KSBTZWN0aW9uIDEuICBQZXIgdGhlIOKAnHNwb29mIG9mIGEgbWFsZm9ybWVkIHBhY2tldOKA nSwgaG93IHdvdWxkIGFuDQo+ID4gSE1BQyBhZGRyZXNzIHRoaXM/ICBFdmVuIGFzc3VtaW5nIHRo YXQgYSBub2RlIGRpc2NhcmRzIHRoZSBtZXNzYWdlDQo+ID4gd2l0aG91dCBwcm9jZXNzaW5nIGlm IHRoZSBITUFDIGlzIGJhZCwgdGhpcyB3b3VsZCBzdGlsbCBiZSBhIHByb2JsZW0NCj4gPiBmcm9t IGEgbWFsaWNpb3VzIHBlZXIuDQo+IA0KPiBQbGVhc2UgZXhwbGFpbi4NCg0KVGhlIGluaXRpYWwg c2l0dWF0aW9uIEkgaGFkIGluIG1pbmQgd2FzIGlmIHRoZXJlIHdhcyBhIGNvbXByb21pc2VkIEJh YmVsIG5vZGUuICBJdCB3aWxsIGhhdmUgdGhlIGtleSB0byBwcm9kdWNlIGEgdmFsaWQgSE1BQyBv biB0aGUgY3JhZnRlZCBwYWNrZXQgdG8gY2F1c2UgdGhlIHBlZXIgQmFiZWwgbm9kZSB0byBwcm9j ZXNzIHRoZSBwYWNrZXQuDQoNCkFub3RoZXIgc2l0dWF0aW9uIHdoaWNoIHdvdWxkIG5vdCBpbnZv bHZlIGEgbWFsaWNpb3VzIEJhYmVsIG5vZGUgd2l0aCB0aGUga2V5IGlzIGEgbm9kZSBydW5uaW5n IGEgYnVnZ3kgQmFiZWwgaW1wbGVtZW50YXRpb24uICBJbWFnaW5lIHRoaXMgaW1wbGVtZW50YXRp b24gaGFzIHNvbWUga2luZCBvZiAoYnVmZmVyIG92ZXJmbG93KSB2dWxuZXJhYmlsaXR5IGluIHRo ZSByb3V0aW5lcyB3aGljaCBwYXJzZXMgdGhlIHBhY2tldCBwYXlsb2FkIHRvIGZpbmQgdGhlIEhN QUMgVExWLiAgSW4gdGhlIHdvcnN0IGNpcmN1bXN0YW5jZSwgdGhpcyBjb3VsZCBoeXBvdGhldGlj YWxseSBjb21wcm9taXNlIHRoZSBCYWJlbCBub2RlIGV2ZW4gYmVmb3JlIHRoZSBjb2RlIHRvIHZl cmlmaWVkIEhNQUMgYW5kIGNob29zZSB0byBkaXNjYXJkIHRoZSBwYWNrZXQgb3Igbm90IGlzIG1h ZGUuDQoNCj4gPiAoOSkgRWRpdG9yaWFsIG5pdHM6DQo+IA0KPiBGaXhlZCwgdGhhbmtzLg0KDQpU aGFua3MuDQoNClJlZ2FyZHMsDQpSb21hbg0KDQo+IC0tIEp1bGl1c3oNCg0K From nobody Thu Aug 8 15:12: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 BFA43120048; Thu, 8 Aug 2019 15:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebHH47Fq9rPD; Thu, 8 Aug 2019 15:12:26 -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 E56BF12002F; Thu, 8 Aug 2019 15:12:25 -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 x78MCKXZ024145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 9 Aug 2019 00:12:20 +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 x78MCLuZ014441; Fri, 9 Aug 2019 00:12:21 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C009D3080A; Fri, 9 Aug 2019 00:12:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id OuD2f2rLMcJd; Fri, 9 Aug 2019 00:12:21 +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 1F7B230807; Fri, 9 Aug 2019 00:12:21 +0200 (CEST) Date: Fri, 09 Aug 2019 00:12:21 +0200 Message-ID: <87tvarmhmi.wl-jch@irif.fr> From: Juliusz Chroboczek To: Alvaro Retana Cc: babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , The IESG , draft-ietf-babel-rfc6126bis@ietf.org In-Reply-To: References: <156518456148.8400.6644665367614468260.idtracker@ietfa.amsl.com> <87y303x17h.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 09 Aug 2019 00:12:20 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 09 Aug 2019 00:12:21 +0200 (CEST) X-Miltered: at korolev with ID 5D4C9E44.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D4C9E45.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4C9E44.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D4C9E45.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 : 5D4C9E44.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D4C9E45.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] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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: Thu, 08 Aug 2019 22:12:28 -0000 >> - §3.8.1.2: "A node MUST NOT increase its sequence number by more than 1 in >> response to a seqno request." > Ahh…I see. The increase MUST NOT be more than 1 per request. That part was > not clear to me. Ah, I think I see the problem: "in response" is ambiguous. I'll change it to "in reaction". >> - §4: "A Babel packet MUST be sent as the body of a UDP datagram, with >> network-layer hop count set to 1..." > This is a requirement for the sender. No receiver side check is required > or even possible. > Well, if the received TTL > 1 then the receiver knows something is wrong. Sure, but there's not much that this check buys you. > Please take a look at rfc5082 and consider using that mechanism instead. That's what ND does, right? It was considered (in the dark times before Babel was at IETF), and rejected. We behave like RIPng and OSPFv3: we use link-local addresses with a TTL of 1, and require checking that the source address of a received packet is link-local. At any rate, changing it at this stage would break compatibility with the installed base, which would be the death of Babel. >> - §4.6.10: "...if AE is 0 (in which case Plen MUST be 0 and Prefix is of >> length 0)." > No clarification is necessary here, just like no clarification is > necessary that for an IPv4 address, plen <= 32. > What do you mean by “no clarification is necessary”? I'll add a mention, but I believe it is redundant. No explicit mention that IPv4 routes with a prefix length of 57 are malformed and must be ignored. That's because IPv4 routes have a maximum prefix length of 32. Analoguously, AE 0 has a maximum prefix length of 0, and it si redundant to mention explicitly that AE 0 routes must not have a plen of 57. > I understand why the values are 0. What I’m asking for is what should the > receiver do if AE = 0 and Plen = n (any number other than 0)? It's a malformed prefix. You ignore the TLV, just like you would ignore a TLV that announces 1.2.3.4/57. >> - §4.6.10/§4.6.11: Is AE 3 a valid value in a request? I assume it isn't. >> What should a receiver do if AE = 3. > This case is allowed -- there's nothing in the protocol that disallows > announcing routes within fe80::/64. Of course, it would be silly to do so. > Silly doesn’t mean that someone won’t try it…and may end up filling up someone > else’s table with garbage. I think this is a vulnerability. Sure. I agree with you that a robust implementation of Babel should filter out fe80::/64, ff00::/8, as well as 0/8, 127.0.0.1/32 and 224.0.0/24. I just don't agree this filter needs to be hardwired in the protocol specification, it's an implementation detail and should be configurable. A case in point: babeld used to filter out Class-E addresses, and then this happened: https://alioth-lists.debian.net/pipermail/babel-users/2018-December/003492.html > As a point of reference, OSPFv3 doesn’t allow the advertisement of link-local > addresses as destinations. OSPFv3, like all link-state protocols, requires uniform filtering rules within an area, so it makes sense to standardise a default set of filtering rules. Babel, like any distance-vector protocol, has no such limitation (nodes with different filtering rules will interoperate just fine), so it's much more reasonable to leave filtering to the implementation. -- Juliusz From nobody Thu Aug 8 15:15:36 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 B3F4612003F for ; Thu, 8 Aug 2019 15:15:34 -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 NkpyLiijoCbK for ; Thu, 8 Aug 2019 15:15:33 -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 372C612002F for ; Thu, 8 Aug 2019 15:15:33 -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 x78MFNUS024748; Fri, 9 Aug 2019 00:15:23 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id DA79830825; Fri, 9 Aug 2019 00:15:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id BSQDE6sHR8T8; Fri, 9 Aug 2019 00:15:26 +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 0427030823; Fri, 9 Aug 2019 00:15:26 +0200 (CEST) Date: Fri, 09 Aug 2019 00:15:25 +0200 Message-ID: <87sgqbmhhe.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mahesh Jethanandani Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , "STARK, BARBARA H" , Babel at IETF In-Reply-To: <26F1A0CD-1FD2-456E-B295-8A60D93CF8E0@gmail.com> References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr> <87pnlhaixh.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E257961@GAALPA1MSGUSRBF.ITServices.sbc.com> <0B28A1FA-32B4-41E6-B646-C6A3907E9CCC@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114E258CF7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E25905B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87lfw3u52i.fsf@toke.dk> <110D87BA-BBA1-417B-9BC3-77BAD4B201D1@gmail.com> <87ftmbs92f.fsf@toke.dk> <26F1A0CD-1FD2-456E-B295-8A60D93CF8E0@gmail.com> 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]); Fri, 09 Aug 2019 00:15:23 +0200 (CEST) X-Miltered: at korolev with ID 5D4C9EFB.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4C9EFB.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 : 5D4C9EFB.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] Example configuration 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: Thu, 08 Aug 2019 22:15:35 -0000 > In the second example, the operator will define a babel-link-properties-obj, > call it “radio” or “wireless” or anything they want, and within that object set > the babel-interface-metric-algorithm (because it a mandatory parameter), and > set the babel-split-horizon to false. They will then associate “radio” object > with eth1 interface. Can the UI simulate the babel-link-properties-obj without it being part of the model? I.e. the operator defines a set of values called "radio", this set only exists within the UI. The operator then applies "radio" to a number of interfaces, and the frontend applies the individual values contained in the "radio" dictionary to each of those interfaces. Or does YANG require that the UI reflect the model? -- Juliusz From nobody Thu Aug 8 17:44: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 64D2E12006A; Thu, 8 Aug 2019 17:44:45 -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 pB-2gevXBqJk; Thu, 8 Aug 2019 17:44:42 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4DA120025; Thu, 8 Aug 2019 17:44:41 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id m8so56961214lji.7; Thu, 08 Aug 2019 17:44:41 -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=XxJA3A2JrbP4vEtUlU2SHRGYda7FUlXMiBM7SzvIoxg=; b=Ccx5bjmrVvBwjQov9UBMKI5O1WpQ40DBEo0X9knMIf+Zhd04yr33oEO8dbXZ24hmbX brrjTwcPlfIKaKf8cPIEB2icb56sKLEDcFke6CjMX3Ut+HW7ux+pQCr+zu/Pjtc6NpRR 4ttijyhJ5cEBvhTbQ6AqaasfDYTVEgLAypXB/mZt7SPl59l5/G5Fb1oZ3ZNlnDNK+4rO A7HiI5UBUXMlEVmjIuMgWccHaxSd4/MGbDQtyTr9h4KXNeWvN/M/riCM6XQgJML0zPwJ EwgtCfvgDU93yU6xFFegsmG/sWrhG6SL+U0La0QQlIFE2fiJQLWKH3NsFlhA9AxRh5Ve PssQ== 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=XxJA3A2JrbP4vEtUlU2SHRGYda7FUlXMiBM7SzvIoxg=; b=AOlB12B+Jf+8RIgJ6CwDoo9bDpnQSXOGssPclQxYHfdhKPVxcM2kmwg7UOuvxIPkc7 MMg1gbIO9oGk5LkycW6J4aFJvbhxVJ71T9pHjC3u5+uT/WOBpUDgTSLFWcigSWgTOIYd VA1KQ3mwgga3MWph+30VgfRHX1jy5xAaaJtCMXnHEcoSb/QZqs669Vak5HOifTsGrRV1 RwynqF7DfJ6DAZHZNiYxUkxvskRYV2vU52O11SYQ1V1kEhBs7zsssZWgt0zjjmjIhmPk qI+eIkex3KmoYRNh/0hfbAVFNYEPPKTs+YTKbxPN7UtPjzp6VaWf12e1VptaUtIu4LI6 EmkA== X-Gm-Message-State: APjAAAW0ihv3YHB7Kzqi+Z/pdbUL163l2QCfOyUe+NyKwuFjZcHGQBmi nZT7FM8souR/5kwC8XOSBXYC5X0JF1ZeZ+Dyzek= X-Google-Smtp-Source: APXvYqxykFZpP58UxaX2zeIH3vxmZ+xsu6u60kZnc3M01tyxSW2NX/ON7MHmtm5TBDaV8+AGvVPvpM6UmXCaM57nO6g= X-Received: by 2002:a2e:94cb:: with SMTP id r11mr9228088ljh.212.1565311479931; Thu, 08 Aug 2019 17:44:39 -0700 (PDT) MIME-Version: 1.0 References: <156520596444.8244.649940515091541992.idtracker@ietfa.amsl.com> In-Reply-To: <156520596444.8244.649940515091541992.idtracker@ietfa.amsl.com> From: David Schinazi Date: Thu, 8 Aug 2019 17:44:29 -0700 Message-ID: To: Roman Danyliw Cc: The IESG , draft-ietf-babel-dtls@ietf.org, Donald Eastlake , babel-chairs , Babel at IETF Content-Type: multipart/alternative; boundary="000000000000b9671b058fa47ad0" Archived-At: Subject: Re: [babel] Roman Danyliw's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT) 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, 09 Aug 2019 00:44:46 -0000 --000000000000b9671b058fa47ad0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for your review Roman! We've made changes on our git repository and will submit a revised draft shortly. Detailed responses inline. Thanks, David On Wed, Aug 7, 2019 at 12:26 PM Roman Danyliw via Datatracker < noreply@ietf.org> wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > (1) Section 1. These are different than the ones listed in Section 6 of > draft-ietf-babel-rfc6126bis and Section 1 of draft-ietf-babel-dtls. As > DTLS > and HMAC are mitigations for attacks in draft-ietf-babel-rfc6126bis, they > really should be harmonized. > We've fleshed out the text in draft-ietf-babel-rfc6126bis and kept the reference in draft-ietf-babel-dtls. (2) Section 2.1. Per =E2=80=9CImplementations MUST support authenticating = peers > against a local store of credentials=E2=80=9D, what does that credentiali= ng look > like? > Is it certificates, PSK, etc? What validation procedure is being used fo= r > this > authentication? > I'll respond to this point on Ben's DISCUSS since I think you're both askin= g for the same thing. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (3) Abstract. Per =E2=80=9CBabel does not contain any means =E2=80=A6 [t= o] protect > messages=E2=80=9D, > be more precise in the definition of protect (i.e., integrity and > confidentiality) > Agreed, fixed. > (4) Section 1.2. Per =E2=80=9CA comparison of Babel security mechanisms = and their > applicability can be found in [RFC6126bis]=E2=80=9D, where in > draft-ietf-babel-rfc6126bis does this comparison occur. The references t= o > HMAC > and TLS are in a single paragraph in in Section 6/Security Considerations > which > roughly reiterate the one sentence statements written here. > We've fleshed out the text in draft-ietf-babel-rfc6126bis and kept the reference in draft-ietf-babel-dtls. > (5) Section 2.1. Per =E2=80=9CWhen a node receives a new DTLS connection= , it MUST > verify that the source IP address is an IPv6 link-local address =E2=80=A6= =E2=80=9D, what > happens if IPv4 is in use? > This was an oversight. The text now also discusses IPv4. > (6) Section 2.1. Per =E2=80=9CNodes MUST only negotiate DTLS version 1.2 = or > higher=E2=80=9D, > this is stricter than RFC7525 cited in the Security Consideration later i= n > the > draft. That=E2=80=99s fine, but please reiterate that in Section 5. > Done. (7) Section 2.6 Suggest being clearer that this is a deployment not an > implementation issue. s/Implementations MAY implement both Babel over > DTLS and > unprotected Babel./ /A node MAY run both Babel over DTLS and unprotected > Babel./ > Agreed. We added your new sentence but also kept the old one since both are true. > (8) Section 2.6, Per =E2=80=9CHowever, accepting unprotected Babel packet= s =E2=80=A6 loses > the > security properties of Babel over DTLS=E2=80=9D. This seems misleading. = The > security > properties of =E2=80=9CBabel over DTLS=E2=80=9D as a protocol are stated = in Section 1.2. > In > this section there is discussion of the security properties of the node > (and > the resulting neighbor table). These are different. The issue seems to = be > that a node is building a neighbor table with updates from sources which > need > to be trusted to different degrees. > Agreed. We've reworked that paragraph. > (9) Section 5. Per =E2=80=9CConfidential interaction between two Babel p= eers > requires > Datagram Transport Layer Security (DTLS) with a cipher suite offering > confidentiality protection. The guidance given in [RFC7525] MUST be > followed > to avoid attacks on DTLS.=E2=80=9D, the first sentence is true, but incom= plete, in > that > we=E2=80=99d also want cipher suites with a strong key exchange algorithm= , etc. > Section 4.2 of RFC7525, which is cited as a MUST, provides a list of > recommended ciphers suites. Do we need this first sentence? > Fair enough, We've removed that sentence. (10) Editorial > -- Section 2.1. Expand =E2=80=9CIHU=E2=80=9D on first use > Done -- Section 3. Nit. s/ciphers/ciphersuites/ Done --000000000000b9671b058fa47ad0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your review Roman! We've made changes = on our git repository
<https://github.com/jech/babel-drafts> and will submit a re= vised draft shortly.

Detailed responses inline= .

Thanks,
David

On Wed, Aug 7, 2019 at 12= :26 PM Roman Danyliw via Datatracker <noreply@ietf.org> wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) Section 1. These are different than the ones listed in Section 6 of
draft-ietf-babel-rfc6126bis and Section 1 of draft-ietf-babel-dtls.=C2=A0 A= s DTLS
and HMAC are mitigations for attacks in draft-ietf-babel-rfc6126bis, they really should be harmonized.

We've = fleshed out the text in=C2=A0draft-ietf-babel-rfc6126bis and kept the refer= ence
in draft-ietf-babel-dtls.

(2) Section 2.1.=C2=A0 Per =E2=80=9CImplementations MUST support authentica= ting peers
against a local store of credentials=E2=80=9D, what does that credentialing= look like?
Is it certificates, PSK, etc?=C2=A0 What validation procedure is being used= for this
authentication?

I'll respond to thi= s point on Ben's DISCUSS since I think you're both asking
for the same=C2=A0thing.
=C2=A0
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(3) Abstract.=C2=A0 Per =E2=80=9CBabel does not contain any means =E2=80=A6= [to] protect messages=E2=80=9D,
be more precise in the definition of protect (i.e., integrity and
confidentiality)

Agreed, fixed.
=C2=A0
(4) Section 1.2.=C2=A0 Per =E2=80=9CA comparison of Babel security mechanis= ms and their
applicability can be found in [RFC6126bis]=E2=80=9D, where in
draft-ietf-babel-rfc6126bis does this comparison occur.=C2=A0 The reference= s to HMAC
and TLS are in a single paragraph in in Section 6/Security Considerations w= hich
roughly reiterate the one sentence statements written here.

We've fleshed out the text in=C2=A0draft-ietf= -babel-rfc6126bis and kept the reference
in draft-ietf-babel-dtls= .
=C2=A0
(5) Section 2.1.=C2=A0 Per =E2=80=9CWhen a node receives a new DTLS connect= ion, it MUST
verify that the source IP address is an IPv6 link-local address =E2=80=A6= =E2=80=9D, what
happens if IPv4 is in use?

This was an = oversight. The text now also discusses IPv4.
=C2=A0
(6) Section 2.1. Per =E2=80=9CNodes MUST only negotiate DTLS version 1.2 or= higher=E2=80=9D,
this is stricter than RFC7525 cited in the Security Consideration later in = the
draft.=C2=A0 That=E2=80=99s fine, but please reiterate that in Section 5.

Done.=C2=A0

(7) Section 2.6=C2=A0 Suggest being clearer that this is a deployment not a= n
implementation issue. s/Implementations MAY impleme= nt both Babel over DTLS and
unprotected Babel./ /A node MAY run both Babel over DTLS and unprotected Ba= bel./

Agreed. We added your new sentenc= e but also kept the old one since both are true.
=C2=A0
(8) Section 2.6, Per =E2=80=9CHowever, accepting unprotected Babel packets = =E2=80=A6 loses the
security properties of Babel over DTLS=E2=80=9D.=C2=A0 This seems misleadin= g.=C2=A0 The security
properties of =E2=80=9CBabel over DTLS=E2=80=9D as a protocol are stated in= Section 1.2.=C2=A0 In
this section there is discussion of the security properties of the node (an= d
the resulting neighbor table).=C2=A0 These are different.=C2=A0 The issue s= eems to be
that a node is building a neighbor table with updates from sources which ne= ed
to be trusted to different degrees.

Agr= eed. We've reworked that paragraph.
=C2=A0
(9) Section 5.=C2=A0 Per =E2=80=9CConfidential interaction between two Babe= l peers requires
Datagram Transport Layer Security (DTLS) with a cipher suite offering
confidentiality protection.=C2=A0 The guidance given in [RFC7525] MUST be f= ollowed
to avoid attacks on DTLS.=E2=80=9D, the first sentence is true, but incompl= ete, in that
we=E2=80=99d also want cipher suites with a strong key exchange algorithm, = etc.
Section 4.2 of RFC7525, which is cited as a MUST, provides a list of
recommended ciphers suites.=C2=A0 Do we need this first sentence?

Fair enough, We've removed that sentence.=C2= =A0

(10) Editorial
-- Section 2.1.=C2=A0 Expand =E2=80=9CIHU=E2=80=9D on first use

Done=C2=A0

-- Section 3.=C2=A0 Nit. s/ciphers/ciphersuites= /

Done
--000000000000b9671b058fa47ad0-- From nobody Fri Aug 9 04:38:38 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 A5008120168; Fri, 9 Aug 2019 04:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 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, HTML_OBFUSCATE_05_10=0.26, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 jeZGydAqGiKM; Fri, 9 Aug 2019 04:38:34 -0700 (PDT) Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (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 9539512016A; Fri, 9 Aug 2019 04:38:33 -0700 (PDT) Received: by mail-ed1-x541.google.com with SMTP id s49so59861281edb.1; Fri, 09 Aug 2019 04:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=T+e2O2YgOg2CeIsFY4wTK+kMP3rFyNpMgbpWNPTpCZ0=; b=HfnbAZf+cs81TyyUsQOG993j3qHq1n4AAr940ljeUcVUkmpzlxXzgZ0gGQ3hEvsQBX b5ZZbP2GfMcaptMUSc1ZKwjmoiLCw+dgKfYA2ynjVLPZXGPJh9i3AsjBsT7VuB2GB3Se 6pTya2BjFA0DNtEDIJz3ylU9wkuisYzTQDVNWuVBTvU3vDsiOwd/+cvIGx/KvAaNrtVR SA9Y2ee4gxfG4pXjxO/yaHOn7Nek+reLwVxCVLJpZxC31Ttsczww1SV+fJosPxGhpiB5 WddGH4e2Y+4+7Nlm1SxQCR4r3alXmR9qmHfOb85OrkfeYRkFmZf3LcuBuHK1I6XbFW5q CAkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=T+e2O2YgOg2CeIsFY4wTK+kMP3rFyNpMgbpWNPTpCZ0=; b=OXu4ra7aSYCiJGxu7jH3qWSw+y1Gwl0EZY4baHGrGn+o0Aigbjf5A/vhl3uFPBHjoG rrr36QJUQcTIAITbeU0lce6B+9Cn9gh+lFpLunRJT7HbNNR3wBQJ4HvytcrwugK/Nje5 10N5pwKOYroF9xJLc4qDww61CIAqDQG5BoFfPRuRhgYP5Ddl4UBbIKq1T22SgHP1nSBf o1IKT6ZqOLbek1pxd1aBjIz2BSSimLkg/CEW5OQeqDQxopsnLsTjKR8z9DgZSCwDZXo4 9c1ZooVuzb7Z1GFOmj8YU9r1cK84Qqq/ldhmxh7rJ2m3DLBSZPXe2BpdmGAiiB9Pt8q6 HElQ== X-Gm-Message-State: APjAAAX7BEsK54Txdbf7sN+VR5cpMTfeEZgJ5GntCl/a8WorZmpWKmSD maxL0F9gdESCBYSUTngLxGyTwWaCi02+LXpN/iI= X-Google-Smtp-Source: APXvYqyjGLm20ak5d26m95DS+grlo9jp7FPuUqyQwbK8rG0rAykfPFuy1vTyczIdaxfanAzaeELdP8alEf/LxHv/dOU= X-Received: by 2002:a17:906:505:: with SMTP id j5mr17895000eja.261.1565350712164; Fri, 09 Aug 2019 04:38:32 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Aug 2019 06:38:31 -0500 From: Alvaro Retana In-Reply-To: <87tvarmhmi.wl-jch@irif.fr> References: <156518456148.8400.6644665367614468260.idtracker@ietfa.amsl.com> <87y303x17h.wl-jch@irif.fr> <87tvarmhmi.wl-jch@irif.fr> MIME-Version: 1.0 Date: Fri, 9 Aug 2019 06:38:31 -0500 Message-ID: To: Juliusz Chroboczek Cc: The IESG , draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org Content-Type: multipart/alternative; boundary="00000000000025cad2058fad9ddb" Archived-At: Subject: Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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, 09 Aug 2019 11:38:37 -0000 --00000000000025cad2058fad9ddb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On August 8, 2019 at 6:12:24 PM, Juliusz Chroboczek (jch@irif.fr) wrote: ... > Please take a look at rfc5082 and consider using that mechanism instead. That's what ND does, right? It was considered (in the dark times before Babel was at IETF), and rejected. We behave like RIPng and OSPFv3: we use link-local addresses with a TTL of 1, and require checking that the source address of a received packet is link-local. But that doesn=E2=80=99t cover IPv4 properly. Are you saying that if both an IPv4 and IPv6 network-layer is available then IPv6 should be preferred? I think that would be a good statement to make. At any rate, changing it at this stage would break compatibility with the installed base, which would be the death of Babel. Not if you make it optional. >> - =C2=A74.6.10: "...if AE is 0 (in which case Plen MUST be 0 and Prefix = is of >> length 0)." > No clarification is necessary here, just like no clarification is > necessary that for an IPv4 address, plen <=3D 32. > What do you mean by =E2=80=9Cno clarification is necessary=E2=80=9D? I'll add a mention, but I believe it is redundant. No explicit mention that IPv4 routes with a prefix length of 57 are malformed and must be ignored. That's because IPv4 routes have a maximum prefix length of 32. Analoguously, AE 0 has a maximum prefix length of 0, and it si redundant to mention explicitly that AE 0 routes must not have a plen of 57. I brought this comment up because the text says that =E2=80=9CPlan MUST be = 0=E2=80=9D. There are (I think) two different cases: - Plen doesn=E2=80=99t make sense, IPv4/57, for example. This is clearly m= alformed. - Plen doesn=E2=80=99t matter. In the case of AE =3D 0 in a Route Request,= does it really matter what Plen is set to? IOW, if the request is ignored then no routes are provided=E2=80=A6 Going back to the use of MUST. I think consistency is important. In this case, there=E2=80=99s no explicit text saying that for AE =3D 1 Plen MUST b= e <=3D32. I then think it is ok to not make normative the setting for AE =3D 0. s/Plen MUST/Plen must >> - =C2=A74.6.10/=C2=A74.6.11: Is AE 3 a valid value in a request? I assum= e it isn't. >> What should a receiver do if AE =3D 3. > This case is allowed -- there's nothing in the protocol that disallows > announcing routes within fe80::/64. Of course, it would be silly to do so= . > Silly doesn=E2=80=99t mean that someone won=E2=80=99t try it=E2=80=A6and = may end up filling up someone > else=E2=80=99s table with garbage. I think this is a vulnerability. Sure. I agree with you that a robust implementation of Babel should filter out fe80::/64, ff00::/8, as well as 0/8, 127.0.0.1/32 and 224.0.0/24= . I just don't agree this filter needs to be hardwired in the protocol specification, it's an implementation detail and should be configurable. A case in point: babeld used to filter out Class-E addresses, and then this happened: https://alioth-lists.debian.net/pipermail/babel-users/2018-December/003492.= html > As a point of reference, OSPFv3 doesn=E2=80=99t allow the advertisement o= f link-local > addresses as destinations. OSPFv3, like all link-state protocols, requires uniform filtering rules within an area, so it makes sense to standardise a default set of filtering rules. Babel, like any distance-vector protocol, has no such limitation (nodes with different filtering rules will interoperate just fine), so it's much more reasonable to leave filtering to the implementation. Ok. While I still think that not filtering out link-local routes is a vulnerability, please at least mention it: =E2=80=9CAn implementation may c= onsider filtering useless information=E2=80=A6or should provide configuration filte= rs=E2=80=A6. These are the considerations to do so (or not): potential too much garbage= =E2=80=A6=E2=80=9D Thanks! Alvaro. --00000000000025cad2058fad9ddb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On August 8, 2019 at 6:12:24 PM, Juliusz Chroboc= zek (jch@irif.fr) wrote:

...
> Please take a lo= ok at rfc5082 and consider using that mechanism instead.=C2=A0

That's what ND does, right?=C2=A0

It was considered (i= n the dark times before Babel was at IETF), and=C2=A0
rejected. We behave like RIPng and OSPFv3: we us= e link-local addresses=C2=A0with a TTL of 1, and require checking that the source address of=C2=A0
a received packet is link-loc= al.=C2=A0

But that doesn=E2=80=99t cover IPv4 properly.

Are= you saying that if both an IPv4 and IPv6 network-layer is available then I= Pv6 should be preferred?=C2=A0 I think that would be a good statement to ma= ke.

<= div>At any rate, changing it at this stage would break compatibility with t= he=C2=A0
installed base, wh= ich would be the death of Babel.=C2= =A0

Not if you make it optio= nal.


=
>> - =C2=A74.6.10: "...if AE is 0 (in which case= Plen MUST be 0 and Prefix is of=C2= =A0
>> length 0)."=C2=A0

> No clarification is necessary here, just like n= o clarification is=C2=A0
&g= t; necessary that for an IPv4 address, plen <=3D 32.=C2=A0

> What do you mean by =E2=80=9Cno= clarification is necessary=E2=80=9D?= =C2=A0

I'll add a mention, but I believe it is redundant.= =C2=A0

No explicit ment= ion that IPv4 routes with a prefix length of 57 are=C2=A0
malformed and must be ignored. That's be= cause IPv4 routes have a maximum=C2= =A0
prefix length of 32.=C2= =A0

Analoguously, AE 0 has a maximum prefix length of 0, and = it si redundant=C2=A0
to me= ntion explicitly that AE 0 routes must not have a plen of 57.

I brought this comment up because the text says = that =E2=80=9CPlan MUST be 0=E2=80=9D.

There are (I think) two differ= ent cases:

- Plen doesn=E2=80=99t make sense, IPv4/57, for example.= =C2=A0 This is clearly malformed.

- Plen doesn=E2=80=99t matter.=C2= =A0 In the case of AE =3D 0 in a Route Request, does it really matter what = Plen is set to?=C2=A0 IOW, if the request is ignored then no routes are pro= vided=E2=80=A6

Going back to the use of MUST. =C2=A0 I think consiste= ncy is important.=C2=A0 In this case, there=E2=80=99s no explicit text sayi= ng that for AE =3D 1 Plen MUST be <=3D32.=C2=A0 I then think it is ok to= not make normative the setting for AE =3D 0. =C2=A0s/Plen MUST/Plen must


>> - =C2=A74.6.10/=C2=A74.6.11: Is AE 3 a valid value in = a request? I assume it isn't.=C2= =A0
>> What should a receiver do if AE =3D 3.=C2=A0

> This case is allowed -- t= here's nothing in the protocol that disallows=C2=A0
> announcing routes within fe80::/64. Of co= urse, it would be silly to do so.=C2= =A0

> Silly doesn=E2=80=99t mean that someone won=E2=80=99= t try it=E2=80=A6and may end up filling up someone=C2=A0
> else=E2=80=99s table with garbage. I thi= nk this is a vulnerability.=C2=A0

Sure. I agree with you that a robust implementation of Babel sho= uld=C2=A0
filter out fe80::= /64, ff00::/8, as well as 0/8, 127.0.0.1/32= and 224.0.0/24.=C2=A0
= I just don't agree this filter needs to be hardwired in the protocol=C2=A0
specification, it's= an implementation detail and should be configurable.=C2=A0

A case in point: babeld used to filter= out Class-E addresses, and then=C2= =A0
this happened:=C2=A0

https://alioth-lists.debian.net/pipermail/babe= l-users/2018-December/003492.html= =C2=A0

> As a point of reference, OSPFv3 doesn=E2=80=99t a= llow the advertisement of link-local= =C2=A0
> addresses as destinations.=C2=A0

OSPFv3, like all link-state protocols, requ= ires uniform filtering rules=C2=A0
within an area, so it makes sense to standardise a default set of=C2=A0
filtering rules. Babel= , like any distance-vector protocol, has no such=C2=A0
limitation (nodes with different filtering rule= s will interoperate just=C2=A0=
fine), so it's much more reasonable to leave filtering to the imple= mentation.=C2=A0

Ok.=C2=A0 While I still think that not filtering= out link-local routes is a vulnerability, please at least mention it: =E2= =80=9CAn implementation may consider filtering useless information=E2=80=A6= or should provide configuration filters=E2=80=A6. These are the considerati= ons to do so (or not): potential too much garbage=E2=80=A6=E2=80=9D

<= br>

Thanks!

Alvaro.

--00000000000025cad2058fad9ddb-- From nobody Fri Aug 9 05:39:59 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 E19BB120140; Fri, 9 Aug 2019 05:39:56 -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 wvaYpMtetKGZ; Fri, 9 Aug 2019 05:39:55 -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 B13601200D6; Fri, 9 Aug 2019 05:39:54 -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 x79CdnlE010037; Fri, 9 Aug 2019 14:39:49 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 618B932C5F; Fri, 9 Aug 2019 14:39:52 +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 0ht-qr0XwmoK; Fri, 9 Aug 2019 14:39:51 +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 7A8B932C5D; Fri, 9 Aug 2019 14:39:49 +0200 (CEST) Date: Fri, 09 Aug 2019 14:39:48 +0200 Message-ID: <87k1bm8qcr.wl-jch@irif.fr> From: Juliusz Chroboczek To: Alvaro Retana Cc: The IESG , draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: References: <156518456148.8400.6644665367614468260.idtracker@ietfa.amsl.com> <87y303x17h.wl-jch@irif.fr> <87tvarmhmi.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 [194.254.61.138]); Fri, 09 Aug 2019 14:39:49 +0200 (CEST) X-Miltered: at korolev with ID 5D4D6995.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4D6995.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 : 5D4D6995.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] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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, 09 Aug 2019 12:39:57 -0000 Would adding the following informative appendix solve the problem? Are you going to complain that it's not referenced in the document body? Appendix C. Route filtering Route filtering is a procedure where an instance of a routing protocol either discards some of the routes announced by its neighbours or learns them with a metric that is higher than what would be expected. Like all distance-vector protocols, Babel has the ability to apply arbitrary filtering to the routes it learns, and implementations of Babel that apply different sets of filtering rules will interoperate without causing routing loops. The protocol's ability to perform route filtering is a consequence of the definitions in Section 3.5.2: Babel can use any metric that is strictly monotonic, including one that assigns an infinite metric to a selected subset of routes. (See also Section 3.8.1, where requests for nonexistent routes are treated in the same way as requests for routes with infinite metric.) It is not in general correct to learn a route with a metric smaller than the one it was announced with, or to replace a route's destination prefix with a longer one. Doing either of those may cause persistent routing loops. Route filtering is a useful tool, since it allows fine-grained tuning of the routing decisions made by the routing protocol. Accordingly, some implementations of Babel implement a rich configuration language for configuring route filtering. At a minimum, these implementations allow selecting routes for filtering by incoming interface and by destination prefix. In order to limit the consequences of misconfiguration, Babel implementations provide a reasonable set of default filtering rules even when th don't allow configuration of filtering by the user. At a minimum, they discard routes with a destination prefix in fe80::/64, ff00::/8, 127.0.0.1/32, 0.0.0.0/32 and 224.0.0.0/8. From nobody Fri Aug 9 05:51:34 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 4B405120140; Fri, 9 Aug 2019 05:51:32 -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, UNPARSEABLE_RELAY=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 Cbl5mD3j1oS6; Fri, 9 Aug 2019 05:51:30 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 6C70A120131; Fri, 9 Aug 2019 05:51:30 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id w13so94933906eds.4; Fri, 09 Aug 2019 05:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=gxvEb3bX65tO8LwTPBHHSQucFl3CAw4NOlnctOU3p1s=; b=VX+MA4fIHGNmaNNySg6tN+6zWyyt3dc7LpEmYfJh0NX2AZWtrouTGfGn8CQvEp7kfP eUjCvc0utbZN5AGI1KM27h+uGWk0Bp0gQe9B7D7whD/1iuJdh2mWFGaQQclXR0JkngsQ 2tY+gY67EAKQ9L2LFDculJdDeqEpgRlceTY4lZf9d90JkrmY0W9AAYv9uiR5tW8gaN70 8Kmc3uLTeBAnTXz4K1D87ggBfWX9zTUCWuuGNeMuRHvACeyxQzm3UHH0icBW5yePsKMu OBuHXX5hELCKRsQK8FP5I2l8kJu9Nkzpgxtfuu3L19vB2Gt2xiKoHtoGZS40iJHYguTq pDrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=gxvEb3bX65tO8LwTPBHHSQucFl3CAw4NOlnctOU3p1s=; b=VHVlRRV3WC936kXbnpvUPK2H+7E1ClQYKkJ40UKDvkSHlwXlyte5naS5G03s2Ky1Zc oITsZM3eSF0nlmjizmBh9I4KDtk1U/D57mSk2iyJURHQGWVWvFiimeEGtQsCrFhUqE6d wo16mDjODdOhkNuuAPB1tDOI/L1edgAKLlHUflaku58DXBPmtHNyH/TsfJCZmHXSBsN+ osyXHH731I2uQfbIgJFBiRrsMlgZdcdJspIrfTGt4NPJjIZiOlJk6kF2WGCslg1zJUUY HGpOLS/8xC6V7qfF/0GufPOcbjCS0gQhmdN5h6d4S2k9S4UUSoQ+q+aDKlE7cvxinnsN UUDQ== X-Gm-Message-State: APjAAAXDni1knYvuATabZRCU/yDICo3sqoS647F9fAUgFBokKUFWUl96 Y8MmKPIBjFoUpwTOQvINeUHjxqloGtMnKjir9cs= X-Google-Smtp-Source: APXvYqxsj/Y2pjPes65iRs+uDVgpo89q+mK2pSWZhUTDTOYnT0ZTfFFgaFNttj+Tn9XcmWWyDWl6M1JhYyg6fSNoKoU= X-Received: by 2002:aa7:ca49:: with SMTP id j9mr22528254edt.148.1565355089035; Fri, 09 Aug 2019 05:51:29 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Aug 2019 05:51:28 -0700 From: Alvaro Retana In-Reply-To: <87k1bm8qcr.wl-jch@irif.fr> References: <156518456148.8400.6644665367614468260.idtracker@ietfa.amsl.com> <87y303x17h.wl-jch@irif.fr> <87tvarmhmi.wl-jch@irif.fr> <87k1bm8qcr.wl-jch@irif.fr> MIME-Version: 1.0 Date: Fri, 9 Aug 2019 05:51:28 -0700 Message-ID: To: Juliusz Chroboczek Cc: babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , The IESG , draft-ietf-babel-rfc6126bis@ietf.org Content-Type: multipart/alternative; boundary="000000000000078591058faea288" Archived-At: Subject: Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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, 09 Aug 2019 12:51:33 -0000 --000000000000078591058faea288 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On August 9, 2019 at 8:39:52 AM, Juliusz Chroboczek (jch@irif.fr) wrote: Would adding the following informative appendix solve the problem? Yes, it would address the filtering part. Are you going to complain that it's not referenced in the document body? Yes. I think that you could either reference it in one of the sections mentioned in it=E2=80=A6or maybe you just want to provide a information about the app= endices somewhere in the Introduction. Either way would be fine for me. Thanks! Alvaro. --000000000000078591058faea288 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On August 9, 2019 at 8:39:52 AM, Juliusz Chroboczek (jch@irif.fr) wrote:

Would adding the following informative appendix solve the problem?=C2=A0
<= /blockquote>

Yes, it would address the fil= tering part.

<= span>
Are=C2=A0you going to complain that= it's not referenced in the document body?=C2=A0

Yes.

I think tha= t you could either reference it in one of the sections mentioned in it=E2= =80=A6or maybe you just want to provide a information about the appendices = somewhere in the Introduction.=C2=A0 Either way would be fine for me.

Thanks!

Alvaro.



--000000000000078591058faea288-- From nobody Fri Aug 9 06:54:52 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 CF04D120077; Fri, 9 Aug 2019 06:54: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 HlE53fekqoxj; Fri, 9 Aug 2019 06:54:49 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316FF120043; Fri, 9 Aug 2019 06:54:49 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x79Dsh3i007815; Fri, 9 Aug 2019 15:54:43 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id D2531335D1; Fri, 9 Aug 2019 15:54:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id cjCK2hzMjoSg; Fri, 9 Aug 2019 15:54:45 +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 D7808335CC; Fri, 9 Aug 2019 15:54:41 +0200 (CEST) Date: Fri, 09 Aug 2019 15:54:41 +0200 Message-ID: <87h86q8mvy.wl-jch@irif.fr> From: Juliusz Chroboczek To: Alvaro Retana Cc: The IESG , draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: References: <156518456148.8400.6644665367614468260.idtracker@ietfa.amsl.com> <87y303x17h.wl-jch@irif.fr> <87tvarmhmi.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 09 Aug 2019 15:54:43 +0200 (CEST) X-Miltered: at korolev with ID 5D4D7B23.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4D7B23.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 : 5D4D7B23.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] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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, 09 Aug 2019 13:54:51 -0000 > It was considered (in the dark times before Babel was at IETF), and > rejected. We behave like RIPng and OSPFv3: we use link-local addresses > with a TTL of 1, and require checking that the source address of > a received packet is link-local. > But that doesn’t cover IPv4 properly. > Are you saying that if both an IPv4 and IPv6 network-layer is available then > IPv6 should be preferred? I think that would be a good statement to make. Yes, that has been the WG consensus for a long time (all implementations known to me run in that mode). However we only wrote it down recently at Eric Vyncke's prompting (my bad). Section 3.1: The exclusive use of IPv6 for all control traffic is RECOMMENDED, -- Juliusz From nobody Fri Aug 9 11:06:49 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 25560120041; Fri, 9 Aug 2019 11:06:40 -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 Op6142MBpWpP; Fri, 9 Aug 2019 11:06: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 52F96120019; Fri, 9 Aug 2019 11:06:37 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x79I6WCh024666; Fri, 9 Aug 2019 20:06: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 286CE34416; Fri, 9 Aug 2019 20:06: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 ER_Edcxnr_VJ; Fri, 9 Aug 2019 20:06: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 B13C73440F; Fri, 9 Aug 2019 20:06:31 +0200 (CEST) Date: Fri, 09 Aug 2019 20:06:31 +0200 Message-ID: <877e7m8b88.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mirja =?ISO-8859-1?Q?K=FChlewind?= Cc: "The IESG" , draft-ietf-babel-rfc6126bis@ietf.org, d3e3e3@gmail.com, babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> References: <156517737995.8257.5538554979559246700.idtracker@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=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]); Fri, 09 Aug 2019 20:06:32 +0200 (CEST) X-Miltered: at korolev with ID 5D4DB628.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4DB628.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 : 5D4DB628.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] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 09 Aug 2019 18:06:41 -0000 Dear Mirja, The replies in this mail concern -13, which I haven't submitted yet (still working on it). My working copy is on https://github.com/jech/babel-drafts > DISCUSS: > ---------------------------------------------------------------------- > I have a couple of points that needs addressing before this document can move > forward. Most of them should the straight forward to address. My main point is > about network load. I agree, that's an important point, especially when running over 802.11. > Note that RFC8085 recommend a minimal interval of 3 seconds which > probably is also a good hard boundary here. As mentioned in my previous mail, RFC 8085 deals with UDP packets sent across the Internet. What we are discussing here is a link-local protocol, where there are no intermediary routers to congest. Thus, on robust link technologies (such as Ethernet) it is enough to ensure that we don't overwhelm sender and receiver queues; on more fragile technologies (such as 802.11), we need to ensure we don't overwhelm the MAC. In short, if the 3 second limitation is to be enforced, then OSPF cannot exist. > More concretely I think there are these cases that need more guidance: I agree. I've added a short discussion of packet pacing at the end of 3.1, and I refer to it at suitable places. > - Section 3.7.2. (Triggered Updates) advises to send a message multiple > times for redundancy in case of loss. 5 and 2 are mentioned as example > values. Please provide a normative default value and a normative maximum > value here. Moreover the spec should also require to pace out these > messages and avoid "tail loss" by overloading the local queue. (See > also section 3.8.2.1) Done for the normative max and recommendation to avoid tail loss. I haven't made the default values normative. > - Section 3.8.1.1. (Route Requests) says: "Full route dumps MAY be > rate-limited, especially > if they are sent over multicast." > I think this should at least be a SHOULD. Agreed. > Please also provide further guidance about to appropriately rate limit > and think about other cases where a recommend to implement rate-limiting > could make sense. Done. > - In section 4.1.1 the update interval needs a lower limit (e.g. 3 seconds) I strongly disagree. Sub-second convergence after a mobility event is required in some networks. To put things into perspective, a full-size Ethernet frame is able to carry over 60 Babel updates (assuming 50% IPv4 + 50% IPv6 and reasonably successful IPv6 prefix compression). Thus, in a network with 1000 routes, a full update occupies 16 packets. With an update interval of 0.1 seconds, we are sending an average of 160 packets per second, which is very reasonable for a number link technologies. > and a recommend default value would be could as well (Note that there > are other part in section 3 where the update value is discussed as > well). Appendix B. > - Section 3.8.2.4. mentions network load when requests are sent to all > neighbours after reboot. Please provide more guidance about how to pace out > these requests. I've removed this section altogether. > - Section 3.8.1.2. (Seqno Requests) discusses hop count values but > could maybe also give more concrete guidance. I would assume that the > hop count value of the current active route is usually know. Maybe that > knowledge could be used to pick an appropriate value? The hop-count is a last resort mechanism intended to save your network from catastrophic failure in case everything goes horribly wrong. It never triggers in normal usage. Any value will do. I've made that clear, and suggested the value 64 (non-normatively). > Two other smaller discuss points/questions/comments: > 1) Sec 4.6.8. (Next Hop): If I interpret this correctly, address compression is > allowed for the next hop field and therefore this TLV would actually not be > self-terminating. What do I miss? Address compression is only allowed in Update TLVs (the only compression mechanism allowed in NH is AE 3). I've clarified that. > 2) This document needs to specify a registration policy also for each of the > already existing registries given this document obsoletes RFC7557. Ok. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > 1) While this point might not raise discuss-level, it would probably also be > good to provide more concrete advise on how to implement jitter: Sec 3.1.: “ Expanded this in 3.1. Removed from Section 4. > 2) Sec 4.1.2. (Router-Id) should probably state again that the router-id is > assumed to be unique within a domain. No, this section only defines the datatype, which is carried by Router-ID TLVs. It does not define the local Router-ID field, which is part of the data structures. > 3) Sec 4: “The most-significant bit of the sub-TLV, called the mandatory bit, > indicates how to handle unknown sub-TLVs.” This has been clarified. > I would recommend to also indicate this bit in the image. The mandatory bit is part of the TLV Type (see the discussion with Alvaro), this has been clarified. I am not aware of a way to describe that in a packet diagram. > 4) Sec 4.4: “If a TLV has a self-terminating format, then it MAY allow > a sequence of sub-TLVs to follow the body.” Initially I wasn’t quite > sure what you wanted to say here. I guess you say that the length would > indicate a larger value that needed for the body and therefore a subTLV > might be present? I recommend to clarify this here a bit. Done. Thanks, -- Juliusz From nobody Fri Aug 9 13:07: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 6B76112015B; Fri, 9 Aug 2019 13:07:08 -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 HskY9W6Wo7Gk; Fri, 9 Aug 2019 13:07: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 BF70512006B; Fri, 9 Aug 2019 13:07:05 -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 x79K7033022253; Fri, 9 Aug 2019 22:07: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 71D6F347F7; Fri, 9 Aug 2019 22:07:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id cDjxYJJUw2kU; Fri, 9 Aug 2019 22:07: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 C7AA8347F5; Fri, 9 Aug 2019 22:07:01 +0200 (CEST) Date: Fri, 09 Aug 2019 22:07:01 +0200 Message-ID: <875zn685ne.wl-jch@irif.fr> From: Juliusz Chroboczek To: Alvaro Retana Cc: "The IESG" , draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156518456148.8400.6644665367614468260.idtracker@ietfa.amsl.com> References: <156518456148.8400.6644665367614468260.idtracker@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=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 09 Aug 2019 22:07:00 +0200 (CEST) X-Miltered: at korolev with ID 5D4DD264.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4DD264.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 : 5D4DD264.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] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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, 09 Aug 2019 20:07:09 -0000 Dear Alvaro, This mail concerns your Discuss point (A) and your Comments. Discuss points (B) and (C) have been discussed in an earlier mail. > (A) Clear Defaults and Operational Guidance > While I appreciate Babel's flexibility in terms of the ability to use > different strategies, I believe that both defaults and clear guidance > should be provided. Given that "not all...strategies will give good > results" and that in most cases these are listed as possible choices, > I don't think that this document "has resolved known design choices" > [BCP9/rfc7127]. The cost/metric computation and route selection > specially concern me because I believe that a robust/clear specification > is at the heart of any routing protocol. After thinking it over very carefully, it is with utmost sadness that I must disagree with you on this latter point. This document does three things: - it makes normative requirements where the issues are well-understood (e.g. strict monotnicity of the metric); - in all cases, it suggests algorithms that are known to work well; - it gives a statement of caution to the adventurous implementer. This gives enough information to the implementer to implement something that works, while not unduly restricting the possibilities of future experimentation. Compare this with RFC 4271, which proudly states: BGP can support any policy conforming to the destination-based forwarding paradigm. even though many such policies will cause persistent oscillations. (By no fault of theirs -- determining statically if a given set of BGP route policies gives rise to oscillations is an open research problem.) (FWIW, early drafts of RFC 6126 used to describe cost and metric computation normatively. It was Joel Halpern who convinced me to move them to an informative appendix, and to give more flexibility in the core protocol. The results we have obtained with RTT-sensitive routing show that he was entirely right.) > (A1) Clear defaults. For example, Appendix B talks about constants/default > values. I would assume that, given the existing experience, that the values > there are probably sensible defaults. Is that not the case? I've rewritten Appendix B in the way you suggest, and added references to it in the document. > (A2) Operational Considerations. Given that Babel can be (and is) used > in different environments, I would like to see guidance to operators as > they deploy the protocol in their networks. An example of the type of > discussion I would like to see expanded is: "a mobile node that is low > on battery may choose to use larger time constants (hello and update > intervals, etc.) than a node that has access to wall power" (1.1). I've expanded Appendix B. > (B) Error Handling Discussed in a previous mail. > (C) Mandatory Bit Discussed in a previous mail. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > (a) 3.1 introduces the term "urgent TLVs". The whole paragraph has been rewritten, and the terminology unified throughout. > (b) 3.2.2: "SHOULD NOT increment its sequence number (seqno) > spontaneously" When it is ok to increase the seqno spontaneously? It is always ok. The worst it can do is prematurely make some unselected routes unfeasible at downstream nodes, which they will recover from. This is intended as a warning to the implementer familiar with DSDV where seqnos are incremented periodically. > IOW, why not use MUST NOT? This document is fairly consistent in its usage of MUST NOT and SHOULD NOT. You MUST NOT break the network. You SHOULD NOT do harmless but pointless things. > I think it would be better if there was a clear indication of when the > seqno is increased. Scanning the rest of the document, it seems that > those indications are in place. I'm fairly positive this is the case. Starvation avoidance is a crucial part of the algorithm. > (c) There seems to be no specific explanation of how the timers are handled, > what happens when they expire, etc. I have added some precisions. > The only place where hello timers are mentioned is in Appendix A.1...but > that is just an example. This is expected. Hellos are used to compute link cost, and cost computation is in Appendix A. > (d) 3.7.2 includes two instances of "SHOULD make a reasonable attempt > at ensuring that all [reachable] neighbours receive this > update/retraction". What does making "a reasonable attempt" mean? This is expanded in the next two paragraphs. > How can that be Normatively enforced? If an implementation implements one of the two algorithms, it complies. If an implementation implements a different algorithm that can be shown to have the same effect, it complies. If an implementation doesn't implement any algorithm that has a similar effect, it doesn't comply. > (e) 3.7.2 > Finally, a node MAY send a triggered update when the metric for a > given prefix changes in a significant manner, due to a received > update, because a link's cost has changed, or because a different > next hop has been selected. 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). > How much is "a significant manner"? What about "a minor fluctuation"? > Are the modifiers (next hop change, for example) the only conditions to > take into account, or are they just examples of when these > significant/minor changes may occur? I'm not sure what you're aiming for here. This enumeration lists a set of events for which an implementer might be tempted to send a triggered update, and states that it's a bad idea. > How can these terms be Normatively enforced? In order to comply, an implementation: - doesn't send an update when the metric changes by 1 and nothing else changes; - doesn't send an update when NH changes and nothing else changes; - doesn't send an update when seqno changes and nothing else changes. The boundary between minor and major fluctuation is left to the implementation, which is okay, since in any case that's only a MAY. The intent being that it's reasonable to send a triggered update when the metric fluctuation is large enough to indicate that the route has probably become unusable. If the implementation doesn't follow the MAY, then the fluctuation will be propagated by the next periodic update. > (f) 3.8.1.1: "When a node receives a wildcard route request, it SHOULD > send a full route table dump." When is it ok to not send a full table dump? It is always okay to not send one. The protocol does not rely on full route dump requests. The ability to make a full route dump makes debugging easier, and the feature has very little implementation cost (since you already have code to send a full dump). > IOW, why is MUST not used? Because you might be rate limiting the updates. I've added a sentence to that effect. > (g) 3.8.2.1: "a node SHOULD repeat such a request a small number of times if > no route becomes feasible within a short time." What does "a small number of > times" and "within a short time" mean? How can that be Normatively enforced? > Please be specific. Suggested values are given in Appendix B: Request timeout: initially 2 seconds, doubled every time a request is resent, up to a maximum of three times. I've added a forward ref. > (h) 4.6.9: "Omitted...that should be taken from a preceding Update TLV > in the same address family with the Prefix flag set." What if that > Update TLV is not in the packet? That's part of error handling, your Discuss above. > (i) Security Considerations We've rewritten this section. > (j) Are the appendices intended to be Normative or not? I'm assuming the > answer is no...but I can base that only on the references in the text to > Appendix A.*, pointing to them as examples. I've removed all normative language from the appendices. > What about the others? They are not even referenced in the text. Appendices A and B are referenced. I've added a reference to what was Appendix C (now D). > - Appendix D defines a "stub implementation". This is also valuable > information. But...there's no reference from the text, and Normative language > is used... This is not references in the main body. I don't see a good way to reference it. I've removed all normative language from this appendix, since all the properties stated are consequences of the protocol definition. > Why is this type of implementation (which I would think might be > relatively common) not normative? This appendix doesn't add any new requirements -- it merely describes what is in our opinion the smallest useful implementation that complies with the body of the spec. It is a convenience for the implementer. > - Appendix E simply points to the sample implementation. I've removed the whole appendix. > (k) "The length of..." is used everywhere in the document, but no units are > mentioned. Added suitable boilerplate. > (l) 4: s/SHOULD attempt to maximise the size of the packets/SHOULD maximise > the size of the packets Done. > (m) 4.1.3: The description of AE 1 and 2 says that "Compression is allowed." > -- but it looks like the only place where it can happen is in an Update. It > might be nice to indicate that...and avoid indicating that compression is not > allowed where it can't be done anyway. Done. > (n) rfc8126 should be a Normative reference. Done. > (o) Please include Informative references to rfc6126 and rfc7557. Done. > (p) s/Bellman-Ford protocol/Bellman-Ford algorithm Done. > (q) 2.4: Include an Informative reference to AODV (rfc3561). Done. > (r) 2.4: "if A has selected B as its successor" This is the only place where > "successor" is used. For clarity, perhaps use a different word/description. Done. -- Juliusz From nobody Fri Aug 9 14:02:10 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 57A4D120142; Fri, 9 Aug 2019 14:02: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 TIYE_fRRhIhC; Fri, 9 Aug 2019 14:01: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 BA9EC1200FA; Fri, 9 Aug 2019 14:01:58 -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 x79L1m7N031249; Fri, 9 Aug 2019 23:01:50 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C72AC34957; Fri, 9 Aug 2019 23:01:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id uFENr9tTSAgD; Fri, 9 Aug 2019 23:01:50 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C5AA134955; Fri, 9 Aug 2019 23:01:49 +0200 (CEST) Date: Fri, 09 Aug 2019 23:01:49 +0200 Message-ID: <871rxu8342.wl-jch@irif.fr> From: Juliusz Chroboczek To: Roman Danyliw Cc: "The IESG" , draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156520559749.8305.9821179209918519561.idtracker@ietfa.amsl.com> References: <156520559749.8305.9821179209918519561.idtracker@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=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]); Fri, 09 Aug 2019 23:01:50 +0200 (CEST) X-Miltered: at korolev with ID 5D4DDF3C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4DDF3C.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 : 5D4DDF3C.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] Roman Danyliw's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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, 09 Aug 2019 21:02:02 -0000 Dear Roman, Thank your for your review. > (1) Per “Any attacker can misdirect data traffic by advertising routes with a > low metric or a high seqno.”: -- Can the "any" of the attacker be scoped any > more? This whole discussion has been rewritten. I believe that it now meets most of your concerns. > -- Note that because Babel messages aren’t encrypted any on-path attacker can > gather the routing topology (Note that Babel is a distance-vector protocol, the full topology is not available. From a security point of view, this can be seen as a good or a bad thing, depending on your perspective.) > (3) Per “HMAC is simpler and does not depend on DTLS, and therefore its use is > RECOMMENDED whenever both mechanisms are applicable”, can you explain this > recommendation and the circumstances where “both mechanisms are applicable”. > If one wants to ensure confidentiality, it can’t be realized with HMAC – they > aren’t equal. Fully agreed, we must be clear on this point. > (4) Per “The privacy issues that this causes can be mitigated somewhat > by using randomly chosen router-ids and randomly chosen IP addresses, > and changing them periodically, who’s IP address should be randomly > chosen the Babel node or the mobile device? It is assumed in this paragraph that the mobile device is a Babel node. It makes no sense otherwise. > (5) Appendix C: Per the last paragraph, “The packet trailer is intended to > carry cryptographic signatures …”, to what security mechanism is that > referring? Where is that defined? Babel-HMAC is the only currently defined mechanism that uses the trailer. If the user community ends up accepting the notion of inline security (as opposed to using a secure link layer or DTLS), then I expect other such mechanisms to appear. > (6) Appendix D: Is the stub implementation guidance normative? It's not, I've removed all normative language. > If so, will it satisfy all of the RFC2119 language in this document? >From the point of view of an outside observer, yes -- it cannot be distinguished from a compliant implementation just by looking at the packets it sends or the routes it selects. >From the point of view of the letter of the specification, obviously not. The specification says that you maintain a source table which you use to evaluate the feasibility condition. In the case of a stub implementation, the feasibility condition is known to be always true, so the stub implementation doesn't bother maintaining a source table. > (7) Appendix E. Please explicitly state that the sample implementation is > non-normative. This appendix has been removed. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > (8) Section 1.1. What is a “network diameter”? Calculated how? http://mathworld.wolfram.com/GraphDiameter.html > (9) Section 3.6. Recommend avoiding the phrase “protocol’s correctness” I've replaced it with "algorithm's correctness". > (10) Section 3.7.2, Per the guidance to send updates with > acknowledgement requests to a small, but not a large number of > neighbors. Is there guidance to provide on what is a large number? Unfortunately not. It will depend on the relative cost of multicast vs. unicast, and the expected packet loss. Coming up with a suitable algorithm to determine that dynamically would be a fun little project. > (11) Section 3.8.2.4. Is there any guidance on what a “small number of > multicast” requests constitutes? This section has been removed. > (12) Section 4. Per “Both the source and destination UDP port are set to a > well-known port number”, the same one? Yes. That's implied by "both". > (14) Section 4.6.4. What are the properties needed for this nonce? None that are defined in this specification. The only requirement is that it will be returned in the Ack. If an implementation can guarantee that it has at most one ack request in flight to a given peer, then it can clear the nonce. If an implementation wants multiple in-flight requests, it can use a sequential counter. It can also use it for some smart algorithm that encodes information about the packet being acked in the nonce, but I cannot conceive of any such algorithm offhand. The choice of ack has no security implications, since spoofing a bogus route is a much more effective way of attacking an unsecured Babel implementation. > (15) Section 6. Per the concern that Babel packets might escape into the wild > and “No such natural protection exists when Babel packets are carried over > IPv4”, doesn’t setting the TTL=1 per Section 4 help? The concern here is about off-link attackers sending us packets. It's not too difficult to choose a TTL that leads to the TTL being 1 on reception. That's why this document does not require checking the TTL on reception, just the sender's address. > (16) Appendix D: Per “Nonetheless, in some very constrained environments, such > as … abacuses”, what does it mean to implement Babel on an analog device? Abacuses are digital. > (17) Did the WG consider renaming the title of thisdraft “Babel Routing > Protocol v2” (as this is a distinct and new protocol)? No, we didn't, as this would only create confusion. Both RFC 6126 and this document use version 2 in the header; see my reply to Alvaro about details. (Versions 0 and 1 were early variants that have never been documented. Version 0 was a hybrid link-state/distance-vector protocol. Version 1 was fairly close to the protocol in RFC 6126, but had a design flaw that caused it to fail in the presence of parallel edges in the adjacency multigraph.) > (18) Editorial. s/Babel never/Babel does not/ Disagree, this states an invariant. > -- Section 1.2 Editorial. s/Babel does impose/Babel imposes/ Disagree, the auxiliary is used to stress a weakness of Babel. > -- Section 2. Editorial. s/venerable RIP/RIP/ Disagree, I see RIP like a distinguished gentleman with a white beard, the kind you tend to meet at IETF meetings. > -- Section 2.3. Editorial. s/It is well known that a/A/ Disagree, the subclause is used to stress that this is a standard property, not something that we claim to have discoverd. > -- Section 4.1.2. Typo. s/ones ones/ones/ Done, thanks. -- Juliusz From nobody Fri Aug 9 14:21:27 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 117E012006B; Fri, 9 Aug 2019 14:21:26 -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 RvOV0kp2pVTl; Fri, 9 Aug 2019 14:21:22 -0700 (PDT) Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (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 CEE02120118; Fri, 9 Aug 2019 14:21:21 -0700 (PDT) Received: by mail-lj1-x243.google.com with SMTP id 15so1520641ljr.9; Fri, 09 Aug 2019 14:21:21 -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=ijkje3Ju+wwWtmQOTXZa+5JQxb8EjZ8XMAX9WiPrqTs=; b=AbMtxjdycQ5a3RtZlZZcKvrSgivco1lFaDi+OSkn3RSZ/PGtQ0/83U1cTKBFmKxTIU PcI39s0paiJ7YWxJQcuN+LXzM2mdBkBa+dzKlfBqe38wOfeNvAPAWPcSnlYqtn1TRVZ/ 8iQ8xng3HJ0JdE4Sa3cXK6d4jKNdAqiCHwR3bpA8OZsJiK9aatqCD+TArw3NUgFxeHp6 Luv3+0N0q3JkSPg+NoCc2YqQZzNymgOTrtbh1gFPxXKvLj6O6aWpDEtr2lpXZVZbmX9h zc5u3CQih2QO/rt9KstjQcWTXJfV4+7HLbJaBL6P7ONKVG72GJfQ2d2h1fD25N36LknH 8Wfw== 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=ijkje3Ju+wwWtmQOTXZa+5JQxb8EjZ8XMAX9WiPrqTs=; b=IPhCH0b4np+JfHM1WfZ2zhgCybhaTgDpyg+J5GL0gSUTFMqwsvFZ3ghJ+5UyLGQmO8 QXpdcfRen9gamJPx3p+HHXGluplODNG8Ti9+jRj1xyn7sIBEpW/ia8D3pfORNcNfYySj GfOE48D9Q5S/fcDML921SawuGobx4aNbrVOF6PZ82Fb0PQWDeuHUsBXrdHcm5qZyZLXO bWsh1hhHYxu1rGWKZm6/QmpHj4zhbH7/FmPi/TstFG8X+2W7B8ewPXxnsV2/aUFUKFqr yRZhMVjA1Vqccy3lZQAIJIDVQSLV/1G8qRHvPqSPGkc6WeusIxn7xyuMfUjuh23uRUUj mqbA== X-Gm-Message-State: APjAAAVVq+AtIT+nj5Fws/KrgNyaL2gPyID/WpGZK/MBUVrrzYifVIrO YhnjUYwrqbUO7ac8nbKmVNEdNmA4aQ4buT/hM6A= X-Google-Smtp-Source: APXvYqx1ueNyYqJeouyykli+TFeHqUOHhGdDyQPy9d6ynsB1xk63aQQ46sz7gOs1hafRnwY+1Isx3FKESZkNdP7pEkE= X-Received: by 2002:a2e:81c3:: with SMTP id s3mr2918356ljg.70.1565385679801; Fri, 09 Aug 2019 14:21:19 -0700 (PDT) MIME-Version: 1.0 References: <156521337799.8333.13258734665763149206.idtracker@ietfa.amsl.com> In-Reply-To: <156521337799.8333.13258734665763149206.idtracker@ietfa.amsl.com> From: David Schinazi Date: Fri, 9 Aug 2019 14:21:08 -0700 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-babel-dtls@ietf.org, Donald Eastlake , babel-chairs , Babel at IETF Content-Type: multipart/alternative; boundary="000000000000619167058fb5c185" Archived-At: Subject: Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT) 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, 09 Aug 2019 21:21:26 -0000 --000000000000619167058fb5c185 Content-Type: text/plain; charset="UTF-8" Thanks for your review Ben! We've incorporated your comments into our working copy and we'll publish a revised draft shortly. Detailed responses inline. Thanks, David On Wed, Aug 7, 2019 at 2:29 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I support Roman's Discuss point (1) (and basically cover the same as his > (2) below). > > Let's have a discussion about (DTLS) identity. > Section 2.1 says that we use mutual authentication and that > implementations "MUST support authenticating peers against a local store > of credentials"; also that "if a node receives a new DTLS connection > from a neighbour to whom it already has a connection, the node MUST NOT > discard the older connection until it has completed the handshake of the > new one and validated the identity of the peer". But how does this > authentication occur, and what constitutes the identity of the peer. We > will frequently have (D)TLS consumers cite RFC 6125 and say that (e.g.) > DNS-ID or SRV-ID must match the name obtained in some fashion. But for > Babel, we are authenticating routers -- router identity is usually in > the form of just an IP address on a loopback interface! Are we expected > to get certificates that certify IP addresses as identity, or use some > sort of PSK or password-based TLS authentication? (The last two are not > really compatible with the "MUST send a CertificateRequest", BTW.) Raw > public keys? I think we can give a more clear picture of how to build a > secure system. > Our intent in this document was to leave the complex question of identity to deployment profiles. For example, the homenet working group is interested in potentially using Babel over DTLS to protect routing inside the home. The idea there being that each router you buy has an identity, and then there would be some process to let your existing routers know about the new router you just bought. However, homenet has not yet solved how to do this. They may choose to use self-signed certificates and develop a provisioning mechanism to share them. They could also decide to use raw keys. Our goal with the present draft is to define how one runs Babel over DTLS. I imagine that if homenet decides to use Babel over DTLS, they'll publish another document explaining how to manage identities. I would prefer not having this document be too prescriptive with regards to identities, because that could prevent some deployment profiles. But I'm happy to add guidance for writers of deployment profiles. Do you have thoughts on what such guidance would look like? That said I've removed the mention of CertificateRequest since as you pointed out that's too restrictive. Relatedly, once DTLS authenticates an identity, what level of > authorization checks are performed? Are we still in a single > authorization domain, where any router that authenticates as being part > of a given domain is implictily authorized to be a babel peer and convey > any and all routing information? > It's a single authentication domain. We've added text in the document to clarify that. > We should also give some guidance on ciphers and algorithms where we > discuss the DTLS details (BCP 195 is probably the safest bet here, even > if it's a little in need of an update). > We have a reference to BCP195, did you have anything else in mind? > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 1.2 > > The protocol described in this document protects Babel packets with > DTLS. As such, it inherits the features offered by DTLS, notably > authentication, integrity, replay protection, confidentiality and > asymmetric keying. It is therefore expected to be applicable in a > > replay protection is not an inherent feature of DTLS, so I suggest > "optional replay protection" to emphasize that an implementation of > babel may need to explicitly configure it. > We already have this text in section 2.1: Nodes MUST use DTLS replay protection to prevent attackers from replaying stale information. Is there something we should add to that? > There exists another mechanism for securing Babel, namely Babel HMAC > authentication [BABEL-HMAC]. HMAC only offers basic features, namely > authentication, integrity and replay protection with a small number > of symmetric keys. A comparison of Babel security mechanisms and > > Even the authentication is limited, as it is group authentication, not > true per-entity authentication. > That is true. We've fleshed out the text in RFC6126bis that compares both mechanisms. > Section 2.1 > > information last longer. If a node receives a new DTLS connection > from a neighbour to whom it already has a connection, the node MUST > NOT discard the older connection until it has completed the handshake > of the new one and validated the identity of the peer. > > (Does the validated identity of the peer have to match the one from the > previous handshake?) > It doesn't. Conceptually there is a single security domain so as long as the credentials are valid you're free to stomp on previous connections from other IPs. > Section 2.3 > > I agree with the RtgDir reviewer that unprotected (multicast) Hellos are > at risk of tampering by an attacker, who could drop them or modify the > seqno/interval, for DoS purposes. > I see the text about use of multicast Hellos for discovery and the > acknowledgment that an out-of-band neighbor discovery mechanism may be > available. Are there any such discovery mechanism under development? > There aren't, at least not as standards. This text is there to accommodate implementations/deployments that already have a non-standard out-of-band discovery mechanism. > Regardless, I think we should consider mandating/suggesting (to some > strength; maybe SHOULD is enough) the use of protected unicast Hellos > instead of just stating that nodes can either rely on multicast or send > protected unicast Hellos. When unicast (protected) Hellos are in use, > even tampering with multicast Hellos will not be enough to cause a DoS > attack, since a node must be detected as down on both unicast and > multicast to be considered gone. (Of course, a sufficiently powerful > attacker can still just drop all traffic and cause DoS.) > The issue here is that multicast and unicast don't behave the same way at the link layer. We've found empirically that ETX is a great way to assess wireless link quality but that requires sending hellos over multicast. https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-12#appendix-A.2.2 That said, we added the following text to security considerations: Babel over DTLS allows sending multicast Hellos unprotected; attackers can therefore tamper with them. For example, an attacker could send erroneous values for the Seqno and Interval fields, causing bidirectional reachability detection to fail. While implementations MAY use multicast Hellos for link quality estimation, they SHOULD also emit protected unicast Hellos to prevent this class of denial-of-service attack. Section 2.4 > > Note that receiving an unprotected packet can still be used to > discover new neighbours, even when all TLVs in that packet are > silently ignored. > > Is this going to cause a lot of spurious DTLS handshake attempts if we > ever end up with a babel-dtls implementation adjacent to a > classic-babel-only implementation? Is there any rate limiting on that? > Good point. We've added a "Simultaneous operation of both Babel over DTLS and unprotected Babel on a Network" section containing: If Babel over DTLS and unprotected Babel are both operated on the same network, the Babel over DTLS implementation will receive unprotected multicast Hellos and attempt to initiate a DTLS connection. These connection attempts can be sent to nodes that only run unprotected Babel, who will not respond. Babel over DTLS implementations SHOULD therefore rate-limit their DTLS connection attempts to avoid causing undue load on the network. > Section 2.5 > > Do we want to talk about the potential consequences of an attacker > arbitrarily delaying valid content (to justify the need for a timeout)? > The section currently states: This attack could be used to make a node believe it has bidirectional reachability to a neighbour even though that neighbour has disconnected from the network. What more did you have in mind? > Section 2.6 > > A node MAY allow configuration options to allow unprotected Babel on > some interfaces but not others; this effectively gives nodes on that > interface the same access as authenticated nodes, and SHOULD NOT be > done unless that interface has a mechanism to authenticate nodes at a > lower layer (e.g., IPsec). > > I'm unhappy that this SHOULD NOT is not a MUST NOT, but cannot quite > justify making it a Discuss-level point. > The rationale for the SHOULD was to allow deployments that we hadn't thought of. I think the text makes it clear what will go wrong if you do this. > Section 3 > > IP, UDP and DTLS. Nodes MUST NOT send Babel packets larger than the > attached interface's MTU adjusted for known lower-layer headers (at > least UDP and IP) or 512 octets, whichever is larger, but not > exceeding 2^16 - 1 adjusted for lower-layer headers. Every Babel > speaker MUST be able to receive packets that are as large as any > > Aren't these requirements just duplicating what's in 6126bis? We > probably don't need to repeat the normative language, at least, even if > there's a desire to repeat the content. > These requirements mimic the ones in 6126bis, but with the addition of DTLS in the list of underlying layers that add overhead. This section references the appropriate section in 6126bis so readers can compare them if need be. > Note that distinct DTLS connections can use different ciphers, which > can have different amounts of overhead per packet. Therefore, the > > nit: I think the intention here was "per-packet overhead", though the > statement is true as currently written (due to variable length padding > for block ciphers). > I'm not sure I understand, are you saying there is a difference between the terms "overhead per packet" and "per-packet overhead" ? > Section 5 > > The RFC 7525 ref is probably better spelled as BCP 195, and arguably > moved earlier in the text (i.e., where I mentioned it previously). > Done. > A malicious client might attempt to perform a high number of DTLS > handshakes with a server. As the clients are not uniquely identified > by the protocol and can be obfuscated with IPv6 temporary addresses, > a server needs to mitigate the impact of such an attack. Such > > nit: they're not uniquely identified by the protocol *until the > handshake completes* -- our requirement for mutual authentication will > cause all valid clients to be identified. However, the DoS risk does > not require the client to let the handshake complete, so the core > statement here remains valid. It may also be worth mentioning > "Slowloris"-style attacks that keep handshake state active for as long > as possible to increase resource consumption. > Agreed. Added "until the handshake completes" and reference to Slowloris. Section 6.2 > > DTLS-CID needs to be normative if it is a MAY-level feature. (See > https://www6.ietf.org/iesg/statement/normative-informative.html .) > I've replaced "MAY" with "could" and kept this informative. DTLS-CID is not an optional feature of Babel over DTLS, it's just an informative pointer to a DTLS feature. (I don't want to make this normative as that would create a blocking dependency on publication of that draft.) > RFC 7525 (i.e., BCP 195) definitely needs to be normative, as a > MUST-level requirement! > Good catch, done. --000000000000619167058fb5c185 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your review Ben! We've inc= orporated your comments into our
working copy <https://github.com/jech/babel= -drafts> and we'll publish
a revised draft shortly. De= tailed responses inline.

Thanks,
David


On Wed, Aug 7, 2019 at 2:29 PM Benjamin Kaduk via Datatracker = <noreply@ietf.org<= /a>> wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I support Roman's Discuss point (1) (and basically cover the same as hi= s
(2) below).

Let's have a discussion about (DTLS) identity.
Section 2.1 says that we use mutual authentication and that
implementations "MUST support authenticating peers against a local sto= re
of credentials"; also that "if a node receives a new DTLS connect= ion
from a neighbour to whom it already has a connection, the node MUST NOT
discard the older connection until it has completed the handshake of the new one and validated the identity of the peer".=C2=A0 But how does th= is
authentication occur, and what constitutes the identity of the peer.=C2=A0 = We
will frequently have (D)TLS consumers cite RFC 6125 and say that (e.g.)
DNS-ID or SRV-ID must match the name obtained in some fashion.=C2=A0 But fo= r
Babel, we are authenticating routers -- router identity is usually in
the form of just an IP address on a loopback interface!=C2=A0 Are we expect= ed
to get certificates that certify IP addresses as identity, or use some
sort of PSK or password-based TLS authentication?=C2=A0 (The last two are n= ot
really compatible with the "MUST send a CertificateRequest", BTW.= )=C2=A0 Raw
public keys?=C2=A0 I think we can give a more clear picture of how to build= a
secure system.

=
The idea there being that each router you buy has an identity, and the= n there
would be some process to let your existing routers know a= bout the new
router you just bought. However, homenet has not yet= solved how to do this.
They may choose to use self-signed certif= icates and develop a provisioning
mechanism to share them. They c= ould also decide to use raw keys. Our
goal with the present draft= is to define how one runs Babel over DTLS.
I imagine that if hom= enet decides to use Babel over DTLS, they'll publish
another = document explaining how to manage identities.

I wo= uld prefer not having this document be too prescriptive with regards
<= div>to identities, because that could prevent some deployment profiles.
But I'm happy to add guidance for writers of deployment profiles= . Do you
have thoughts on what such guidance would look like?

That said I've removed the mention of Certificate= Request since as you
pointed out that's too restrictive.

Relatedly, once DTLS authenticates an identity, what level of
authorization checks are performed?=C2=A0 Are we still in a single
authorization domain, where any router that authenticates as being part
of a given domain is implictily authorized to be a babel peer and convey any and all routing information?

It'= ;s a single authentication domain. We've added text in the document to = clarify that.
=C2=A0
We should also give some guidance on ciphers and algorithms where we
discuss the DTLS details (BCP 195 is probably the safest bet here, even
if it's a little in need of an update).

=
We have a reference to BCP195, did you have anything else in mind?
=C2=A0
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1.2

=C2=A0 =C2=A0The protocol described in this document protects Babel packets= with
=C2=A0 =C2=A0DTLS.=C2=A0 As such, it inherits the features offered by DTLS,= notably
=C2=A0 =C2=A0authentication, integrity, replay protection, confidentiality = and
=C2=A0 =C2=A0asymmetric keying.=C2=A0 It is therefore expected to be applic= able in a

replay protection is not an inherent feature of DTLS, so I suggest
"optional replay protection" to emphasize that an implementation = of
babel may need to explicitly configure it.

<= div>We already have this text in section 2.1:
=C2=A0 =C2=A0 Nodes= MUST use DTLS replay protection to prevent attackers
=C2=A0 =C2= =A0 from replaying stale information.=C2=A0
Is there somethin= g we should add to that?
=C2=A0
=C2=A0 =C2=A0There exists another mechanism for securing Babel, namely Babe= l HMAC
=C2=A0 =C2=A0authentication [BABEL-HMAC].=C2=A0 HMAC only offers basic feat= ures, namely
=C2=A0 =C2=A0authentication, integrity and replay protection with a small n= umber
=C2=A0 =C2=A0of symmetric keys.=C2=A0 A comparison of Babel security mechan= isms and

Even the authentication is limited, as it is group authentication, not
true per-entity authentication.

That is= true. We've fleshed out the text in RFC6126bis that compares both mech= anisms.
=C2=A0
Section 2.1

=C2=A0 =C2=A0information last longer.=C2=A0 If a node receives a new DTLS c= onnection
=C2=A0 =C2=A0from a neighbour to whom it already has a connection, the node= MUST
=C2=A0 =C2=A0NOT discard the older connection until it has completed the ha= ndshake
=C2=A0 =C2=A0of the new one and validated the identity of the peer.

(Does the validated identity of the peer have to match the one from the
previous handshake?)

It doesn't. Co= nceptually there is a single security domain so as long as
the cr= edentials are valid you're free to stomp on previous connections
<= div>from other IPs.
=C2=A0
Section 2.3

I agree with the RtgDir reviewer that unprotected (multicast) Hellos are at risk of tampering by an attacker, who could drop them or modify the
seqno/interval, for DoS purposes.
I see the text about use of multicast Hellos for discovery and the
acknowledgment that an out-of-band neighbor discovery mechanism may be
available.=C2=A0 Are there any such discovery mechanism under development?<= br>

There aren't, at least not as stand= ards. This text is there to accommodate
implementations/deploymen= ts that already have a non-standard out-of-band
discovery mechani= sm.
=C2=A0
Regardless, I think we should consider mandating/suggesting (to some
strength; maybe SHOULD is enough) the use of protected unicast Hellos
instead of just stating that nodes can either rely on multicast or send
protected unicast Hellos.=C2=A0 When unicast (protected) Hellos are in use,=
even tampering with multicast Hellos will not be enough to cause a DoS
attack, since a node must be detected as down on both unicast and
multicast to be considered gone.=C2=A0 (Of course, a sufficiently powerful<= br> attacker can still just drop all traffic and cause DoS.)

The issue here is that multicast and unicast don't be= have the same way
at the link layer. We've found empirically = that ETX is a great way to
assess wireless link quality but that = requires sending hellos over multicast.
That said, we added the following text to security considerations:
=
=C2=A0 =C2=A0 Babel over DTLS allows sending multicast Hellos unprotec= ted; attackers can
=C2=A0 =C2=A0=C2=A0therefore tamper with them.=C2=A0 = For example, an attacker could send erroneous
=C2=A0 =C2=A0=C2=A0values = for the Seqno and Interval fields, causing bidirectional
=C2=A0 =C2=A0= =C2=A0reachability detection to fail.=C2=A0 While implementations MAY use m= ulticast Hellos
=C2=A0 =C2=A0=C2=A0for link quality estimation, they SHO= ULD also emit protected unicast Hellos to
=C2=A0 =C2=A0=C2=A0prevent thi= s class of denial-of-service attack.

Section 2.4

=C2=A0 =C2=A0Note that receiving an unprotected packet can still be used to=
=C2=A0 =C2=A0discover new neighbours, even when all TLVs in that packet are=
=C2=A0 =C2=A0silently ignored.

Is this going to cause a lot of spurious DTLS handshake attempts if we
ever end up with a babel-dtls implementation adjacent to a
classic-babel-only implementation?=C2=A0 Is there any rate limiting on that= ?

Good point. We've added a "S= imultaneous operation of both Babel over
DTLS and unprotected Bab= el on a Network" section containing:
=C2=A0 =C2=A0 If Babel = over DTLS and unprotected Babel are both operated on the same
=C2=A0 =C2= =A0=C2=A0network, the Babel over DTLS implementation will receive unprotect= ed multicast
=C2=A0 =C2=A0=C2=A0Hellos and attempt to initiate a DTLS co= nnection.=C2=A0 These connection attempts
=C2=A0 =C2=A0=C2=A0can be sent= to nodes that only run unprotected Babel, who will not
=C2=A0 =C2=A0=C2= =A0respond.=C2=A0 Babel over DTLS implementations SHOULD therefore rate-lim= it their
=C2=A0 =C2=A0 DTLS connection attempts to avoid causing undue l= oad on the network.
=C2=A0
Section 2.5

Do we want to talk about the potential consequences of an attacker
arbitrarily delaying valid content (to justify the need for a timeout)?
=

The section currently states:
= =C2=A0 =C2=A0 This attack could be used to make a node believe it has bidir= ectional
=C2=A0 =C2=A0 reachability to a neighbour even though th= at neighbour has disconnected
=C2=A0 =C2=A0 from the network.
=
What more did you have in mind?
=C2=A0
Section 2.6

=C2=A0 =C2=A0A node MAY allow configuration options to allow unprotected Ba= bel on
=C2=A0 =C2=A0some interfaces but not others; this effectively gives nodes o= n that
=C2=A0 =C2=A0interface the same access as authenticated nodes, and SHOULD N= OT be
=C2=A0 =C2=A0done unless that interface has a mechanism to authenticate nod= es at a
=C2=A0 =C2=A0lower layer (e.g., IPsec).

I'm unhappy that this SHOULD NOT is not a MUST NOT, but cannot quite justify making it a Discuss-level point.

The rationale for the SHOULD was to allow deployments that we hadn't<= /div>
thought of. I think the text makes it clear what will go wrong if= you do this.
=C2=A0
Section 3

=C2=A0 =C2=A0IP, UDP and DTLS.=C2=A0 Nodes MUST NOT send Babel packets larg= er than the
=C2=A0 =C2=A0attached interface's MTU adjusted for known lower-layer he= aders (at
=C2=A0 =C2=A0least UDP and IP) or 512 octets, whichever is larger, but not<= br> =C2=A0 =C2=A0exceeding 2^16 - 1 adjusted for lower-layer headers.=C2=A0 Eve= ry Babel
=C2=A0 =C2=A0speaker MUST be able to receive packets that are as large as a= ny

Aren't these requirements just duplicating what's in 6126bis?=C2=A0= We
probably don't need to repeat the normative language, at least, even if=
there's a desire to repeat the content.

=
These requirements mimic the ones in 6126bis, but with the addition of= DTLS
in the list of underlying layers that add overhead. This se= ction references the
appropriate section in 6126bis so readers ca= n compare them if need be.
=C2=A0
=C2=A0 =C2=A0Note that distinct DTLS connections can use different ciphers,= which
=C2=A0 =C2=A0can have different amounts of overhead per packet.=C2=A0 There= fore, the

nit: I think the intention here was "per-packet overhead", though= the
statement is true as currently written (due to variable length padding
for block ciphers).

I'm not sure I = understand, are you saying there is a difference between
the term= s "overhead per packet" and=C2=A0"per-packet overhead" = ?
=C2=A0
Section 5

The RFC 7525 ref is probably better spelled as BCP 195, and arguably
moved earlier in the text (i.e., where I mentioned it previously).

Done.
=C2=A0
=C2=A0 =C2=A0A malicious client might attempt to perform a high number of D= TLS
=C2=A0 =C2=A0handshakes with a server.=C2=A0 As the clients are not uniquel= y identified
=C2=A0 =C2=A0by the protocol and can be obfuscated with IPv6 temporary addr= esses,
=C2=A0 =C2=A0a server needs to mitigate the impact of such an attack.=C2=A0= Such

nit: they're not uniquely identified by the protocol *until the
handshake completes* -- our requirement for mutual authentication will
cause all valid clients to be identified.=C2=A0 However, the DoS risk does<= br> not require the client to let the handshake complete, so the core
statement here remains valid.=C2=A0 It may also be worth mentioning
"Slowloris"-style attacks that keep handshake state active for as= long
as possible to increase resource consumption.

Agreed. Added "until the handshake completes" and referenc= e to Slowloris.

Section 6.2

DTLS-CID needs to be normative if it is a MAY-level feature.=C2=A0 (See
https://www6.ietf.org/iesg/statement/= normative-informative.html .)

I'= ;ve replaced "MAY" with "could" and kept this informati= ve. DTLS-CID
is not an optional feature of Babel over DTLS, it= 9;s just an informative
pointer to a DTLS feature. (I don't w= ant to make this normative as that
would create a blocking depend= ency on publication of that draft.)
=C2=A0
RFC 7525 (i.e., BCP 195) definitely needs to be normative, as a
MUST-level requirement!

Good catch, don= e.=C2=A0
--000000000000619167058fb5c185-- From nobody Fri Aug 9 16:39: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 9D272120059; Fri, 9 Aug 2019 16:39:15 -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.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156539395555.1819.13466889061703924275@ietfa.amsl.com> Date: Fri, 09 Aug 2019 16:39:15 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-dtls-08.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, 09 Aug 2019 23:39:16 -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-08.txt Pages : 10 Date : 2019-08-09 Abstract: The Babel Routing Protocol does not contain any means to authenticate neighbours or provide integrity or confidentiality for 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-babel-dtls-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-dtls-08 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 Aug 9 16:40:17 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 E812A12027A; Fri, 9 Aug 2019 16:40:09 -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 pUrHSC8O_qTO; Fri, 9 Aug 2019 16:40:06 -0700 (PDT) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 E7D011201AA; Fri, 9 Aug 2019 16:40:05 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id x4so1378312ljj.6; Fri, 09 Aug 2019 16:40:05 -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=IrvZKzYts+a1qHmN05xVbdmLnY06TGVbLXAhw/tzjG4=; b=bTQRbY+3otYQetJPOUCPG6R6jO+kbVPOpka6+h6+/1qpC1xRLCm3EKXQkXX/lQ+F6W e+hH78SbO49CCzeYgFl2N+zwKa8L5HQTmPB0CDwRGs+IWtZuk1bm+hfW7YxLGhkHfupX Hw1JNdCli1sUiM8v7Lvz7kE9QTAHkN3l9XFsNEsowAQsxsC7mhXnE5gB8Im/D6xGwEm9 yN62otILLuaqdRKDGmE/h/MpyurSbL1ynPWWzOH/Q44spb/0f/mSOAPWCSlFjL+a+Fle tTRTH0QYC1SKz4ntDmW6UXcHfx15h2MDxIrR92Rtx9SMb1XJgmKo4mAW4XJ1Jl7j3U/H C8Vg== 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=IrvZKzYts+a1qHmN05xVbdmLnY06TGVbLXAhw/tzjG4=; b=ab3R4YmhrPvjoWlFF7S42U1qg8KtMefaXvPpWkEV7ph8AsjUk7ByN7FQPtY8yZwRID jDuTJKdntpU0822rOgd0gRzXcU/e9Hvul8ByVZluKZ7cIeY1jfuJ3YAzSIuVOFYssZIQ 2qZ1o1bCDb4pBKZtl+jnvjy113KmpVaPeoFSMmr5qhz7KuhcHpuEoL+HbR0jURuNlOGq kNth8YLJ3vE6NL1wzTGQLDDwcpSD7w+ZyGevCB82bX4/6zvMdcW0l5BZEewtjg4n+jHS 2tzLXweaWyYzuX/40rhiSQ666JPR7ortEzlXpwqpiPdw3ztaC9CeC1I6gJ7CRSfMvjCN oZ5A== X-Gm-Message-State: APjAAAXE4BPM6PHWtmY9KK2kAUbTRWdpwXAq5AxTm1BBrhCyZ6FboNeT UDOwJLp+diFIeKoOM9U4zMD8ZgtqvMM42L7sI1M= X-Google-Smtp-Source: APXvYqy9bHIjdRK4sAGtRuxgUcI+MUpHOxe1LQdKbnKo9eRJTvJOdiZYArO88a7DF1wPn5CjBbh2Or/w9L2+UVihAh0= X-Received: by 2002:a2e:7f05:: with SMTP id a5mr12722603ljd.190.1565394003872; Fri, 09 Aug 2019 16:40:03 -0700 (PDT) MIME-Version: 1.0 References: <156521337799.8333.13258734665763149206.idtracker@ietfa.amsl.com> In-Reply-To: From: David Schinazi Date: Fri, 9 Aug 2019 16:39:52 -0700 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-babel-dtls@ietf.org, Donald Eastlake , babel-chairs , Babel at IETF Content-Type: multipart/alternative; boundary="00000000000088d304058fb7b102" Archived-At: Subject: Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT) 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, 09 Aug 2019 23:40:16 -0000 --00000000000088d304058fb7b102 Content-Type: text/plain; charset="UTF-8" We've now submitted -08 which contains the changes discussed below. Thanks, David On Fri, Aug 9, 2019 at 2:21 PM David Schinazi wrote: > Thanks for your review Ben! We've incorporated your comments into our > working copy and we'll publish > a revised draft shortly. Detailed responses inline. > > Thanks, > David > > > On Wed, Aug 7, 2019 at 2:29 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I support Roman's Discuss point (1) (and basically cover the same as his >> (2) below). >> >> Let's have a discussion about (DTLS) identity. >> Section 2.1 says that we use mutual authentication and that >> implementations "MUST support authenticating peers against a local store >> of credentials"; also that "if a node receives a new DTLS connection >> from a neighbour to whom it already has a connection, the node MUST NOT >> discard the older connection until it has completed the handshake of the >> new one and validated the identity of the peer". But how does this >> authentication occur, and what constitutes the identity of the peer. We >> will frequently have (D)TLS consumers cite RFC 6125 and say that (e.g.) >> DNS-ID or SRV-ID must match the name obtained in some fashion. But for >> Babel, we are authenticating routers -- router identity is usually in >> the form of just an IP address on a loopback interface! Are we expected >> to get certificates that certify IP addresses as identity, or use some >> sort of PSK or password-based TLS authentication? (The last two are not >> really compatible with the "MUST send a CertificateRequest", BTW.) Raw >> public keys? I think we can give a more clear picture of how to build a >> secure system. >> > > Our intent in this document was to leave the complex question of identity > to deployment profiles. For example, the homenet working group is > interested > in potentially using Babel over DTLS to protect routing inside the home. > The idea there being that each router you buy has an identity, and then > there > would be some process to let your existing routers know about the new > router you just bought. However, homenet has not yet solved how to do this. > They may choose to use self-signed certificates and develop a provisioning > mechanism to share them. They could also decide to use raw keys. Our > goal with the present draft is to define how one runs Babel over DTLS. > I imagine that if homenet decides to use Babel over DTLS, they'll publish > another document explaining how to manage identities. > > I would prefer not having this document be too prescriptive with regards > to identities, because that could prevent some deployment profiles. > But I'm happy to add guidance for writers of deployment profiles. Do you > have thoughts on what such guidance would look like? > > That said I've removed the mention of CertificateRequest since as you > pointed out that's too restrictive. > > Relatedly, once DTLS authenticates an identity, what level of >> authorization checks are performed? Are we still in a single >> authorization domain, where any router that authenticates as being part >> of a given domain is implictily authorized to be a babel peer and convey >> any and all routing information? >> > > It's a single authentication domain. We've added text in the document to > clarify that. > > >> We should also give some guidance on ciphers and algorithms where we >> discuss the DTLS details (BCP 195 is probably the safest bet here, even >> if it's a little in need of an update). >> > > We have a reference to BCP195, did you have anything else in mind? > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Section 1.2 >> >> The protocol described in this document protects Babel packets with >> DTLS. As such, it inherits the features offered by DTLS, notably >> authentication, integrity, replay protection, confidentiality and >> asymmetric keying. It is therefore expected to be applicable in a >> >> replay protection is not an inherent feature of DTLS, so I suggest >> "optional replay protection" to emphasize that an implementation of >> babel may need to explicitly configure it. >> > > We already have this text in section 2.1: > Nodes MUST use DTLS replay protection to prevent attackers > from replaying stale information. > Is there something we should add to that? > > >> There exists another mechanism for securing Babel, namely Babel HMAC >> authentication [BABEL-HMAC]. HMAC only offers basic features, namely >> authentication, integrity and replay protection with a small number >> of symmetric keys. A comparison of Babel security mechanisms and >> >> Even the authentication is limited, as it is group authentication, not >> true per-entity authentication. >> > > That is true. We've fleshed out the text in RFC6126bis that compares both > mechanisms. > > >> Section 2.1 >> >> information last longer. If a node receives a new DTLS connection >> from a neighbour to whom it already has a connection, the node MUST >> NOT discard the older connection until it has completed the handshake >> of the new one and validated the identity of the peer. >> >> (Does the validated identity of the peer have to match the one from the >> previous handshake?) >> > > It doesn't. Conceptually there is a single security domain so as long as > the credentials are valid you're free to stomp on previous connections > from other IPs. > > >> Section 2.3 >> >> I agree with the RtgDir reviewer that unprotected (multicast) Hellos are >> at risk of tampering by an attacker, who could drop them or modify the >> seqno/interval, for DoS purposes. >> I see the text about use of multicast Hellos for discovery and the >> acknowledgment that an out-of-band neighbor discovery mechanism may be >> available. Are there any such discovery mechanism under development? >> > > There aren't, at least not as standards. This text is there to accommodate > implementations/deployments that already have a non-standard out-of-band > discovery mechanism. > > >> Regardless, I think we should consider mandating/suggesting (to some >> strength; maybe SHOULD is enough) the use of protected unicast Hellos >> instead of just stating that nodes can either rely on multicast or send >> protected unicast Hellos. When unicast (protected) Hellos are in use, >> even tampering with multicast Hellos will not be enough to cause a DoS >> attack, since a node must be detected as down on both unicast and >> multicast to be considered gone. (Of course, a sufficiently powerful >> attacker can still just drop all traffic and cause DoS.) >> > > The issue here is that multicast and unicast don't behave the same way > at the link layer. We've found empirically that ETX is a great way to > assess wireless link quality but that requires sending hellos over > multicast. > https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-12#appendix-A.2.2 > That said, we added the following text to security considerations: > Babel over DTLS allows sending multicast Hellos unprotected; attackers > can > therefore tamper with them. For example, an attacker could send > erroneous > values for the Seqno and Interval fields, causing bidirectional > reachability detection to fail. While implementations MAY use > multicast Hellos > for link quality estimation, they SHOULD also emit protected unicast > Hellos to > prevent this class of denial-of-service attack. > > Section 2.4 >> >> Note that receiving an unprotected packet can still be used to >> discover new neighbours, even when all TLVs in that packet are >> silently ignored. >> >> Is this going to cause a lot of spurious DTLS handshake attempts if we >> ever end up with a babel-dtls implementation adjacent to a >> classic-babel-only implementation? Is there any rate limiting on that? >> > > Good point. We've added a "Simultaneous operation of both Babel over > DTLS and unprotected Babel on a Network" section containing: > If Babel over DTLS and unprotected Babel are both operated on the same > network, the Babel over DTLS implementation will receive unprotected > multicast > Hellos and attempt to initiate a DTLS connection. These connection > attempts > can be sent to nodes that only run unprotected Babel, who will not > respond. Babel over DTLS implementations SHOULD therefore rate-limit > their > DTLS connection attempts to avoid causing undue load on the network. > > >> Section 2.5 >> >> Do we want to talk about the potential consequences of an attacker >> arbitrarily delaying valid content (to justify the need for a timeout)? >> > > The section currently states: > This attack could be used to make a node believe it has bidirectional > reachability to a neighbour even though that neighbour has disconnected > from the network. > What more did you have in mind? > > >> Section 2.6 >> >> A node MAY allow configuration options to allow unprotected Babel on >> some interfaces but not others; this effectively gives nodes on that >> interface the same access as authenticated nodes, and SHOULD NOT be >> done unless that interface has a mechanism to authenticate nodes at a >> lower layer (e.g., IPsec). >> >> I'm unhappy that this SHOULD NOT is not a MUST NOT, but cannot quite >> justify making it a Discuss-level point. >> > > The rationale for the SHOULD was to allow deployments that we hadn't > thought of. I think the text makes it clear what will go wrong if you do > this. > > >> Section 3 >> >> IP, UDP and DTLS. Nodes MUST NOT send Babel packets larger than the >> attached interface's MTU adjusted for known lower-layer headers (at >> least UDP and IP) or 512 octets, whichever is larger, but not >> exceeding 2^16 - 1 adjusted for lower-layer headers. Every Babel >> speaker MUST be able to receive packets that are as large as any >> >> Aren't these requirements just duplicating what's in 6126bis? We >> probably don't need to repeat the normative language, at least, even if >> there's a desire to repeat the content. >> > > These requirements mimic the ones in 6126bis, but with the addition of DTLS > in the list of underlying layers that add overhead. This section > references the > appropriate section in 6126bis so readers can compare them if need be. > > >> Note that distinct DTLS connections can use different ciphers, which >> can have different amounts of overhead per packet. Therefore, the >> >> nit: I think the intention here was "per-packet overhead", though the >> statement is true as currently written (due to variable length padding >> for block ciphers). >> > > I'm not sure I understand, are you saying there is a difference between > the terms "overhead per packet" and "per-packet overhead" ? > > >> Section 5 >> >> The RFC 7525 ref is probably better spelled as BCP 195, and arguably >> moved earlier in the text (i.e., where I mentioned it previously). >> > > Done. > > >> A malicious client might attempt to perform a high number of DTLS >> handshakes with a server. As the clients are not uniquely identified >> by the protocol and can be obfuscated with IPv6 temporary addresses, >> a server needs to mitigate the impact of such an attack. Such >> >> nit: they're not uniquely identified by the protocol *until the >> handshake completes* -- our requirement for mutual authentication will >> cause all valid clients to be identified. However, the DoS risk does >> not require the client to let the handshake complete, so the core >> statement here remains valid. It may also be worth mentioning >> "Slowloris"-style attacks that keep handshake state active for as long >> as possible to increase resource consumption. >> > > Agreed. Added "until the handshake completes" and reference to Slowloris. > > Section 6.2 >> >> DTLS-CID needs to be normative if it is a MAY-level feature. (See >> https://www6.ietf.org/iesg/statement/normative-informative.html .) >> > > I've replaced "MAY" with "could" and kept this informative. DTLS-CID > is not an optional feature of Babel over DTLS, it's just an informative > pointer to a DTLS feature. (I don't want to make this normative as that > would create a blocking dependency on publication of that draft.) > > >> RFC 7525 (i.e., BCP 195) definitely needs to be normative, as a >> MUST-level requirement! >> > > Good catch, done. > --00000000000088d304058fb7b102 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We've now submitted -08 which contains the changes dis= cussed below.

Thanks,
David

On Fri, Aug 9= , 2019 at 2:21 PM David Schinazi <dschinazi.ietf@gmail.com> wrote:
Thanks for = your review Ben! We've incorporated your comments into our
working copy <https://github.com/jech/babel-drafts> and we'= ll publish
a revised draft shortly. Detailed responses inline.

Thanks,
David


On Wed, Aug 7,= 2019 at 2:29 PM Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I support Roman's Discuss point (1) (and basically cover the same as hi= s
(2) below).

Let's have a discussion about (DTLS) identity.
Section 2.1 says that we use mutual authentication and that
implementations "MUST support authenticating peers against a local sto= re
of credentials"; also that "if a node receives a new DTLS connect= ion
from a neighbour to whom it already has a connection, the node MUST NOT
discard the older connection until it has completed the handshake of the new one and validated the identity of the peer".=C2=A0 But how does th= is
authentication occur, and what constitutes the identity of the peer.=C2=A0 = We
will frequently have (D)TLS consumers cite RFC 6125 and say that (e.g.)
DNS-ID or SRV-ID must match the name obtained in some fashion.=C2=A0 But fo= r
Babel, we are authenticating routers -- router identity is usually in
the form of just an IP address on a loopback interface!=C2=A0 Are we expect= ed
to get certificates that certify IP addresses as identity, or use some
sort of PSK or password-based TLS authentication?=C2=A0 (The last two are n= ot
really compatible with the "MUST send a CertificateRequest", BTW.= )=C2=A0 Raw
public keys?=C2=A0 I think we can give a more clear picture of how to build= a
secure system.

Our intent in this docum= ent was to leave the complex question of identity
to deployment p= rofiles. For example, the homenet working group is interested
in = potentially using Babel over DTLS to protect routing inside the home.
=
The idea there being that each router you buy has an identity, and the= n there
would be some process to let your existing routers know a= bout the new
router you just bought. However, homenet has not yet= solved how to do this.
They may choose to use self-signed certif= icates and develop a provisioning
mechanism to share them. They c= ould also decide to use raw keys. Our
goal with the present draft= is to define how one runs Babel over DTLS.
I imagine that if hom= enet decides to use Babel over DTLS, they'll publish
another = document explaining how to manage identities.

I wo= uld prefer not having this document be too prescriptive with regards
<= div>to identities, because that could prevent some deployment profiles.
But I'm happy to add guidance for writers of deployment profiles= . Do you
have thoughts on what such guidance would look like?

That said I've removed the mention of Certificate= Request since as you
pointed out that's too restrictive.

Relatedly, once DTLS authenticates an identity, what level of
authorization checks are performed?=C2=A0 Are we still in a single
authorization domain, where any router that authenticates as being part
of a given domain is implictily authorized to be a babel peer and convey any and all routing information?

It'= ;s a single authentication domain. We've added text in the document to = clarify that.
=C2=A0
We should also give some guidance on ciphers and algorithms where we
discuss the DTLS details (BCP 195 is probably the safest bet here, even
if it's a little in need of an update).

=
We have a reference to BCP195, did you have anything else in mind?
=C2=A0
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1.2

=C2=A0 =C2=A0The protocol described in this document protects Babel packets= with
=C2=A0 =C2=A0DTLS.=C2=A0 As such, it inherits the features offered by DTLS,= notably
=C2=A0 =C2=A0authentication, integrity, replay protection, confidentiality = and
=C2=A0 =C2=A0asymmetric keying.=C2=A0 It is therefore expected to be applic= able in a

replay protection is not an inherent feature of DTLS, so I suggest
"optional replay protection" to emphasize that an implementation = of
babel may need to explicitly configure it.

<= div>We already have this text in section 2.1:
=C2=A0 =C2=A0 Nodes= MUST use DTLS replay protection to prevent attackers
=C2=A0 =C2= =A0 from replaying stale information.=C2=A0
Is there somethin= g we should add to that?
=C2=A0
=C2=A0 =C2=A0There exists another mechanism for securing Babel, namely Babe= l HMAC
=C2=A0 =C2=A0authentication [BABEL-HMAC].=C2=A0 HMAC only offers basic feat= ures, namely
=C2=A0 =C2=A0authentication, integrity and replay protection with a small n= umber
=C2=A0 =C2=A0of symmetric keys.=C2=A0 A comparison of Babel security mechan= isms and

Even the authentication is limited, as it is group authentication, not
true per-entity authentication.

That is= true. We've fleshed out the text in RFC6126bis that compares both mech= anisms.
=C2=A0
Section 2.1

=C2=A0 =C2=A0information last longer.=C2=A0 If a node receives a new DTLS c= onnection
=C2=A0 =C2=A0from a neighbour to whom it already has a connection, the node= MUST
=C2=A0 =C2=A0NOT discard the older connection until it has completed the ha= ndshake
=C2=A0 =C2=A0of the new one and validated the identity of the peer.

(Does the validated identity of the peer have to match the one from the
previous handshake?)

It doesn't. Co= nceptually there is a single security domain so as long as
the cr= edentials are valid you're free to stomp on previous connections
<= div>from other IPs.
=C2=A0
Section 2.3

I agree with the RtgDir reviewer that unprotected (multicast) Hellos are at risk of tampering by an attacker, who could drop them or modify the
seqno/interval, for DoS purposes.
I see the text about use of multicast Hellos for discovery and the
acknowledgment that an out-of-band neighbor discovery mechanism may be
available.=C2=A0 Are there any such discovery mechanism under development?<= br>

There aren't, at least not as stand= ards. This text is there to accommodate
implementations/deploymen= ts that already have a non-standard out-of-band
discovery mechani= sm.
=C2=A0
Regardless, I think we should consider mandating/suggesting (to some
strength; maybe SHOULD is enough) the use of protected unicast Hellos
instead of just stating that nodes can either rely on multicast or send
protected unicast Hellos.=C2=A0 When unicast (protected) Hellos are in use,=
even tampering with multicast Hellos will not be enough to cause a DoS
attack, since a node must be detected as down on both unicast and
multicast to be considered gone.=C2=A0 (Of course, a sufficiently powerful<= br> attacker can still just drop all traffic and cause DoS.)

The issue here is that multicast and unicast don't be= have the same way
at the link layer. We've found empirically = that ETX is a great way to
assess wireless link quality but that = requires sending hellos over multicast.
That said, we added the following text to security con= siderations:
=C2=A0 =C2=A0 Babel over DTLS allows sending multica= st Hellos unprotected; attackers can
=C2=A0 =C2=A0=C2=A0therefore tamper= with them.=C2=A0 For example, an attacker could send erroneous
=C2=A0 = =C2=A0=C2=A0values for the Seqno and Interval fields, causing bidirectional=
=C2=A0 =C2=A0=C2=A0reachability detection to fail.=C2=A0 While implemen= tations MAY use multicast Hellos
=C2=A0 =C2=A0=C2=A0for link quality est= imation, they SHOULD also emit protected unicast Hellos to
=C2=A0 =C2=A0= =C2=A0prevent this class of denial-of-service attack.

Section 2.4

=C2=A0 =C2=A0Note that receiving an unprotected packet can still be used to=
=C2=A0 =C2=A0discover new neighbours, even when all TLVs in that packet are=
=C2=A0 =C2=A0silently ignored.

Is this going to cause a lot of spurious DTLS handshake attempts if we
ever end up with a babel-dtls implementation adjacent to a
classic-babel-only implementation?=C2=A0 Is there any rate limiting on that= ?

Good point. We've added a "S= imultaneous operation of both Babel over
DTLS and unprotected Bab= el on a Network" section containing:
=C2=A0 =C2=A0 If Babel = over DTLS and unprotected Babel are both operated on the same
=C2=A0 =C2= =A0=C2=A0network, the Babel over DTLS implementation will receive unprotect= ed multicast
=C2=A0 =C2=A0=C2=A0Hellos and attempt to initiate a DTLS co= nnection.=C2=A0 These connection attempts
=C2=A0 =C2=A0=C2=A0can be sent= to nodes that only run unprotected Babel, who will not
=C2=A0 =C2=A0=C2= =A0respond.=C2=A0 Babel over DTLS implementations SHOULD therefore rate-lim= it their
=C2=A0 =C2=A0 DTLS connection attempts to avoid causing undue l= oad on the network.
=C2=A0
Section 2.5

Do we want to talk about the potential consequences of an attacker
arbitrarily delaying valid content (to justify the need for a timeout)?
=

The section currently states:
= =C2=A0 =C2=A0 This attack could be used to make a node believe it has bidir= ectional
=C2=A0 =C2=A0 reachability to a neighbour even though th= at neighbour has disconnected
=C2=A0 =C2=A0 from the network.
=
What more did you have in mind?
=C2=A0
Section 2.6

=C2=A0 =C2=A0A node MAY allow configuration options to allow unprotected Ba= bel on
=C2=A0 =C2=A0some interfaces but not others; this effectively gives nodes o= n that
=C2=A0 =C2=A0interface the same access as authenticated nodes, and SHOULD N= OT be
=C2=A0 =C2=A0done unless that interface has a mechanism to authenticate nod= es at a
=C2=A0 =C2=A0lower layer (e.g., IPsec).

I'm unhappy that this SHOULD NOT is not a MUST NOT, but cannot quite justify making it a Discuss-level point.

The rationale for the SHOULD was to allow deployments that we hadn't<= /div>
thought of. I think the text makes it clear what will go wrong if= you do this.
=C2=A0
Section 3

=C2=A0 =C2=A0IP, UDP and DTLS.=C2=A0 Nodes MUST NOT send Babel packets larg= er than the
=C2=A0 =C2=A0attached interface's MTU adjusted for known lower-layer he= aders (at
=C2=A0 =C2=A0least UDP and IP) or 512 octets, whichever is larger, but not<= br> =C2=A0 =C2=A0exceeding 2^16 - 1 adjusted for lower-layer headers.=C2=A0 Eve= ry Babel
=C2=A0 =C2=A0speaker MUST be able to receive packets that are as large as a= ny

Aren't these requirements just duplicating what's in 6126bis?=C2=A0= We
probably don't need to repeat the normative language, at least, even if=
there's a desire to repeat the content.

=
These requirements mimic the ones in 6126bis, but with the addition of= DTLS
in the list of underlying layers that add overhead. This se= ction references the
appropriate section in 6126bis so readers ca= n compare them if need be.
=C2=A0
=C2=A0 =C2=A0Note that distinct DTLS connections can use different ciphers,= which
=C2=A0 =C2=A0can have different amounts of overhead per packet.=C2=A0 There= fore, the

nit: I think the intention here was "per-packet overhead", though= the
statement is true as currently written (due to variable length padding
for block ciphers).

I'm not sure I = understand, are you saying there is a difference between
the term= s "overhead per packet" and=C2=A0"per-packet overhead" = ?
=C2=A0
Section 5

The RFC 7525 ref is probably better spelled as BCP 195, and arguably
moved earlier in the text (i.e., where I mentioned it previously).

Done.
=C2=A0
=C2=A0 =C2=A0A malicious client might attempt to perform a high number of D= TLS
=C2=A0 =C2=A0handshakes with a server.=C2=A0 As the clients are not uniquel= y identified
=C2=A0 =C2=A0by the protocol and can be obfuscated with IPv6 temporary addr= esses,
=C2=A0 =C2=A0a server needs to mitigate the impact of such an attack.=C2=A0= Such

nit: they're not uniquely identified by the protocol *until the
handshake completes* -- our requirement for mutual authentication will
cause all valid clients to be identified.=C2=A0 However, the DoS risk does<= br> not require the client to let the handshake complete, so the core
statement here remains valid.=C2=A0 It may also be worth mentioning
"Slowloris"-style attacks that keep handshake state active for as= long
as possible to increase resource consumption.

Agreed. Added "until the handshake completes" and referenc= e to Slowloris.

Section 6.2

DTLS-CID needs to be normative if it is a MAY-level feature.=C2=A0 (See
https://www6.ietf.org/iesg/statement/= normative-informative.html .)

I'= ;ve replaced "MAY" with "could" and kept this informati= ve. DTLS-CID
is not an optional feature of Babel over DTLS, it= 9;s just an informative
pointer to a DTLS feature. (I don't w= ant to make this normative as that
would create a blocking depend= ency on publication of that draft.)
=C2=A0
RFC 7525 (i.e., BCP 195) definitely needs to be normative, as a
MUST-level requirement!

Good catch, don= e.=C2=A0
--00000000000088d304058fb7b102-- From nobody Fri Aug 9 16:40: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 BED53120253; Fri, 9 Aug 2019 16:40: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, 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 vkUZZsKPrQjW; Fri, 9 Aug 2019 16:40:16 -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 E1307120168; Fri, 9 Aug 2019 16:40:15 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id h28so70599363lfj.5; Fri, 09 Aug 2019 16:40:15 -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=pH3vDHyTZt4Uyv3AEAhpM36ibWFdjZdaxuDvSKALTVg=; b=C6UYgodTjPW0qJOjZK0dbXoTVTjal1PU5cRHwaym4KwY3EqcxsWza5j6r1c6Wn3A6k 4lUO2L/3Q0rRCpzHh+oM+gIa3n9m9T5MNTe5IP2pSNh+p4iu9Chq9UVt9P1A0q95+WgE yrEIrZciIIKMxdOSMJ9vGCr5L3VKC5UHoqN/4uU/Jp+uyjUzqZHd3mdv4QqgWL1ccGg1 r1wuRGfP5ox1ddhsi9EYEwJSFiupDD0g2w4bwA3bPck3aPAUjHe5N3MynwEP1Fpwvlhj Qb29TBMK5yiDcYnnF/sTXw3GRLLjXy0ooPkC/M8ppy6bfO3HmkiR7O8IrcJQWjFtRKlZ errg== 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=pH3vDHyTZt4Uyv3AEAhpM36ibWFdjZdaxuDvSKALTVg=; b=jQZHN9x2OIpgKrbwMwK6RvGxJPkO6Rd3EshCo4gNRu8S4p6BipHJqmhZiDr/ehehVd SpbQJV5/2BjrmdV3y+/Is58R2mpKMVo+xDxAFUwha2cokxR4TJHQhRnHFST4S6TgHQkF DFwY7IwjJGt1NitSegWXCAX4wVVzBiVVMyhNCxnOwdg0MP+dp+qK5hA7fEPH/Zg62gnJ nZOO9Y+07K+kf2ZxP0G28CgIXht60yN6YGhSsCg0WctAzMYEYqDh5dNGZJlmMlBBlNoT LqamaJq/bTKkPwhrMHRhGgFjLwh/9y6/L4bjXum992NDyB5o9T9bS2x+8v6r4z9lEe97 hLEQ== X-Gm-Message-State: APjAAAXj+K09tAyOJPYAXuy3eNSyzee2foDihipPLFmrHbBVIiYPa736 f3snqKsbEahhxp/N8Pmm3r/tIi7YYaw1KJTLs/k= X-Google-Smtp-Source: APXvYqydqoV9ehgPifYTgIUBxNdTXvMp8ZJb0n7/LRF67+Ysf0yU+enCBqFML7A5TVKqO0Rm4z13Cm/fEGAQtElqzy0= X-Received: by 2002:a19:428c:: with SMTP id p134mr12869862lfa.166.1565394013962; Fri, 09 Aug 2019 16:40:13 -0700 (PDT) MIME-Version: 1.0 References: <156520596444.8244.649940515091541992.idtracker@ietfa.amsl.com> In-Reply-To: From: David Schinazi Date: Fri, 9 Aug 2019 16:40:02 -0700 Message-ID: To: Roman Danyliw Cc: The IESG , draft-ietf-babel-dtls@ietf.org, Donald Eastlake , babel-chairs , Babel at IETF Content-Type: multipart/alternative; boundary="00000000000022c79f058fb7b2d4" Archived-At: Subject: Re: [babel] Roman Danyliw's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT) 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, 09 Aug 2019 23:40:24 -0000 --00000000000022c79f058fb7b2d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We've now submitted -08 which contains the changes discussed below. Thanks, David On Thu, Aug 8, 2019 at 5:44 PM David Schinazi wrote: > Thanks for your review Roman! We've made changes on our git repository > and will submit a revised draft > shortly. > > Detailed responses inline. > > Thanks, > David > > On Wed, Aug 7, 2019 at 12:26 PM Roman Danyliw via Datatracker < > noreply@ietf.org> wrote: > >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> (1) Section 1. These are different than the ones listed in Section 6 of >> draft-ietf-babel-rfc6126bis and Section 1 of draft-ietf-babel-dtls. As >> DTLS >> and HMAC are mitigations for attacks in draft-ietf-babel-rfc6126bis, the= y >> really should be harmonized. >> > > We've fleshed out the text in draft-ietf-babel-rfc6126bis and kept the > reference > in draft-ietf-babel-dtls. > > (2) Section 2.1. Per =E2=80=9CImplementations MUST support authenticatin= g peers >> against a local store of credentials=E2=80=9D, what does that credential= ing look >> like? >> Is it certificates, PSK, etc? What validation procedure is being used >> for this >> authentication? >> > > I'll respond to this point on Ben's DISCUSS since I think you're both > asking > for the same thing. > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> (3) Abstract. Per =E2=80=9CBabel does not contain any means =E2=80=A6 [= to] protect >> messages=E2=80=9D, >> be more precise in the definition of protect (i.e., integrity and >> confidentiality) >> > > Agreed, fixed. > > >> (4) Section 1.2. Per =E2=80=9CA comparison of Babel security mechanisms= and their >> applicability can be found in [RFC6126bis]=E2=80=9D, where in >> draft-ietf-babel-rfc6126bis does this comparison occur. The references >> to HMAC >> and TLS are in a single paragraph in in Section 6/Security Consideration= s >> which >> roughly reiterate the one sentence statements written here. >> > > We've fleshed out the text in draft-ietf-babel-rfc6126bis and kept the > reference > in draft-ietf-babel-dtls. > > >> (5) Section 2.1. Per =E2=80=9CWhen a node receives a new DTLS connectio= n, it MUST >> verify that the source IP address is an IPv6 link-local address =E2=80= =A6=E2=80=9D, what >> happens if IPv4 is in use? >> > > This was an oversight. The text now also discusses IPv4. > > >> (6) Section 2.1. Per =E2=80=9CNodes MUST only negotiate DTLS version 1.2= or >> higher=E2=80=9D, >> this is stricter than RFC7525 cited in the Security Consideration later >> in the >> draft. That=E2=80=99s fine, but please reiterate that in Section 5. >> > > Done. > > (7) Section 2.6 Suggest being clearer that this is a deployment not an >> implementation issue. s/Implementations MAY implement both Babel over >> DTLS and >> unprotected Babel./ /A node MAY run both Babel over DTLS and unprotected >> Babel./ >> > > Agreed. We added your new sentence but also kept the old one since both > are true. > > >> (8) Section 2.6, Per =E2=80=9CHowever, accepting unprotected Babel packe= ts =E2=80=A6 >> loses the >> security properties of Babel over DTLS=E2=80=9D. This seems misleading.= The >> security >> properties of =E2=80=9CBabel over DTLS=E2=80=9D as a protocol are stated= in Section 1.2. >> In >> this section there is discussion of the security properties of the node >> (and >> the resulting neighbor table). These are different. The issue seems to >> be >> that a node is building a neighbor table with updates from sources which >> need >> to be trusted to different degrees. >> > > Agreed. We've reworked that paragraph. > > >> (9) Section 5. Per =E2=80=9CConfidential interaction between two Babel = peers >> requires >> Datagram Transport Layer Security (DTLS) with a cipher suite offering >> confidentiality protection. The guidance given in [RFC7525] MUST be >> followed >> to avoid attacks on DTLS.=E2=80=9D, the first sentence is true, but inco= mplete, >> in that >> we=E2=80=99d also want cipher suites with a strong key exchange algorith= m, etc. >> Section 4.2 of RFC7525, which is cited as a MUST, provides a list of >> recommended ciphers suites. Do we need this first sentence? >> > > Fair enough, We've removed that sentence. > > (10) Editorial >> -- Section 2.1. Expand =E2=80=9CIHU=E2=80=9D on first use >> > > Done > > -- Section 3. Nit. s/ciphers/ciphersuites/ > > > Done > --00000000000022c79f058fb7b2d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We've now submitted -08 which contains the changes dis= cussed below.

Thanks,
David

On Thu, Aug 8= , 2019 at 5:44 PM David Schinazi <dschinazi.ietf@gmail.com> wrote:
Thanks for your review = Roman! We've made changes on our git repository
<https://github.= com/jech/babel-drafts> and will submit a revised draft shortly.
<= /div>

Detailed responses inline.

Thanks,
David

On Wed, Aug 7, 2019 at 12:26 PM Roman Danyliw via = Datatracker <norep= ly@ietf.org> wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) Section 1. These are different than the ones listed in Section 6 of
draft-ietf-babel-rfc6126bis and Section 1 of draft-ietf-babel-dtls.=C2=A0 A= s DTLS
and HMAC are mitigations for attacks in draft-ietf-babel-rfc6126bis, they really should be harmonized.

We've = fleshed out the text in=C2=A0draft-ietf-babel-rfc6126bis and kept the refer= ence
in draft-ietf-babel-dtls.

(2) Section 2.1.=C2=A0 Per =E2=80=9CImplementations MUST support authentica= ting peers
against a local store of credentials=E2=80=9D, what does that credentialing= look like?
Is it certificates, PSK, etc?=C2=A0 What validation procedure is being used= for this
authentication?

I'll respond to thi= s point on Ben's DISCUSS since I think you're both asking
for the same=C2=A0thing.
=C2=A0
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(3) Abstract.=C2=A0 Per =E2=80=9CBabel does not contain any means =E2=80=A6= [to] protect messages=E2=80=9D,
be more precise in the definition of protect (i.e., integrity and
confidentiality)

Agreed, fixed.
=C2=A0
(4) Section 1.2.=C2=A0 Per =E2=80=9CA comparison of Babel security mechanis= ms and their
applicability can be found in [RFC6126bis]=E2=80=9D, where in
draft-ietf-babel-rfc6126bis does this comparison occur.=C2=A0 The reference= s to HMAC
and TLS are in a single paragraph in in Section 6/Security Considerations w= hich
roughly reiterate the one sentence statements written here.

We've fleshed out the text in=C2=A0draft-ietf= -babel-rfc6126bis and kept the reference
in draft-ietf-babel-dtls= .
=C2=A0
(5) Section 2.1.=C2=A0 Per =E2=80=9CWhen a node receives a new DTLS connect= ion, it MUST
verify that the source IP address is an IPv6 link-local address =E2=80=A6= =E2=80=9D, what
happens if IPv4 is in use?

This was an = oversight. The text now also discusses IPv4.
=C2=A0
(6) Section 2.1. Per =E2=80=9CNodes MUST only negotiate DTLS version 1.2 or= higher=E2=80=9D,
this is stricter than RFC7525 cited in the Security Consideration later in = the
draft.=C2=A0 That=E2=80=99s fine, but please reiterate that in Section 5.

Done.=C2=A0

(7) Section 2.6=C2=A0 Suggest being clearer that this is a deployment not a= n
implementation issue. s/Impl= ementations MAY implement both Babel over DTLS and
unprotected Babel./ /A node MAY run both Babel over DTLS and unprotected Ba= bel./

Agreed. We added your new sentenc= e but also kept the old one since both are true.
=C2=A0
(8) Section 2.6, Per =E2=80=9CHowever, accepting unprotected Babel packets = =E2=80=A6 loses the
security properties of Babel over DTLS=E2=80=9D.=C2=A0 This seems misleadin= g.=C2=A0 The security
properties of =E2=80=9CBabel over DTLS=E2=80=9D as a protocol are stated in= Section 1.2.=C2=A0 In
this section there is discussion of the security properties of the node (an= d
the resulting neighbor table).=C2=A0 These are different.=C2=A0 The issue s= eems to be
that a node is building a neighbor table with updates from sources which ne= ed
to be trusted to different degrees.

Agr= eed. We've reworked that paragraph.
=C2=A0
(9) Section 5.=C2=A0 Per =E2=80=9CConfidential interaction between two Babe= l peers requires
Datagram Transport Layer Security (DTLS) with a cipher suite offering
confidentiality protection.=C2=A0 The guidance given in [RFC7525] MUST be f= ollowed
to avoid attacks on DTLS.=E2=80=9D, the first sentence is true, but incompl= ete, in that
we=E2=80=99d also want cipher suites with a strong key exchange algorithm, = etc.
Section 4.2 of RFC7525, which is cited as a MUST, provides a list of
recommended ciphers suites.=C2=A0 Do we need this first sentence?

Fair enough, We've removed that sentence.=C2= =A0

(10) Editorial
-- Section 2.1.=C2=A0 Expand =E2=80=9CIHU=E2=80=9D on first use

Done=C2=A0

-- Section 3.=C2=A0 Nit. s/ciphers/ciphersuites/

Done
=
--00000000000022c79f058fb7b2d4-- From nobody Fri Aug 9 18:55:34 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 E870E120088; Fri, 9 Aug 2019 18:55:26 -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 yX1I91nJh_6B; Fri, 9 Aug 2019 18:55:21 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7D9F12003F; Fri, 9 Aug 2019 18:55:20 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7A1tEx1013621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 10 Aug 2019 03:55:14 +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 x7A1tEgd011618; Sat, 10 Aug 2019 03:55:14 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5058A35002; Sat, 10 Aug 2019 03:55:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id X8rY3cG-eXrS; Sat, 10 Aug 2019 03:55:14 +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 BEF2D34FFF; Sat, 10 Aug 2019 03:54:53 +0200 (CEST) Date: Sat, 10 Aug 2019 03:54:53 +0200 Message-ID: <87v9v57pjm.wl-jch@irif.fr> From: Juliusz Chroboczek To: Benjamin Kaduk Cc: "The IESG" , draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156521599894.8313.13827924927219698158.idtracker@ietfa.amsl.com> References: <156521599894.8313.13827924927219698158.idtracker@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 Content-Transfer-Encoding: quoted-printable 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, 10 Aug 2019 03:55:14 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 10 Aug 2019 03:55:14 +0200 (CEST) X-Miltered: at korolev with ID 5D4E2402.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D4E2402.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4E2402.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D4E2402.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 : 5D4E2402.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D4E2402.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] Benjamin Kaduk's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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, 10 Aug 2019 01:55:27 -0000 Dear Benjamin, Thank you very much for your detailed review. > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > I don't think that all of the arithmetic specified in Section 3.2.1 is > well defined. Specifcally, the formulations involving bitwise AND > assume that the input to the bitwise AND is nonnegative, which does not > seem to be implied by the other stated constraints. (For example, an > "integer n" may well be negative.) I've added "nonnegative" (we never add a negative integer to a seqno, not even when we undo history in Appendix A.2). (The formulation is correct even for negative numbers independently of precision if we assume two's complement.) > It might be simpler to just use the modular arithmetic flavor I agree that it would be simpler, but modular arithmetic is a common source of bugs, especially in languages where the modulo operation does not yield a nonnegative integer (grr). The bitwise formulations constitute useful guidance for the implementer. > Section 3.5.2 needs to explicitly say that the c and m arguments to M() > are the local link cost and the advertised metric, Done. > Section 3.8.2.1 notes that "[d]ue to duplicate suppression, only a small > number of such requests will actually reach the source." (for seqno > requests intending to avoid starvation). But Section 3.8.1.2 only has a > SHOULD-level requirement to suppress duplicate seqno requests, so I > think there is an internal inconsistency. The idea here is that it's a pretty strong SHOULD -- you'd need to be really constrained for resources to not implement it. If that's okay, I'll leave it as it stands, if that's okay with you. > I think we may need to have a discussion about the feasibility of > multicast acknowledgment requests with only a 16-bit nonce. Section 3.3. An acknowledgment MUST be sent to a unicast destination. > The discussion in Section 4.6.9 of computing the prefix from an Update > message (and parser state) seems a little underspecified when the prefix > length is not a multiple of 8 bits. Agreed, I've added the requirement to clear these bits. > (Additionally, "Plen" is not described as measuring bits, explicitly, > for any of the PDU descriptions that I remember.) Fixed. > I appreciate that we have some discussion in Section 4.5 about the need > for a stateful parser for the babel packet body; this seems like one of > the riskiest areas of the protocol from the implementation perspective. I fully agree. I've always had serious misgivings about this encoding, and we did discuss deprecating it in 6126bis. Here's some background. On the one hand, the encoding is inelegant and easy to get wrong, and hinders the extensibility of the protocol. On the other hand, it is dramatically effective in some kinds of networks (networks carrying large numbers of IPv6 host routes sharing a common prefix), leading to a reduction in the amount of data being sent, on the order of 40%. =20 Instead of carrying 40 prefixes in a packet, you carry 60. We did consider an alternative, which was to start the packet with a set of common prefixes that the individual updates could refer to. However, this turned out to have similar complexity at the parser, while making the formatter slightly more complex. An on-list poll of the implementers active at the time (from memory, so don't hold me accountable): - Markus said "the stateful encoding is not that bad"; - Toke declared he's okay with parsing the encoding, but his implementation is not going to send any compressed addresses; - I don't remember if David expressed an opinion, but since he's into wireless networks, I'd expect him to be in favour of keeping it. So we kept it. > However, I think it would be even more helpful to explicitly call out > what pieces of state are needed, what protocol elements affect the > state, and what ordering requirements (or non-requirements) there are > for the interactions between the different protocol elements that affect > parser state. Can we have a discussion about whether it's appropriate > to add some text along these lines? Sure, we may have a discussion. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > Should there be a "changes since RFC 6126" section that is retained in > the published RFC? (I assume that Appendix F is going to be dropped.) Is that a hard requirement? We've updated all implementations, so it wouldn't be too useful to anyone, and it would be a fair amount of work. > The secdir review has some good thoughts (e.g., tracking "link-local" > IPv4 addresses, discussion of non-protection from hostile insiders), but > I don't see a response to it. The review was sent to us off-list, and we replied in kind. Which points exactly did you find useful, and how would you like to see them integrated in the document? > We use the phrase "a small multiple of" a few times, but I don't > remember seeing any concrete guidance for what factor to use. Is it > intended to be closer to 1.1 or to 4? It's 3.5, see Appendix B. I've added refs at the relevant places. > In a related vein, there are many places in the document where the > precise details of processing are left intentionally underspecified > (e.g., computing a link's cost). I understand that due to the protocol > guarantees the needed routing will still be achieved even if nodes use > different parameters and algorithms in these cases, Right. > but do we expect the details to be chosen on a per-implementation basis, > or in profile documents, or even left up to operator configuration on > a per-node basis? I liken the situation to that of BGP, where routing policies are left to the implementation or to the network administrator. In the currently extant implementations, we use different algorithms depending on the link layer (Ethernet, WiFi or tunnel). In this document, we take the following approach: - the normative text stresses the properties that the algorithms used MUST meet; - we give examples of algorithms that work well in Appendix A; - we warn the implementer to be careful. =46rom an empirical point of view, this has worked pretty well: independent reimplementations interoperate. > Section 1 > The introduction should mention obsoleting 6126 and 7557, in addition to > doing so in the abstract. Done. > Section 1.1 > Finally, Babel is a hybrid routing protocol, in the sense that it can > carry routes for multiple network-layer protocols (IPv4 and IPv6), > whichever protocol the Babel packets are themselves being carried > over. > nit: I think "regardless of which" is better than "whichever", Agreed, done. > Section 1.2 > Second, unless the optional algorithm described in Section 3.5.5 is > implemented, Babel does impose a hold time when a prefix is > Similarly to my comment on the applicability doc, I'm not sure if > there's one or two things in Section 3.5.5 that would match this > description. I'm not sure what's missing. 3.5.5 clearly states that either you wait for a fixed timeout, or you do something that doesn't involve waiting for a fixed timeout. > Section 2 > Conceptually, Bellman-Ford is executed in parallel for every source > of routing information (destination of data traffic). In the > following discussion, we fix a source S; the reader will recall that > the same algorithm is executed for all sources. > Just to check my understanding: this "source S" is a source of routing > information, not a source of data-plane traffic being routed? Yes. Added paranthetical. > Section 2.4 > Is there a reference for AODV? Added. > To show that this feasibility condition still guarantees loop- > freedom, recall that at the time when A accepts an update from B, the > metric D(B) announced by B is no smaller than FD(B); since it is > smaller than FD(A), at that point in time FD(B) < FD(A). Since this > property is preserved when A sends updates, it remains true at all > times, which ensures that the forwarding graph has no loops. > I'm trying to walk through this and missing a step or two. "the metric > D(B) announced by B is no smaller than FD(B)" is pretty clear, since > FD(B) is just the minimum value of D(B) over time thus far. But I'm not > sure I follow how A can preserve the property FD(B) < FD(A) when A sends > updates. Clearly FD(B(T')) <=3D FD(B(T0)) for any time T' after T0, but > suppose FD(B) remains constant but A is off interacting with some other > node C and finds a great path via C, which correspondingly causes D(A) > to reduce. Can I get into a situation where > D(A) < FD(B) <=3D D(A) + C(A,B) (and thus, the subsequent > FD(A) < FD(B) <=3D FD(A) + C(A,B)) if A does not interact with B during > that time? We want to prove that the following property is preserved: P: NH(A) =3D B implies FD(B) < FD(A) Assume that initially the following are true: NH(A) =3D B (i) FD(B) < FD(A) (ii) A receives an announcement from C. Then either - A doesn't switch its next hop, in which case D(A) doesn't change, and so neither does FD(A); since FD(B) is nonincreasing, (ii) is still true, and P is true; or - A sets NH(A) :=3D C, so (i) becomes false, and P is true. > Section 2.5 > Using the minusculeu and majuscule forms of the same letter to mean > different things (e.g., source S and sequence number s) is something of > a readability anti-pattern. I agree. We need Greek letters in RFCs. (No Gothic, please.) > Section 3.2.6 > It would probably be helpful to readers to note that "neighbor that > advertised" and "next-hop" can be different due to being different > address families. They are completely different data structures. The neighbour is (a reference to) an entry of the neighbour table, the NH is an IP address. > Section 3.5.1 > (side note: I got a bit confused reading this section and had to go > double-check several definitions, due to the qualitative difference > between the "metric" and "metric'" under comparison. Namely, the > "metric" is for the path from neighbor to S, but the "metric'" is for > the path from the current node to S, and so in some sense they are > "measuring different things". Yeah, it's tricky. This is written with the implementer in mind, who's going to be manipulating, in C notation, update->metric (metric) source->metric (metric') Since this is the crucial part of the algorithm, it's written in a style that attempts to make it as easy as possible to check the implementation against the spec -- you can basically transliterate the RFC into your favourite programming language. > Perhaps using "FD" instead of "metric'" would help disambiguate. I think we're fairly consistent at using "metric" for a metric and "distance" for a pair (seqno, metric). Let me know if you find any counter-examples. > router-id. Feasibility distances are maintained in the source table, > the exact procedure is given in Section 3.7.3. > nit: this is a comma splice. I've made it into a colon; I don't like semicolons. > Section 3.5.2 > Note that while strict monotonicity is essential to the integrity of > the network (persistent routing loops may arise if it is not > satisfied), left distributivity is not: if it is not satisfied, Babel > will still converge to a loop-free configuration, but might not reach > a global optimum (in fact, a global optimum may not even exist). > I might even go so far as to say that a global optimum "will likely not > exist", though this is fairly qualitative/intuitive since we don't > define a configuration space or metric over it in which to evaluate the > probability. I agree with your intuition. I think it should be possible to give a proof for random graphs, but it's not obvious to me whether they are representative of real networks. If you're interested, you should have a chat with Sobrinho. > Section 3.5.4 > We don't seem to use the "link cost value equal to cost" anywhere in > this section, so maybe it is superfluous. Good catch, thanks. Fixed. > If such an entry exists: > o if the entry is currently selected, the update is unfeasible, and > the router-id of the update is equal to the router-id of the > entry, then the update MAY be ignored; > I guess the idea is that we can keep the old one around until it would > time out, since the initial timeout value for it means it should still > be workable until our timer expires, but it's only a MAY in case we want > to be more proactive about noticing that the advertised metric is now > unfeasible? In this case, the local node needs to predict the future in order to make the optimal decision. The minor details of predicting the future are left to the implementation. However, the consequences of getting it wrong are harmless, so predicting the future is left at MAY level. This is unlike Brexit. For this case to trigger, the neighbour needs to have increased its metric enough to make us unfeasible (intuitively, the feasibility condition is able to buffer up to one hop of metric instability), but without itself becoming unfeasible (otherwise it would have sent us a new seqno). That means that there's some instability exactly one hop upstream. And now you need to predict the future: - either this is just a short-term fluctuation, the metric will decrease at the next update, so it's best to stick to the current route; - or this is indicative of our current route getting bad, so it's better to drop it and start hunting for a better one. My intuition is that it's best to ignore the MAY unless your current route is the only route to the destination, but I don't have any hard data to back it. At any rate, it's a fairly rare edge case, one that's not going to happen much in real networks, and both choices are correct. The MAY is intended to communicate that the implementer shouldn't bother with this case, unless he knows better. > Section 3.5.5 > o sending a retraction with an acknowledgment request (Section 3.3) > to every reachable neighbour that has not explicitly retracted > prefix P and waiting for all acknowledgments. > nit(?): I'd suggest a comma before "and waiting for all > acknowledgments", since that's the final gating factor to achieve the > goal. Ack. > The former option is simpler and ensures that at that point, any > routes for prefix P pointing at the current node have expired. > However, since the expiry time can be as high as a few minutes, doing > that prevents automatic aggregation by creating spurious black-holes > for aggregated routes. The latter option is RECOMMENDED as it > dramatically reduces the time for which a prefix is unreachable in > the presence of aggregated routes. > nit: I don't think this "prevents automatic aggregation" at a technical > level, but rather that it "makes automatic aggregation rather unusable > in practice" since if automatic aggregation is used, any route > retraction will result in a spurious blackhole for the (minutes) expiry > time, which is unacceptable for most environments. =46rom a technical point of view, you're right. I'm leaving the current formulation, though, I want to be very clear that it doesn't work in practice (or at least I don't know how to make it work). (It pains me. I know of at least one (not public) application of Babel where automatic aggregation would be useful. So if anyone has any ideas about how to make it work, I'm listening.) > Section 3.7 > Additionally, in order to ensure that any black-holes are reliably > cleared in a timely manner, a Babel node sends retractions (updates > with an infinite metric) for any recently retracted prefixes. > Is the sending of retractions the one described by the SHOULDs in 3.7.2? > If so, I'm not sure that "a Babel node sends retractions for any > recently retracted prefixes" is quite accurate (since SHOULD is not a > mandatory requirement); "can send" or "will generally send" might be > better. Agreed, tweaked. > Section 3.7.1 > Every Babel speaker periodically advertises all of its selected > routes on all of its interfaces, including any recently retracted > routes. Since Babel doesn't suffer from routing loops (there is no > "counting to infinity") and relies heavily on triggered updates > (Section 3.7.2), this full dump only needs to happen infrequently. > Part of the need for the full dump stems from the potential for > unreliable links, right? My intuition was iniially be the same as yours, but unreliable links turn out to be the last of our problems. We'd be using Acks more extensively otherwise. The main issue is recovery after mobility: the node has moved away, it has lost all of its neighbours, you need to rediscover all routes. If you're using link-quality estimation, you cannot easily detect this situation, so you cannot simply send a wildcard request. Until you receive a full update, you're not going to switch to your new neighbours. > Do we want to mention that relationship here, (and that if there are > particularly unreliable links the frequency may need to be more often)? I've tried to clarify this in the new version of Appendix B. > Section 3.8.1.2 > We haven't introduced "hop count" yet and just mention it in passing > here as "[if the] hop count is 2 or more". DOne. > Intuitively, it seems like the routr should send an update if the > router-ids match and the requested seqno is equal to the route entry's > seqno, but I don't see this case covered in the current text. > o otherwise, if the node has one or more (not necessarily feasible) > routes to the requested prefix with a next hop that is not the > nit: I think the parenthetical can just be "not feasible", as any > feasible routes in question would have matched the previous bullet > point. Done. > neighbours. However, if a seqno request is resent by its originator, > the subsequent copies MAY be forwarded to a different neighbour than > the initial one. > Is MAY the appropriate level of strength? Trying the same neighbor > would be effective if the original was unsuccessful due to packet loss, > but is it possible for a routing pathology to occur that directs the > request in the "wrong direction" with respect to a link or node failure? Yes, that's possible if multiple nodes become unfeasible simultaneously. (If that happens, then the mechanism in 3.8.2.2 will eventually clear the blackhole.) =46rom an implementation point of view, you route each seqno request independently. The MAY in this section simply means that you don't need to keep track of the neighbour you previously sent the request to. > Section 3.8.2.4 > Is it worth giving some informal guidance about not sending multicast > wildcard requests if a node observes others doing the same around the > same time (or similar) to avoid the "serious congestion" issues? This section has been removed. > Section 4.2 > A Babel packet consists of a 4-octet header, followed by a sequence > of TLVs (the packet body), optionally followed by a second sequence > of TLVs (the packet trailer). > Without mention of the 'body length' field here, a reader might be > confused at what distinguishes the body TLVs from the trailer TLVs. I'm leaving it as it stands, I think the text is clear. > The packet body and trailer are both sequences of TLVs. The packet > Ibody is the normal place to store TLVs; the packet trailer only > contains specialised TLVs that do not need to be protected by > cryptographic security mechanisms. > I think we need a more explicit statement that the body structure is > subject to change when security mechanisms are in use, to allow for > potential confidentiality-protecting cryptographic mechanisms. > Section 4.3 > Length is still in octets, right? Fixed. > Section 4.4 > Every TLV carries an explicit length in its header; however, most > TLVs are self-terminating, in the sense that it is possible to > determine the length of the body without reference to the explicit > Length field. If a TLV has a self-terminating format, then it MAY > allow a sequence of sub-TLVs to follow the body. > This seems like a statement of fact, for which a lowercase "may" is > perfectly adequate. Fixed. > Sub-TLVs have the same structure as TLVs. With the exception of > PAD1, all TLVs have the following structure: > I was going to complain that it's somewhat unfortunate to use the same > name for a thing that's a TLV and a thing that's a sub-TLV, even if they > have identical encodings. But then I noticed that in this (sub-TLV) > section we spell it "PAD1" and in the previous (TLV) section we spell it > "Pad1", which are different. On the gripping hand, Sections 4.6.1 and > 4.7.1 both spell it "Pad1", which are the same. So a little bit of > effort rationalizing things would go a long way. This is meant to be Pad1. In practice, we have found that there is no confusion. > The most-significant bit of the sub-TLV, called the mandatory bit, > Just to be clear: this is the MSB of the 'type' octet? This has been clarified. > Also, for similar features in other protocols I've suggested the > clarifying language of "comprehension-mandatory" which seems to more > accurately reflect the corresponding behavior. I'm afraid it's too long, people won't use it in conversation. > Section 4.5 > Since the parser state is separate from the bulk of Babel's state, > and since for correct parsing it must be identical across > implementations, it is updated before checking for mandatory TLVs: > nit: "mandatory sub-TLVs" (right?) Fixed, thanks. > Section 4.6.2 > MBZ Set to 0 on transmission. > Is it legal for a receiver to check and abort if any bits are nonzero? If we want to be consistent with the rest of Babel, it is legal to check and to ignore this TLV. Since this TLV is ignored in any case, the distinction is somewhat uninteresting. (I guess you're thinking about adding noise for security purposes. Please define a new TLV if that's required, I prefer protocol extensions to be explicit about their intent.) > Section 4.6.3 > Sixteen bits of nonce does not provide much unguessability (I note that > LISP's rfc6830bis is recommending that their 24-bit nonce echo > functionality not be relied on for return-routability checks over the > public Internet). However, since these acknowledgment exchanges are > only between direct neighbors, it seems that they are only needed for > correlating responses to requests and not for unguessability. (In this > case it seems a sequence number would work just as well as a random > number, and we might want to discourage random assignment in the text to > avoid the risk of birthday collisions.) > On the other hand, multicast acknowledgment requests could be > problematic (and especially so when sequential nonces are used), and if > they are intended to be allowed then we may need to consider using a > larger and random nonce. Section 3.3: An acknowledgment MUST be sent to a unicast destination. > Section 4.6.6 > I'm getting some sever cognitive dissonance between the "Rxcost" field > and the "carrying a link's transmission cost" statement. Also, in > Rxcost The rxcost according to the sending node of the interface > whose address is specified in the Address field. The value > FFFF hexadecimal (infinity) indicates that this interface > is unreachable. > if I insert commas to get "The rxcost, according to the sending node [of > the TLV], of the interface whose address is specified in the Address > field", does that preserve the intended meaning? > nit/aside: It also feels like there's a bit of a mismatch here, in that > the "rxcost of the interface" probably means the local interface (from > the perspective of the sender), but that interface is being identified > by the *remote* address (again, from the perspective of the sender of > the TLV). So maybe "whose remote address" could resolve the mismatch > I'm perceiving? (Or maybe I'm completely misunderstanding, of course.) > Interval An upper bound, expressed in centiseconds, on the time > after which the sending node will send a new IHU; this MUST > NOT be 0. [...] > To check my understanding: are the IHUs conceptually a reply to Hellos, > such that if the Hellos stopped arriving then the peer would stop > sending IHUs in response? I understand that their intervals are set > completely independently, so there is not a direct causal relationship, > but I'm trying to check whether the quoted sentence is a strict > commitment by the sender of the IHU or could be rescinded due to > external events. This is used to set the IHU timer, described in 3.4.2: When a neighbour's IHU timer expires, the neighbour's txcost is set to infinity. > Section 4.6.9 > If the Metric field is finite, the router-id of the originating node > for this announcement is taken from the prefix advertised by this > Update if the Router-Id flag is set, computed as described above. > Otherwise, it is taken either from the preceding Router-Id packet, or > the preceding Update packet with the Router-Id flag set, whichever > comes last, even if that TLV is otherwise ignored due to an unknown > mandatory sub-TLV. > Both cases of "packet" here should be "TLV", right? Fixed, thanks. > Section 5 > "Specification Required" also requires Expert Review. What guidance can > we provide to the experts for making registration decisions? I don't think there's WG consensus on this subject. I am in favour of being very liberal (since the alternative incurs the risk of people squatting our codepoints), but if memory serves at least one WG member argued in favour of "RFC required". I'm not too worried, though. Right now, there is only one nonofficial protocol extension used in production that I know of, and it's completely incompatible with the protocol (it doesn't use sub-TLVs, it savagely appends extra data to the Update TLV). No self-respecting expert would approve such an extension. I think we can deal with that issue when the problem occurs. > Section 6 This section has been completely rewritten. > "periodically" may not be the best advice; coupling such changes to > mobility events is likely to be more effective at preserving privacy. > (QUIC has discussed related topics quite extensively, though there's > enough traffic in the archives that I can neither point you at a > specific thread or recommend searching for it.) Changed to "often enough". > Section 8.2 > I think at least BABEL-HMAC needs to be normative, since it is > RECOMMENDED. Done. > Section A.1 > If we're talking about "appending bits" to the history fields, maybe > describing them as fixed-length queues or something makes more sense > than vectors. I think the current formulation is clear. > If the field is maintained in a 16-bit integer, what is done for the > previously erased bits when we "undo history"? It doesn't matter, these are low-order bits, they're not going to contribute to any of the computed values. 0 is he obvious value. > Whenever either Hello timer associated to a neighbour expires, the > local node adds a 0 bit to this neighbour's Hello history, and > We keep two hello histories; we should clarify that the one in question > is the one corresponding to the timer that expired. Done. > Section A.2.2 > I don't understand the origin of the '256' in the MIN(1, 256/txcost) > formula (described as a probability estimate). We scale the values to fit in a 16-bit integer field without excessive loss of precision. > I think a lot more work is needed to convince me that the two given > formulae for "cost" are equivalent (especially given that 'rxcost' only > appears once in the entire section, in the second formula). I've added explicit mention of the fact that rxcost =3D beta * 256, which is possibly what you were missing. 256/(alpha * beta) =3D 256 / (MIN(1, 256 / txcost) * beta) =3D MAX(256 / 1, 256 / (256 / txcost)) * (rxcost / 256) =3D (MAX(txcost, 256) * rxcost) / 256 > Section A.3.2 > Is k "allowed to" (I know this section is just informative) vary on > non-external data, such as the route or link in question? I've removed this paragraph. Nobody's ever implemented this suggestion, the new appendix about filtering is more informative. (Comma splice, I know.) > Appendix C > I could see this content in the main body of the document. I've rewritten this appendix, and referenced it in a few more places in the body. I've got no strong opinions either way, and unless there's any strong opinions, I'll leave it as it is. -- Juliusz From nobody Fri Aug 9 19:35:39 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 0341012016E; Fri, 9 Aug 2019 19:35:38 -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 ZZSs9eiQOWhp; Fri, 9 Aug 2019 19:35:36 -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 D94C3120120; Fri, 9 Aug 2019 19:35:35 -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 x7A2ZP1W021970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 10 Aug 2019 04:35:25 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x7A2ZPdV018926; Sat, 10 Aug 2019 04:35:25 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C0FC0350DE; Sat, 10 Aug 2019 04:35:27 +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 X2zXmOGtPPec; Sat, 10 Aug 2019 04:35:26 +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 6D379350DB; Sat, 10 Aug 2019 04:35:26 +0200 (CEST) Date: Sat, 10 Aug 2019 04:35:26 +0200 Message-ID: <87tvap7no1.wl-jch@irif.fr> From: Juliusz Chroboczek To: Alissa Cooper Cc: "The IESG" , draft-ietf-babel-rfc6126bis@ietf.org, d3e3e3@gmail.com, babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156526956251.7467.592630566164228470.idtracker@ietfa.amsl.com> References: <156526956251.7467.592630566164228470.idtracker@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]); Sat, 10 Aug 2019 04:35:25 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 10 Aug 2019 04:35:25 +0200 (CEST) X-Miltered: at korolev with ID 5D4E2D6D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D4E2D6D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4E2D6D.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D4E2D6D.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 : 5D4E2D6D.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D4E2D6D.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] Alissa Cooper's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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, 10 Aug 2019 02:35:38 -0000 Dear Alissa, > I support Roman's DISCUSS. There are no less than 7 points raised by Roman in his Discuss. We have tried our best to answer them, please let us know which are the ones you feel strongly about and whether you feel we have answered them to your satisfaction. > I'm also unclear on the over-arching recommendation this document is > making for securely deploying this protocol. Given that the protocol > itself is insecure, I would have expected some normative requirement for > correcting that (e.g., Minimally, Babel deployments MUST be secured > using a lower-layer security mechanism, Babel over DTLS, or HMAC-based > authentication.) This still would not bring it into line with BCP 61 > Section 7, but perhaps there is some argument for making an exception > for this protocol. Section 6 of RFC 6126bis describes the two inline security mechanisms developed for Babel (Babel-DTLS and Babel-HMAC), and recommends that Babel-HMAC should be used in preference to Babel-DTLS unless confidentiality or asymmetric keying is required. We do not think, however, that marking either of these protocols as MTI would have a positive outcome, either for the security of the Internet, for the Babel protocol, the Babel standardisation process, or the already somewhat frayed reputation of the IETF in the free software community. Please let me give you some background. Our decision to go to IETF for standardisation was criticised by part of our user base, who felt that it would push the protocol in a direction that is not directly useful to them. Indeed, before Babel became an IETF protocol, its development was driven by the needs of our users. While this is still the case to a great extent, going to the IETF has meant that we had to suspend development of Babel for many months while we worked on Babel-DTLS and Babel-HMAC, that were both developed not to meed the needs of our user community, but solely to satisfy the requirements of the IETF and the potential future needs of the IETF Homenet WG. Babel-DTLS and Babel-HMAC have been duly developed, implemented and documented in the form of their respective internet-drafts. We have made the code publicly available, and are encouraging our users to consider with the new technologies. However, we do not feel entitled to impose any more on our users. If the Babel user community decide that they do not want to carry code for security protocols that they are not using, there is nothing we can do to force them. Thus, making either security protocol MTI at this time would have one of the following consequences: - it would either force a majority of our users to carry code that they do not use, which would fail to improve security in any significant way but cause further resentment against us and against the IETF; or - it would force a majority of the deployed implementations of Babel to become non-compliant, with no improvement security but with a resulting dilution of the authority of the IETF. Either outcome would fail to improve security in any meaningul way, while being bad for us, bad for our users, and bad for the reputation of the IETF. For this reason, we respectfully request that this document should be allowed to advance without either protocol being marked mandatory to implement. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > I support Suresh's DISCUSS. I have tried to answer it. > An explanation of why this document obsoletes RFC 6126 and RFC 7557 needs to > appear in the introduction of this document. Could you please give me an example of suitable text? > Section 3.2.3: It's a bit odd that the Multicast Hello is introduced here but > the difference between the two kinds of hellos is not explained until Section > 3.4.1. It makes me wonder if 3.2 should come after 3.4. Section 3.2 defines the (conceptual) data structures. The reset of Section 3 describes how they are used. There are many more instances of data structures that are defined in Section 3.2 and not used until later. > Section 3.6: s/is not left-distributive Section 3.5.2/is not left-distributive > (Section 3.5.2)/ Fixed. > Appendix C: This section should be in the body of the document. (This is now Appendix D.) This is an informative section, and is of no interest to implementers of the base protocol. I believe it should remain an appendix. -- Juliusz From nobody Fri Aug 9 19:55:28 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 6FCB3120120; Fri, 9 Aug 2019 19:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nO4dZU3cFn84; Fri, 9 Aug 2019 19:55:23 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 2B6B11200B4; Fri, 9 Aug 2019 19:55:22 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7A2tGEU030293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 9 Aug 2019 22:55:19 -0400 Date: Fri, 9 Aug 2019 21:55:15 -0500 From: Benjamin Kaduk To: David Schinazi Cc: The IESG , draft-ietf-babel-dtls@ietf.org, Donald Eastlake , babel-chairs , Babel at IETF Message-ID: <20190810025515.GA48324@kduck.mit.edu> References: <156521337799.8333.13258734665763149206.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT) 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, 10 Aug 2019 02:55:26 -0000 On Fri, Aug 09, 2019 at 02:21:08PM -0700, David Schinazi wrote: > Thanks for your review Ben! We've incorporated your comments into our > working copy and we'll publish > a revised draft shortly. Detailed responses inline. > > Thanks, > David > > > On Wed, Aug 7, 2019 at 2:29 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I support Roman's Discuss point (1) (and basically cover the same as his > > (2) below). > > > > Let's have a discussion about (DTLS) identity. > > Section 2.1 says that we use mutual authentication and that > > implementations "MUST support authenticating peers against a local store > > of credentials"; also that "if a node receives a new DTLS connection > > from a neighbour to whom it already has a connection, the node MUST NOT > > discard the older connection until it has completed the handshake of the > > new one and validated the identity of the peer". But how does this > > authentication occur, and what constitutes the identity of the peer. We > > will frequently have (D)TLS consumers cite RFC 6125 and say that (e.g.) > > DNS-ID or SRV-ID must match the name obtained in some fashion. But for > > Babel, we are authenticating routers -- router identity is usually in > > the form of just an IP address on a loopback interface! Are we expected > > to get certificates that certify IP addresses as identity, or use some > > sort of PSK or password-based TLS authentication? (The last two are not > > really compatible with the "MUST send a CertificateRequest", BTW.) Raw > > public keys? I think we can give a more clear picture of how to build a > > secure system. > > > > Our intent in this document was to leave the complex question of identity > to deployment profiles. For example, the homenet working group is interested It would be a fine thing to say explicitly that the details of identity and authentication are left to specific profiles. > in potentially using Babel over DTLS to protect routing inside the home. > The idea there being that each router you buy has an identity, and then > there > would be some process to let your existing routers know about the new > router you just bought. However, homenet has not yet solved how to do this. > They may choose to use self-signed certificates and develop a provisioning > mechanism to share them. They could also decide to use raw keys. Our > goal with the present draft is to define how one runs Babel over DTLS. > I imagine that if homenet decides to use Babel over DTLS, they'll publish > another document explaining how to manage identities. > > I would prefer not having this document be too prescriptive with regards > to identities, because that could prevent some deployment profiles. > But I'm happy to add guidance for writers of deployment profiles. Do you > have thoughts on what such guidance would look like? > > That said I've removed the mention of CertificateRequest since as you > pointed out that's too restrictive. > > Relatedly, once DTLS authenticates an identity, what level of > > authorization checks are performed? Are we still in a single > > authorization domain, where any router that authenticates as being part > > of a given domain is implictily authorized to be a babel peer and convey > > any and all routing information? > > > > It's a single authentication domain. We've added text in the document to > clarify that. > > > > We should also give some guidance on ciphers and algorithms where we > > discuss the DTLS details (BCP 195 is probably the safest bet here, even > > if it's a little in need of an update). > > > > We have a reference to BCP195, did you have anything else in mind? No, that should be okay. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 1.2 > > > > The protocol described in this document protects Babel packets with > > DTLS. As such, it inherits the features offered by DTLS, notably > > authentication, integrity, replay protection, confidentiality and > > asymmetric keying. It is therefore expected to be applicable in a > > > > replay protection is not an inherent feature of DTLS, so I suggest > > "optional replay protection" to emphasize that an implementation of > > babel may need to explicitly configure it. > > > > We already have this text in section 2.1: > Nodes MUST use DTLS replay protection to prevent attackers > from replaying stale information. > Is there something we should add to that? I did see that text in 2.1, which is why this comment was less strongly worded. I am interpreting the text I quoted as a description of what functionality DTLS does and can provide, and in that context, DTLS provides optional replay protection. If your implementation doesn't offer it, or you don't turn it on; you're not protected. It seems like it would misconstrue things to imply that DTLS always provides replay protection, since that's not the case! > > > There exists another mechanism for securing Babel, namely Babel HMAC > > authentication [BABEL-HMAC]. HMAC only offers basic features, namely > > authentication, integrity and replay protection with a small number > > of symmetric keys. A comparison of Babel security mechanisms and > > > > Even the authentication is limited, as it is group authentication, not > > true per-entity authentication. > > > > That is true. We've fleshed out the text in RFC6126bis that compares both > mechanisms. Excellent. (Roman said it really well when he noted that it would be good to have alignment across the three documents.) > > > Section 2.1 > > > > information last longer. If a node receives a new DTLS connection > > from a neighbour to whom it already has a connection, the node MUST > > NOT discard the older connection until it has completed the handshake > > of the new one and validated the identity of the peer. > > > > (Does the validated identity of the peer have to match the one from the > > previous handshake?) > > > > It doesn't. Conceptually there is a single security domain so as long as > the credentials are valid you're free to stomp on previous connections > from other IPs. Okay (and the current text is fine for this desired behavior). > > > Section 2.3 > > > > I agree with the RtgDir reviewer that unprotected (multicast) Hellos are > > at risk of tampering by an attacker, who could drop them or modify the > > seqno/interval, for DoS purposes. > > I see the text about use of multicast Hellos for discovery and the > > acknowledgment that an out-of-band neighbor discovery mechanism may be > > available. Are there any such discovery mechanism under development? > > > > There aren't, at least not as standards. This text is there to accommodate > implementations/deployments that already have a non-standard out-of-band > discovery mechanism. "standard" is a touchy term here in the IETF :) But I take it there are no published drafts or similar, either, in which case there's not anything we can make an informative reference to, which is what I was really getting at. > > > Regardless, I think we should consider mandating/suggesting (to some > > strength; maybe SHOULD is enough) the use of protected unicast Hellos > > instead of just stating that nodes can either rely on multicast or send > > protected unicast Hellos. When unicast (protected) Hellos are in use, > > even tampering with multicast Hellos will not be enough to cause a DoS > > attack, since a node must be detected as down on both unicast and > > multicast to be considered gone. (Of course, a sufficiently powerful > > attacker can still just drop all traffic and cause DoS.) > > > > The issue here is that multicast and unicast don't behave the same way > at the link layer. We've found empirically that ETX is a great way to > assess wireless link quality but that requires sending hellos over > multicast. > https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-12#appendix-A.2.2 Ah, yes, that was some interesting discussion to read -- automatic compensation in the lower layer causing problems for higher-layer recovery. > That said, we added the following text to security considerations: > Babel over DTLS allows sending multicast Hellos unprotected; attackers > can > therefore tamper with them. For example, an attacker could send > erroneous > values for the Seqno and Interval fields, causing bidirectional > reachability detection to fail. While implementations MAY use > multicast Hellos > for link quality estimation, they SHOULD also emit protected unicast > Hellos to > prevent this class of denial-of-service attack. That is actually exactly the sort of thing I was looking for; thank you! > Section 2.4 > > > > Note that receiving an unprotected packet can still be used to > > discover new neighbours, even when all TLVs in that packet are > > silently ignored. > > > > Is this going to cause a lot of spurious DTLS handshake attempts if we > > ever end up with a babel-dtls implementation adjacent to a > > classic-babel-only implementation? Is there any rate limiting on that? > > > > Good point. We've added a "Simultaneous operation of both Babel over > DTLS and unprotected Babel on a Network" section containing: > If Babel over DTLS and unprotected Babel are both operated on the same > network, the Babel over DTLS implementation will receive unprotected > multicast > Hellos and attempt to initiate a DTLS connection. These connection > attempts > can be sent to nodes that only run unprotected Babel, who will not > respond. Babel over DTLS implementations SHOULD therefore rate-limit > their > DTLS connection attempts to avoid causing undue load on the network. > > > > Section 2.5 > > > > Do we want to talk about the potential consequences of an attacker > > arbitrarily delaying valid content (to justify the need for a timeout)? > > > > The section currently states: > This attack could be used to make a node believe it has bidirectional > reachability to a neighbour even though that neighbour has disconnected > from the network. > What more did you have in mind? Well, I hadn't thought it through fully. But would it be possible to delay distribution of metric updates, leading to the victim selecting an alternate path than it would have otherwise (whether to cause performance degredation or make the data-plan traffic go through a place that's easier to attack, or otherwise)? It seems that the need for liveness detection would place time bounds on such an attack unless the attacker can selectively drop DTLS datagrams and there are Hellos not piggybacked on the traffic that is targeted. I forget how much tolerance for such drastic reordering there would be. > > > Section 2.6 > > > > A node MAY allow configuration options to allow unprotected Babel on > > some interfaces but not others; this effectively gives nodes on that > > interface the same access as authenticated nodes, and SHOULD NOT be > > done unless that interface has a mechanism to authenticate nodes at a > > lower layer (e.g., IPsec). > > > > I'm unhappy that this SHOULD NOT is not a MUST NOT, but cannot quite > > justify making it a Discuss-level point. > > > > The rationale for the SHOULD was to allow deployments that we hadn't > thought of. I think the text makes it clear what will go wrong if you do > this. It does, and I appreciate the new text about segregation by interface. > > > Section 3 > > > > IP, UDP and DTLS. Nodes MUST NOT send Babel packets larger than the > > attached interface's MTU adjusted for known lower-layer headers (at > > least UDP and IP) or 512 octets, whichever is larger, but not > > exceeding 2^16 - 1 adjusted for lower-layer headers. Every Babel > > speaker MUST be able to receive packets that are as large as any > > > > Aren't these requirements just duplicating what's in 6126bis? We > > probably don't need to repeat the normative language, at least, even if > > there's a desire to repeat the content. > > > > These requirements mimic the ones in 6126bis, but with the addition of DTLS > in the list of underlying layers that add overhead. This section references > the > appropriate section in 6126bis so readers can compare them if need be. I carefully trimmed the sentences that actually mentioned DTLS; "adjusted for known lower-layer headers" is the key phrase (happens twice) that I thought was used unchanged. (But I didn't do a word-by-word comparison.) > > > Note that distinct DTLS connections can use different ciphers, which > > can have different amounts of overhead per packet. Therefore, the > > > > nit: I think the intention here was "per-packet overhead", though the > > statement is true as currently written (due to variable length padding > > for block ciphers). > > > > I'm not sure I understand, are you saying there is a difference between > the terms "overhead per packet" and "per-packet overhead" ? "different amounts of overhead per packet" implies something whose magnitude varies on a packet-by-packet basis, potentially drastically so, whereas "different amounts of per-packet overhead" is more of a fixed (potentially range) of overhead across all packets in question. (And yes, I know that CBC padding can fall into the former!) > > > Section 5 > > > > The RFC 7525 ref is probably better spelled as BCP 195, and arguably > > moved earlier in the text (i.e., where I mentioned it previously). > > > > Done. > > > > A malicious client might attempt to perform a high number of DTLS > > handshakes with a server. As the clients are not uniquely identified > > by the protocol and can be obfuscated with IPv6 temporary addresses, > > a server needs to mitigate the impact of such an attack. Such > > > > nit: they're not uniquely identified by the protocol *until the > > handshake completes* -- our requirement for mutual authentication will > > cause all valid clients to be identified. However, the DoS risk does > > not require the client to let the handshake complete, so the core > > statement here remains valid. It may also be worth mentioning > > "Slowloris"-style attacks that keep handshake state active for as long > > as possible to increase resource consumption. > > > > Agreed. Added "until the handshake completes" and reference to Slowloris. Thanks. Though, hmm, if we do TLS-pwd with a single "network password", then we only get identification and not "unique identification". But I don't feel a need to excessively wordmsith this. > Section 6.2 > > > > DTLS-CID needs to be normative if it is a MAY-level feature. (See > > https://www6.ietf.org/iesg/statement/normative-informative.html .) > > > > I've replaced "MAY" with "could" and kept this informative. DTLS-CID > is not an optional feature of Babel over DTLS, it's just an informative > pointer to a DTLS feature. (I don't want to make this normative as that > would create a blocking dependency on publication of that draft.) Sure! > > > RFC 7525 (i.e., BCP 195) definitely needs to be normative, as a > > MUST-level requirement! > > > > Good catch, done. Thanks for all the updates, Ben From nobody Sat Aug 10 03:35:31 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 A03AE12008C; Sat, 10 Aug 2019 03:35:22 -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.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156543332258.3628.11438225871774118723@ietfa.amsl.com> Date: Sat, 10 Aug 2019 03:35:22 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-rfc6126bis-13.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, 10 Aug 2019 10:35:23 -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-13.txt Pages : 66 Date : 2019-08-10 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-13 https://datatracker.ietf.org/doc/html/draft-ietf-babel-rfc6126bis-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-rfc6126bis-13 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 Aug 10 03:51:22 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 AAD1A1200CC; Sat, 10 Aug 2019 03:51:20 -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 V-j7kYVYzX4R; Sat, 10 Aug 2019 03:51:17 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B32120089; Sat, 10 Aug 2019 03:51:16 -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 x7AApB0Q004427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 10 Aug 2019 12:51:11 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x7AApBUf009106; Sat, 10 Aug 2019 12:51:11 +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 7760E361D0; Sat, 10 Aug 2019 12:51:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id I-PBHn2bYws1; Sat, 10 Aug 2019 12:51:12 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 68A90361CC; Sat, 10 Aug 2019 12:51:12 +0200 (CEST) Date: Sat, 10 Aug 2019 12:51:11 +0200 Message-ID: <87h86pcmzk.wl-jch@irif.fr> From: Juliusz Chroboczek To: Benjamin Kaduk Cc: "The IESG" , draft-ietf-babel-hmac@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156521429138.8333.12124544758210076970.idtracker@ietfa.amsl.com> References: <156521429138.8333.12124544758210076970.idtracker@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]); Sat, 10 Aug 2019 12:51:11 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 10 Aug 2019 12:51:12 +0200 (CEST) X-Miltered: at korolev with ID 5D4EA19F.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D4EA19F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D4EA19F.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D4EA19F.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 : 5D4EA19F.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D4EA19F.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] Benjamin Kaduk's Discuss on draft-ietf-babel-hmac-08: (with DISCUSS and COMMENT) 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, 10 Aug 2019 10:51:21 -0000 Dear Benjamin, Thank you for your review. > Are the HMAC keys required to be the hash function's block size or its > output size? Section 3.1 says just "the length of each key is exactly > the hash size of the associated HMAC algorithm", and "hash size" > conventionally refers to the output length. The referenced Section 2 of > RFC 2104 concerns itself with the hash's compression function's block > size B, which is generally different. The block size, good catch. > Also in Section 3.1, if we are going to claim that a "random string of > sufficient length" suffices to initialize a fresh index, we need to > provide guidance on what constitutes "sufficient length" to achieve the > needed property. Section 6 says This property can be satisfied either by using a cryptographically secure random number generator to generate indices and nonces that contain enough entropy (64-bit values are believed to be large enough for all practical applications), or by using a reliably monotonic hardware clock. > Blake2s is a keyed MAC, but is not an HMAC construction. If we are to > allow its usage for providing integrity protection of babel packets > directly, we therefore cannot refer to the preotection scheme as "HMAC" > generically. Fixing this will, unfortunately, be somewhat invasive to > the document, since we mention HMAC all over the place. I believe that > "Keyed Message Authentication Code (Keyed MAC)" is an appropriate > replacement description. I disagree. While you're technically correct, for the typical network operator "HMAC" is a familiar term, "Keyed MAC" is not. I think that renaming this document to "Keyed MAC" would make it less informative. > The suggestion that the large challenge nonce size admits storage of > state in a secure "cookie" in the nonce is true, however, implementing > this properly presents some subtleties, and it seems like something of > an attractive nuisance to suggest that it is possible without giving > adequate guidance at how to do it safely. Unfortunately, the best > reference I can think of, offhand, is the obsoleted RFC 5077. I agree. This is something that we considered in the design of the protocol (which is why Nonces are allowed to be so large), but never implemented ourselves; it would probably be some work to get it right. Hence the very careful formulation ("might"). Let me know if you want to suggest a different formulation. > Let's also have a discussion about whether 64 bits of randomness is > always sufficient; I left a longer note down in the Comment since I > don't expect this to end up being a blocking point. Let's. See below. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > This is a symmetric-keyed scenario, so most attacks that involve a > compromised node will be "uninteresting", in that once the key is > exposed all guarantees are lost. However, it may still be worth noting > that a compromised node can cause disruption on multi-access links > without detection since there is no "end of generation" signal when a > node changes its index. That is, if node B reboots or otherwise resets > its index/pc, then compromised node C can spoof packets from B with the > previous index and honest node A will accept them, and B will be unable > to detect that it has been spoofed. On the flip side, we may want to > discuss that B can watch for messages that spoof its source address to > detect compromised nodes. I may be misunderstanding what you mean, but I think that's not the case. If B reboots, then: - if A has state about B, then any previous PC will be rejected; - if A has no state about B, then A will send a challenge which C won't - be able to reply to. Are we misunderstanding each other? > Is there any need for initial PC value randomization? I don't see why. > Do we want to recommend starting at 0 or 1 (or prohibit recipients from > assuming that the initial value for an index will be that)? The initial value as well as the rate of increase are arbitrary. For example, a node may use a hardware clock (suitably offset to fit in 32 bits) as the PC. > Section 1 > "This document obsoletes RFC 7298" should be in the Introduction as well > as the abstract. Done. > Is the capability for an attacker to modify/spoof Babel packets in > order to cause data to get dropped or cause a routing loop worth > mentioning here? No, that's a particular case of redirecting. > Section 1.2 > o that the Hashed Message Authentication Code (HMAC) being used is > invulnerable to pre-image attacks, i.e., that an attacker is > unable to generate a packet with a correct HMAC; > I think it's more conventional to include the caveat "without [access > to/knowledge of] the secret key" for this sort of statement about HMAC. Agreed, done. > The first assumption is a property of the HMAC being used. The > second assumption can be met either by using a robust random number > generator [RFC4086] and sufficiently large indices and nonces, by > using a reliable hardware clock, or by rekeying whenever a collision > becomes likely. > Does this rekeying option require an external operation/management actor > to trigger it? It might be worth mentioning with some operational > considerations. Disagree. > o among different nodes, it is only vulnerable to immediate replay: > if a node A has accepted a packet from C as valid, then a node B > will only accept a copy of that packet as authentic if B has > accepted an older packet from C and B has received no later packet > from C. > nit: I don't think "A has accepted a packet from C" is quite the right > precondition; it seems to be more like "A has received a valid packet > from C", since whether or not A (as an attacker) considers it valid is > irrelevant to whether (honest) B will. C is the attacker here, A is honest. > Section 4.1 > If we had identifiers for symmetric keys or HMAC algorithms, we could > include those identifiers in the pseudo-header and thereby gain some > protection from downgrade/HMAC-stripping attacks in the presence of a > weak keyed MAC algorithm. (I think we have to include both what we are > sending and what we think the peer can do in order to get substantial > protection, though, which diminishes the appeal for multicast > scenarios.) This is a symmetric algorithm, for downgrade attacks to work the victim would need to be configured with a weak key. I therefore don't see how this added complexity helps. > nit: I don't think the past tense is correct for "packet was carried > over IPvN", since we're talking about a pseudo-header used in > computations before the packet is sent. Agreed, done. > It might be worth reiterating that every time a packet goes on the wire, > it gets a fresh PC, regardless of whether it's a "retransmit" after a > timeout or a new message. There are no retransmits in this protocol. > interface MTU (Section 4 of [RFC6126bis]). For an interface on which > HMAC protection is configured, the TLV aggregation logic MUST take > into account the overhead due to PC TLVs (one in each packet) and > HMAC TLVs (one per configured key). > (per configured key, and also per packet, right?) Of course. The MTU applies per packet. > Does it matter whether the sender increments the PC before or after > inserting it in the PC TLV? (I think the only potential impact would be > as it relates to the value sent in response to a challenge nonce, but > the "increment by a positive not-necessarily-one amount" property may > provide all the flexibility we need.) I don't think so. > Section 4.3 > Validating the HMACs is the sort of operation that we tend to recommend > be done in constnt-time to avoid side channel attacks. I don't have a > concrete attack handy here at the moment, though. I frankly have no idea if that's necessary or not. FWIW, the protocol is asynchronous, and there is jitter applied to packets. > When a PC TLV is encountered, the enclosed PC and Index are saved > for later processing; if multiple PCs are found (which should not > happen, see Section 4.2 above), only the first one is processed, > the remaining ones MUST be silently ignored. If a Challenge > Any reason to not just drop the whole packet if there are multiple PCs > present? I see this is not rfc7298bis but don't know what level of > breaking change is reasonable. It doesn't matter much, it's a "cannot happen" case. (Note that the HMAC has already been validted at this point, so it isn't a security issue.) > o The preparse phase above has yielded two pieces of data: the PC > and Index from the first PC TLV, and a bit indicating whether the > packet contains a successful Challenge Reply. If the packet does > not contain a PC TLV, the packet MUST be dropped and processing > stops at this point. If the packet contains a successful > Challenge Reply, then the PC and Index contained in the PC TLV > MUST be stored in the Neighbour Table entry corresponding to the > sender (which already exists in this case), and the packet is > accepted. > I'd suggest explicitly stating that if there is a challenge reply that > doesn't validate, the packet should be discarded. > Or are there multicast scenarios where that is not the case? The key > point being to emphasize that just the presence of a challenge reply > doesn't mean anything, it has to be valid in order to have significance. This is already the case -- a packet with an incorrect challenge reply is treated just like a packet with no challenge reply. I don't feel comfortable with discarding a packet just because it contains an obsolete challenge reply -- what if the packet also contains a challenge request? It also complicates the code, by requiring three challenge verdicts (positive/neutral/negative) rather than just two (positive/neutral). > o At this stage, the packet contains no successful challenge reply > and the Index contained in the PC TLV is equal to the Index in the > Neighbour Table entry corresponding to the sender. The receiver > compares the received PC with the PC contained in the Neighbour > Table; if the received PC is smaller or equal than the PC > contained in the Neighbour Table, the packet MUST be dropped and > processing stops (no challenge is sent in this case, since the > mismatch might be caused by harmless packet reordering on the > link). Otherwise, the PC contained in the Neighbour Table entry > is set to the received PC, and the packet is accepted. > Does this mean that if packet reordering is encountered, we will just > not process packets that get reordered later? (AFAIK babel will still > work fine in such conditions, so I'm just checking my understanding.) Correct on both counts. The WG did consider using a sliding window in the style of DTLS, but we finally decided against it for the sake of simplicity. Since this is a link-local protocol, packet reordering is unlikely. > it MAY ignore a challenge request in the case where it it contained > nit: s/it it/it is/ Done, thanks. > The same is true of challenge replies. However, since validating a > challenge reply is extremely cheap (it's just a bitwise comparison of > two strings of octets), a similar optimisation for challenge replies > is not worthwile. > Er, challenge reply validation still requires the HMAC validation step, > right? At this stage we've already verified the HMAC. The only thing we could potentially save would be a bitwise comparison, and that's not worth it. > Section 4.3.1.1 > When it encounters a mismatched Index during the preparse phase, a > node picks a nonce that it has never used with any of the keys > currently configured on the relevant interface, for example by > drawing a sufficiently large random string of bytes or by consulting > (same comment as above about "sufficiently large") See Section 6. > Section 4.3.1.2 > buffered TLVs in the same packet as the Challenge Reply. However, it > MUST arrange for the Challenge Reply to be sent in a timely manner > (within a few seconds), and SHOULD NOT send any other packets over > the same interface before sending the Challenge Reply, as those would > be dropped by the challenger. > I think this "SHOULD NOT" (or rather, "would be dropped by the > challenger") is predicated on the challenge request having not been a > replay, but I do not see anything requiring the recipient to do nonce > uniqueness validation. This doesn't require delaying any packets, quite the opposite, it says that you SHOULD send out the challenge reply before sending out any more packets. > Section 4.3.1.3 > neighbour that sent the Challenge Reply. If no challenge is in > progress, i.e., if there is no Nonce stored in the Neighbour > Table entry or the Challenge timer has expired, the Challenge Reply > MUST be silently ignored and the challenge has failed. > I think "the challenge has failed" is predicated on the challenge reply > being in response to a challenge sent by this node. The previous > section's "send the Challenge Reply to the unicast address" seems to > imply that there are no multicast scenarios which would make that not > the case, but I just wanted to check my understanding. That's right. > Section 5 > Do we need to say whether sub-TLVs are allowed in any of these TLVs? > (Presumably they are not, since the length is needed in order to > identify the length of the variable-length fields, but being explicit > can be useful.) 6126bis only specifies which TLVs do allow sub-TLVs, I think it makes sense to follow the same format. > Section 5.1 > This [HMAC] TLV is allowed in the packet trailer (see Section 4.2 of > [RFC6126bis]), and MUST be ignored if it is found in the packet body. > side note: Using "MUST ignore" vs. "discard the packet" has some > protocol evolution consequences -- it in practice then becomes an > alternative padding technique for use in packet bodies, and if ever used > as such then could lead to a way to fingerprint an implementation or be > used as a hidden channel for sending other data. But, I see that > ignoring at the TLV level is something of a core babel design choice, Right. > and I don't see any serious consequences that would merit revisiting > that decision. Good. > Section 6 > This mechanism relies on two assumptions, as described in > Section 1.2. First, it assumes that the hash being used is > s/hash/MAC/ I'm confused. This section refers to pre-image attacks, which I was under the impression is a property of the hash. > It would require a bit more thought to convince me that 64-bit indices > are sufficient for *all* cases. Specifically, if we want full 64-bit > strength, then the 64-bit space cannot be controlled or affected by the > attacker to cause collisions. But I think there will be a reasonable > risk that an attacker can cause a given node to need to regenerate its > index on demand (e.g,. but triggering a bug that crashes it, or power > cycling it) Assume the attacker is able to crash the node at will, and that the node needs 10s to reboot. If we assume the attacker will start seeing collisions after 2^32 tries, then this will happen after 1360 years, which is slightly more than the duration of the Byzantine empire. The Babel working group recommends rekeying whenever Anatolia is invaded. > present at the receiver. If the attacker is able to cause the > (Index, PC) pair to persist for arbitrary amounts of time (e.g., by > repeatedly causing failed challenges), then it is able to delay the > packet by arbitrary amounts of time, even after the sender has left > the network. > I'd suggest adding another sentence describing the potential > consequences of selectively delayed input (i.e., messing up the > routing). We don't know about any such consequences. Still, we believe it is good to avoid this situation. > protocol (the data structures described in Section 3.2 of > [RFC6126bis] are conceptual, any data structure that yields the same > result may be used). Implementers might also consider using the fact > nit: that's a comma splice in the parenthetical; a semicolon would be better. I've added a conjunction, I didn't realise such usage is unacceptable. -- Juliusz From nobody Sat Aug 10 04:00:14 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 1A493120089; Sat, 10 Aug 2019 04:00:13 -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.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156543481302.3595.8167825345794873379@ietfa.amsl.com> Date: Sat, 10 Aug 2019 04:00:13 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-hmac-09.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, 10 Aug 2019 11:00:13 -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-09.txt Pages : 20 Date : 2019-08-10 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-babel-hmac-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-hmac-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Aug 11 18:34:41 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 802D61209D2 for ; Sun, 11 Aug 2019 18:34: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 Qi0pcCdL_aCx for ; Sun, 11 Aug 2019 18:33: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 A4EA3120CAD for ; Sun, 11 Aug 2019 07:50:51 -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 x7BEokR4025010 for ; Sun, 11 Aug 2019 16:50:46 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 57A5A38AE8 for ; Sun, 11 Aug 2019 16:50:49 +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 Q96Re657MaEf for ; Sun, 11 Aug 2019 16:50:48 +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 7BE9C38AE6 for ; Sun, 11 Aug 2019 16:50:48 +0200 (CEST) Date: Sun, 11 Aug 2019 16:50:48 +0200 Message-ID: <871rxrdad3.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 11 Aug 2019 16:50:46 +0200 (CEST) X-Miltered: at korolev with ID 5D502B46.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D502B46.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 : 5D502B46.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [babel] AEs: define a registry? 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: Mon, 12 Aug 2019 01:34:40 -0000 I've just found an omission in the mots recent draft of 6126bis: no registry is defined for Address Encodings. Would anyone object if I added an AE registry to the IANA Considerations section of rfc6126bis? -- Juliusz From nobody Mon Aug 12 14:07: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 D744D120CB2 for ; Mon, 12 Aug 2019 14:07:44 -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 Cv1QoVb7081u for ; Mon, 12 Aug 2019 14:07:43 -0700 (PDT) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 277D81210B8 for ; Sun, 11 Aug 2019 19:06:22 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id o101so671636ota.8 for ; Sun, 11 Aug 2019 19:06:22 -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=2T12Ra5McCicH+9WCf6PCYcOJp2fCN8p7akqBZ0H+uI=; b=kQsOS42zQU437rkRvpBzIpcQwHDx1LZv7TSxzUqO3WPv1r9BTKnEGbJL4ev1OfNm7Z 3S7+FPsZHV6VGycQrm1v4qyb5te3q9fHk7XzjDIgmXHorChU7b+ouUmdI2DhSp5IRgaI 9y2432GAdp2cUK1W+bQP1kMyoxOCZDjkAs3vfZiymvBHXBIY7U61q/OdNMdDfU+TCZ0s JH/ptseiUQojnmadblXtydGBm/H2qpm+FfBZEa1jFJPZVDY9kgqqeCbb/A7u81PlSkNs jqUSFQStEVV/ZG+su24sexln+XH/m2pbuDgaatrGWjpTGDIwFNVhVlau2KzEVM68wj0I NkFA== 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=2T12Ra5McCicH+9WCf6PCYcOJp2fCN8p7akqBZ0H+uI=; b=EZbnEfNqADlhnSzKLqVyIkxEi4L8x6hLWmex25ZevjD4HWHnRjJ/KHuPU3BCQ2VXPu xjhvN/mzLMnJ02404Sedzu6qw4MUnNtMrhyxyAn8z/0Fsnxo06grJyyZuu9mM+0cGgG8 BAd6u2BOT6pdmlCSfFRRMLVuvuSwYzVl9uODoOT27XDNwDVJpnOfmVn3ngPrfG3mFPM+ RCfKYa+EJnJJVpUTZt4QvobAerERRK+5MiS7A9f/1hOY0+xj4XCdTMTm1KhjGi2X013q LfRb4caGLwb2sdUkhfHkMtktzlNzIyp3h7q3Pm5rbtJbrJJ/XbYBeL3zFEVlbpiBa09B JQuw== X-Gm-Message-State: APjAAAUHUCDLGtNG2KLmkp07EhR0QAkaDsF1Qm5VPW4z5m7CKptNsbG4 5972r3sBIhqH/hF6mZoPE4Sh7VZ8SlJW61FF9h0= X-Google-Smtp-Source: APXvYqwJziLReEnBB+vw+HX94njBXSyXrCZW+E9jae1JxRHpU64RSy6bro6JN7LiaFBT2uWfYFNTcSsBgjuBnZ9/0sA= X-Received: by 2002:a02:c996:: with SMTP id b22mr11511447jap.39.1565575581253; Sun, 11 Aug 2019 19:06:21 -0700 (PDT) MIME-Version: 1.0 References: <871rxrdad3.wl-jch@irif.fr> In-Reply-To: <871rxrdad3.wl-jch@irif.fr> From: Donald Eastlake Date: Sun, 11 Aug 2019 22:06:08 -0400 Message-ID: To: Martin Vigoureux Cc: Babel at IETF , Juliusz Chroboczek Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] AEs: define a registry? 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: Mon, 12 Aug 2019 21:07:46 -0000 Hi Martin, I think Juliusz has a good idea below. It obviously has no technical effect on the protocol. However, given that we are past IESG telechat and no AD mentioned this, I wanted your input as to whether it would be OK add this to the draft. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com On Sun, Aug 11, 2019 at 9:34 PM Juliusz Chroboczek wrote: > > I've just found an omission in the mots recent draft of 6126bis: no > registry is defined for Address Encodings. > > Would anyone object if I added an AE registry to the IANA Considerations > section of rfc6126bis? > > -- Juliusz > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Mon Aug 12 14:13:27 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 0FC0E12086A for ; Mon, 12 Aug 2019 14:13:26 -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 9_5XpdLniZ9a for ; Mon, 12 Aug 2019 14:13:22 -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 05FF512114A for ; Sun, 11 Aug 2019 20:34:54 -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 x7C3Yo7R021891 for ; Mon, 12 Aug 2019 05:34:50 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3783939B2E for ; Mon, 12 Aug 2019 05:34:53 +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 P5nLPTDqhv-S for ; Mon, 12 Aug 2019 05:34:52 +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 65DA639B2C for ; Mon, 12 Aug 2019 05:34:52 +0200 (CEST) Date: Mon, 12 Aug 2019 05:34:52 +0200 Message-ID: <87k1bjawf7.wl-jch@irif.fr> From: Juliusz Chroboczek To: Babel at IETF User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 12 Aug 2019 05:34:50 +0200 (CEST) X-Miltered: at korolev with ID 5D50DE5A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D50DE5A.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 : 5D50DE5A.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [babel] More about (H)MAC 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: Mon, 12 Aug 2019 21:13:26 -0000 Dear all, Re Babel-(H)MAC. Blake2s is not an HMAC During IESG review, Benjamin Kaduk mentioned that Blake2s (which is a SHOULD) is not an HMAC but a generic keyed MAC. He's right. I'm going to rename Babel-HMAC to Babel-MAC and tweak the draft to speak of keyed MACs? (I'm assuming here that HMAC is generally considered a special case of keyed MAC -- if anyone knows otherwise, please let me know.) Does anyone object to this, or have a better suggestion? -- Juliusz From nobody Mon Aug 12 14:19:25 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 04C621209FB; Mon, 12 Aug 2019 14:19:24 -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 T7l160ZX2Erm; Mon, 12 Aug 2019 14:19:22 -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 4039112121A; Sun, 11 Aug 2019 22:20:05 -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 x7C5K0YZ006374; Mon, 12 Aug 2019 07:20: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 019A139DD2; Mon, 12 Aug 2019 07:20:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id ovrjwgD6p1Wg; Mon, 12 Aug 2019 07:20: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 82E0D39DD0; Mon, 12 Aug 2019 07:20:01 +0200 (CEST) Date: Mon, 12 Aug 2019 07:20:01 +0200 Message-ID: <87ftm7arjy.wl-jch@irif.fr> From: Juliusz Chroboczek To: Yingzhen Qu Cc: rtg-dir@ietf.org, draft-ietf-babel-rfc6126bis.all@ietf.org, ietf@ietf.org, babel@ietf.org In-Reply-To: References: <156470236376.19191.1026181661457374790@ietfa.amsl.com> <87o918ou5d.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 12 Aug 2019 07:20:00 +0200 (CEST) X-Miltered: at korolev with ID 5D50F700.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D50F700.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 : 5D50F700.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Rtgdir telechat review of draft-ietf-babel-rfc6126bis-11 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: Mon, 12 Aug 2019 21:19:24 -0000 Dear Ms. Qu, Sorry for the delay, and thank you for your reminder. >> The description about packet trailer is in RFC 7557 section 2.5, but >> not included in the bis version. > The packet trailer is described in Section 4.2. > [YQ]: In RFC 7557 section 2.5, there is a clear description about how the > packet trailer length is calculated etc. Personally I feel it's more > straightforward, but if you think section 4.2 is enough, I'm not going to > insist. I see. Yes, I'll clarify that. >> There are multiple places in the document about TLV/Sub-TLV being >> “self-terminating”, but I didn’t find what it means. Maybe I’m missing >> something here? > This is defined in Section 4.4. I have checked that all uses of > self-terminating occur after its definition. > [YQ]: in section 4.4, it says self-terminating can be used to determine the > length of the TLV body without using the length field. This is clear, however > what does it look like? how to detect it? maybe I'm missing something here. For example, the router-id TLV is always 8 octets long. It is self-terminating. The Pad1 TLV can have arbitrary length, and it is impossible to determine its length without the explicit Length field. It is not self-terminating. >> Section 1.1 >> “unmanaged and wireless environment”, what does “unmanaged” mean here? > Not being actively managed by a human administrator. This is a > non-normative > section. Please let me know if I'm using this term badly. > [YQ]: my understanding is unmanaged can mean anything, like no management at > all. I don't think it's a good term, especially put together with wireless. > maybe try to add a bit more explanation? This is a conceptual overview, unmanaged is used in a non-technical sense. >> Section 3.2.3 The interface Hello seqno is changed to outing multicast >> hello seqno, however there is no description about unicast hello at >> all. > Unicast Hellos are per-neighbour, so they appear in Section 3.2.4 (Section > 3.2.3 describes per-interface data structure while 3.2.4 describes > per-neighbour structures). Both kinds of Hellos are described in more > detail in Section 3.4.1. > [YQ]: there is nothing wrong with current text. I was thinking of adding > unicast just for easy readability. same for the following three related > questions. The approach taken here is to define the data structures before explaining the protocol. The advantage is to have a clear reference for the implementer; but of course it leads to a number of things that are not entirely clear at this point. It's a difficult tradeoff, I'm going to leave it as is. >> Section 3.8.1.1 >> After a node receives a route request, if the given prefix doesn’t >> exist in its route table, it MUST send a retraction for that prefix. So >> my question is whether a node is allowed to send multiple explicit >> requests for a given prefix? [...] > [YQ] thanks for the explanation. I'm just wondering whether we should > document it somewhere? No, I don't think so. This case is not specific -- for example, sending multiple copies of updates is also not a good idea. > [YQ]: My understanding is Babel uses a stateful parser, and TLVs in the packet > trailer are not allowed to modify the state. So the text here is suggesting to > implement a stateless parser for packet trailer. so the question is: will > packet trailer to able to use/read the state? is the stateless parser suggested > just for implementation simplicity? None of the TLVs allowed in the packet trailer use or modify the state. See also the last paragraph of the appendix "Considerations for protocol extensions". >> Section 4.5 >> 1674 parsing a TLV MUST update the parser state even if the TLV is >> 1675 otherwise ignored due to an unknown mandatory sub-TLV. > I believe you may have forgotten to write your comment. > [YQ]: is it correct that the parser state is updated by a TLV even if the TLV > is ignored due to unknown sub-tlv? what about a TLV ignored due to other > reasons? You're right, I'll add a comment. >> Section 4.6.5 >> 1805 send a new scheduled Hello TLV with the same setting > of the >> 1806 Unicast flag. If this is 0, then this Hello > represents an >> I’d suggest changing the text to “the same setting of flags” instead of > “the >> same setting of the Unicast flag”, considering the flags will be extended > later. > I disagree. This paragraph is about the multicast/unicast dichotomy, not > about future flags of an informative nature. > [YQ]: then I misunderstood it. I thought it was meant to copy the entire flag > field. >> Nits: >> 1049 metric) from a neighbour neigh with a link cost value equal to > cost, >> 1050 it checks whether it already has a route table entry indexed > by >> [neighbour neigh] => [neighbour] > I disagree. We're defining the variable neigh, which we use in the next > sequence. > [YQ]: it seems that this is the only place using "neigh", so I thought it was a > typo. I would suggest some clarification. This has been removed. -- Juliusz From nobody Mon Aug 12 15:29:22 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 EF4CC1213B8; Mon, 12 Aug 2019 15:29:15 -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 sQ5ckUpZ2kCY; Mon, 12 Aug 2019 15:29:13 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 EBF50120C68; Mon, 12 Aug 2019 12:32:07 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id a30so11973878lfk.12; Mon, 12 Aug 2019 12:32:07 -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=xwpomQLth7TCDOm4vG9zvJyx7ljYZ3BH4K7YZgfOn7s=; b=Z0mw1dkTidmXyONzMdDtlr6nEB/r1ykSGZc8aZbcY4VR8qGXaScrGDeomNvJxrFpPJ bc5QDJr/Ry3o5wVvBwToEvRTQE2spys3N6C7MmV/ZPYFtDs4BlFFIIoxfLSLNkqx8ksq tF2OUVtNN5Mr/2vK1vYVUvRGM8okVp7lMKkQASW/rehNeU02Lxp7UhMz4KtJzh+p4KrG xUGgm3mCwa2QW5Fir25o6dsmfbj/OSP3cj/9M4uHX2SKW+lI/MNeU0102JJDOVfUdoqJ dcxih8o0Lq3AdM+bE+nFt01lHFsXRdIn5S9/MxKArgHRTgV3k/EV/QD2gmek4cBcGelB rRpg== 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=xwpomQLth7TCDOm4vG9zvJyx7ljYZ3BH4K7YZgfOn7s=; b=aLwWVRqIY7dpCtbXOT3FzUrmmHvjTmGcz69rCd+orjvKESbgg1bOHRHUZmJA9Cwc1Y L6ycUNQO6QKrUBWfXnVJZOVHW67Fpp3Hgmv8iPAqtixS4Ak/UoeoRrINoDKXspbQtJBW HiEEaijIPTq5z/9QFt19oOxZBTU99IM6HutPQZ64YtGNiQQCVysgGAp9T+gNY2YAT/3p Juro87hr/DoY9ztiwgVJAsI9RkK44UNdkdFhz89ba4lp3+grO9aVdt2WE9BmWb+sJa7D IElyJQJ1Mq4bIayHeMjwRku3T0edNtPYu9kNWBuFKgvn6/z70ahS0oCzLLZPEGOD0FBE exNw== X-Gm-Message-State: APjAAAVah0WW3lKyy04q1nGQBEH4/L52t7cz5Gfql1aYqjy5VU8RCPU8 DySEuI3g7YHHL873aGQqc2vEPyw8TGNCI7SK11o= X-Google-Smtp-Source: APXvYqzn5jNP/oPY/1DwAQnFPYbZMQRDYS3qbiWsdIUIUdX/s4D7zIHzI6Om3oYb8DUM5niOKz+FdfQxqzgP9cx4i48= X-Received: by 2002:a19:ed0f:: with SMTP id y15mr21292854lfy.148.1565638325916; Mon, 12 Aug 2019 12:32:05 -0700 (PDT) MIME-Version: 1.0 References: <156521337799.8333.13258734665763149206.idtracker@ietfa.amsl.com> <20190810025515.GA48324@kduck.mit.edu> In-Reply-To: <20190810025515.GA48324@kduck.mit.edu> From: David Schinazi Date: Mon, 12 Aug 2019 12:31:54 -0700 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-babel-dtls@ietf.org, Donald Eastlake , babel-chairs , Babel at IETF Content-Type: multipart/alternative; boundary="00000000000043577f058ff0943f" Archived-At: Subject: Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT) 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: Mon, 12 Aug 2019 22:29:19 -0000 --00000000000043577f058ff0943f Content-Type: text/plain; charset="UTF-8" Thanks Ben! I've incorporated these comments in the following commit: https://github.com/jech/babel-drafts/commit/458a9ae6b9b136122d8668b26ba403f4f3a57167 We'll submit an updated draft after this round of comments. Detailed responses inline. Thanks, David > > Our intent in this document was to leave the complex question of identity > > to deployment profiles. For example, the homenet working group is > interested > > It would be a fine thing to say explicitly that the details of identity and > authentication are left to specific profiles. > Added the following paragraph to the Applicability section: DTLS supports several mechanisms by which nodes can identify themselves and prove possession of secrets tied to these identities. This document does not prescribe which of these mechanisms to use; details of identity management are left to deployment profiles of Babel over DTLS. > > We already have this text in section 2.1: > > Nodes MUST use DTLS replay protection to prevent attackers > > from replaying stale information. > > Is there something we should add to that? > > I did see that text in 2.1, which is why this comment was less strongly > worded. I am interpreting the text I quoted as a description of what > functionality DTLS does and can provide, and in that context, DTLS provides > optional replay protection. If your implementation doesn't offer it, or > you don't turn it on; you're not protected. It seems like it would > misconstrue things to imply that DTLS always provides replay protection, > since that's not the case! > Makes sense. Changed "replay protection" to "optional replay protection". > > > I see the text about use of multicast Hellos for discovery and the > > > acknowledgment that an out-of-band neighbor discovery mechanism may be > > > available. Are there any such discovery mechanism under development? > > > > > > > There aren't, at least not as standards. This text is there to > accommodate > > implementations/deployments that already have a non-standard out-of-band > > discovery mechanism. > > "standard" is a touchy term here in the IETF :) But I take it there are no > published drafts or similar, either, in which case there's not anything we > can make an informative reference to, which is what I was really getting > at. > Fair enough, by "standard" I meant "being openly discussed in a standardization organization". The only existing out-of-band discovery mechanism that was discussed was proprietary and has nothing we can link to. > > > Section 2.5 > > > > > > Do we want to talk about the potential consequences of an attacker > > > arbitrarily delaying valid content (to justify the need for a timeout)? > > > > > > > The section currently states: > > This attack could be used to make a node believe it has bidirectional > > reachability to a neighbour even though that neighbour has > disconnected > > from the network. > > What more did you have in mind? > > Well, I hadn't thought it through fully. But would it be possible to delay > distribution of metric updates, leading to the victim selecting an > alternate path than it would have otherwise (whether to cause performance > degredation or make the data-plan traffic go through a place that's easier > to attack, or otherwise)? It seems that the need for liveness detection > would place time bounds on such an attack unless the attacker can > selectively drop DTLS datagrams and there are Hellos not piggybacked on the > traffic that is targeted. I forget how much tolerance for such drastic > reordering there would be. > That's fair. We've added the following text: Additionally, an attacker could save some packets and replay them later in hopes of propagating stale routing information at a later time. To mitigate this, nodes MUST discard received packets that have been reordered by more than one IHU interval. > > > Section 3 > > > > > > IP, UDP and DTLS. Nodes MUST NOT send Babel packets larger than the > > > attached interface's MTU adjusted for known lower-layer headers (at > > > least UDP and IP) or 512 octets, whichever is larger, but not > > > exceeding 2^16 - 1 adjusted for lower-layer headers. Every Babel > > > speaker MUST be able to receive packets that are as large as any > > > > > > Aren't these requirements just duplicating what's in 6126bis? We > > > probably don't need to repeat the normative language, at least, even if > > > there's a desire to repeat the content. > > > > > > > These requirements mimic the ones in 6126bis, but with the addition of > DTLS > > in the list of underlying layers that add overhead. This section > references > > the > > appropriate section in 6126bis so readers can compare them if need be. > > I carefully trimmed the sentences that actually mentioned DTLS; "adjusted > for known lower-layer headers" is the key phrase (happens twice) that I > thought was used unchanged. (But I didn't do a word-by-word comparison.) > That sentence is the same in both documents, but "known lower-layer headers" doesn't mean the same thing in both, since we now have the DTLS layer. I'm not coming up with an easy way to convey this without repeating at least some parts of the text in 6126bis. > > I'm not sure I understand, are you saying there is a difference between > > the terms "overhead per packet" and "per-packet overhead" ? > > "different amounts of overhead per packet" implies something whose > magnitude varies on a packet-by-packet basis, potentially drastically so, > whereas "different amounts of per-packet overhead" is more of a fixed > (potentially range) of overhead across all packets in question. (And yes, > I know that CBC padding can fall into the former!) > Thanks for the clarification, changed to "per-packet overhead". --00000000000043577f058ff0943f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ben! I've incorporated these comments in t= he following commit:
https://github.com/jec= h/babel-drafts/commit/458a9ae6b9b136122d8668b26ba403f4f3a57167

We'll submit an updated draft after this round of = comments.

Detailed responses inline.
Thanks,
David
=C2=A0
> Our intent in this document was to leave the complex question of ident= ity
> to deployment profiles. For example, the homenet working group is inte= rested

It would be a fine thing to say explicitly that the details of identity and=
authentication are left to specific profiles.

Added the following paragraph to the Applicability section:
=C2=A0 =C2=A0 DTLS supports several mechanisms by which nodes can identif= y
=C2=A0 =C2=A0 themselves and prove possession of secrets tied t= o these identities.
=C2=A0 =C2=A0 This document does not prescrib= e which of these mechanisms
=C2=A0 =C2=A0 to use; details of iden= tity management are left to deployment
=C2=A0 =C2=A0 profiles of = Babel over DTLS.
=C2=A0
> We already have this text in section 2.1:
>=C2=A0 =C2=A0 =C2=A0Nodes MUST use DTLS replay protection to prevent at= tackers
>=C2=A0 =C2=A0 =C2=A0from replaying stale information.
> Is there something we should add to that?

I did see that text in 2.1, which is why this comment was less strongly
worded.=C2=A0 I am interpreting the text I quoted as a description of what<= br> functionality DTLS does and can provide, and in that context, DTLS provides=
optional replay protection.=C2=A0 If your implementation doesn't offer = it, or
you don't turn it on; you're not protected.=C2=A0 It seems like it = would
misconstrue things to imply that DTLS always provides replay protection, since that's not the case!

Makes se= nse. Changed "replay protection" to "optional replay protect= ion".
=C2=A0
> > I see the text about use of multicast Hellos for discovery and th= e
> > acknowledgment that an out-of-band neighbor discovery mechanism m= ay be
> > available.=C2=A0 Are there any such discovery mechanism under dev= elopment?
> >
>
> There aren't, at least not as standards. This text is there to acc= ommodate
> implementations/deployments that already have a non-standard out-of-ba= nd
> discovery mechanism.

"standard" is a touchy term here in the IETF :)=C2=A0 But I take = it there are no
published drafts or similar, either, in which case there's not anything= we
can make an informative reference to, which is what I was really getting at.

Fair enough, by "standard"= ; I meant "being openly discussed in a
standardization organ= ization". The only existing out-of-band discovery
mechanism = that was discussed was proprietary and has nothing we
can link to= .
=C2=A0
> > Section 2.5
> >
> > Do we want to talk about the potential consequences of an attacke= r
> > arbitrarily delaying valid content (to justify the need for a tim= eout)?
> >
>
> The section currently states:
>=C2=A0 =C2=A0 =C2=A0This attack could be used to make a node believe it= has bidirectional
>=C2=A0 =C2=A0 =C2=A0reachability to a neighbour even though that neighb= our has disconnected
>=C2=A0 =C2=A0 =C2=A0from the network.
> What more did you have in mind?

Well, I hadn't thought it through fully.=C2=A0 But would it be possible= to delay
distribution of metric updates, leading to the victim selecting an
alternate path than it would have otherwise (whether to cause performance degredation or make the data-plan traffic go through a place that's eas= ier
to attack, or otherwise)?=C2=A0 It seems that the need for liveness detecti= on
would place time bounds on such an attack unless the attacker can
selectively drop DTLS datagrams and there are Hellos not piggybacked on the=
traffic that is targeted.=C2=A0 I forget how much tolerance for such drasti= c
reordering there would be.

That's f= air. We've added the following text:
=C2=A0 =C2=A0 Additional= ly, an attacker could save some packets and replay them
=C2=A0 = =C2=A0 later in hopes of propagating stale routing information at a later t= ime.
=C2=A0 =C2=A0 To mitigate this, nodes MUST discard received = packets that have
=C2=A0 =C2=A0 been reordered by more than one I= HU interval.
=C2=A0
> > Section 3
> >
> >=C2=A0 =C2=A0 IP, UDP and DTLS.=C2=A0 Nodes MUST NOT send Babel pa= ckets larger than the
> >=C2=A0 =C2=A0 attached interface's MTU adjusted for known lowe= r-layer headers (at
> >=C2=A0 =C2=A0 least UDP and IP) or 512 octets, whichever is larger= , but not
> >=C2=A0 =C2=A0 exceeding 2^16 - 1 adjusted for lower-layer headers.= =C2=A0 Every Babel
> >=C2=A0 =C2=A0 speaker MUST be able to receive packets that are as = large as any
> >
> > Aren't these requirements just duplicating what's in 6126= bis?=C2=A0 We
> > probably don't need to repeat the normative language, at leas= t, even if
> > there's a desire to repeat the content.
> >
>
> These requirements mimic the ones in 6126bis, but with the addition of= DTLS
> in the list of underlying layers that add overhead. This section refer= ences
> the
> appropriate section in 6126bis so readers can compare them if need be.=

I carefully trimmed the sentences that actually mentioned DTLS; "adjus= ted
for known lower-layer headers" is the key phrase (happens twice) that = I
thought was used unchanged.=C2=A0 (But I didn't do a word-by-word compa= rison.)

That sentence is the same in bo= th documents, but "known lower-layer
headers" doesn'= ;t mean the same thing in both, since we now have
the DTLS layer.= I'm not coming up with an easy way to convey this
without re= peating at least some parts of the text in 6126bis.
=C2=A0
<= 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"> > I'm not sure I understand, are you saying there is a difference be= tween
> the terms "overhead per packet" and "per-packet overhea= d" ?

"different amounts of overhead per packet" implies something whos= e
magnitude varies on a packet-by-packet basis, potentially drastically so, whereas "different amounts of per-packet overhead" is more of a f= ixed
(potentially range) of overhead across all packets in question.=C2=A0 (And = yes,
I know that CBC padding can fall into the former!)
Thanks for the clarification, changed to "per-packet overh= ead".
--00000000000043577f058ff0943f-- From nobody Mon Aug 12 15:32:28 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 5C50E120BDB for ; Mon, 12 Aug 2019 15:32:26 -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 jY9g_bPCiF_q for ; Mon, 12 Aug 2019 15:32:23 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 E3230120D59 for ; Mon, 12 Aug 2019 14:30:32 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id h28so75201039lfj.5 for ; Mon, 12 Aug 2019 14:30:32 -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=4WhRJF/5SRkRDoV/xhkNIhU6iLOUMTh/6HiJ5m91Db4=; b=PzQMu44g3NLGC5+EJ5YY8yf/J3jvOjWRVYv9DiBSykFa9s0xBrl/+fbUQGE1b0DyjZ UK8hlUbQb4FxpWf32ub6wYCWxplY8HqNUbPxaVNPu3Ggm03poq4ByZEVMmYGMo/Ut3pk MMOm8PILkDI8enRWLA19uHLmvVS8iX2iEbAIXz/i75I64rEK3DQaJCwFeehtAWTcs/UW cR0qzSHEDHvbl39q/H/mRRuxiaDPktE5MyLBd6Dx1kqmdfivEHmNQB4xOXYPLd9g1ZIE g6s63wpOxQe012xFBAjADZnwB1KDLsCXAxWEeCC2ZHC5nbAei8BzcoTnydAEvf8CkSbD rCrA== 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=4WhRJF/5SRkRDoV/xhkNIhU6iLOUMTh/6HiJ5m91Db4=; b=G2cUUSk1ziphcUV3UXGAu3tKkvDEd7DNmyqkkYrQfECwXPDIZDyuFakLHVitkUHWe9 AG4Ft1xFOatCEymb3x9LGQ6UISu1DZwve2gJ5Zdc4Rr9rJTNSOOEmm1oRntp/8CRhU1Z InPDAgS6t8N7G6rDJOQkcAL8eHID/aQt1NuOna9a/vF/oijOGR68Tw0skQbatrORHHUG 5Pbo0gaJtcvBy+V90tnIhF9vfm3rzrglqMLE1wGIb+Xvk55J/seU/dVPJWD9zAGbGe+9 w7iUUcZ1wsIZpLD1btLvgVHERo46m6RnfDJJeQBCNOMWM33GdvLoq3MOJOQtclR4ySxP 6QmA== X-Gm-Message-State: APjAAAVqQJKQrkvnN7XSlJtokb5kSgVilGi6cuOl5jc0ifkCOj94xjFT mUSLrz+L3DLE/zQbVmhWi488cTNvOYmto4l+uNU= X-Google-Smtp-Source: APXvYqwLcBkGAlh0PlIzfgIqRaOKLGJUtESFVUwhdTKj5yz4/bM0Tj9cB3XC3vnpXWC/AoOe3qb3biPSEAh0tQC0fhY= X-Received: by 2002:a19:5f0f:: with SMTP id t15mr21468310lfb.67.1565645431064; Mon, 12 Aug 2019 14:30:31 -0700 (PDT) MIME-Version: 1.0 References: <87k1bjawf7.wl-jch@irif.fr> In-Reply-To: <87k1bjawf7.wl-jch@irif.fr> From: David Schinazi Date: Mon, 12 Aug 2019 14:30:19 -0700 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF Content-Type: multipart/alternative; boundary="000000000000c34a41058ff23bb4" Archived-At: Subject: Re: [babel] More about (H)MAC 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: Mon, 12 Aug 2019 22:32:27 -0000 --000000000000c34a41058ff23bb4 Content-Type: text/plain; charset="UTF-8" That sounds good to me. David On Mon, Aug 12, 2019 at 2:13 PM Juliusz Chroboczek wrote: > Dear all, > > Re Babel-(H)MAC. > > Blake2s is not an HMAC > > During IESG review, Benjamin Kaduk mentioned that Blake2s (which is > a SHOULD) is not an HMAC but a generic keyed MAC. He's right. I'm going > to rename Babel-HMAC to Babel-MAC and tweak the draft to speak of keyed > MACs? (I'm assuming here that HMAC is generally considered a special case > of keyed MAC -- if anyone knows otherwise, please let me know.) > > Does anyone object to this, or have a better suggestion? > > -- Juliusz > > > > > > > > > > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --000000000000c34a41058ff23bb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That sounds good to me.

David

On M= on, Aug 12, 2019 at 2:13 PM Juliusz Chroboczek <jch@irif.fr> wrote:
Dear all,

Re Babel-(H)MAC.

Blake2s is not an HMAC

During IESG review, Benjamin Kaduk mentioned that Blake2s (which is
a SHOULD) is not an HMAC but a generic keyed MAC.=C2=A0 He's right.=C2= =A0 I'm going
to rename Babel-HMAC to Babel-MAC and tweak the draft to speak of keyed
MACs?=C2=A0 (I'm assuming here that HMAC is generally considered a spec= ial case
of keyed MAC -- if anyone knows otherwise, please let me know.)

Does anyone object to this, or have a better suggestion?

-- Juliusz










_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--000000000000c34a41058ff23bb4-- From nobody Mon Aug 12 15:40: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 BE5D4121053 for ; Mon, 12 Aug 2019 15:40:17 -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 MH293iMrrbPJ for ; Mon, 12 Aug 2019 15:40:15 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A3AA120C4E for ; Mon, 12 Aug 2019 11:26:06 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id z28so44975757ljn.4 for ; Mon, 12 Aug 2019 11:26:06 -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=EM9L8KL5hSy1wMDBfAurnE2CCImdTCmLT0z7BH1ZzM0=; b=X29DJR/IhnCZTqokSrCcNj6Rue0dlZ9Ul6cr2Xzr/2IXcDWKmDBZCE1L4pnQZPSqOJ Kv/GVUnXRMyBlQ6qsQ6f1T5PgOfwiV0eNBDYI2pNapzqiG1KsHcqXd03kqumljgHMMy/ oy9TCzFP6ETKmCHZhXfQOmXxZrGOV2QsK7lVuoXs66SbGSB5qvUz1YeFZXQDU6juyDJi clSFHS/8yGaYgDtCLCUkj9MDwNGcZGXneIpG1NNb4P6scyG6mIWbc/4fcFdV6xuPDYDV 0sEGU/eKW+J6t26sxnxzqI5jV5QhpQ79p1YhOIwTLmaDFTrl5XCNuiwlSSlhbZipVyPq 8B5g== 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=EM9L8KL5hSy1wMDBfAurnE2CCImdTCmLT0z7BH1ZzM0=; b=tidhiPDZok6f7sgSHYCo1qh2PnlQzmveeM6doA6BjaBDGMc5qGZmoIUCzshinz93g4 ywCQIuw4il6QCe9DJgvzsoaYyS3FK7Rth5f9oEIPTFI7dasAx9XlQAFUV/5fxRgVpOVx L4jK4dLhXRP3KKAGGwRCIde+mTL5qUA+QjsLmWhDOdt4JBlO0Hl5Nv0dQxU74bJrtM6v qmHq9Rmcm2Vld3/R/Pwku9OOvvD3B7WXEv/LXqy/KBXERxxqATSXgr2lCftf4DwJkZ8n m11/cNjIPNaJ/CHeZkisAZ3J+k03bzI04r0K0ks/GcSKDOWG9sHRsTWHjuOz1r4gpZvW KSZA== X-Gm-Message-State: APjAAAWG7g7YIX4Y3SzXkUk69Dy10ROECjUvZvuIQIwtmphvuVF8L8ZH 7GFL1SLdrKB/+pZzC6lsrMCxe/BtInyzFr1so+g= X-Google-Smtp-Source: APXvYqydgOIIxvMEXW5UoMTHQrVYHnGCvyFYOJtxbeSejckZwLH55r6YqAhFCy9zoggQ2wdUBnZHkU0KiSGEUugyY4E= X-Received: by 2002:a2e:96d5:: with SMTP id d21mr20012683ljj.170.1565634364453; Mon, 12 Aug 2019 11:26:04 -0700 (PDT) MIME-Version: 1.0 References: <871rxrdad3.wl-jch@irif.fr> In-Reply-To: <871rxrdad3.wl-jch@irif.fr> From: David Schinazi Date: Mon, 12 Aug 2019 11:25:53 -0700 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF Content-Type: multipart/alternative; boundary="000000000000243a64058fefa862" Archived-At: Subject: Re: [babel] AEs: define a registry? 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: Mon, 12 Aug 2019 22:40:21 -0000 --000000000000243a64058fefa862 Content-Type: text/plain; charset="UTF-8" I think adding a registry is the best way forward. David On Sun, Aug 11, 2019 at 6:34 PM Juliusz Chroboczek wrote: > I've just found an omission in the mots recent draft of 6126bis: no > registry is defined for Address Encodings. > > Would anyone object if I added an AE registry to the IANA Considerations > section of rfc6126bis? > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --000000000000243a64058fefa862 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think adding a registry is the best way forward.
David

On Sun, Aug 11, 2019 at 6:34 PM Juliusz Chroboczek &= lt;jch@irif.fr> wrote:
I've just found an omissio= n in the mots recent draft of 6126bis: no
registry is defined for Address Encodings.

Would anyone object if I added an AE registry to the IANA Considerations section of rfc6126bis?

-- Juliusz

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--000000000000243a64058fefa862-- From nobody Mon Aug 12 16:35:26 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 7A4FC120019; Mon, 12 Aug 2019 16:35:24 -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, 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 (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXDX1uivnmcY; Mon, 12 Aug 2019 16:35:21 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 BFDCA12000E; Mon, 12 Aug 2019 16:35:21 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x7CNZJ0m003884; Mon, 12 Aug 2019 19:35:20 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x7CNZJ0m003884 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1565652920; bh=OStF6Egf1YYMOWqwGwKyvtuTHSsnAwVS1U6pak65Lc4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=PuwdTB+Ffxsl+Xqnzm7A/1C9oKuCvrQGhZk89dtwQ7MMzvYLwgjoK7uUlBmIEd8So 94s1Vqx+WzH6hRbfNGHyoHEIOLGBffT9sLlJAHpERBehV54LYaqIuA2k+5L1LzNzH8 /Ls7Vf1ToIIGqzDd3oqTI7f61Jp2ZSfswWUc2Jmo= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x7CNZI9m011380; Mon, 12 Aug 2019 19:35:18 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Mon, 12 Aug 2019 19:35:18 -0400 From: Roman Danyliw To: David Schinazi CC: The IESG , "draft-ietf-babel-dtls@ietf.org" , Donald Eastlake , babel-chairs , Babel at IETF Thread-Topic: Roman Danyliw's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT) Thread-Index: AQHVTVX/GUz1qFLfsU6ZzqI2Nk9MnqbyP5aAgAGAUwCABG7OgA== Date: Mon, 12 Aug 2019 23:35:18 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B34054D4@marchand> References: <156520596444.8244.649940515091541992.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC01B34054D4marchand_" MIME-Version: 1.0 Archived-At: Subject: Re: [babel] Roman Danyliw's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT) 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: Mon, 12 Aug 2019 23:35:25 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC01B34054D4marchand_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQhDQoNCkZyb206IERhdmlkIFNjaGluYXppIFttYWlsdG86ZHNjaGluYXppLmlldGZA Z21haWwuY29tXQ0KU2VudDogRnJpZGF5LCBBdWd1c3QgOSwgMjAxOSA3OjQwIFBNDQpUbzogUm9t YW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPg0KQ2M6IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPjsg ZHJhZnQtaWV0Zi1iYWJlbC1kdGxzQGlldGYub3JnOyBEb25hbGQgRWFzdGxha2UgPGQzZTNlM0Bn bWFpbC5jb20+OyBiYWJlbC1jaGFpcnMgPGJhYmVsLWNoYWlyc0BpZXRmLm9yZz47IEJhYmVsIGF0 IElFVEYgPGJhYmVsQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFJvbWFuIERhbnlsaXcncyBEaXNj dXNzIG9uIGRyYWZ0LWlldGYtYmFiZWwtZHRscy0wNzogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVO VCkNCg0KV2UndmUgbm93IHN1Ym1pdHRlZCAtMDggd2hpY2ggY29udGFpbnMgdGhlIGNoYW5nZXMg ZGlzY3Vzc2VkIGJlbG93Lg0KDQpUaGFua3MsDQpEYXZpZA0KDQpPbiBUaHUsIEF1ZyA4LCAyMDE5 IGF0IDU6NDQgUE0gRGF2aWQgU2NoaW5hemkgPGRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbTxtYWls dG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpUaGFua3MgZm9yIHlvdXIgcmV2 aWV3IFJvbWFuISBXZSd2ZSBtYWRlIGNoYW5nZXMgb24gb3VyIGdpdCByZXBvc2l0b3J5DQo8aHR0 cHM6Ly9naXRodWIuY29tL2plY2gvYmFiZWwtZHJhZnRzPiBhbmQgd2lsbCBzdWJtaXQgYSByZXZp c2VkIGRyYWZ0IHNob3J0bHkuDQoNCkRldGFpbGVkIHJlc3BvbnNlcyBpbmxpbmUuDQoNClRoYW5r cywNCkRhdmlkDQoNCk9uIFdlZCwgQXVnIDcsIDIwMTkgYXQgMTI6MjYgUE0gUm9tYW4gRGFueWxp dyB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc8bWFpbHRvOm5vcmVwbHlAaWV0Zi5v cmc+PiB3cm90ZToNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkRJU0NVU1M6DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCigx KSBTZWN0aW9uIDEuIFRoZXNlIGFyZSBkaWZmZXJlbnQgdGhhbiB0aGUgb25lcyBsaXN0ZWQgaW4g U2VjdGlvbiA2IG9mDQpkcmFmdC1pZXRmLWJhYmVsLXJmYzYxMjZiaXMgYW5kIFNlY3Rpb24gMSBv ZiBkcmFmdC1pZXRmLWJhYmVsLWR0bHMuICBBcyBEVExTDQphbmQgSE1BQyBhcmUgbWl0aWdhdGlv bnMgZm9yIGF0dGFja3MgaW4gZHJhZnQtaWV0Zi1iYWJlbC1yZmM2MTI2YmlzLCB0aGV5DQpyZWFs bHkgc2hvdWxkIGJlIGhhcm1vbml6ZWQuDQoNCldlJ3ZlIGZsZXNoZWQgb3V0IHRoZSB0ZXh0IGlu IGRyYWZ0LWlldGYtYmFiZWwtcmZjNjEyNmJpcyBhbmQga2VwdCB0aGUgcmVmZXJlbmNlDQppbiBk cmFmdC1pZXRmLWJhYmVsLWR0bHMuDQoNCigyKSBTZWN0aW9uIDIuMS4gIFBlciDigJxJbXBsZW1l bnRhdGlvbnMgTVVTVCBzdXBwb3J0IGF1dGhlbnRpY2F0aW5nIHBlZXJzDQphZ2FpbnN0IGEgbG9j YWwgc3RvcmUgb2YgY3JlZGVudGlhbHPigJ0sIHdoYXQgZG9lcyB0aGF0IGNyZWRlbnRpYWxpbmcg bG9vayBsaWtlPw0KSXMgaXQgY2VydGlmaWNhdGVzLCBQU0ssIGV0Yz8gIFdoYXQgdmFsaWRhdGlv biBwcm9jZWR1cmUgaXMgYmVpbmcgdXNlZCBmb3IgdGhpcw0KYXV0aGVudGljYXRpb24/DQoNCkkn bGwgcmVzcG9uZCB0byB0aGlzIHBvaW50IG9uIEJlbidzIERJU0NVU1Mgc2luY2UgSSB0aGluayB5 b3UncmUgYm90aCBhc2tpbmcNCmZvciB0aGUgc2FtZSB0aGluZy4NCg0KW1JvbWFuXSBDb25jdXIg dGhhdCBCZW4gYW5kIEkgYXJlIHJhaXNpbmcgdGhlIHNhbWUgY29uY2Vybi4gIEkgYXBwcmVjaWF0 ZSB0aGUgZXhwbGFuYXRpb24geW91IHByb3ZpZGVkIGluOg0KDQpodHRwczovL21haWxhcmNoaXZl LmlldGYub3JnL2FyY2gvbXNnL2JhYmVsL0h1b0VHN0hHX3JTZnMzckNGWm8yWllkQ2xfSQ0KDQpC ZW7igJlzIHJlY29tbWVuZGF0aW9uIHRvIGV4cGxpY2l0bHkgbm90ZSB0aGF0IHRoaXMgYXV0aGVu dGljYXRpb24gbmVlZHMgdG8gYmUgc29sdmVkIGluIGV4dGVybmFsIHByb2ZpbGVzIHdvdWxkIGFk ZHJlc3MgbXkgY29uY2VybiB0b286DQoNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJj aC9tc2cvYmFiZWwvNUFuTGxhSFBURXNCSnBWN1dWclpMcHcwN2xzDQoNCihJIGRvbuKAmXQga25v dyBpZiB5b3Ugd2VyZSB3YWl0aW5nIG9uIEJlbiBmb3IgYW55dGhpbmcgZWxzZSwgYnV0IOKApikg SSBkaWRu4oCZdCBzZWUgdGhpcyBkaXNjdXNzaW9uIGFib3V0IHByb2ZpbGVzIGluIHRoZSBuZXcg LTA4IHRleHQuDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQooMykgQWJzdHJhY3QuICBQZXIg4oCcQmFiZWwgZG9lcyBub3QgY29udGFpbiBhbnkgbWVhbnMg 4oCmIFt0b10gcHJvdGVjdCBtZXNzYWdlc+KAnSwNCmJlIG1vcmUgcHJlY2lzZSBpbiB0aGUgZGVm aW5pdGlvbiBvZiBwcm90ZWN0IChpLmUuLCBpbnRlZ3JpdHkgYW5kDQpjb25maWRlbnRpYWxpdHkp DQoNCkFncmVlZCwgZml4ZWQuDQoNCig0KSBTZWN0aW9uIDEuMi4gIFBlciDigJxBIGNvbXBhcmlz b24gb2YgQmFiZWwgc2VjdXJpdHkgbWVjaGFuaXNtcyBhbmQgdGhlaXINCmFwcGxpY2FiaWxpdHkg Y2FuIGJlIGZvdW5kIGluIFtSRkM2MTI2YmlzXeKAnSwgd2hlcmUgaW4NCmRyYWZ0LWlldGYtYmFi ZWwtcmZjNjEyNmJpcyBkb2VzIHRoaXMgY29tcGFyaXNvbiBvY2N1ci4gIFRoZSByZWZlcmVuY2Vz IHRvIEhNQUMNCmFuZCBUTFMgYXJlIGluIGEgc2luZ2xlIHBhcmFncmFwaCBpbiBpbiBTZWN0aW9u IDYvU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgd2hpY2gNCnJvdWdobHkgcmVpdGVyYXRlIHRoZSBv bmUgc2VudGVuY2Ugc3RhdGVtZW50cyB3cml0dGVuIGhlcmUuDQoNCldlJ3ZlIGZsZXNoZWQgb3V0 IHRoZSB0ZXh0IGluIGRyYWZ0LWlldGYtYmFiZWwtcmZjNjEyNmJpcyBhbmQga2VwdCB0aGUgcmVm ZXJlbmNlDQppbiBkcmFmdC1pZXRmLWJhYmVsLWR0bHMuDQoNCig1KSBTZWN0aW9uIDIuMS4gIFBl ciDigJxXaGVuIGEgbm9kZSByZWNlaXZlcyBhIG5ldyBEVExTIGNvbm5lY3Rpb24sIGl0IE1VU1QN CnZlcmlmeSB0aGF0IHRoZSBzb3VyY2UgSVAgYWRkcmVzcyBpcyBhbiBJUHY2IGxpbmstbG9jYWwg YWRkcmVzcyDigKbigJ0sIHdoYXQNCmhhcHBlbnMgaWYgSVB2NCBpcyBpbiB1c2U/DQoNClRoaXMg d2FzIGFuIG92ZXJzaWdodC4gVGhlIHRleHQgbm93IGFsc28gZGlzY3Vzc2VzIElQdjQuDQoNCig2 KSBTZWN0aW9uIDIuMS4gUGVyIOKAnE5vZGVzIE1VU1Qgb25seSBuZWdvdGlhdGUgRFRMUyB2ZXJz aW9uIDEuMiBvciBoaWdoZXLigJ0sDQp0aGlzIGlzIHN0cmljdGVyIHRoYW4gUkZDNzUyNSBjaXRl ZCBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbiBsYXRlciBpbiB0aGUNCmRyYWZ0LiAgVGhh dOKAmXMgZmluZSwgYnV0IHBsZWFzZSByZWl0ZXJhdGUgdGhhdCBpbiBTZWN0aW9uIDUuDQoNCkRv bmUuDQoNCig3KSBTZWN0aW9uIDIuNiAgU3VnZ2VzdCBiZWluZyBjbGVhcmVyIHRoYXQgdGhpcyBp cyBhIGRlcGxveW1lbnQgbm90IGFuDQppbXBsZW1lbnRhdGlvbiBpc3N1ZS4gcy9JbXBsZW1lbnRh dGlvbnM8aHR0cDovL3MvSW1wbGVtZW50YXRpb25zPiBNQVkgaW1wbGVtZW50IGJvdGggQmFiZWwg b3ZlciBEVExTIGFuZA0KdW5wcm90ZWN0ZWQgQmFiZWwuLyAvQSBub2RlIE1BWSBydW4gYm90aCBC YWJlbCBvdmVyIERUTFMgYW5kIHVucHJvdGVjdGVkIEJhYmVsLi8NCg0KQWdyZWVkLiBXZSBhZGRl ZCB5b3VyIG5ldyBzZW50ZW5jZSBidXQgYWxzbyBrZXB0IHRoZSBvbGQgb25lIHNpbmNlIGJvdGgg YXJlIHRydWUuDQoNCig4KSBTZWN0aW9uIDIuNiwgUGVyIOKAnEhvd2V2ZXIsIGFjY2VwdGluZyB1 bnByb3RlY3RlZCBCYWJlbCBwYWNrZXRzIOKApiBsb3NlcyB0aGUNCnNlY3VyaXR5IHByb3BlcnRp ZXMgb2YgQmFiZWwgb3ZlciBEVExT4oCdLiAgVGhpcyBzZWVtcyBtaXNsZWFkaW5nLiAgVGhlIHNl Y3VyaXR5DQpwcm9wZXJ0aWVzIG9mIOKAnEJhYmVsIG92ZXIgRFRMU+KAnSBhcyBhIHByb3RvY29s IGFyZSBzdGF0ZWQgaW4gU2VjdGlvbiAxLjIuICBJbg0KdGhpcyBzZWN0aW9uIHRoZXJlIGlzIGRp c2N1c3Npb24gb2YgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgb2YgdGhlIG5vZGUgKGFuZA0KdGhl IHJlc3VsdGluZyBuZWlnaGJvciB0YWJsZSkuICBUaGVzZSBhcmUgZGlmZmVyZW50LiAgVGhlIGlz c3VlIHNlZW1zIHRvIGJlDQp0aGF0IGEgbm9kZSBpcyBidWlsZGluZyBhIG5laWdoYm9yIHRhYmxl IHdpdGggdXBkYXRlcyBmcm9tIHNvdXJjZXMgd2hpY2ggbmVlZA0KdG8gYmUgdHJ1c3RlZCB0byBk aWZmZXJlbnQgZGVncmVlcy4NCg0KQWdyZWVkLiBXZSd2ZSByZXdvcmtlZCB0aGF0IHBhcmFncmFw aC4NCg0KKDkpIFNlY3Rpb24gNS4gIFBlciDigJxDb25maWRlbnRpYWwgaW50ZXJhY3Rpb24gYmV0 d2VlbiB0d28gQmFiZWwgcGVlcnMgcmVxdWlyZXMNCkRhdGFncmFtIFRyYW5zcG9ydCBMYXllciBT ZWN1cml0eSAoRFRMUykgd2l0aCBhIGNpcGhlciBzdWl0ZSBvZmZlcmluZw0KY29uZmlkZW50aWFs aXR5IHByb3RlY3Rpb24uICBUaGUgZ3VpZGFuY2UgZ2l2ZW4gaW4gW1JGQzc1MjVdIE1VU1QgYmUg Zm9sbG93ZWQNCnRvIGF2b2lkIGF0dGFja3Mgb24gRFRMUy7igJ0sIHRoZSBmaXJzdCBzZW50ZW5j ZSBpcyB0cnVlLCBidXQgaW5jb21wbGV0ZSwgaW4gdGhhdA0Kd2XigJlkIGFsc28gd2FudCBjaXBo ZXIgc3VpdGVzIHdpdGggYSBzdHJvbmcga2V5IGV4Y2hhbmdlIGFsZ29yaXRobSwgZXRjLg0KU2Vj dGlvbiA0LjIgb2YgUkZDNzUyNSwgd2hpY2ggaXMgY2l0ZWQgYXMgYSBNVVNULCBwcm92aWRlcyBh IGxpc3Qgb2YNCnJlY29tbWVuZGVkIGNpcGhlcnMgc3VpdGVzLiAgRG8gd2UgbmVlZCB0aGlzIGZp cnN0IHNlbnRlbmNlPw0KDQpGYWlyIGVub3VnaCwgV2UndmUgcmVtb3ZlZCB0aGF0IHNlbnRlbmNl Lg0KDQooMTApIEVkaXRvcmlhbA0KLS0gU2VjdGlvbiAyLjEuICBFeHBhbmQg4oCcSUhV4oCdIG9u IGZpcnN0IHVzZQ0KDQpEb25lDQoNCi0tIFNlY3Rpb24gMy4gIE5pdC4gcy9jaXBoZXJzL2NpcGhl cnN1aXRlcy88aHR0cDovL3MvY2lwaGVycy9jaXBoZXJzdWl0ZXMvPg0KDQpEb25lDQoNCltSb21h bl0gVGhhbmtzIGZvciBhbGwgb2YgdGhlIGNoYW5nZXMgYWJvdmUhDQoNClJlZ2FyZHMsDQpSb21h bg0K --_000_359EC4B99E040048A7131E0F4E113AFC01B34054D4marchand_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIERhdmlkITxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IERhdmlkIFNjaGluYXppIFttYWlsdG86ZHNjaGluYXpp LmlldGZAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXVndXN0IDksIDIw MTkgNzo0MCBQTTxicj4NCjxiPlRvOjwvYj4gUm9tYW4gRGFueWxpdyAmbHQ7cmRkQGNlcnQub3Jn Jmd0Ozxicj4NCjxiPkNjOjwvYj4gVGhlIElFU0cgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7OyBkcmFm dC1pZXRmLWJhYmVsLWR0bHNAaWV0Zi5vcmc7IERvbmFsZCBFYXN0bGFrZSAmbHQ7ZDNlM2UzQGdt YWlsLmNvbSZndDs7IGJhYmVsLWNoYWlycyAmbHQ7YmFiZWwtY2hhaXJzQGlldGYub3JnJmd0Ozsg QmFiZWwgYXQgSUVURiAmbHQ7YmFiZWxAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBSb21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWJhYmVsLWR0bHMtMDc6 ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlJ3ZlIG5vdyBzdWJtaXR0ZWQgLTA4IHdoaWNoIGNv bnRhaW5zIHRoZSBjaGFuZ2VzIGRpc2N1c3NlZCBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdmlkPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgQXVnIDgsIDIwMTkgYXQgNTo0 NCBQTSBEYXZpZCBTY2hpbmF6aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRzY2hpbmF6aS5pZXRmQGdt YWlsLmNvbSI+ZHNjaGluYXppLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcyBmb3IgeW91ciByZXZpZXcgUm9tYW4hIFdlJ3ZlIG1hZGUgY2hhbmdlcyBv biBvdXIgZ2l0IHJlcG9zaXRvcnk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZsdDs8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vamVjaC9iYWJl bC1kcmFmdHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vamVjaC9iYWJlbC1k cmFmdHM8L2E+Jmd0OyBhbmQgd2lsbCBzdWJtaXQgYSByZXZpc2VkIGRyYWZ0IHNob3J0bHkuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRldGFp bGVkIHJlc3BvbnNlcyBpbmxpbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdmlkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEF1ZyA3LCAyMDE5IGF0IDEyOjI2IFBNIFJvbWFuIERh bnlsaXcgdmlhIERhdGF0cmFja2VyICZsdDs8YSBocmVmPSJtYWlsdG86bm9yZXBseUBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm5vcmVwbHlAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQpESVNDVVNTOjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQooMSkg U2VjdGlvbiAxLiBUaGVzZSBhcmUgZGlmZmVyZW50IHRoYW4gdGhlIG9uZXMgbGlzdGVkIGluIFNl Y3Rpb24gNiBvZjxicj4NCmRyYWZ0LWlldGYtYmFiZWwtcmZjNjEyNmJpcyBhbmQgU2VjdGlvbiAx IG9mIGRyYWZ0LWlldGYtYmFiZWwtZHRscy4mbmJzcDsgQXMgRFRMUzxicj4NCmFuZCBITUFDIGFy ZSBtaXRpZ2F0aW9ucyBmb3IgYXR0YWNrcyBpbiBkcmFmdC1pZXRmLWJhYmVsLXJmYzYxMjZiaXMs IHRoZXk8YnI+DQpyZWFsbHkgc2hvdWxkIGJlIGhhcm1vbml6ZWQuPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSd2ZSBmbGVzaGVk IG91dCB0aGUgdGV4dCBpbiZuYnNwO2RyYWZ0LWlldGYtYmFiZWwtcmZjNjEyNmJpcyBhbmQga2Vw dCB0aGUgcmVmZXJlbmNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5pbiBkcmFmdC1pZXRmLWJhYmVsLWR0bHMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPigyKSBTZWN0aW9uIDIuMS4m bmJzcDsgUGVyIOKAnEltcGxlbWVudGF0aW9ucyBNVVNUIHN1cHBvcnQgYXV0aGVudGljYXRpbmcg cGVlcnM8YnI+DQphZ2FpbnN0IGEgbG9jYWwgc3RvcmUgb2YgY3JlZGVudGlhbHPigJ0sIHdoYXQg ZG9lcyB0aGF0IGNyZWRlbnRpYWxpbmcgbG9vayBsaWtlPyA8YnI+DQpJcyBpdCBjZXJ0aWZpY2F0 ZXMsIFBTSywgZXRjPyZuYnNwOyBXaGF0IHZhbGlkYXRpb24gcHJvY2VkdXJlIGlzIGJlaW5nIHVz ZWQgZm9yIHRoaXM8YnI+DQphdXRoZW50aWNhdGlvbj88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbGwgcmVzcG9uZCB0byB0aGlz IHBvaW50IG9uIEJlbidzIERJU0NVU1Mgc2luY2UgSSB0aGluayB5b3UncmUgYm90aCBhc2tpbmc8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZvciB0 aGUgc2FtZSZuYnNwO3RoaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1JvbWFuXSBDb25jdXIgdGhhdCBCZW4g YW5kIEkgYXJlIHJhaXNpbmcgdGhlIHNhbWUgY29uY2Vybi4mbmJzcDsgSSBhcHByZWNpYXRlIHRo ZSBleHBsYW5hdGlvbiB5b3UgcHJvdmlkZWQgaW46PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvbXNnL2JhYmVsL0h1b0VHN0hHX3JTZnMzckNGWm8yWllkQ2xfSSI+aHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9iYWJlbC9IdW9FRzdIR19yU2ZzM3JDRlpvMlpZZENsX0k8 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZW7igJlzIHJl Y29tbWVuZGF0aW9uIHRvIGV4cGxpY2l0bHkgbm90ZSB0aGF0IHRoaXMgYXV0aGVudGljYXRpb24g bmVlZHMgdG8gYmUgc29sdmVkIGluIGV4dGVybmFsIHByb2ZpbGVzIHdvdWxkIGFkZHJlc3MgbXkg Y29uY2VybiB0b286PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2JhYmVsLzVBbkxs YUhQVEVzQkpwVjdXVnJaTHB3MDdscyI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNo L21zZy9iYWJlbC81QW5MbGFIUFRFc0JKcFY3V1ZyWkxwdzA3bHM8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4oSSBkb27igJl0IGtub3cgaWYgeW91IHdlcmUg d2FpdGluZyBvbiBCZW4gZm9yIGFueXRoaW5nIGVsc2UsIGJ1dCDigKYpIEkgZGlkbuKAmXQgc2Vl IHRoaXMgZGlzY3Vzc2lvbiBhYm91dCBwcm9maWxlcyBpbiB0aGUgbmV3IC0wOCB0ZXh0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpDT01NRU5UOjxicj4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnI+DQo8YnI+DQooMykgQWJzdHJhY3QuJm5ic3A7IFBlciDigJxCYWJlbCBk b2VzIG5vdCBjb250YWluIGFueSBtZWFucyDigKYgW3RvXSBwcm90ZWN0IG1lc3NhZ2Vz4oCdLDxi cj4NCmJlIG1vcmUgcHJlY2lzZSBpbiB0aGUgZGVmaW5pdGlvbiBvZiBwcm90ZWN0IChpLmUuLCBp bnRlZ3JpdHkgYW5kPGJyPg0KY29uZmlkZW50aWFsaXR5KTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVkLCBmaXhlZC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ KDQpIFNlY3Rpb24gMS4yLiZuYnNwOyBQZXIg4oCcQSBjb21wYXJpc29uIG9mIEJhYmVsIHNlY3Vy aXR5IG1lY2hhbmlzbXMgYW5kIHRoZWlyPGJyPg0KYXBwbGljYWJpbGl0eSBjYW4gYmUgZm91bmQg aW4gW1JGQzYxMjZiaXNd4oCdLCB3aGVyZSBpbjxicj4NCmRyYWZ0LWlldGYtYmFiZWwtcmZjNjEy NmJpcyBkb2VzIHRoaXMgY29tcGFyaXNvbiBvY2N1ci4mbmJzcDsgVGhlIHJlZmVyZW5jZXMgdG8g SE1BQzxicj4NCmFuZCBUTFMgYXJlIGluIGEgc2luZ2xlIHBhcmFncmFwaCBpbiBpbiBTZWN0aW9u IDYvU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgd2hpY2g8YnI+DQpyb3VnaGx5IHJlaXRlcmF0ZSB0 aGUgb25lIHNlbnRlbmNlIHN0YXRlbWVudHMgd3JpdHRlbiBoZXJlLjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlJ3Zl IGZsZXNoZWQgb3V0IHRoZSB0ZXh0IGluJm5ic3A7ZHJhZnQtaWV0Zi1iYWJlbC1yZmM2MTI2Ymlz IGFuZCBrZXB0IHRoZSByZWZlcmVuY2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmluIGRyYWZ0LWlldGYtYmFiZWwtZHRscy48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPig1KSBTZWN0aW9uIDIuMS4mbmJzcDsg UGVyIOKAnFdoZW4gYSBub2RlIHJlY2VpdmVzIGEgbmV3IERUTFMgY29ubmVjdGlvbiwgaXQgTVVT VDxicj4NCnZlcmlmeSB0aGF0IHRoZSBzb3VyY2UgSVAgYWRkcmVzcyBpcyBhbiBJUHY2IGxpbmst bG9jYWwgYWRkcmVzcyDigKbigJ0sIHdoYXQ8YnI+DQpoYXBwZW5zIGlmIElQdjQgaXMgaW4gdXNl PzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhpcyB3YXMgYW4gb3ZlcnNpZ2h0LiBUaGUgdGV4dCBub3cgYWxzbyBkaXNjdXNzZXMg SVB2NC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+KDYpIFNlY3Rpb24gMi4xLiBQZXIg4oCcTm9kZXMgTVVTVCBvbmx5IG5lZ290aWF0 ZSBEVExTIHZlcnNpb24gMS4yIG9yIGhpZ2hlcuKAnSw8YnI+DQp0aGlzIGlzIHN0cmljdGVyIHRo YW4gUkZDNzUyNSBjaXRlZCBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbiBsYXRlciBpbiB0 aGU8YnI+DQpkcmFmdC4mbmJzcDsgVGhhdOKAmXMgZmluZSwgYnV0IHBsZWFzZSByZWl0ZXJhdGUg dGhhdCBpbiBTZWN0aW9uIDUuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb25lLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oNykgU2VjdGlvbiAyLjYmbmJz cDsgU3VnZ2VzdCBiZWluZyBjbGVhcmVyIHRoYXQgdGhpcyBpcyBhIGRlcGxveW1lbnQgbm90IGFu PGJyPg0KaW1wbGVtZW50YXRpb24gaXNzdWUuIDxhIGhyZWY9Imh0dHA6Ly9zL0ltcGxlbWVudGF0 aW9ucyIgdGFyZ2V0PSJfYmxhbmsiPnMvSW1wbGVtZW50YXRpb25zPC9hPiBNQVkgaW1wbGVtZW50 IGJvdGggQmFiZWwgb3ZlciBEVExTIGFuZDxicj4NCnVucHJvdGVjdGVkIEJhYmVsLi8gL0Egbm9k ZSBNQVkgcnVuIGJvdGggQmFiZWwgb3ZlciBEVExTIGFuZCB1bnByb3RlY3RlZCBCYWJlbC4vPG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BZ3JlZWQuIFdlIGFkZGVkIHlvdXIgbmV3IHNlbnRlbmNlIGJ1dCBhbHNvIGtlcHQgdGhlIG9s ZCBvbmUgc2luY2UgYm90aCBhcmUgdHJ1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KDgpIFNlY3Rpb24gMi42LCBQZXIg4oCcSG93 ZXZlciwgYWNjZXB0aW5nIHVucHJvdGVjdGVkIEJhYmVsIHBhY2tldHMg4oCmIGxvc2VzIHRoZTxi cj4NCnNlY3VyaXR5IHByb3BlcnRpZXMgb2YgQmFiZWwgb3ZlciBEVExT4oCdLiZuYnNwOyBUaGlz IHNlZW1zIG1pc2xlYWRpbmcuJm5ic3A7IFRoZSBzZWN1cml0eTxicj4NCnByb3BlcnRpZXMgb2Yg 4oCcQmFiZWwgb3ZlciBEVExT4oCdIGFzIGEgcHJvdG9jb2wgYXJlIHN0YXRlZCBpbiBTZWN0aW9u IDEuMi4mbmJzcDsgSW48YnI+DQp0aGlzIHNlY3Rpb24gdGhlcmUgaXMgZGlzY3Vzc2lvbiBvZiB0 aGUgc2VjdXJpdHkgcHJvcGVydGllcyBvZiB0aGUgbm9kZSAoYW5kPGJyPg0KdGhlIHJlc3VsdGlu ZyBuZWlnaGJvciB0YWJsZSkuJm5ic3A7IFRoZXNlIGFyZSBkaWZmZXJlbnQuJm5ic3A7IFRoZSBp c3N1ZSBzZWVtcyB0byBiZTxicj4NCnRoYXQgYSBub2RlIGlzIGJ1aWxkaW5nIGEgbmVpZ2hib3Ig dGFibGUgd2l0aCB1cGRhdGVzIGZyb20gc291cmNlcyB3aGljaCBuZWVkPGJyPg0KdG8gYmUgdHJ1 c3RlZCB0byBkaWZmZXJlbnQgZGVncmVlcy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFncmVlZC4gV2UndmUgcmV3b3JrZWQgdGhh dCBwYXJhZ3JhcGguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPig5KSBTZWN0aW9uIDUuJm5ic3A7IFBlciDigJxDb25maWRlbnRpYWwg aW50ZXJhY3Rpb24gYmV0d2VlbiB0d28gQmFiZWwgcGVlcnMgcmVxdWlyZXM8YnI+DQpEYXRhZ3Jh bSBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKERUTFMpIHdpdGggYSBjaXBoZXIgc3VpdGUgb2Zm ZXJpbmcgPGJyPg0KY29uZmlkZW50aWFsaXR5IHByb3RlY3Rpb24uJm5ic3A7IFRoZSBndWlkYW5j ZSBnaXZlbiBpbiBbUkZDNzUyNV0gTVVTVCBiZSBmb2xsb3dlZDxicj4NCnRvIGF2b2lkIGF0dGFj a3Mgb24gRFRMUy7igJ0sIHRoZSBmaXJzdCBzZW50ZW5jZSBpcyB0cnVlLCBidXQgaW5jb21wbGV0 ZSwgaW4gdGhhdDxicj4NCndl4oCZZCBhbHNvIHdhbnQgY2lwaGVyIHN1aXRlcyB3aXRoIGEgc3Ry b25nIGtleSBleGNoYW5nZSBhbGdvcml0aG0sIGV0Yy4gPGJyPg0KU2VjdGlvbiA0LjIgb2YgUkZD NzUyNSwgd2hpY2ggaXMgY2l0ZWQgYXMgYSBNVVNULCBwcm92aWRlcyBhIGxpc3Qgb2Y8YnI+DQpy ZWNvbW1lbmRlZCBjaXBoZXJzIHN1aXRlcy4mbmJzcDsgRG8gd2UgbmVlZCB0aGlzIGZpcnN0IHNl bnRlbmNlPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RmFpciBlbm91Z2gsIFdlJ3ZlIHJlbW92ZWQgdGhhdCBzZW50ZW5jZS4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+KDEwKSBFZGl0b3JpYWw8YnI+DQotLSBTZWN0aW9uIDIuMS4mbmJzcDsgRXhwYW5kIOKA nElIVeKAnSBvbiBmaXJzdCB1c2U8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvbmUmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gU2VjdGlvbiAzLiZuYnNw OyBOaXQuIDxhIGhyZWY9Imh0dHA6Ly9zL2NpcGhlcnMvY2lwaGVyc3VpdGVzLyIgdGFyZ2V0PSJf YmxhbmsiPg0Kcy9jaXBoZXJzL2NpcGhlcnN1aXRlcy88L2E+PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb25lPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltSb21hbl0gVGhhbmtzIGZvciBhbGwgb2YgdGhlIGNo YW5nZXMgYWJvdmUhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Sb21hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_359EC4B99E040048A7131E0F4E113AFC01B34054D4marchand_-- From nobody Mon Aug 12 20:01: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 7F23612006A; Mon, 12 Aug 2019 20:01:02 -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 uxKdwmC80d65; Mon, 12 Aug 2019 20:01:00 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29FC3120052; Mon, 12 Aug 2019 20:01:00 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id f9so1626448ljc.13; Mon, 12 Aug 2019 20:01:00 -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=jJ4WuNf1d581g1iBYqympDVFw7hVE+PGxdBv87GoFI4=; b=T2Ql9sDlyohNjIyUuecN0PjG+YJixE5SJzpIqhoC+b33dlw+v9uoAYIoMU11JdqSfb yYZzw3CPPCOEcQuo2NN+NrHbRbmJZ9CwB2RuL47ePwnxWWLBvkb8MIxmdhVlLjpHfuSz XWoIBaXlDVcDXN/UUzDE1f0U5lx8svHIMbGrL2AytZo6Q+7lMoMXl8IJQkh1rgdVNUZS fLiIrLG+awfX5L0B2w493IO2R9xIhpLT64kchH8syNPMIlvhGoa6GfXsHjKDkfD/R6RD KgygUri729r7FudsnT5LDIn9jTPPOYQg/WeGlJh+uXIHXRaL5gaS9Q4M7orgcmEFKJcZ GEsQ== 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=jJ4WuNf1d581g1iBYqympDVFw7hVE+PGxdBv87GoFI4=; b=r4Ss4vcIPKv6WF1hpT2/wHvDjO6BAyigap0h1TqZQ0YE1o9hqyTrDUqKHAzY481JA0 79/3G15lkXMhL1/izmJGJwIbVN4cCbZekg3EvLsjEMvcQX2WnXDetNIYNgSo+FnRI1CI bQWVC04+KkZIArXMyrI+9Scm0f1QsMNESOV/j2LikyQ/CZCj8xU972P3ZFtPXYa3tthT /NG4aW4ZZSe4h6/JsxI47/sIddUCy9re0FjaXxYS0b+Il3FjdakFyykAwJL4TfaamlYs 3Nv9fbiEuS6X1qwStih4GSJTvBXuFR1tpx3HHngllbUlggbboDxtJyhJijW7GsGhQZOB uPgw== X-Gm-Message-State: APjAAAVUCcxbedL4XH92Bd5m69E4yLzK8j1QFZkzVsNHXNtMYhXkM1di P4fmbJOkWg2SJaK6BjUgNKmb8czuDIqgWhUnpa0= X-Google-Smtp-Source: APXvYqyQ72+AORCU2YilBuNimUjArVSnuAY6HMHWg4kFO3FbtYtKnfr3anNuXsSwSLwVoKuWGv44qEs1ID7x9riRDm4= X-Received: by 2002:a2e:96d5:: with SMTP id d21mr20894907ljj.170.1565665258223; Mon, 12 Aug 2019 20:00:58 -0700 (PDT) MIME-Version: 1.0 References: <156520596444.8244.649940515091541992.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B34054D4@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B34054D4@marchand> From: David Schinazi Date: Mon, 12 Aug 2019 20:00:47 -0700 Message-ID: To: Roman Danyliw Cc: The IESG , "draft-ietf-babel-dtls@ietf.org" , Donald Eastlake , babel-chairs , Babel at IETF Content-Type: multipart/alternative; boundary="0000000000008dbaf4058ff6d96e" Archived-At: Subject: Re: [babel] Roman Danyliw's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT) 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, 13 Aug 2019 03:01:03 -0000 --0000000000008dbaf4058ff6d96e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for your reply! On Mon, Aug 12, 2019 at 4:35 PM Roman Danyliw wrote: > Ben=E2=80=99s recommendation to explicitly note that this authentication = needs to > be solved in external profiles would address my concern too: > > > > https://mailarchive.ietf.org/arch/msg/babel/5AnLlaHPTEsBJpV7WVrZLpw07ls > > > > (I don=E2=80=99t know if you were waiting on Ben for anything else, but = =E2=80=A6) I > didn=E2=80=99t see this discussion about profiles in the new -08 text. > > The new profile text was added after -08 was submitted, it's in this commit= : https://github.com/jech/babel-drafts/commit/458a9ae6b9b136122d8668b26ba403f= 4f3a57167 Does it resolve your concern? If yes we'll submit a -09 with this new text. Thanks, David > --0000000000008dbaf4058ff6d96e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your reply!

On Mon, Aug 12, 2019 at 4:35 PM Roman Danyliw <rdd@cert.org> wrote:

Ben=E2=80=99s recommendation to explicitly n= ote that this authentication needs to be solved in external profiles would = address my concern too:

=C2=A0

https://mailarchi= ve.ietf.org/arch/msg/babel/5AnLlaHPTEsBJpV7WVrZLpw07ls

=C2=A0

(I don=E2=80=99t know if you were waiting on= Ben for anything else, but =E2=80=A6) I didn=E2=80=99t see this discussion= about profiles in the new -08 text.


The new profile= text was added after -08 was submitted, it's in this commit:
https://github.com/jech/babel-drafts/commit/458a9ae6= b9b136122d8668b26ba403f4f3a57167

Does it r= esolve your concern?
If yes we'll submit a -09 with this new = text.

Thanks,
David
--0000000000008dbaf4058ff6d96e-- From nobody Tue Aug 13 02:54: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 53ADD12008F for ; Tue, 13 Aug 2019 02:54:06 -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 p6ZmeFdtMHL7 for ; Tue, 13 Aug 2019 02:54:03 -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 99B331200E9 for ; Tue, 13 Aug 2019 02:54:03 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1565690040; bh=P4oX8Wb1bXJSWPIeNJOsXg2SGwATbqFBrrWZ5UYdOm0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=WaMEep6WV8KFrcV2nsZzNTcilYuRK/EZkWmL4A3IK8l7lYILYQGYY3NgStKZDrApD VC6CssymVQHxCjSDcTnAp6jYU+E9gaN/f/OJ95wxqxtOOWC3Mrl1bbxNXOuZD+qQsU QVShM9QhHy5wQRuJQmwdAgZ3ivzY3cZk4sol/qwOAmLVp7KMQwLFUDoW5y11Gei61m s2CZ4Ap7aRswEQW0wQL4q+B9vZwh4KQonprqOBEpTfTfSLIYVVjm6un1xRbH+ihmWC 7Q7iDPWecN343BuQT/gvSy4SdoD9HSdwms43NchlzBVPcGqtx+TWlOe/hLpZtDYdh7 dLTjrLH3d9CqA== To: David Schinazi , Juliusz Chroboczek Cc: Babel at IETF In-Reply-To: References: <87k1bjawf7.wl-jch@irif.fr> Date: Tue, 13 Aug 2019 11:53:59 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <877e7hcrwo.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] More about (H)MAC 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, 13 Aug 2019 09:54:06 -0000 David Schinazi writes: > That sounds good to me. No objections from me either... -Toke From nobody Tue Aug 13 06:08:58 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 DD953120154 for ; Tue, 13 Aug 2019 06:08:57 -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 7qDYcy_AKplM for ; Tue, 13 Aug 2019 06:08:56 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E74D120147 for ; Tue, 13 Aug 2019 06:08:56 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7DD4nix020101; Tue, 13 Aug 2019 09:08:55 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2ubuw0u24w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Aug 2019 09:08:55 -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 x7DD8rpu026462; Tue, 13 Aug 2019 09:08:53 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7DD8mYr026353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Aug 2019 09:08:49 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id B5FE74009E78; Tue, 13 Aug 2019 13:08:48 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30485.vci.att.com (Service) with ESMTPS id A36294009E74; Tue, 13 Aug 2019 13:08:48 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0439.000; Tue, 13 Aug 2019 09:08:48 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: "'babel@ietf.org'" Thread-Topic: [babel] I-D Action: draft-ietf-babel-information-model-08.txt Thread-Index: AQHVSy+136XJ0cDtj0yz+6M8HuFcTqbsr76wgAIi5wCACkT8kA== Date: Tue, 13 Aug 2019 13:08:47 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E26708E@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <156496962402.26572.16204290795859744323@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114E254159@GAALPA1MSGUSRBF.ITServices.sbc.com> <874l2uawcv.wl-jch@irif.fr> In-Reply-To: <874l2uawcv.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.230.113] 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-08-13_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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908130140 Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-08.txt 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, 13 Aug 2019 13:08:58 -0000 > Sections 3.1 and 3.3 -- please remove the hmac-algorithm. >=20 > The algorithm is a property of a key, not of an interface. There's no ne= ed to > specify the algo here, it is determined by the set of configured keys. (= And it > is quite legal to use keys with different algos on the same interface, fo= r > example when transitioning from one algorithm to a different one.) In that case, the MAC algorithm needs to associated with keys (add key-mac-= algorithm parameter to babel-hmac-keys-obj). And I'll be changing all "hmac" to "mac" in the model. =20 > The second point is something we've discussed before. The implementation > has the interface point at the set of keys; in the model, the key set poi= nts at > the interface. Is the discrepancy intentional? I don't see where a key set points to the interface? I only see where the i= nterface points to a set of keys: --------------------------------- 3.3. Definition of babel-interfaces-obj object { ... [reference rw babel-if-hmac-key-sets<0..*>;] ... [reference rw babel-if-dtls-cert-sets<0..*>;] ---------------------------------- There is the Boolean parameter in the key set object that indicates whether= it is automatically applied to a new interface. But that's not a pointer t= o any existing interface. Barbara From nobody Tue Aug 13 07:29:59 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 1DED2120219; Tue, 13 Aug 2019 07:29:50 -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, 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 (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAeclbm9pPeA; Tue, 13 Aug 2019 07:29:48 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 BB4D31201E3; Tue, 13 Aug 2019 07:29:48 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x7DETl5d046284; Tue, 13 Aug 2019 10:29:47 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x7DETl5d046284 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1565706587; bh=VULJbmdh85Kn2tEaltWPKttQBXKFdbtrKZacrSKZEbg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ETfjF+t1L0HBG2hByByPoYAJp1EfYVqL7c/lRqAHcwPxfMayYt68T3fG0L+X/KGk6 84DrikOhTpWH8X0Cj6NjdK2s6ta6uQJdHaLAvKAhgcCRZsmtFuBKVcLMs2ZKuNFXSN DaNXEulgYx+HCkwqVt2avjhNl4kLBMuYrNxTNAG8= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x7DEThPE018828; Tue, 13 Aug 2019 10:29:43 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0468.000; Tue, 13 Aug 2019 10:29:43 -0400 From: Roman Danyliw To: David Schinazi CC: The IESG , "draft-ietf-babel-dtls@ietf.org" , Donald Eastlake , babel-chairs , Babel at IETF Thread-Topic: Roman Danyliw's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT) Thread-Index: AQHVTVX/GUz1qFLfsU6ZzqI2Nk9MnqbyP5aAgAGAUwCABG7OgIAAgEeAgAB8qLA= Date: Tue, 13 Aug 2019 14:29:42 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B34056BD@marchand> References: <156520596444.8244.649940515091541992.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B34054D4@marchand> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC01B34056BDmarchand_" MIME-Version: 1.0 Archived-At: Subject: Re: [babel] Roman Danyliw's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT) 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, 13 Aug 2019 14:29:50 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC01B34056BDmarchand_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQhDQoNCkZyb206IERhdmlkIFNjaGluYXppIFttYWlsdG86ZHNjaGluYXppLmlldGZA Z21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBBdWd1c3QgMTIsIDIwMTkgMTE6MDEgUE0NClRvOiBS b21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+DQpDYzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+ OyBkcmFmdC1pZXRmLWJhYmVsLWR0bHNAaWV0Zi5vcmc7IERvbmFsZCBFYXN0bGFrZSA8ZDNlM2Uz QGdtYWlsLmNvbT47IGJhYmVsLWNoYWlycyA8YmFiZWwtY2hhaXJzQGlldGYub3JnPjsgQmFiZWwg YXQgSUVURiA8YmFiZWxAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogUm9tYW4gRGFueWxpdydzIERp c2N1c3Mgb24gZHJhZnQtaWV0Zi1iYWJlbC1kdGxzLTA3OiAod2l0aCBESVNDVVNTIGFuZCBDT01N RU5UKQ0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkhDQoNCk9uIE1vbiwgQXVnIDEyLCAyMDE5IGF0 IDQ6MzUgUE0gUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPG1haWx0bzpyZGRAY2VydC5vcmc+ PiB3cm90ZToNCkJlbuKAmXMgcmVjb21tZW5kYXRpb24gdG8gZXhwbGljaXRseSBub3RlIHRoYXQg dGhpcyBhdXRoZW50aWNhdGlvbiBuZWVkcyB0byBiZSBzb2x2ZWQgaW4gZXh0ZXJuYWwgcHJvZmls ZXMgd291bGQgYWRkcmVzcyBteSBjb25jZXJuIHRvbzoNCg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5p ZXRmLm9yZy9hcmNoL21zZy9iYWJlbC81QW5MbGFIUFRFc0JKcFY3V1ZyWkxwdzA3bHMNCg0KKEkg ZG9u4oCZdCBrbm93IGlmIHlvdSB3ZXJlIHdhaXRpbmcgb24gQmVuIGZvciBhbnl0aGluZyBlbHNl LCBidXQg4oCmKSBJIGRpZG7igJl0IHNlZSB0aGlzIGRpc2N1c3Npb24gYWJvdXQgcHJvZmlsZXMg aW4gdGhlIG5ldyAtMDggdGV4dC4NCg0KVGhlIG5ldyBwcm9maWxlIHRleHQgd2FzIGFkZGVkIGFm dGVyIC0wOCB3YXMgc3VibWl0dGVkLCBpdCdzIGluIHRoaXMgY29tbWl0Og0KaHR0cHM6Ly9naXRo dWIuY29tL2plY2gvYmFiZWwtZHJhZnRzL2NvbW1pdC80NThhOWFlNmI5YjEzNjEyMmQ4NjY4YjI2 YmE0MDNmNGYzYTU3MTY3DQoNCkRvZXMgaXQgcmVzb2x2ZSB5b3VyIGNvbmNlcm4/DQpJZiB5ZXMg d2UnbGwgc3VibWl0IGEgLTA5IHdpdGggdGhpcyBuZXcgdGV4dC4NCg0KW1JvbWFuXSAgVW5kZXJz dG9vZC4gIFllcywgdGhhdCB0ZXh0IHJlc29sdmVzIG15IGNvbmNlcm4uICBUaGFuayB5b3UuDQoN ClJvbWFuDQo= --_000_359EC4B99E040048A7131E0F4E113AFC01B34056BDmarchand_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIERhdmlkITxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IERhdmlkIFNjaGluYXppIFttYWlsdG86ZHNjaGluYXpp LmlldGZAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDEyLCAy MDE5IDExOjAxIFBNPGJyPg0KPGI+VG86PC9iPiBSb21hbiBEYW55bGl3ICZsdDtyZGRAY2VydC5v cmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDs7IGRy YWZ0LWlldGYtYmFiZWwtZHRsc0BpZXRmLm9yZzsgRG9uYWxkIEVhc3RsYWtlICZsdDtkM2UzZTNA Z21haWwuY29tJmd0OzsgYmFiZWwtY2hhaXJzICZsdDtiYWJlbC1jaGFpcnNAaWV0Zi5vcmcmZ3Q7 OyBCYWJlbCBhdCBJRVRGICZsdDtiYWJlbEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFJvbWFuIERhbnlsaXcncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtYmFiZWwtZHRscy0w NzogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgeW91ciByZXBseSE8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgQXVn IDEyLCAyMDE5IGF0IDQ6MzUgUE0gUm9tYW4gRGFueWxpdyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJk ZEBjZXJ0Lm9yZyI+cmRkQGNlcnQub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZW7igJlzIHJlY29tbWVuZGF0aW9u IHRvIGV4cGxpY2l0bHkgbm90ZSB0aGF0IHRoaXMgYXV0aGVudGljYXRpb24gbmVlZHMgdG8gYmUg c29sdmVkIGluIGV4dGVybmFsIHByb2ZpbGVzDQogd291bGQgYWRkcmVzcyBteSBjb25jZXJuIHRv bzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48YSBocmVm PSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2JhYmVsLzVBbkxsYUhQVEVz QkpwVjdXVnJaTHB3MDdscyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0 Zi5vcmcvYXJjaC9tc2cvYmFiZWwvNUFuTGxhSFBURXNCSnBWN1dWclpMcHcwN2xzPC9hPjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPihJIGRvbuKAmXQga25v dyBpZiB5b3Ugd2VyZSB3YWl0aW5nIG9uIEJlbiBmb3IgYW55dGhpbmcgZWxzZSwgYnV0IOKApikg SSBkaWRu4oCZdCBzZWUgdGhpcyBkaXNjdXNzaW9uIGFib3V0DQogcHJvZmlsZXMgaW4gdGhlIG5l dyAtMDggdGV4dC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBuZXcgcHJvZmlsZSB0ZXh0 IHdhcyBhZGRlZCBhZnRlciAtMDggd2FzIHN1Ym1pdHRlZCwgaXQncyBpbiB0aGlzIGNvbW1pdDo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhy ZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9qZWNoL2JhYmVsLWRyYWZ0cy9jb21taXQvNDU4YTlhZTZi OWIxMzYxMjJkODY2OGIyNmJhNDAzZjRmM2E1NzE2NyI+aHR0cHM6Ly9naXRodWIuY29tL2plY2gv YmFiZWwtZHJhZnRzL2NvbW1pdC80NThhOWFlNmI5YjEzNjEyMmQ4NjY4YjI2YmE0MDNmNGYzYTU3 MTY3PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Eb2VzIGl0IHJlc29sdmUgeW91ciBjb25jZXJuPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeWVzIHdlJ2xsIHN1Ym1pdCBhIC0wOSB3 aXRoIHRoaXMgbmV3IHRleHQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltS b21hbl0mbmJzcDsgVW5kZXJzdG9vZC4gJm5ic3A7WWVzLCB0aGF0IHRleHQgcmVzb2x2ZXMgbXkg Y29uY2Vybi4mbmJzcDsgVGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Um9tYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_359EC4B99E040048A7131E0F4E113AFC01B34056BDmarchand_-- From nobody Tue Aug 13 08:01: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 D8A801201E3 for ; Tue, 13 Aug 2019 08:01:18 -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 EJJXwBo-A1nr for ; Tue, 13 Aug 2019 08:01:17 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D8612021D for ; Tue, 13 Aug 2019 08:01:16 -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 x7DF18dH020338; Tue, 13 Aug 2019 17:01:08 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 330044238E; Tue, 13 Aug 2019 17:01:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 5UbTmyzFQnYx; Tue, 13 Aug 2019 17:01:10 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 8FEE44238B; Tue, 13 Aug 2019 17:01:08 +0200 (CEST) Date: Tue, 13 Aug 2019 17:01:07 +0200 Message-ID: <87blwtun2k.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'babel@ietf.org'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E26708E@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <156496962402.26572.16204290795859744323@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114E254159@GAALPA1MSGUSRBF.ITServices.sbc.com> <874l2uawcv.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E26708E@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 13 Aug 2019 17:01:08 +0200 (CEST) X-Miltered: at korolev with ID 5D52D0B4.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D52D0B4.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 : 5D52D0B4.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-08.txt 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, 13 Aug 2019 15:01:19 -0000 >> The second point is something we've discussed before. The >> implementation has the interface point at the set of keys; in the >> model, the key set points at the interface. Is the discrepancy >> intentional? > I don't see where a key set points to the interface? I only see where > the interface points to a set of keys: Section 3.8: babel-hmac-interfaces: List of references to the babel-interfaces entries this babel-hmac entry applies to. From nobody Tue Aug 13 08:40:56 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 065E81207FE for ; Tue, 13 Aug 2019 08:40: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 cdhgSFM36qsW for ; Tue, 13 Aug 2019 08:40: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 71BCF12083C for ; Tue, 13 Aug 2019 08:40:48 -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 x7DFedRl031473; Tue, 13 Aug 2019 17:40:39 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9D57842610; Tue, 13 Aug 2019 17:40:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id p42cVow3O-I7; Tue, 13 Aug 2019 17:40:41 +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 CC4FD4260D; Tue, 13 Aug 2019 17:40:38 +0200 (CEST) Date: Tue, 13 Aug 2019 17:40:38 +0200 Message-ID: <8736i5ul8p.wl-jch@irif.fr> From: Juliusz Chroboczek To: Barbara Stark CC: babel@ietf.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 13 Aug 2019 17:40:39 +0200 (CEST) X-Miltered: at korolev with ID 5D52D9F7.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D52D9F7.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 : 5D52D9F7.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [babel] HMAC: removed constraint on the key stored in interface table 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, 13 Aug 2019 15:40:55 -0000 Dear Barbara, I have removed from draft...hmac the requirement for the key that is stored in the interface entry for being equal to the block size of the hash. This means that you need to put this requirement in the information model. After thinking it over, I don't think it's part of the HMAC protocol, since it's not visible on the wire. It's purely a management issue, and thus should be in the management document. -- Juliusz From nobody Tue Aug 13 09:02:57 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 F231012020A for ; Tue, 13 Aug 2019 09:02:54 -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 F0y4DbF-4i9p for ; Tue, 13 Aug 2019 09:02:53 -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 55AC91200FA for ; Tue, 13 Aug 2019 09:02:53 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7DG03PZ005322; Tue, 13 Aug 2019 12:02:52 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 2ubyx6rxuj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Aug 2019 12:02:51 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7DG2oVm011741; Tue, 13 Aug 2019 12:02:51 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7DG2htG011436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Aug 2019 12:02:44 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 8E7244009E74; Tue, 13 Aug 2019 16:02:43 +0000 (GMT) Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (unknown [130.8.218.153]) by zlp30485.vci.att.com (Service) with ESMTPS id 78B524009E7B; Tue, 13 Aug 2019 16:02:43 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0439.000; Tue, 13 Aug 2019 12:02:40 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: "'babel@ietf.org'" Thread-Topic: [babel] I-D Action: draft-ietf-babel-information-model-08.txt Thread-Index: AQHVSy+136XJ0cDtj0yz+6M8HuFcTqbsr76wgAIi5wCACkT8kIAAZOyA///NHZA= Date: Tue, 13 Aug 2019 16:02:40 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E26762D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <156496962402.26572.16204290795859744323@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114E254159@GAALPA1MSGUSRBF.ITServices.sbc.com> <874l2uawcv.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E26708E@GAALPA1MSGUSRBF.ITServices.sbc.com> <87blwtun2k.wl-jch@irif.fr> In-Reply-To: <87blwtun2k.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.230.113] 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-08-13_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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=747 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908130160 Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-08.txt 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, 13 Aug 2019 16:02:55 -0000 > >> The second point is something we've discussed before. The > >> implementation has the interface point at the set of keys; in the > >> model, the key set points at the interface. Is the discrepancy > >> intentional? >=20 > > I don't see where a key set points to the interface? I only see where > > the interface points to a set of keys: >=20 > Section 3.8: >=20 > babel-hmac-interfaces: List of references to the babel-interfaces > entries this babel-hmac entry applies to. I don't see that in -08 https://tools.ietf.org/html/draft-ietf-babel-information-model-08 Where are you looking? My github is behind datatracker, right now -- are yo= u looking there? Barbara From nobody Tue Aug 13 10:11: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 68D34120127 for ; Tue, 13 Aug 2019 10:11:22 -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 X-Tpb_PQTepo for ; Tue, 13 Aug 2019 10:11:20 -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 7ACCF1200D6 for ; Tue, 13 Aug 2019 10:11:20 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7DHBDSs024946; Tue, 13 Aug 2019 19:11:13 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 7127A42CCD; Tue, 13 Aug 2019 19:11:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id uQ2lfu_IQCSw; Tue, 13 Aug 2019 19:11:15 +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 E3ED742CC3; Tue, 13 Aug 2019 19:11:12 +0200 (CEST) Date: Tue, 13 Aug 2019 19:11:12 +0200 Message-ID: <87zhkdt2hb.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'babel@ietf.org'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E26762D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <156496962402.26572.16204290795859744323@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114E254159@GAALPA1MSGUSRBF.ITServices.sbc.com> <874l2uawcv.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E26708E@GAALPA1MSGUSRBF.ITServices.sbc.com> <87blwtun2k.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E26762D@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 13 Aug 2019 19:11:13 +0200 (CEST) X-Miltered: at korolev with ID 5D52EF31.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D52EF31.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 : 5D52EF31.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-08.txt 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, 13 Aug 2019 17:11:23 -0000 > https://tools.ietf.org/html/draft-ietf-babel-information-model-08 My bad -- I've been a victim of a bug in the tools website. (For some reason, if you click on -05, then there are no later versions displayed, so it looks like -05 is the latest version.) From nobody Tue Aug 13 11:04: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 E9D87120801 for ; Tue, 13 Aug 2019 11:04:05 -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 1DjKiffxFt1L for ; Tue, 13 Aug 2019 11:04:04 -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 B3136120251 for ; Tue, 13 Aug 2019 11:04:04 -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 x7DHn5v3041204; Tue, 13 Aug 2019 14:04:02 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2uc1r4gye8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Aug 2019 14:04:01 -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 x7DI3tHD025389; Tue, 13 Aug 2019 14:03:56 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7DI3nsC025242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Aug 2019 14:03:50 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 157E74009E7E; Tue, 13 Aug 2019 18:03:49 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30486.vci.att.com (Service) with ESMTPS id 01B234009E7A; Tue, 13 Aug 2019 18:03:49 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0439.000; Tue, 13 Aug 2019 14:03:48 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: "'babel@ietf.org'" Thread-Topic: HMAC: removed constraint on the key stored in interface table Thread-Index: AQHVUe2J94IZUlXvWUGht5ECY/kmSKb5V8Hw Date: Tue, 13 Aug 2019 18:03:47 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E26794B@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8736i5ul8p.wl-jch@irif.fr> In-Reply-To: <8736i5ul8p.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.230.113] 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-08-13_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908130166 Archived-At: Subject: Re: [babel] HMAC: removed constraint on the key stored in interface table 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, 13 Aug 2019 18:04:06 -0000 > I have removed from draft...hmac the requirement for the key that is stor= ed > in the interface entry for being equal to the block size of the hash. Th= is > means that you need to put this requirement in the information model. >=20 > After thinking it over, I don't think it's part of the HMAC protocol, sin= ce it's > not visible on the wire. It's purely a management issue, and thus should= be > in the management document. But this brings us back to the problems that prompted this text in the hmac= draft. Where the Bird implementation manipulated the input "key" according= to the HMAC RFC (which defined several different things that it called a "= key", IIRC) -- and this was unexpected and would not have interoperated wit= h the babeld implementation (the two implementations would send different b= its on the wire, given the same input key). Somehow, I need to be sure that= for a given input key, I'll always get the same output on the wire, no mat= ter which Babel implementation I'm inputting the key to.=20 The information model is not normative for babel-hmac. So info model cannot= impose any input condition or constraint on a babel-hmac implementation, r= elated to what values can be expected for a key. The Bird implementation al= lowed someone to enter the key through a GUI. This is a major proposed change that can lead to non-interoperability. I think it would also make Dave Taht unhappy. You don't want to make Dave u= nhappy, do you? Barbara From nobody Tue Aug 13 11:09: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 134CA120125 for ; Tue, 13 Aug 2019 11:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 6JxBduYJ1tLS for ; Tue, 13 Aug 2019 11:09:09 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 9515E1200B1 for ; Tue, 13 Aug 2019 11:09:09 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id gn20so347315plb.2 for ; Tue, 13 Aug 2019 11:09:09 -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=u/P4gRbzmjXEnewD/fiIKBVJilgkltZ1STDXG9vrJIg=; b=j8FSZJ9MOLi2zxuAcKR4NmNO3JMTuPEVVvdgnquWVidRS/MbpabKooX9kbqcwxAdN5 mVPYl4c4uKhR8ZVw2LgmSbQ4ocNCZ+WxmEFkQ/ODhoFvpRcUp10JI6tnAlVYK1wJ9A/P ZTTm6gnXJvIMW/ZfTLZXYuFWp1k1tan23me1tJ0I+d9PuBYZSl+p++OWymin3wSLW6gD CHX8/QY3/5LzDnOyM7Cddm7laVmBAaYb2WWCpATslsEJF4YQqWQ200AXzhTb30MRZzO2 rzOSXhzgIFdpbjYsVvw/0sTJNZZbCrWeXmqrH5qX/vIQ/7VrPW1AfEEppKSfT2yS88Xu S2Yw== 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=u/P4gRbzmjXEnewD/fiIKBVJilgkltZ1STDXG9vrJIg=; b=cwRlu13+I69JVQtQxQhCpmqmpK0fgyX4wo0qgZ0/QzNJ9tLyw7GIemAOXZOXDZJqf8 yWoZTXwcfLFUvAAQ+t1W334Sd8vHhEHolbiNdCAQnBsrEZRHIXm9WZr0b6UV4Uk50zrX nyNu/cNtqqW99t6rhj/+ktHsttzXPfOMnjv2jofnUxdySszzdS5ImP9Gw0U8OqNUooOR S8JFmfx7SHDZDA2y1pdqwfiDh+MNnFZSc+ryFbyb0giguNJOQsbAoBTpZZefcQ3Jft7U LTqc35+RFAOfUiFy/pEX9ir+TrljGbbMhj3sOCR47Hr3NbI7+2eFPsV+ynqo3pz//GMU /Kog== X-Gm-Message-State: APjAAAX0VwEGWJnzEa1MqRwSAvuHV37MnZ3uddaCSQmDtJSvpGH3mhMr 2nO7PB+RTomHxWdlJQuugtg= X-Google-Smtp-Source: APXvYqzaMpWIggYsiLyOE9GdveOFobZapeLtlhGVs8RcRSLvE4XzJODc/b8VDybg0KR0j+EX8YDzFw== X-Received: by 2002:a17:902:2ae8:: with SMTP id j95mr35804384plb.276.1565719749091; Tue, 13 Aug 2019 11:09:09 -0700 (PDT) Received: from [10.33.122.240] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id k64sm42158545pgk.74.2019.08.13.11.09.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Aug 2019 11:09:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mahesh Jethanandani In-Reply-To: <87sgqbmhhe.wl-jch@irif.fr> Date: Tue, 13 Aug 2019 11:09:07 -0700 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , "STARK, BARBARA H" , Babel at IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr> <87pnlhaixh.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E257961@GAALPA1MSGUSRBF.ITServices.sbc.com> <0B28A1FA-32B4-41E6-B646-C6A3907E9CCC@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114E258CF7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E25905B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87lfw3u52i.fsf@toke.dk> <110D87BA-BBA1-417B-9BC3-77BAD4B201D1@gmail.com> <87ftmbs92f.fsf@toke.dk> <26F1A0CD-1FD2-456E-B295-8A60D93CF8E0@gmail.com> <87sgqbmhhe.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Example configuration 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, 13 Aug 2019 18:09:11 -0000 Hi Juliusz, > On Aug 8, 2019, at 3:15 PM, Juliusz Chroboczek wrote: >=20 >> In the second example, the operator will define a = babel-link-properties-obj, >> call it =E2=80=9Cradio=E2=80=9D or =E2=80=9Cwireless=E2=80=9D or = anything they want, and within that object set >> the babel-interface-metric-algorithm (because it a mandatory = parameter), and >> set the babel-split-horizon to false. They will then associate = =E2=80=9Cradio=E2=80=9D object >> with eth1 interface. >=20 > Can the UI simulate the babel-link-properties-obj without it being = part of > the model? Before I answer that question, let me know if the following answers = help. If they do not, I am afraid that we will need a whiteboard = discussion on management interface and the role YANG plays in it. >=20 > I.e. the operator defines a set of values called "radio", this set = only > exists within the UI. =20 =E2=80=9Cradio=E2=80=9D in my example is what you call UIs, just like = =E2=80=9Cwireless=E2=80=9D. Therefore when you say =E2=80=9Cset of = values called =E2=80=9Cradio=E2=80=9D=E2=80=9D, I read it as set of link = properties that you want to club together and associate with a name, and = that name is =E2=80=9Cradio". Is that correct? > The operator then applies "radio" to a number of > interfaces, and the frontend applies the individual values contained = in > the "radio" dictionary to each of those interfaces. But that is exactly what the new babel-link-properties-obj allows you to = do. It allows you to define any number of babel-link-properties-obj, and = name them whatever you want, e.g. =E2=80=9Cradio=E2=80=9D, =E2=80=9Cwired=E2= =80=9D, =E2=80=9Cwireless=E2=80=9D etc, or what you call =E2=80=9CUI". = In each of the babel-link-properties-obj you set the properties you = want, e.g. split horizon, rtt, etc. As a final step you associate any = of the defined UI with any number of interfaces. When you associate the = given UI with an interface, all the link properties defined as part of = that UI are then applied on the interface. Did that answer your question, or confuse you even more? >=20 > Or does YANG require that the UI reflect the model? >=20 > -- Juliusz Mahesh Jethanandani mjethanandani@gmail.com From nobody Tue Aug 13 11:54:54 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 43BA31201B7 for ; Tue, 13 Aug 2019 11:54: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 PyhWAx6uffDS for ; Tue, 13 Aug 2019 11:54:51 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFEB4120814 for ; Tue, 13 Aug 2019 11:54:50 -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 x7DIrUUd028095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Aug 2019 20:53:30 +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 x7DIrUFJ032740; Tue, 13 Aug 2019 20:53:30 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 59BB4431D0; Tue, 13 Aug 2019 20:53:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 1XSlnNBAI1qc; Tue, 13 Aug 2019 20:53:32 +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 E8BDF431CE; Tue, 13 Aug 2019 20:53:29 +0200 (CEST) Date: Tue, 13 Aug 2019 20:53:29 +0200 Message-ID: <87v9v0ucba.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'babel@ietf.org'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E26794B@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8736i5ul8p.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E26794B@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 13 Aug 2019 20:53:30 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 13 Aug 2019 20:53:31 +0200 (CEST) X-Miltered: at korolev with ID 5D53072A.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D53072A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D53072A.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D53072A.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 : 5D53072A.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D53072A.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] HMAC: removed constraint on the key stored in interface table 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, 13 Aug 2019 18:54:54 -0000 >> I have removed from draft...hmac the requirement for the key that is >> stored in the interface entry for being equal to the block size of the >> hash. [...] It's purely a management issue, and thus should be in the >> management document. > But this brings us back to the problems that prompted this text in the > hmac draft. The problem is that this constraint is not normatively enforceable. The point is that this normalisation property is never used in the (H)MAC draft -- it appears there as a completely arbitrary requirement on the conceptual data structures that has no effect on what bits are sent on the wire. Since the data structures are conceptual, an implementation is allowed to use any other representation that leads to the same on-the-wire result. In the words of RFC 6126bis: This description is conceptual: a Babel speaker may use different data structures as long as the resulting protocol is the same as the one described in this document. What I'm suggesting is that you add something to the following effect to the description of babel-mac-key-value: In the case where babel-mac-key-algorithm specifies an algorithm based on the HMAC construction, then this value MUST be the exact size of the hash's block size (i.e. it has already undergone any preprocessing, such as the hashing or zero extension described in Section 2 of RFC 2104). > This is a major proposed change that can lead to non-interoperability. I don't see how. The end result is the same; the only difference is that now the normalisation is allowed to happen in the management interface. > I think it would also make Dave Taht unhappy. You don't want to make > Dave unhappy, do you? It sometimes takes a tough man to make a tender chicken. -- Juliusz From nobody Tue Aug 13 13:35: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 60902120916 for ; Tue, 13 Aug 2019 13:35:18 -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 QRO7a1ZwZDlg for ; Tue, 13 Aug 2019 13:35:15 -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 8CEC612091D for ; Tue, 13 Aug 2019 13:35:15 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7DKYxEU032983; Tue, 13 Aug 2019 16:35:13 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 2uc3eysmsp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Aug 2019 16:35:12 -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 x7DKZBaE004211; Tue, 13 Aug 2019 16:35:11 -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 x7DKZ7s9004098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Aug 2019 16:35:07 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id F119E4009E72; Tue, 13 Aug 2019 20:35:06 +0000 (GMT) Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (unknown [130.8.218.153]) by zlp30484.vci.att.com (Service) with ESMTPS id DD4D64009E62; Tue, 13 Aug 2019 20:35:06 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0439.000; Tue, 13 Aug 2019 16:35:06 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: "'babel@ietf.org'" Thread-Topic: HMAC: removed constraint on the key stored in interface table Thread-Index: AQHVUe2J94IZUlXvWUGht5ECY/kmSKb5V8HwgABYPID//8teAA== Date: Tue, 13 Aug 2019 20:35:05 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E267D1B@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8736i5ul8p.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E26794B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87v9v0ucba.wl-jch@irif.fr> In-Reply-To: <87v9v0ucba.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.230.113] 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-08-13_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=741 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908130195 Archived-At: Subject: Re: [babel] HMAC: removed constraint on the key stored in interface table 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, 13 Aug 2019 20:35:19 -0000 > What I'm suggesting is that you add something to the following effect to = the > description of babel-mac-key-value: >=20 > In the case where babel-mac-key-algorithm specifies an algorithm based > on the HMAC construction, then this value MUST be the exact size of the > hash's block size (i.e. it has already undergone any preprocessing, suc= h > as the hashing or zero extension described in Section 2 of RFC 2104). So the way I interpret this is the only HMAC key length I can reliably expe= ct all implementations to treat the same, is a key the same length as the h= ash block size. Is there any rule for Blake2s keys? I see from RFC7693 that a Blake2s key c= an be 0 <=3D kk <=3D 32. The RFC tells the implementation to zero-pad keys = less than 32 bytes. So do I maybe have a rule that - for algorithms based on HMAC construction, the key MUST be the exact siz= e of the block size. For HMAC-SHA256, this is defined in RFC4868 as 64 byte= s. - for algorithms with specifications that unambiguously define allowed key= length, the key MUST be the maximum length allowed by the specification. F= or Blake2s, this is defined in RFC7693 as 32 bytes. - for other algorithms, the key MUST be the maximum key length that can be= provided such that the implementation will not zero-pad or otherwise manip= ulate the key prior to use. ? Or maybe I just say: The key MUST be the maximum key length that can be provided such that the i= mplementation will not zero-pad, truncate, or otherwise manipulate the key = prior to use. For HMAC-SHA256, this is defined in RFC4868 as 64 bytes. For = Blake2s, this is defined in RFC7693 as 32 bytes. ? Barbara From nobody Tue Aug 13 14:58:46 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 874F21208F3 for ; Tue, 13 Aug 2019 14:58:33 -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 VM9G8wkFc7qa for ; Tue, 13 Aug 2019 14:58:31 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13AE120919 for ; Tue, 13 Aug 2019 14:58:30 -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 x7DLwIAi004454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Aug 2019 23:58:18 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x7DLwIpf018446; Tue, 13 Aug 2019 23:58:18 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3433443621; Tue, 13 Aug 2019 23:58:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id BYMM1JOKOdSv; Tue, 13 Aug 2019 23:58:15 +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 77DBA4361C; Tue, 13 Aug 2019 23:58:10 +0200 (CEST) Date: Tue, 13 Aug 2019 23:58:09 +0200 Message-ID: <87r25ou3ri.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'babel@ietf.org'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E267D1B@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8736i5ul8p.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E26794B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87v9v0ucba.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267D1B@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 13 Aug 2019 23:58:18 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 13 Aug 2019 23:58:18 +0200 (CEST) X-Miltered: at korolev with ID 5D53327A.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D53327A.004 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D53327A.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D53327A.004 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D53327A.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D53327A.004 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] HMAC: removed constraint on the key stored in interface table 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, 13 Aug 2019 21:58:45 -0000 >> What I'm suggesting is that you add something to the following effect to >> the description of babel-mac-key-value: In the case where >> babel-mac-key-algorithm specifies an algorithm based on the HMAC >> construction, then this value MUST be the exact size of the hash's block >> size (i.e. it has already undergone any preprocessing, such as the >> hashing or zero extension described in Section 2 of RFC 2104). > Or maybe I just say: The key MUST be the maximum key length that can be > provided such that the implementation will not zero-pad, truncate, or > otherwise manipulate the key prior to use. For HMAC-SHA256, this is > defined in RFC4868 as 64 bytes. For Blake2s, this is defined in RFC7693 as > 32 bytes. ? We have at least three reasonable options. 1. Deterministic: - for HMAC based algorithms, the key is exactly the block size (64 bytes for HMAC-SHA256); - for Blake2s, it is exactly 32 bytes. This is deterministic, but not very convenient for the user (the user needs to do zero-pad himself). The behaviour is suprising to the user, especially in the case of Blake2s. 2. Consistent: - for HMAC based algorithms, the key is at most the block size (64 bytes for HMAC-SHA256), and is zero-padded as described in Sectin 2 of RFC 2104; - for Blake2s, it is at most 32 bytes. This makes behaviour coherent between HMAC and Blake2s, in both cases any size of key is allowed up some maximum. This is convenient for the user (who can use shorter keys), and reasonably deterministic -- the only operation performed on the key is zero-padding. It also doesn't use the hashing defined in RFC 2104, which is not a good idea (you should be using a proper KDF instead, and be doing the transformation offline). 3. Beaurocratic: - for HMAC based algorithms, the key is an arbitrary size, and is either zero-padded or hashed as described in Section 2 of RFC 2104; - for Blake2s, it is at most 32 bytes. This has the advantage of obeying the RFCs. It has the flaw of being inconsistent (long keys are only accepted for HMAC), and of encouraging a practice that is insecure (the hashing from RFC 2104). I have a weak preference for (2), but can live with (3). I realise it contradicts what I advocated earlier. -- Juliusz From nobody Tue Aug 13 14:59:55 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 262C81208E6 for ; Tue, 13 Aug 2019 14:59:54 -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 yarn020j8nDR for ; Tue, 13 Aug 2019 14:59:52 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324471208C2 for ; Tue, 13 Aug 2019 14:59:52 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7DLpNLM013094; Tue, 13 Aug 2019 17:59:51 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2uc45e240y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Aug 2019 17:59:49 -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 x7DLxBVx003437; Tue, 13 Aug 2019 17:59:11 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7DLx6Bt003344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Aug 2019 17:59:08 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id B2CDF4009E83; Tue, 13 Aug 2019 21:59:06 +0000 (GMT) Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (unknown [130.8.218.152]) by zlp30486.vci.att.com (Service) with ESMTPS id 96C9F4009E7A; Tue, 13 Aug 2019 21:59:06 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0439.000; Tue, 13 Aug 2019 17:59:06 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: "'babel@ietf.org'" Thread-Topic: [babel] I-D Action: draft-ietf-babel-information-model-08.txt Thread-Index: AQHVSy+136XJ0cDtj0yz+6M8HuFcTqbsr76wgAIhVYCACl/6QA== Date: Tue, 13 Aug 2019 21:59:05 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E267F05@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <156496962402.26572.16204290795859744323@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114E254159@GAALPA1MSGUSRBF.ITServices.sbc.com> <875znaawm8.wl-jch@irif.fr> In-Reply-To: <875znaawm8.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.230.113] 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-08-13_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908130203 Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-08.txt 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, 13 Aug 2019 21:59:54 -0000 > # Section 1. >=20 > "one of these security mechanisms" -> "one or both of these security > mechanisms" Done =20 > "(contingent on a management protocol with Babel support being > implemented)" > I don't know what this means If your Babel implementation has a data model and you want to claim complia= nce with the info model, then you must have these parameters. I didn't want this concept confused with the idea that if you do a Babel im= plementation you have to implement a data model that is compliant with the = info model. That would be wrong. And I didn't want it confused with the idea that the parameters must have v= alues (cannot be NULL). Mahesh and I have had a lot of discussion over what MTI in this draft means= , so I was trying to explain it better. But I agree I still didn't get it r= ight. I suggest changing this parenthetic to "(for an implementation attempting t= o comply with this information model)" > "a referential [...] structure." I don't know what this means For example, SQL uses a purely referential structure for its data (each tab= le is stand-alone, and they are linked through means of foreign keys), rath= er than hierarchical. It would be possible to create a SQL data model from = this (mostly) hierarchical info model. Should something change here? =20 > # Section 3.2 >=20 > "Default is ff02:0:0:0:0:0:1:6". Why not write this as ff02::1:6, as is = usual? I think I just copied it from somewhere (like the IANA IPv6 multicast addre= ss registry). But I'm fine with the shorter version. Done. > # Section 3.3 >=20 > The metric computation algorithm is described twice, here and globally in= the > babel-information-obj. Is the global value a default for newly created > interfaces, or does it provide a value in case the interface-obj doesn't = specify > it? Please clarify. The global parameter is a read-only list of algorithms supported by the imp= lementation. It's used to constrain the value in interfaces. The initial va= lue used for an interface will always be set by an implementation, using wh= atever logic is internal to the implementation. But whatever value the impl= ementation uses needs to be in the global list of supported algorithms. It'= s also allowed for the implementation to let a user change the value set by= the implementation -- in which case the user needs to know the allowed set= of values it can be changed to (and constrained to setting it to a support= ed algorithm). > The same goes for babel-hmac-algorithm. Similar answer. But since the parameter is moving from interfaces to mac-ke= ys (so it can be specific to a key), it won't be set by the implementation.= It's set by the user when adding the key. But it still needs to be constra= ined to an algorithm the implementation supports (as indicated by the list = in the global parameter). [Also: changing the babel-mac-algorithm, per decision to make hmac draft a = mac draft.] > # Section 3.4 >=20 > Aren't we missing an entry for the total number of packets sent? So in addition to totals of multicast hellos and updates separately, includ= e a total of all Babel packets sent on the interface? I could add that, if = people think it would be useful. I'm going to hold off on adding this to se= e if anyone else has an opinion. I think if this were done, it doesn't make= sense to require the more granular "sent" counts (if statistics are implem= ented). They would become optional. But I think seeing counts for hellos an= d updates separately is more useful for seeing how the implementation is be= having. And if you have those counts, the combined count provides no additi= onal value. So I'm sort of conflicted. > Should these entries be optional? Having the babel-if-stats-obj is optional (under interfaces). But if the im= plementation has the babel-if-stats-obj, then I think all 3 of these statis= tics should be required.=20 =20 > # Section 3.5 >=20 > I don't think that the nbr-stats entries is useful. A neighbour is a tra= nsient > data structure, and neighbours get destroyed when they become > unreachable. Thus, there is no good place to persist the statistics. > I suggest moving all statistics into the interface-obj, and not keeping p= er- > neighbour stats. I'm fine with that. That would suggest putting optional babel-sent-ucast-he= llo, babel-sent-ucast-update, and babel-sent-IHU under the interfaces stati= stics (where all 3 are totals sent to all neighbors on the interface). The = 3 received statistics parameters go away (babel-received-hello, babel-recei= ved-update, babel-received-IHU). Do others have opinions? If no-one says ot= herwise, I'll do this. =20 > babel-exp-{m,u}cast-hello-seqno: the use of 0 for undefined is not a good > idea, since 0 is a perfectly valid seqno. OK. Then this goes in the same bucket as the other read-only int parameters= that need to have a NULL distinct from zero. Is the following ok? Expected {m,u}cast Hello sequence number of next Hello to be received from this neighbor.=20 If {m,u}cast Hello packets are not expected, or processing of {m,u}cast packets is not enabled, this MUST be NULL. This is a 16-bit= unsigned integer; if the data model uses zero (0) to represent NULL values for unsigned integers, the data model may use a different data type that allows differentiation between zero (0) and NULL. > babel-ucast-hello-seqno: what's the value when the implementation is not > sending unicast hellos? Same sort of thing? The current sequence number in use for unicast Hellos sent to this neighbor. If unicast Hellos are not bein= g sent, this MUST be NULL. This is a 16-bit unsigned integer; if the data model uses zero (0) to represent NULL values for unsigned integers, the data model may use a different data type that allows differentiation between zero (0) and NULL. > babel-cost: this is written in a different style. I suggest something li= ke "the > link cost, as computed from...". OK =20 > # Section 3.6 >=20 > See above. I suggest moving this into the interface-stats object, and on= ly > keeping aggregate statistics. As above discussed above, then. =20 > # Section 3.7 >=20 > babel-route-router-id: suggst "the router-id of the router that originate= d this > route". OK =20 > # Section 3.9 >=20 > babel-key-use-{sign, verify}: good idea, I'll add this to the implementat= ion. Thank you. I took the idea from the babel-hmac spec. And Toke refined it. > babel-hmac-test: why non-empty? If there's no mac algorithm that will choke on zero-length input string, th= en I guess empty is ok. I'm thinking I won't have issues with NULL/zero/emp= ty ambiguity, since it's a binary string. So just change that sentence to "Input to this operation is a binary string= ." (instead of "Input to this operation MUST be a non-empty binary string."= )? Same for the babel-cert-test? Unless I hear otherwise, I'll do the same = change to both. Barbara From nobody Tue Aug 13 15:26: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 ED9091208E6 for ; Tue, 13 Aug 2019 15:26:51 -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 nVyZs5e0xgdn for ; Tue, 13 Aug 2019 15:26:50 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675AC1208C2 for ; Tue, 13 Aug 2019 15:26:50 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7DMFBEt006242; Tue, 13 Aug 2019 18:26:50 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2uc45e2nxc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Aug 2019 18:26:49 -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 x7DMQljD021913; Tue, 13 Aug 2019 18:26:48 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7DMQep2021826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Aug 2019 18:26:41 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 98292400AE37; Tue, 13 Aug 2019 22:26:40 +0000 (GMT) Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (unknown [130.8.218.152]) by zlp30488.vci.att.com (Service) with ESMTPS id 8279A400AE36; Tue, 13 Aug 2019 22:26:40 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0439.000; Tue, 13 Aug 2019 18:26:40 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: "'babel@ietf.org'" Thread-Topic: HMAC: removed constraint on the key stored in interface table Thread-Index: AQHVUe2J94IZUlXvWUGht5ECY/kmSKb5V8HwgABYPID//8teAIAAaDuA//++YOA= Date: Tue, 13 Aug 2019 22:26:39 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E267FBE@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8736i5ul8p.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E26794B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87v9v0ucba.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267D1B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87r25ou3ri.wl-jch@irif.fr> In-Reply-To: <87r25ou3ri.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.230.113] 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-08-13_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908130209 Archived-At: Subject: Re: [babel] HMAC: removed constraint on the key stored in interface table 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, 13 Aug 2019 22:26:52 -0000 > >> What I'm suggesting is that you add something to the following effect > >> to the description of babel-mac-key-value: In the case where > >> babel-mac-key-algorithm specifies an algorithm based on the HMAC > >> construction, then this value MUST be the exact size of the hash's > >> block size (i.e. it has already undergone any preprocessing, such as > >> the hashing or zero extension described in Section 2 of RFC 2104). >=20 > > Or maybe I just say: The key MUST be the maximum key length that can > > be provided such that the implementation will not zero-pad, truncate, > > or otherwise manipulate the key prior to use. For HMAC-SHA256, this is > > defined in RFC4868 as 64 bytes. For Blake2s, this is defined in > > RFC7693 as > > 32 bytes. ? >=20 > We have at least three reasonable options. >=20 > 1. Deterministic: >=20 > - for HMAC based algorithms, the key is exactly the block size (64 byte= s > for HMAC-SHA256); > - for Blake2s, it is exactly 32 bytes. >=20 > This is deterministic, but not very convenient for the user (the user nee= ds to > do zero-pad himself). The behaviour is suprising to the user, especially= in the > case of Blake2s. The info model doesn't describe the user interface. We're describing the bi= ts that get delivered to the babel-mac implementation. What do you want to = see as an input to a babel-mac implementation? >=20 > 2. Consistent: >=20 > - for HMAC based algorithms, the key is at most the block size (64 byte= s > for HMAC-SHA256), and is zero-padded as described in Sectin 2 of RFC > 2104; > - for Blake2s, it is at most 32 bytes. >=20 > This makes behaviour coherent between HMAC and Blake2s, in both cases > any size of key is allowed up some maximum. This is convenient for the u= ser > (who can use shorter keys), and reasonably deterministic -- the only > operation performed on the key is zero-padding. It also doesn't use the > hashing defined in RFC 2104, which is not a good idea (you should be usin= g a > proper KDF instead, and be doing the transformation offline). This would work if the babel-mac implementation were willing to do the zero= -padding. But not if you want zero-padding done before delivery to babel-ma= c. =20 > 3. Beaurocratic: >=20 > - for HMAC based algorithms, the key is an arbitrary size, and is eithe= r > zero-padded or hashed as described in Section 2 of RFC 2104; > - for Blake2s, it is at most 32 bytes. >=20 > This has the advantage of obeying the RFCs. It has the flaw of being > inconsistent (long keys are only accepted for HMAC), and of encouraging a > practice that is insecure (the hashing from RFC 2104). This is just confusing, because it's not describing what goes across the wi= re. It seems the intent of this is that for HMAC-SHA256, the key that gets = delivered to babel-mac is max of 64 bytes. So it devolves to case 2. And if= cases 2 and 3 are really expecting the zero-padding to be included in what= gets delivered, then both devolve completely back into case 1. If Case 1 is what you want delivered to babel-mac, but you want some UI nic= eness expressed, I can add a statement like "If keys are generated from use= r input, the user interface or management system is expected to zero-pad st= rings that are less than the required length, and prohibit strings longer t= han the required length. This ensures the delivered string is exactly the r= equired number of bytes." This would effectively provide Case 2, but with t= he zero-padding in what gets delivered to babel-mac. Barbara =20 > I have a weak preference for (2), but can live with (3). I realise it co= ntradicts > what I advocated earlier. >=20 > -- Juliusz From nobody Tue Aug 13 15: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 56A141208F5 for ; Tue, 13 Aug 2019 15:31:35 -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 pveYa391z3jt for ; Tue, 13 Aug 2019 15:31:33 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA6741208C2 for ; Tue, 13 Aug 2019 15:31:32 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id f9so4481911ljc.13 for ; Tue, 13 Aug 2019 15:31:32 -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=5MykBaelGqLgz36mqECKQdYbfbnrHCBRnyW7mi3scv4=; b=RFmpoJA150pEsSeENGvuAnEBlxUmtjOM8s/5IoePpIkDKnO36M1+OyEgMxP9ewp2CW 0jh3k2bDto/p5okyr63jWnwhMdzj99dAcDyitBVn4Z0DhTRcdssKZ34oZpU+Vcw1xd4P oqcA4/eB5mNF6w5wQjXX2wmVg4fXTEOVH2NoxEKNnNcWKFp6dlLIi0WfzdARiMdLBZNF K4sbIyfp7o34J5IDJrTbW9XzyW8kx9qzpOva1peQfl8jnZBTSznERY6RIROmQOVaxiRk 1TBhFQc3KHTKMv1PUXFQOzEiGXfyezcxmO1bglRSCIUDquVGOWhkFs8m2YyubgpRazd1 x9+g== 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=5MykBaelGqLgz36mqECKQdYbfbnrHCBRnyW7mi3scv4=; b=VmRyA/Nkc55BhJOyakHFzItYRcKPAxW7l6pFu30KGj6MWK9Ii3jbZsB7oUwL6hKd4h 5lf5QJpDmJef8YAFgHq+3EQ3hsxaLAd7Kw3BNTV8QWx7vzEloziwX7bGXUPIW+Vv8QQP SHUe5pJb7DDR867Z4JP39VP8Blgpw57lDG4y1J3pGAhUncoxtKzCAz343wQ6WwD3xO9F h6gn1Vua0hr80N31N1PbwfGsQR136+Cy2RNptwlPvgK6doyYSqgH4Zc0ijZU/Fc+j9mg Z1vfBsqySuMPKKgb7NGZTYUKomLXc8T/kaxlTIObQwFm4MTJCkZro8qGsQFIcDBt0f1D vyjw== X-Gm-Message-State: APjAAAVPWHQbUdj1PdTUXcIqKaQjt5kJn1sxsQGh/3ZXE+p/Eq7G/nof IXxtuUUWEQ2tMSqVOPd08rAs1Cs4oxG4DcHRuyA= X-Google-Smtp-Source: APXvYqxWz2h/7DoOCqqwWVVBwlSHHufvLDHtWcRgQ9PjDpxj2PYdC3+suYOhwrnVbEQJczltHSDowhvn3I5JNQYbwrI= X-Received: by 2002:a2e:94cb:: with SMTP id r11mr242174ljh.212.1565735490990; Tue, 13 Aug 2019 15:31:30 -0700 (PDT) MIME-Version: 1.0 References: <8736i5ul8p.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E26794B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87v9v0ucba.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267D1B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87r25ou3ri.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267FBE@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E267FBE@GAALPA1MSGUSRBF.ITServices.sbc.com> From: David Schinazi Date: Tue, 13 Aug 2019 15:31:20 -0700 Message-ID: To: "STARK, BARBARA H" Cc: Juliusz Chroboczek , "babel@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c0b4f9059007338a" Archived-At: Subject: Re: [babel] HMAC: removed constraint on the key stored in interface table 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, 13 Aug 2019 22:31:35 -0000 --000000000000c0b4f9059007338a Content-Type: text/plain; charset="UTF-8" I think we may be overly constraining ourselves here. How about: - Keys used for Babel-MAC MUST be of a length suitable for that MAC function. - Implementations MUST reject keys that are not suitable for the MAC function; in other words, implementations MUST NOT preprocess keys of unsuitable lengths to produce a key of suitable length. - Babel management interfaces MUST NOT allow configuring keys of non suitable lengths. - Keys for HMAC-SHA256 SHOULD be 64 bytes long, keys for Blake2s SHOULD be 32 bytes long. David On Tue, Aug 13, 2019 at 3:26 PM STARK, BARBARA H wrote: > > >> What I'm suggesting is that you add something to the following effect > > >> to the description of babel-mac-key-value: In the case where > > >> babel-mac-key-algorithm specifies an algorithm based on the HMAC > > >> construction, then this value MUST be the exact size of the hash's > > >> block size (i.e. it has already undergone any preprocessing, such as > > >> the hashing or zero extension described in Section 2 of RFC 2104). > > > > > Or maybe I just say: The key MUST be the maximum key length that can > > > be provided such that the implementation will not zero-pad, truncate, > > > or otherwise manipulate the key prior to use. For HMAC-SHA256, this is > > > defined in RFC4868 as 64 bytes. For Blake2s, this is defined in > > > RFC7693 as > > > 32 bytes. ? > > > > We have at least three reasonable options. > > > > 1. Deterministic: > > > > - for HMAC based algorithms, the key is exactly the block size (64 > bytes > > for HMAC-SHA256); > > - for Blake2s, it is exactly 32 bytes. > > > > This is deterministic, but not very convenient for the user (the user > needs to > > do zero-pad himself). The behaviour is suprising to the user, > especially in the > > case of Blake2s. > > The info model doesn't describe the user interface. We're describing the > bits that get delivered to the babel-mac implementation. What do you want > to see as an input to a babel-mac implementation? > > > > > 2. Consistent: > > > > - for HMAC based algorithms, the key is at most the block size (64 > bytes > > for HMAC-SHA256), and is zero-padded as described in Sectin 2 of RFC > > 2104; > > - for Blake2s, it is at most 32 bytes. > > > > This makes behaviour coherent between HMAC and Blake2s, in both cases > > any size of key is allowed up some maximum. This is convenient for the > user > > (who can use shorter keys), and reasonably deterministic -- the only > > operation performed on the key is zero-padding. It also doesn't use the > > hashing defined in RFC 2104, which is not a good idea (you should be > using a > > proper KDF instead, and be doing the transformation offline). > > This would work if the babel-mac implementation were willing to do the > zero-padding. But not if you want zero-padding done before delivery to > babel-mac. > > > 3. Beaurocratic: > > > > - for HMAC based algorithms, the key is an arbitrary size, and is > either > > zero-padded or hashed as described in Section 2 of RFC 2104; > > - for Blake2s, it is at most 32 bytes. > > > > This has the advantage of obeying the RFCs. It has the flaw of being > > inconsistent (long keys are only accepted for HMAC), and of encouraging a > > practice that is insecure (the hashing from RFC 2104). > > This is just confusing, because it's not describing what goes across the > wire. It seems the intent of this is that for HMAC-SHA256, the key that > gets delivered to babel-mac is max of 64 bytes. So it devolves to case 2. > And if cases 2 and 3 are really expecting the zero-padding to be included > in what gets delivered, then both devolve completely back into case 1. > > If Case 1 is what you want delivered to babel-mac, but you want some UI > niceness expressed, I can add a statement like "If keys are generated from > user input, the user interface or management system is expected to zero-pad > strings that are less than the required length, and prohibit strings longer > than the required length. This ensures the delivered string is exactly the > required number of bytes." This would effectively provide Case 2, but with > the zero-padding in what gets delivered to babel-mac. > Barbara > > > I have a weak preference for (2), but can live with (3). I realise it > contradicts > > what I advocated earlier. > > > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --000000000000c0b4f9059007338a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think we may be overly constraining ourselves here. How = about:

- Keys used for Babel-MAC MUST be of a length sui= table for that MAC function.
- Implementations MUST reject keys t= hat are not suitable for the MAC function; in other words, implementations = MUST NOT preprocess keys of unsuitable lengths to produce a key of suitable= length.
- Babel management interfaces MUST NOT allow configuring= keys of non suitable lengths.
- Keys for=C2=A0HMAC-SHA256 SHOULD be 64 bytes long, key= s for=C2=A0Blake2s SHOULD be 32 bytes long.

David

On Tue, Aug 13, 2019 at 3:26 PM STARK, BARBARA H <bs7652@att.com> wrote:
> >> What I'm suggesting= is that you add something to the following effect
> >> to the description of babel-mac-key-value: In the case where<= br> > >> babel-mac-key-algorithm specifies an algorithm based on the H= MAC
> >> construction, then this value MUST be the exact size of the h= ash's
> >> block size (i.e. it has already undergone any preprocessing, = such as
> >> the hashing or zero extension described in Section 2 of RFC 2= 104).
>
> > Or maybe I just say: The key MUST be the maximum key length that = can
> > be provided such that the implementation will not zero-pad, trunc= ate,
> > or otherwise manipulate the key prior to use. For HMAC-SHA256, th= is is
> > defined in RFC4868 as 64 bytes. For Blake2s, this is defined in > > RFC7693 as
> > 32 bytes.=C2=A0 ?
>
> We have at least three reasonable options.
>
> 1. Deterministic:
>
>=C2=A0 =C2=A0- for HMAC based algorithms, the key is exactly the block = size (64 bytes
>=C2=A0 =C2=A0 =C2=A0for HMAC-SHA256);
>=C2=A0 =C2=A0- for Blake2s, it is exactly 32 bytes.
>
> This is deterministic, but not very convenient for the user (the user = needs to
> do zero-pad himself).=C2=A0 The behaviour is suprising to the user, es= pecially in the
> case of Blake2s.

The info model doesn't describe the user interface. We're describin= g the bits that get delivered to the babel-mac implementation. What do you = want to see as an input to a babel-mac implementation?

>
> 2. Consistent:
>
>=C2=A0 =C2=A0- for HMAC based algorithms, the key is at most the block = size (64 bytes
>=C2=A0 =C2=A0 =C2=A0for HMAC-SHA256), and is zero-padded as described i= n Sectin 2 of RFC
> 2104;
>=C2=A0 =C2=A0- for Blake2s, it is at most 32 bytes.
>
> This makes behaviour coherent between HMAC and Blake2s, in both cases<= br> > any size of key is allowed up some maximum.=C2=A0 This is convenient f= or the user
> (who can use shorter keys), and reasonably deterministic -- the only > operation performed on the key is zero-padding.=C2=A0 It also doesn= 9;t use the
> hashing defined in RFC 2104, which is not a good idea (you should be u= sing a
> proper KDF instead, and be doing the transformation offline).

This would work if the babel-mac implementation were willing to do the zero= -padding. But not if you want zero-padding done before delivery to babel-ma= c.

> 3. Beaurocratic:
>
>=C2=A0 =C2=A0- for HMAC based algorithms, the key is an arbitrary size,= and is either
>=C2=A0 =C2=A0 =C2=A0zero-padded or hashed as described in Section 2 of = RFC 2104;
>=C2=A0 =C2=A0- for Blake2s, it is at most 32 bytes.
>
> This has the advantage of obeying the RFCs.=C2=A0 It has the flaw of b= eing
> inconsistent (long keys are only accepted for HMAC), and of encouragin= g a
> practice that is insecure (the hashing from RFC 2104).

This is just confusing, because it's not describing what goes across th= e wire. It seems the intent of this is that for HMAC-SHA256, the key that g= ets delivered to babel-mac is max of 64 bytes. So it devolves to case 2. An= d if cases 2 and 3 are really expecting the zero-padding to be included in = what gets delivered, then both devolve completely back into case 1.

If Case 1 is what you want delivered to babel-mac, but you want some UI nic= eness expressed, I can add a statement like "If keys are generated fro= m user input, the user interface or management system is expected to zero-p= ad strings that are less than the required length, and prohibit strings lon= ger than the required length. This ensures the delivered string is exactly = the required number of bytes." This would effectively provide Case 2, = but with the zero-padding in what gets delivered to babel-mac.
Barbara

> I have a weak preference for (2), but can live with (3).=C2=A0 I reali= se it contradicts
> what I advocated earlier.
>
> -- Juliusz

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--000000000000c0b4f9059007338a-- From nobody Tue Aug 13 15:42: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 7D3011208C2; Tue, 13 Aug 2019 15:42:04 -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.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156573612442.24045.10410673247467154613@ietfa.amsl.com> Date: Tue, 13 Aug 2019 15:42:04 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-dtls-09.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: Tue, 13 Aug 2019 22:42: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 : Babel Routing Protocol over Datagram Transport Layer Security Authors : Antonin Decimo David Schinazi Juliusz Chroboczek Filename : draft-ietf-babel-dtls-09.txt Pages : 10 Date : 2019-08-13 Abstract: The Babel Routing Protocol does not contain any means to authenticate neighbours or provide integrity or confidentiality for 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-babel-dtls-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-dtls-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 13 15:50:21 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 0A0D71208F5; Tue, 13 Aug 2019 15:50:19 -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 yx-jRyEPM2Yp; Tue, 13 Aug 2019 15:50:17 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 ED1011208C2; Tue, 13 Aug 2019 15:50:16 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id a30so14854721lfk.12; Tue, 13 Aug 2019 15:50:16 -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=wA6nKflcrB0fVPRmBf+6YwtUGz6N7qmUjpk3qDL0lbs=; b=cGu2s9YH+OYa1P9/CDkAseiNGdpkLa8SDvcTfVuV1fBC/tfjS1k/qBbNw8OTyRIDLs hukUmk4GZGnuRmPYyWuOgYulxubbqd0GBIB9Xlw2z1NT+9749bN1aZ7qyb/CS1Nv2GnF 2ExAM0J0nqg+iyX/3DmX9yvfgcUV+WKUlZ6ahVE6Ra2R8EnIPPFIc5FvH6m2N1tFTNHh QBScwcxnI2mdzyww4/4gX/epP9Nl54sCoKIbhQbpufTw+PXBbUQH+JQn3uZ0r9BEk+5u mFwM19K/sD4vZ55R1QT74O48KPuL0mpfy6wiGxjD0wlSZjDTNNn88YHdN8/mhW9xTg5i ldTA== 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=wA6nKflcrB0fVPRmBf+6YwtUGz6N7qmUjpk3qDL0lbs=; b=gMVa0im8mIyvM23TPnrcls+rO0TkUVAoxz8/whmhyMmRaPct9srbDErjlFN8HdLEe6 1fhh4tTw5ZEo2FyKKQ1+JcM5CqMmB56wanp50+8dO94i26PEaChyEWTXdXxA2VhaUcqz 5biJUi9bv2W5NP+nkh3Bs50jiJVfuKjcO2pTI9GvWuNeI3rT9iANwNZZ8gGONp5+LfI3 k/fRecLMTpfE8TGEVIlMdkY+k35vw9Y1VcGegdYHlD+Vq/sI5rH8GIIT+Qowox3fGB7n AUZxHkd89HHatcZQ8Lm5jd6yntM1W5w2uyoWRDxot5ZYoaWx9CDYxUsBVA6f12v6rFE0 Cu6g== X-Gm-Message-State: APjAAAWmhocKTjlrjnFjmCDrRpXlLgyJx7ESIeduF4CaI3Fgk1VIchnW FAMXAn5XvnU+yKRN+IsesgRnb8NFmwRNySCShMg= X-Google-Smtp-Source: APXvYqx/YABavXL0QgIwP4RD+YLSs5uRAIIOtig3QVVaOF/VV0BV3Cgh0DISxGJP78MjIrjXZLMBvTWTsPiOeMrQCX8= X-Received: by 2002:a05:6512:403:: with SMTP id u3mr24215546lfk.10.1565736615045; Tue, 13 Aug 2019 15:50:15 -0700 (PDT) MIME-Version: 1.0 References: <156520596444.8244.649940515091541992.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B34054D4@marchand> <359EC4B99E040048A7131E0F4E113AFC01B34056BD@marchand> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B34056BD@marchand> From: David Schinazi Date: Tue, 13 Aug 2019 15:50:04 -0700 Message-ID: To: Roman Danyliw Cc: The IESG , "draft-ietf-babel-dtls@ietf.org" , Donald Eastlake , babel-chairs , Babel at IETF Content-Type: multipart/alternative; boundary="000000000000c06cfa0590077669" Archived-At: Subject: Re: [babel] Roman Danyliw's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT) 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, 13 Aug 2019 22:50:19 -0000 --000000000000c06cfa0590077669 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Roman! We've now uploaded -09 with the new text: https://tools.ietf.org/html/draft-ietf-babel-dtls-09 David On Tue, Aug 13, 2019 at 7:29 AM Roman Danyliw wrote: > Hi David! > > > > *From:* David Schinazi [mailto:dschinazi.ietf@gmail.com] > *Sent:* Monday, August 12, 2019 11:01 PM > *To:* Roman Danyliw > *Cc:* The IESG ; draft-ietf-babel-dtls@ietf.org; Donald > Eastlake ; babel-chairs ; Babel > at IETF > *Subject:* Re: Roman Danyliw's Discuss on draft-ietf-babel-dtls-07: (with > DISCUSS and COMMENT) > > > > Thanks for your reply! > > > > On Mon, Aug 12, 2019 at 4:35 PM Roman Danyliw wrote: > > Ben=E2=80=99s recommendation to explicitly note that this authentication = needs to > be solved in external profiles would address my concern too: > > > > https://mailarchive.ietf.org/arch/msg/babel/5AnLlaHPTEsBJpV7WVrZLpw07ls > > > > (I don=E2=80=99t know if you were waiting on Ben for anything else, but = =E2=80=A6) I > didn=E2=80=99t see this discussion about profiles in the new -08 text. > > > > The new profile text was added after -08 was submitted, it's in this > commit: > > > https://github.com/jech/babel-drafts/commit/458a9ae6b9b136122d8668b26ba40= 3f4f3a57167 > > > > Does it resolve your concern? > > If yes we'll submit a -09 with this new text. > > > > [Roman] Understood. Yes, that text resolves my concern. Thank you. > > > > Roman > --000000000000c06cfa0590077669 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Roman! We've now uploaded -09 with the new text= :

David

On Tue, Aug 13, 2019 at 7:29 AM Roman Danyliw <rdd@cert.org> wrote:

Hi David!

=C2=A0

From: David Schinazi [mailto:dschinazi.ietf@gmail.com]
Sent: Monday, August 12, 2019 11:01 PM
To: Roman Danyliw <rdd@cert.org>
Cc: The IESG <= iesg@ietf.org>; draft-ietf-babel-dtls@ietf.org; Donald Eastlake <d3e3e3@gmail.com>= ; babel-chairs <babel-chairs@ietf.org>; Babel at IETF <babel@ietf.org>
Subject: Re: Roman Danyliw's Discuss on draft-ietf-babel-dtls-07= : (with DISCUSS and COMMENT)

=C2=A0

Thanks for your reply!

=C2=A0

On Mon, Aug 12, 2019 at 4:35 PM Roman Danyliw <rdd@cert.org> wrote:=

Ben=E2=80=99s recommendation to explicitly n= ote that this authentication needs to be solved in external profiles would address my concern too:

=C2=A0

https://mailarchi= ve.ietf.org/arch/msg/babel/5AnLlaHPTEsBJpV7WVrZLpw07ls=

=C2=A0

(I don=E2=80=99t know if you were waiting on= Ben for anything else, but =E2=80=A6) I didn=E2=80=99t see this discussion= about profiles in the new -08 text.

=C2=A0

The new profile text was added after -08 was submitt= ed, it's in this commit:

=C2=A0

Does it resolve your concern?

If yes we'll submit a -09 with this new text.=

=C2=A0

[Roman]=C2=A0 Understood.=C2=A0 Yes, that te= xt resolves my concern.=C2=A0 Thank you.

=C2=A0

Roman

--000000000000c06cfa0590077669-- From nobody Tue Aug 13 15:51:29 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 C45EE1208FD for ; Tue, 13 Aug 2019 15:51:28 -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 Eeg8icwJRg9z for ; Tue, 13 Aug 2019 15:51:27 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E515A1208C2 for ; Tue, 13 Aug 2019 15:51:26 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7DMjwpT001799; Tue, 13 Aug 2019 18:51:25 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2uc65e88xb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Aug 2019 18:51:24 -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 x7DMpNPt003732; Tue, 13 Aug 2019 18:51:23 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7DMpJtv003655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Aug 2019 18:51:19 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 376E24014661; Tue, 13 Aug 2019 22:51:19 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30483.vci.att.com (Service) with ESMTPS id 1F2DB40135E9; Tue, 13 Aug 2019 22:51:19 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0439.000; Tue, 13 Aug 2019 18:51:18 -0400 From: "STARK, BARBARA H" To: "'Mahesh Jethanandani'" , "'Juliusz Chroboczek'" CC: =?utf-8?B?J1Rva2UgSMO4aWxhbmQtSsO4cmdlbnNlbic=?= , "'Babel at IETF'" Thread-Topic: [babel] Example configuration Thread-Index: AQHVQysP27rmDxHNmE+dOkameIFP66bcIv6AgBKtMoCAAAmwgIAACWOAgAAV/4CAAC8QgIAAC2UAgABwxXCAAK2IgP//vsCAgABe24D//71TQIABdAyAgAAImACAAGCgAIAAGqGAgAAFboCAB5bYgIAABZVQ Date: Tue, 13 Aug 2019 22:51:18 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E2680FE@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr> <87pnlhaixh.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E257961@GAALPA1MSGUSRBF.ITServices.sbc.com> <0B28A1FA-32B4-41E6-B646-C6A3907E9CCC@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114E258CF7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E25905B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87lfw3u52i.fsf@toke.dk> <110D87BA-BBA1-417B-9BC3-77BAD4B201D1@gmail.com> <87ftmbs92f.fsf@toke.dk> <26F1A0CD-1FD2-456E-B295-8A60D93CF8E0@gmail.com> <87sgqbmhhe.wl-jch@irif.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.230.113] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-13_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908130213 Archived-At: Subject: Re: [babel] Example configuration 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, 13 Aug 2019 22:51:29 -0000 SSd2ZSBiZWVuIHJ1bWluYXRpbmcgbG9uZyBhbmQgaGFyZCBvbiB0aGlzIGlkZWEgb2YgYWJzdHJh Y3RpbmcgdGhlIGxpbmsgcHJvcGVydGllcy4NCkknbSB0aGlua2luZyB0aGlzIGFic3RyYWN0aW9u IHJlYWxseSBpcyB0b28gY29tcGxleCwgYW5kIEknZCBwcmVmZXIgdG8ganVzdCBzdGljayB3aXRo IHRoZSBwcm9wZXJ0aWVzIHVuZGVyIGludGVyZmFjZS4NCkJ1dCwgSSB0aGluayBpdCB3b3VsZCBi ZSByZWFzb25hYmxlIHRvIGFkZCBsYW5ndWFnZSB0aGF0IGRlc2NyaWJlcyB3aGF0IGxpbmsgY2hh cmFjdGVyaXN0aWNzIG1ha2UgYSBwYXJ0aWN1bGFyIGNob2ljZSBwcmVmZXJyZWQgb3ZlciBvdGhl ciBjaG9pY2VzLg0KSWYgYSB1c2VyIHJlYWxseSB3YW50cyB0byBjaGFuZ2Ugb25lIG9mIHRoZXNl IChhbmQgQmFiZWwgaXMgZGVzaWduZWQgbm90IHRvIHJlcXVpcmUgbWFudWFsIGNoYW5nZXMgdG8g bGluayBwcm9wZXJ0aWVzIGluIG1vc3QgY2FzZXMpLCB0aGVuIHRoZXkganVzdCBuZWVkIHRvIGtu b3cgd2hhdCB0aGV5J3JlIGRvaW5nLiANCkNvbXBsZXhpdGllcyBjcmVlcCBpbiB3cnQgdXNlciBs YW5ndWFnZSAoc28gdXNlcnMgZG8gbmVlZCB0byBjdXN0b21pemUgdGhlIG5hbWUsIHdoaWNoIG1l YW5zIGl0IGNhbid0IGJlIGltbXV0YWJsZSksIGdyb3dpbmcgcGVybXV0YXRpb25zIGFzIG1vcmUg cHJvcGVydGllcyBhcmUgZGVmaW5lZCwgZXRjLg0KDQpMYW5ndWFnZSBJIHN1Z2dlc3Q6DQoNCiAg IGJhYmVsLW1ldHJpYy1jb21wLWFsZ29yaXRobXM6ICBMaXN0IG9mIHN1cHBvcnRlZCBjb3N0IGNv bXB1dGF0aW9uDQogICAgICBhbGdvcml0aG1zLiAgUG9zc2libGUgdmFsdWVzIGluY2x1ZGUgIjIt b3V0LW9mLTMiLCBhbmQgIkVUWCIuDQogICAgICAiMi1vdXQtb2YtMyIgKGEgc3BlY2lmaWMgY2Fz ZSBvZiBLLW91dC1vZi1qICkgbGluayBzZW5zaW5nIGlzIHN1aXRhYmxlIGZvciB3aXJlZCBsaW5r cyB0aGF0IGFyZSBlaXRoZXINCiAgICAgICB1cCwgaW4gd2hpY2ggY2FzZSB0aGV5IG9ubHkgb2Nj YXNpb25hbGx5IGRyb3AgYSBwYWNrZXQsIG9yIGRvd24sIGluDQogICAgICAgd2hpY2ggY2FzZSB0 aGV5IGRyb3AgYWxsIHBhY2tldHMuICJFVFgiIGlzIGEgbGluay1xdWFsaXR5IGVzdGltYXRpb24g YWxnb3JpdGhtIHRoYXQgaXMNCiAgICAgICBkZXNpZ25lZCB0byB3b3JrIHdlbGwgd2l0aCB0aGUg SUVFRSA4MDIuMTEgTUFDLg0KDQogICBiYWJlbC1pbnRlcmZhY2Utc3BsaXQtaG9yaXpvbjogIElu ZGljYXRlcyB3aGV0aGVyIG9yIG5vdCB0aGUgc3BsaXQNCiAgICAgIGhvcml6b24gb3B0aW1pemF0 aW9uIGlzIHVzZWQgd2hlbiBjYWxjdWxhdGluZyBtZXRyaWNzIG9uIHRoaXMNCiAgICAgIGludGVy ZmFjZS4gIEEgdmFsdWUgb2YgdHJ1ZSBpbmRpY2F0ZXMgc3BsaXQgaG9yaXpvbiBvcHRpbWl6YXRp b24NCiAgICAgIGlzIHVzZWQuIFNwbGl0IGhvcml6b24gb3B0aW1pemF0aW9uIGlzIHVzZWZ1bCB3 aGVuIHJ1bm5pbmcgb3ZlciBhDQogICAgICB0cmFuc2l0aXZlLCBzeW1tZXRyaWMgbGluayB0ZWNo bm9sb2d5LCBlLmcuLCBhDQogICAgICBwb2ludC10by1wb2ludCBsaW5rIG9yIGEgd2lyZWQgTEFO IHRlY2hub2xvZ3kgc3VjaCBhcyBFdGhlcm5ldC4gDQogICAgICBJdCBpcyBub3QgYXBwcm9wcmlh dGUgZm9yIGxpbmtzIG5vdCBrbm93biB0byBiZSBzeW1tZXRyaWMgYW5kIHRyYW5zaXRpdmU7IGlu IHBhcnRpY3VsYXIsDQogICAgICBzcGxpdCBob3Jpem9uIGlzIG5vdCBhcHByb3ByaWF0ZSBmb3Ig ZGVjZW50cmFsaXplZCB3aXJlbGVzcyBsaW5rDQogICAgICB0ZWNobm9sb2dpZXMgKGUuZy4sIElF RUUgODAyLjExIGluIGFkIGhvYyBtb2RlKSB3aGVuIHJvdXRpbmcgdXBkYXRlcw0KICAgICAgYXJl IHNlbnQgb3ZlciBtdWx0aWNhc3QuDQoNCkJhcmJhcmENCg0KPiA+PiBJbiB0aGUgc2Vjb25kIGV4 YW1wbGUsIHRoZSBvcGVyYXRvciB3aWxsIGRlZmluZSBhDQo+ID4+IGJhYmVsLWxpbmstcHJvcGVy dGllcy1vYmosIGNhbGwgaXQg4oCccmFkaW/igJ0gb3Ig4oCcd2lyZWxlc3PigJ0gb3IgYW55dGhp bmcNCj4gPj4gdGhleSB3YW50LCBhbmQgd2l0aGluIHRoYXQgb2JqZWN0IHNldCB0aGUNCj4gPj4g YmFiZWwtaW50ZXJmYWNlLW1ldHJpYy1hbGdvcml0aG0gKGJlY2F1c2UgaXQgYSBtYW5kYXRvcnkg cGFyYW1ldGVyKSwNCj4gPj4gYW5kIHNldCB0aGUgYmFiZWwtc3BsaXQtaG9yaXpvbiB0byBmYWxz ZS4gVGhleSB3aWxsIHRoZW4gYXNzb2NpYXRlIOKAnHJhZGlv4oCdDQo+IG9iamVjdCB3aXRoIGV0 aDEgaW50ZXJmYWNlLg0KPiA+DQo+ID4gQ2FuIHRoZSBVSSBzaW11bGF0ZSB0aGUgYmFiZWwtbGlu ay1wcm9wZXJ0aWVzLW9iaiB3aXRob3V0IGl0IGJlaW5nDQo+ID4gcGFydCBvZiB0aGUgbW9kZWw/ DQo+IA0KPiBCZWZvcmUgSSBhbnN3ZXIgdGhhdCBxdWVzdGlvbiwgbGV0IG1lIGtub3cgaWYgdGhl IGZvbGxvd2luZyBhbnN3ZXJzIGhlbHAuIElmDQo+IHRoZXkgZG8gbm90LCBJIGFtIGFmcmFpZCB0 aGF0IHdlIHdpbGwgbmVlZCBhIHdoaXRlYm9hcmQgZGlzY3Vzc2lvbiBvbg0KPiBtYW5hZ2VtZW50 IGludGVyZmFjZSBhbmQgdGhlIHJvbGUgWUFORyBwbGF5cyBpbiBpdC4NCj4gDQo+ID4NCj4gPiBJ LmUuIHRoZSBvcGVyYXRvciBkZWZpbmVzIGEgc2V0IG9mIHZhbHVlcyBjYWxsZWQgInJhZGlvIiwg dGhpcyBzZXQNCj4gPiBvbmx5IGV4aXN0cyB3aXRoaW4gdGhlIFVJLg0KPiANCj4g4oCccmFkaW/i gJ0gaW4gbXkgZXhhbXBsZSBpcyB3aGF0IHlvdSBjYWxsIFVJcywganVzdCBsaWtlIOKAnHdpcmVs ZXNz4oCdLiBUaGVyZWZvcmUNCj4gd2hlbiB5b3Ugc2F5IOKAnHNldCBvZiB2YWx1ZXMgY2FsbGVk IOKAnHJhZGlv4oCd4oCdLCBJIHJlYWQgaXQgYXMgc2V0IG9mIGxpbmsgcHJvcGVydGllcw0KPiB0 aGF0IHlvdSB3YW50IHRvIGNsdWIgdG9nZXRoZXIgYW5kIGFzc29jaWF0ZSB3aXRoIGEgbmFtZSwg YW5kIHRoYXQgbmFtZSBpcw0KPiDigJxyYWRpbyIuIElzIHRoYXQgY29ycmVjdD8NCj4gDQo+ID4g VGhlIG9wZXJhdG9yIHRoZW4gYXBwbGllcyAicmFkaW8iIHRvIGEgbnVtYmVyIG9mIGludGVyZmFj ZXMsIGFuZCB0aGUNCj4gPiBmcm9udGVuZCBhcHBsaWVzIHRoZSBpbmRpdmlkdWFsIHZhbHVlcyBj b250YWluZWQgaW4gdGhlICJyYWRpbyINCj4gPiBkaWN0aW9uYXJ5IHRvIGVhY2ggb2YgdGhvc2Ug aW50ZXJmYWNlcy4NCj4gDQo+IA0KPiBCdXQgdGhhdCBpcyBleGFjdGx5IHdoYXQgdGhlIG5ldyBi YWJlbC1saW5rLXByb3BlcnRpZXMtb2JqIGFsbG93cyB5b3UgdG8gZG8uIEl0DQo+IGFsbG93cyB5 b3UgdG8gZGVmaW5lIGFueSBudW1iZXIgb2YgYmFiZWwtbGluay1wcm9wZXJ0aWVzLW9iaiwgYW5k IG5hbWUNCj4gdGhlbSB3aGF0ZXZlciB5b3Ugd2FudCwgZS5nLiDigJxyYWRpb+KAnSwg4oCcd2ly ZWTigJ0sIOKAnHdpcmVsZXNz4oCdIGV0Yywgb3Igd2hhdCB5b3UNCj4gY2FsbCDigJxVSSIuIElu IGVhY2ggb2YgdGhlIGJhYmVsLWxpbmstcHJvcGVydGllcy1vYmogeW91IHNldCB0aGUgcHJvcGVy dGllcyB5b3UNCj4gd2FudCwgZS5nLiBzcGxpdCBob3Jpem9uLCBydHQsIGV0Yy4gIEFzIGEgZmlu YWwgc3RlcCB5b3UgYXNzb2NpYXRlIGFueSBvZiB0aGUNCj4gZGVmaW5lZCBVSSB3aXRoIGFueSBu dW1iZXIgb2YgaW50ZXJmYWNlcy4gV2hlbiB5b3UgYXNzb2NpYXRlIHRoZSBnaXZlbiBVSQ0KPiB3 aXRoIGFuIGludGVyZmFjZSwgYWxsIHRoZSBsaW5rIHByb3BlcnRpZXMgZGVmaW5lZCBhcyBwYXJ0 IG9mIHRoYXQgVUkgYXJlIHRoZW4NCj4gYXBwbGllZCBvbiB0aGUgaW50ZXJmYWNlLg0KPiANCj4g RGlkIHRoYXQgYW5zd2VyIHlvdXIgcXVlc3Rpb24sIG9yIGNvbmZ1c2UgeW91IGV2ZW4gbW9yZT8N Cj4gDQo+ID4NCj4gPiBPciBkb2VzIFlBTkcgcmVxdWlyZSB0aGF0IHRoZSBVSSByZWZsZWN0IHRo ZSBtb2RlbD8NCj4gDQo+ID4NCj4gPiAtLSBKdWxpdXN6DQo+IA0KPiBNYWhlc2ggSmV0aGFuYW5k YW5pDQo+IG1qZXRoYW5hbmRhbmlAZ21haWwuY29tDQo+IA0KPiANCg0K From nobody Tue Aug 13 16:01:59 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 41E9A12092A for ; Tue, 13 Aug 2019 16:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 4ZfkuVyqBv5h for ; Tue, 13 Aug 2019 16:01:50 -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 A612F1208FD for ; Tue, 13 Aug 2019 16:01:50 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7DMwppU021600; Tue, 13 Aug 2019 19:01:48 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 2uc58j1q74-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Aug 2019 19:01:47 -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 x7DN1hnm024757; Tue, 13 Aug 2019 19:01:46 -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 x7DN1a3n024376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Aug 2019 19:01:36 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id A618F4009E73; Tue, 13 Aug 2019 23:01:36 +0000 (GMT) Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (unknown [130.8.218.152]) by zlp30484.vci.att.com (Service) with ESMTPS id 8D5224009E62; Tue, 13 Aug 2019 23:01:36 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0439.000; Tue, 13 Aug 2019 19:01:36 -0400 From: "STARK, BARBARA H" To: "'David Schinazi'" CC: "'Juliusz Chroboczek'" , "'babel@ietf.org'" Thread-Topic: [babel] HMAC: removed constraint on the key stored in interface table Thread-Index: AQHVUe2J94IZUlXvWUGht5ECY/kmSKb5V8HwgABYPID//8teAIAAaDuA//++YOCAAErlAP//wwPw Date: Tue, 13 Aug 2019 23:01:35 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E2681C5@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8736i5ul8p.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E26794B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87v9v0ucba.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267D1B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87r25ou3ri.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267FBE@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.230.113] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114E2681C5GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-13_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908130215 Archived-At: Subject: Re: [babel] HMAC: removed constraint on the key stored in interface table 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, 13 Aug 2019 23:01:55 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114E2681C5GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VlIHJlc3BvbnNlIHRvIEp1bGl1c3ouIFRoZSBpbmZvIG1vZGVsIGlzICpub3QqIGRlc2lnbmlu ZyBhIHVzZXIgaW50ZXJmYWNlLiBJdCBpcyBzdGF0aW5nIHdoYXQgaXQgd2lsbCAob3IgaXMgYWxs b3dlZCB0bykgZGVsaXZlciB0byB0aGUgYmFiZWwgaW1wbGVtZW50YXRpb24uIFdoYXQgaGFwcGVu cyB0byBnZW5lcmF0ZSB0aGUgYnl0ZXMgdGhhdCBnZXQgZGVsaXZlcmVkIHRvIGJhYmVsIGJ5IHRo ZSBpbmZvIG1vZGVsIGFyZSBvdXRzaWRlIHRoZSBjb250cm9sIG9mIHRoZSBpbmZvIG1vZGVsIChz byBub3JtYXRpdmUgbGFuZ3VhZ2UgaXMgbm8gZ29vZCkuIFRob3NlIHByb3Bvc2VkIFNIT1VMRCBz dGF0ZW1lbnRzIG1lYW4gdGhlIGluZm8gbW9kZWwgcmVhbGx5IGNhbiBkZWxpdmVyIHByZXR0eSBt dWNoIGFueSBzdHJpbmcgdG8gYSBiYWJlbCBpbXBsZW1lbnRhdGlvbiBhbmQgZXhwZWN0IGludGVy b3BlcmFibGUgcmVzdWx0cy4gSSBkb27igJl0IHRoaW5rIHRoYXTigJlzIHRydWUuDQpCYXJiYXJh DQoNCkZyb206IERhdmlkIFNjaGluYXppIDxkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20+DQpTZW50 OiBUdWVzZGF5LCBBdWd1c3QgMTMsIDIwMTkgNjozMSBQTQ0KVG86IFNUQVJLLCBCQVJCQVJBIEgg PGJzNzY1MkBhdHQuY29tPg0KQ2M6IEp1bGl1c3ogQ2hyb2JvY3playA8amNoQGlyaWYuZnI+OyBi YWJlbEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtiYWJlbF0gSE1BQzogcmVtb3ZlZCBjb25zdHJh aW50IG9uIHRoZSBrZXkgc3RvcmVkIGluIGludGVyZmFjZSB0YWJsZQ0KDQpJIHRoaW5rIHdlIG1h eSBiZSBvdmVybHkgY29uc3RyYWluaW5nIG91cnNlbHZlcyBoZXJlLiBIb3cgYWJvdXQ6DQoNCi0g S2V5cyB1c2VkIGZvciBCYWJlbC1NQUMgTVVTVCBiZSBvZiBhIGxlbmd0aCBzdWl0YWJsZSBmb3Ig dGhhdCBNQUMgZnVuY3Rpb24uDQotIEltcGxlbWVudGF0aW9ucyBNVVNUIHJlamVjdCBrZXlzIHRo YXQgYXJlIG5vdCBzdWl0YWJsZSBmb3IgdGhlIE1BQyBmdW5jdGlvbjsgaW4gb3RoZXIgd29yZHMs IGltcGxlbWVudGF0aW9ucyBNVVNUIE5PVCBwcmVwcm9jZXNzIGtleXMgb2YgdW5zdWl0YWJsZSBs ZW5ndGhzIHRvIHByb2R1Y2UgYSBrZXkgb2Ygc3VpdGFibGUgbGVuZ3RoLg0KLSBCYWJlbCBtYW5h Z2VtZW50IGludGVyZmFjZXMgTVVTVCBOT1QgYWxsb3cgY29uZmlndXJpbmcga2V5cyBvZiBub24g c3VpdGFibGUgbGVuZ3Rocy4NCi0gS2V5cyBmb3IgSE1BQy1TSEEyNTYgU0hPVUxEIGJlIDY0IGJ5 dGVzIGxvbmcsIGtleXMgZm9yIEJsYWtlMnMgU0hPVUxEIGJlIDMyIGJ5dGVzIGxvbmcuDQoNCkRh dmlkDQoNCk9uIFR1ZSwgQXVnIDEzLCAyMDE5IGF0IDM6MjYgUE0gU1RBUkssIEJBUkJBUkEgSCA8 YnM3NjUyQGF0dC5jb208bWFpbHRvOmJzNzY1MkBhdHQuY29tPj4gd3JvdGU6DQo+ID4+IFdoYXQg SSdtIHN1Z2dlc3RpbmcgaXMgdGhhdCB5b3UgYWRkIHNvbWV0aGluZyB0byB0aGUgZm9sbG93aW5n IGVmZmVjdA0KPiA+PiB0byB0aGUgZGVzY3JpcHRpb24gb2YgYmFiZWwtbWFjLWtleS12YWx1ZTog SW4gdGhlIGNhc2Ugd2hlcmUNCj4gPj4gYmFiZWwtbWFjLWtleS1hbGdvcml0aG0gc3BlY2lmaWVz IGFuIGFsZ29yaXRobSBiYXNlZCBvbiB0aGUgSE1BQw0KPiA+PiBjb25zdHJ1Y3Rpb24sIHRoZW4g dGhpcyB2YWx1ZSBNVVNUIGJlIHRoZSBleGFjdCBzaXplIG9mIHRoZSBoYXNoJ3MNCj4gPj4gYmxv Y2sgc2l6ZSAoaS5lLiBpdCBoYXMgYWxyZWFkeSB1bmRlcmdvbmUgYW55IHByZXByb2Nlc3Npbmcs IHN1Y2ggYXMNCj4gPj4gdGhlIGhhc2hpbmcgb3IgemVybyBleHRlbnNpb24gZGVzY3JpYmVkIGlu IFNlY3Rpb24gMiBvZiBSRkMgMjEwNCkuDQo+DQo+ID4gT3IgbWF5YmUgSSBqdXN0IHNheTogVGhl IGtleSBNVVNUIGJlIHRoZSBtYXhpbXVtIGtleSBsZW5ndGggdGhhdCBjYW4NCj4gPiBiZSBwcm92 aWRlZCBzdWNoIHRoYXQgdGhlIGltcGxlbWVudGF0aW9uIHdpbGwgbm90IHplcm8tcGFkLCB0cnVu Y2F0ZSwNCj4gPiBvciBvdGhlcndpc2UgbWFuaXB1bGF0ZSB0aGUga2V5IHByaW9yIHRvIHVzZS4g Rm9yIEhNQUMtU0hBMjU2LCB0aGlzIGlzDQo+ID4gZGVmaW5lZCBpbiBSRkM0ODY4IGFzIDY0IGJ5 dGVzLiBGb3IgQmxha2UycywgdGhpcyBpcyBkZWZpbmVkIGluDQo+ID4gUkZDNzY5MyBhcw0KPiA+ IDMyIGJ5dGVzLiAgPw0KPg0KPiBXZSBoYXZlIGF0IGxlYXN0IHRocmVlIHJlYXNvbmFibGUgb3B0 aW9ucy4NCj4NCj4gMS4gRGV0ZXJtaW5pc3RpYzoNCj4NCj4gICAtIGZvciBITUFDIGJhc2VkIGFs Z29yaXRobXMsIHRoZSBrZXkgaXMgZXhhY3RseSB0aGUgYmxvY2sgc2l6ZSAoNjQgYnl0ZXMNCj4g ICAgIGZvciBITUFDLVNIQTI1Nik7DQo+ICAgLSBmb3IgQmxha2UycywgaXQgaXMgZXhhY3RseSAz MiBieXRlcy4NCj4NCj4gVGhpcyBpcyBkZXRlcm1pbmlzdGljLCBidXQgbm90IHZlcnkgY29udmVu aWVudCBmb3IgdGhlIHVzZXIgKHRoZSB1c2VyIG5lZWRzIHRvDQo+IGRvIHplcm8tcGFkIGhpbXNl bGYpLiAgVGhlIGJlaGF2aW91ciBpcyBzdXByaXNpbmcgdG8gdGhlIHVzZXIsIGVzcGVjaWFsbHkg aW4gdGhlDQo+IGNhc2Ugb2YgQmxha2Uycy4NCg0KVGhlIGluZm8gbW9kZWwgZG9lc24ndCBkZXNj cmliZSB0aGUgdXNlciBpbnRlcmZhY2UuIFdlJ3JlIGRlc2NyaWJpbmcgdGhlIGJpdHMgdGhhdCBn ZXQgZGVsaXZlcmVkIHRvIHRoZSBiYWJlbC1tYWMgaW1wbGVtZW50YXRpb24uIFdoYXQgZG8geW91 IHdhbnQgdG8gc2VlIGFzIGFuIGlucHV0IHRvIGEgYmFiZWwtbWFjIGltcGxlbWVudGF0aW9uPw0K DQo+DQo+IDIuIENvbnNpc3RlbnQ6DQo+DQo+ICAgLSBmb3IgSE1BQyBiYXNlZCBhbGdvcml0aG1z LCB0aGUga2V5IGlzIGF0IG1vc3QgdGhlIGJsb2NrIHNpemUgKDY0IGJ5dGVzDQo+ICAgICBmb3Ig SE1BQy1TSEEyNTYpLCBhbmQgaXMgemVyby1wYWRkZWQgYXMgZGVzY3JpYmVkIGluIFNlY3RpbiAy IG9mIFJGQw0KPiAyMTA0Ow0KPiAgIC0gZm9yIEJsYWtlMnMsIGl0IGlzIGF0IG1vc3QgMzIgYnl0 ZXMuDQo+DQo+IFRoaXMgbWFrZXMgYmVoYXZpb3VyIGNvaGVyZW50IGJldHdlZW4gSE1BQyBhbmQg Qmxha2UycywgaW4gYm90aCBjYXNlcw0KPiBhbnkgc2l6ZSBvZiBrZXkgaXMgYWxsb3dlZCB1cCBz b21lIG1heGltdW0uICBUaGlzIGlzIGNvbnZlbmllbnQgZm9yIHRoZSB1c2VyDQo+ICh3aG8gY2Fu IHVzZSBzaG9ydGVyIGtleXMpLCBhbmQgcmVhc29uYWJseSBkZXRlcm1pbmlzdGljIC0tIHRoZSBv bmx5DQo+IG9wZXJhdGlvbiBwZXJmb3JtZWQgb24gdGhlIGtleSBpcyB6ZXJvLXBhZGRpbmcuICBJ dCBhbHNvIGRvZXNuJ3QgdXNlIHRoZQ0KPiBoYXNoaW5nIGRlZmluZWQgaW4gUkZDIDIxMDQsIHdo aWNoIGlzIG5vdCBhIGdvb2QgaWRlYSAoeW91IHNob3VsZCBiZSB1c2luZyBhDQo+IHByb3BlciBL REYgaW5zdGVhZCwgYW5kIGJlIGRvaW5nIHRoZSB0cmFuc2Zvcm1hdGlvbiBvZmZsaW5lKS4NCg0K VGhpcyB3b3VsZCB3b3JrIGlmIHRoZSBiYWJlbC1tYWMgaW1wbGVtZW50YXRpb24gd2VyZSB3aWxs aW5nIHRvIGRvIHRoZSB6ZXJvLXBhZGRpbmcuIEJ1dCBub3QgaWYgeW91IHdhbnQgemVyby1wYWRk aW5nIGRvbmUgYmVmb3JlIGRlbGl2ZXJ5IHRvIGJhYmVsLW1hYy4NCg0KPiAzLiBCZWF1cm9jcmF0 aWM6DQo+DQo+ICAgLSBmb3IgSE1BQyBiYXNlZCBhbGdvcml0aG1zLCB0aGUga2V5IGlzIGFuIGFy Yml0cmFyeSBzaXplLCBhbmQgaXMgZWl0aGVyDQo+ICAgICB6ZXJvLXBhZGRlZCBvciBoYXNoZWQg YXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMiBvZiBSRkMgMjEwNDsNCj4gICAtIGZvciBCbGFrZTJz LCBpdCBpcyBhdCBtb3N0IDMyIGJ5dGVzLg0KPg0KPiBUaGlzIGhhcyB0aGUgYWR2YW50YWdlIG9m IG9iZXlpbmcgdGhlIFJGQ3MuICBJdCBoYXMgdGhlIGZsYXcgb2YgYmVpbmcNCj4gaW5jb25zaXN0 ZW50IChsb25nIGtleXMgYXJlIG9ubHkgYWNjZXB0ZWQgZm9yIEhNQUMpLCBhbmQgb2YgZW5jb3Vy YWdpbmcgYQ0KPiBwcmFjdGljZSB0aGF0IGlzIGluc2VjdXJlICh0aGUgaGFzaGluZyBmcm9tIFJG QyAyMTA0KS4NCg0KVGhpcyBpcyBqdXN0IGNvbmZ1c2luZywgYmVjYXVzZSBpdCdzIG5vdCBkZXNj cmliaW5nIHdoYXQgZ29lcyBhY3Jvc3MgdGhlIHdpcmUuIEl0IHNlZW1zIHRoZSBpbnRlbnQgb2Yg dGhpcyBpcyB0aGF0IGZvciBITUFDLVNIQTI1NiwgdGhlIGtleSB0aGF0IGdldHMgZGVsaXZlcmVk IHRvIGJhYmVsLW1hYyBpcyBtYXggb2YgNjQgYnl0ZXMuIFNvIGl0IGRldm9sdmVzIHRvIGNhc2Ug Mi4gQW5kIGlmIGNhc2VzIDIgYW5kIDMgYXJlIHJlYWxseSBleHBlY3RpbmcgdGhlIHplcm8tcGFk ZGluZyB0byBiZSBpbmNsdWRlZCBpbiB3aGF0IGdldHMgZGVsaXZlcmVkLCB0aGVuIGJvdGggZGV2 b2x2ZSBjb21wbGV0ZWx5IGJhY2sgaW50byBjYXNlIDEuDQoNCklmIENhc2UgMSBpcyB3aGF0IHlv dSB3YW50IGRlbGl2ZXJlZCB0byBiYWJlbC1tYWMsIGJ1dCB5b3Ugd2FudCBzb21lIFVJIG5pY2Vu ZXNzIGV4cHJlc3NlZCwgSSBjYW4gYWRkIGEgc3RhdGVtZW50IGxpa2UgIklmIGtleXMgYXJlIGdl bmVyYXRlZCBmcm9tIHVzZXIgaW5wdXQsIHRoZSB1c2VyIGludGVyZmFjZSBvciBtYW5hZ2VtZW50 IHN5c3RlbSBpcyBleHBlY3RlZCB0byB6ZXJvLXBhZCBzdHJpbmdzIHRoYXQgYXJlIGxlc3MgdGhh biB0aGUgcmVxdWlyZWQgbGVuZ3RoLCBhbmQgcHJvaGliaXQgc3RyaW5ncyBsb25nZXIgdGhhbiB0 aGUgcmVxdWlyZWQgbGVuZ3RoLiBUaGlzIGVuc3VyZXMgdGhlIGRlbGl2ZXJlZCBzdHJpbmcgaXMg ZXhhY3RseSB0aGUgcmVxdWlyZWQgbnVtYmVyIG9mIGJ5dGVzLiIgVGhpcyB3b3VsZCBlZmZlY3Rp dmVseSBwcm92aWRlIENhc2UgMiwgYnV0IHdpdGggdGhlIHplcm8tcGFkZGluZyBpbiB3aGF0IGdl dHMgZGVsaXZlcmVkIHRvIGJhYmVsLW1hYy4NCkJhcmJhcmENCg0KPiBJIGhhdmUgYSB3ZWFrIHBy ZWZlcmVuY2UgZm9yICgyKSwgYnV0IGNhbiBsaXZlIHdpdGggKDMpLiAgSSByZWFsaXNlIGl0IGNv bnRyYWRpY3RzDQo+IHdoYXQgSSBhZHZvY2F0ZWQgZWFybGllci4NCj4NCj4gLS0gSnVsaXVzeg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KYmFiZWwg bWFpbGluZyBsaXN0DQpiYWJlbEBpZXRmLm9yZzxtYWlsdG86YmFiZWxAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JhYmVsPGh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5f bGlzdGluZm9fYmFiZWwmZD1Ed01GYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9TG9HemhD LThzYzhTWThUcTR2cmZvZyZtPUpaN3hsTTJDcDlRdW0xbkpkUTBLR091dklyYkR2amtka195NWtE MXp2LTQmcz1tLXJCZnAySWh1M0xES090SzlNWFVaSmQtNXlMN1hTT0FySko4T3k0d3NJJmU9Pg0K --_000_2D09D61DDFA73D4C884805CC7865E6114E2681C5GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T ZWUgcmVzcG9uc2UgdG8gSnVsaXVzei4gVGhlIGluZm8gbW9kZWwgaXMgKjxiPm5vdDwvYj4qIGRl c2lnbmluZyBhIHVzZXIgaW50ZXJmYWNlLiBJdCBpcyBzdGF0aW5nIHdoYXQgaXQgd2lsbCAob3Ig aXMgYWxsb3dlZCB0bykgZGVsaXZlciB0byB0aGUgYmFiZWwgaW1wbGVtZW50YXRpb24uIFdoYXQg aGFwcGVucyB0byBnZW5lcmF0ZSB0aGUgYnl0ZXMgdGhhdCBnZXQgZGVsaXZlcmVkIHRvIGJhYmVs IGJ5IHRoZQ0KIGluZm8gbW9kZWwgYXJlIG91dHNpZGUgdGhlIGNvbnRyb2wgb2YgdGhlIGluZm8g bW9kZWwgKHNvIG5vcm1hdGl2ZSBsYW5ndWFnZSBpcyBubyBnb29kKS4gVGhvc2UgcHJvcG9zZWQg U0hPVUxEIHN0YXRlbWVudHMgbWVhbiB0aGUgaW5mbyBtb2RlbCByZWFsbHkgY2FuIGRlbGl2ZXIg cHJldHR5IG11Y2ggYW55IHN0cmluZyB0byBhIGJhYmVsIGltcGxlbWVudGF0aW9uIGFuZCBleHBl Y3QgaW50ZXJvcGVyYWJsZSByZXN1bHRzLiBJIGRvbuKAmXQgdGhpbmsNCiB0aGF04oCZcyB0cnVl LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFyYmFyYTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBEYXZpZCBTY2hpbmF6aSAmbHQ7ZHNjaGluYXpp LmlldGZAZ21haWwuY29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXVndXN0IDEz LCAyMDE5IDY6MzEgUE08YnI+DQo8Yj5Ubzo8L2I+IFNUQVJLLCBCQVJCQVJBIEggJmx0O2JzNzY1 MkBhdHQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSnVsaXVzeiBDaHJvYm9jemVrICZsdDtqY2hA aXJpZi5mciZndDs7IGJhYmVsQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbYmFi ZWxdIEhNQUM6IHJlbW92ZWQgY29uc3RyYWludCBvbiB0aGUga2V5IHN0b3JlZCBpbiBpbnRlcmZh Y2UgdGFibGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IHRoaW5rIHdlIG1heSBiZSBvdmVybHkgY29uc3RyYWluaW5nIG91cnNlbHZlcyBoZXJlLiBIb3cg YWJvdXQ6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIEtl eXMgdXNlZCBmb3IgQmFiZWwtTUFDIE1VU1QgYmUgb2YgYSBsZW5ndGggc3VpdGFibGUgZm9yIHRo YXQgTUFDIGZ1bmN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LSBJbXBsZW1lbnRhdGlvbnMgTVVTVCByZWplY3Qga2V5cyB0aGF0IGFyZSBu b3Qgc3VpdGFibGUgZm9yIHRoZSBNQUMgZnVuY3Rpb247IGluIG90aGVyIHdvcmRzLCBpbXBsZW1l bnRhdGlvbnMgTVVTVCBOT1QgcHJlcHJvY2VzcyBrZXlzIG9mIHVuc3VpdGFibGUgbGVuZ3RocyB0 byBwcm9kdWNlIGEga2V5IG9mIHN1aXRhYmxlIGxlbmd0aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gQmFiZWwgbWFuYWdlbWVudCBpbnRlcmZh Y2VzIE1VU1QgTk9UIGFsbG93IGNvbmZpZ3VyaW5nIGtleXMgb2Ygbm9uIHN1aXRhYmxlIGxlbmd0 aHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t IEtleXMgZm9yJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2si PkhNQUMtU0hBMjU2IFNIT1VMRCBiZSA2NCBieXRlcyBsb25nLCBrZXlzIGZvciZuYnNwOzwvc3Bh bj5CbGFrZTJzIFNIT1VMRCBiZSAzMiBieXRlcyBsb25nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXZpZDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEF1ZyAxMywgMjAxOSBh dCAzOjI2IFBNIFNUQVJLLCBCQVJCQVJBIEggJmx0OzxhIGhyZWY9Im1haWx0bzpiczc2NTJAYXR0 LmNvbSI+YnM3NjUyQGF0dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgJmd0OyZndDsgV2hhdCBJ J20gc3VnZ2VzdGluZyBpcyB0aGF0IHlvdSBhZGQgc29tZXRoaW5nIHRvIHRoZSBmb2xsb3dpbmcg ZWZmZWN0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0byB0aGUgZGVzY3JpcHRpb24gb2YgYmFiZWwtbWFj LWtleS12YWx1ZTogSW4gdGhlIGNhc2Ugd2hlcmU8YnI+DQomZ3Q7ICZndDsmZ3Q7IGJhYmVsLW1h Yy1rZXktYWxnb3JpdGhtIHNwZWNpZmllcyBhbiBhbGdvcml0aG0gYmFzZWQgb24gdGhlIEhNQUM8 YnI+DQomZ3Q7ICZndDsmZ3Q7IGNvbnN0cnVjdGlvbiwgdGhlbiB0aGlzIHZhbHVlIE1VU1QgYmUg dGhlIGV4YWN0IHNpemUgb2YgdGhlIGhhc2gnczxicj4NCiZndDsgJmd0OyZndDsgYmxvY2sgc2l6 ZSAoaS5lLiBpdCBoYXMgYWxyZWFkeSB1bmRlcmdvbmUgYW55IHByZXByb2Nlc3NpbmcsIHN1Y2gg YXM8YnI+DQomZ3Q7ICZndDsmZ3Q7IHRoZSBoYXNoaW5nIG9yIHplcm8gZXh0ZW5zaW9uIGRlc2Ny aWJlZCBpbiBTZWN0aW9uIDIgb2YgUkZDIDIxMDQpLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7 IE9yIG1heWJlIEkganVzdCBzYXk6IFRoZSBrZXkgTVVTVCBiZSB0aGUgbWF4aW11bSBrZXkgbGVu Z3RoIHRoYXQgY2FuPGJyPg0KJmd0OyAmZ3Q7IGJlIHByb3ZpZGVkIHN1Y2ggdGhhdCB0aGUgaW1w bGVtZW50YXRpb24gd2lsbCBub3QgemVyby1wYWQsIHRydW5jYXRlLDxicj4NCiZndDsgJmd0OyBv ciBvdGhlcndpc2UgbWFuaXB1bGF0ZSB0aGUga2V5IHByaW9yIHRvIHVzZS4gRm9yIEhNQUMtU0hB MjU2LCB0aGlzIGlzPGJyPg0KJmd0OyAmZ3Q7IGRlZmluZWQgaW4gUkZDNDg2OCBhcyA2NCBieXRl cy4gRm9yIEJsYWtlMnMsIHRoaXMgaXMgZGVmaW5lZCBpbjxicj4NCiZndDsgJmd0OyBSRkM3Njkz IGFzPGJyPg0KJmd0OyAmZ3Q7IDMyIGJ5dGVzLiZuYnNwOyA/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFdlIGhhdmUgYXQgbGVhc3QgdGhyZWUgcmVhc29uYWJsZSBvcHRpb25zLjxicj4NCiZndDsgPGJy Pg0KJmd0OyAxLiBEZXRlcm1pbmlzdGljOjxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDstIGZvciBITUFDIGJhc2VkIGFsZ29yaXRobXMsIHRoZSBrZXkgaXMgZXhhY3RseSB0aGUgYmxv Y2sgc2l6ZSAoNjQgYnl0ZXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtmb3IgSE1BQy1T SEEyNTYpOzxicj4NCiZndDsmbmJzcDsgJm5ic3A7LSBmb3IgQmxha2UycywgaXQgaXMgZXhhY3Rs eSAzMiBieXRlcy48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhpcyBpcyBkZXRlcm1pbmlzdGljLCBi dXQgbm90IHZlcnkgY29udmVuaWVudCBmb3IgdGhlIHVzZXIgKHRoZSB1c2VyIG5lZWRzIHRvPGJy Pg0KJmd0OyBkbyB6ZXJvLXBhZCBoaW1zZWxmKS4mbmJzcDsgVGhlIGJlaGF2aW91ciBpcyBzdXBy aXNpbmcgdG8gdGhlIHVzZXIsIGVzcGVjaWFsbHkgaW4gdGhlPGJyPg0KJmd0OyBjYXNlIG9mIEJs YWtlMnMuPGJyPg0KPGJyPg0KVGhlIGluZm8gbW9kZWwgZG9lc24ndCBkZXNjcmliZSB0aGUgdXNl ciBpbnRlcmZhY2UuIFdlJ3JlIGRlc2NyaWJpbmcgdGhlIGJpdHMgdGhhdCBnZXQgZGVsaXZlcmVk IHRvIHRoZSBiYWJlbC1tYWMgaW1wbGVtZW50YXRpb24uIFdoYXQgZG8geW91IHdhbnQgdG8gc2Vl IGFzIGFuIGlucHV0IHRvIGEgYmFiZWwtbWFjIGltcGxlbWVudGF0aW9uPzxicj4NCjxicj4NCiZn dDsgPGJyPg0KJmd0OyAyLiBDb25zaXN0ZW50Ojxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDstIGZvciBITUFDIGJhc2VkIGFsZ29yaXRobXMsIHRoZSBrZXkgaXMgYXQgbW9zdCB0aGUg YmxvY2sgc2l6ZSAoNjQgYnl0ZXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtmb3IgSE1B Qy1TSEEyNTYpLCBhbmQgaXMgemVyby1wYWRkZWQgYXMgZGVzY3JpYmVkIGluIFNlY3RpbiAyIG9m IFJGQzxicj4NCiZndDsgMjEwNDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOy0gZm9yIEJsYWtlMnMs IGl0IGlzIGF0IG1vc3QgMzIgYnl0ZXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoaXMgbWFrZXMg YmVoYXZpb3VyIGNvaGVyZW50IGJldHdlZW4gSE1BQyBhbmQgQmxha2UycywgaW4gYm90aCBjYXNl czxicj4NCiZndDsgYW55IHNpemUgb2Yga2V5IGlzIGFsbG93ZWQgdXAgc29tZSBtYXhpbXVtLiZu YnNwOyBUaGlzIGlzIGNvbnZlbmllbnQgZm9yIHRoZSB1c2VyPGJyPg0KJmd0OyAod2hvIGNhbiB1 c2Ugc2hvcnRlciBrZXlzKSwgYW5kIHJlYXNvbmFibHkgZGV0ZXJtaW5pc3RpYyAtLSB0aGUgb25s eTxicj4NCiZndDsgb3BlcmF0aW9uIHBlcmZvcm1lZCBvbiB0aGUga2V5IGlzIHplcm8tcGFkZGlu Zy4mbmJzcDsgSXQgYWxzbyBkb2Vzbid0IHVzZSB0aGU8YnI+DQomZ3Q7IGhhc2hpbmcgZGVmaW5l ZCBpbiBSRkMgMjEwNCwgd2hpY2ggaXMgbm90IGEgZ29vZCBpZGVhICh5b3Ugc2hvdWxkIGJlIHVz aW5nIGE8YnI+DQomZ3Q7IHByb3BlciBLREYgaW5zdGVhZCwgYW5kIGJlIGRvaW5nIHRoZSB0cmFu c2Zvcm1hdGlvbiBvZmZsaW5lKS48YnI+DQo8YnI+DQpUaGlzIHdvdWxkIHdvcmsgaWYgdGhlIGJh YmVsLW1hYyBpbXBsZW1lbnRhdGlvbiB3ZXJlIHdpbGxpbmcgdG8gZG8gdGhlIHplcm8tcGFkZGlu Zy4gQnV0IG5vdCBpZiB5b3Ugd2FudCB6ZXJvLXBhZGRpbmcgZG9uZSBiZWZvcmUgZGVsaXZlcnkg dG8gYmFiZWwtbWFjLjxicj4NCjxicj4NCiZndDsgMy4gQmVhdXJvY3JhdGljOjxicj4NCiZndDsg PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDstIGZvciBITUFDIGJhc2VkIGFsZ29yaXRobXMsIHRoZSBr ZXkgaXMgYW4gYXJiaXRyYXJ5IHNpemUsIGFuZCBpcyBlaXRoZXI8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDt6ZXJvLXBhZGRlZCBvciBoYXNoZWQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24g MiBvZiBSRkMgMjEwNDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOy0gZm9yIEJsYWtlMnMsIGl0IGlz IGF0IG1vc3QgMzIgYnl0ZXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoaXMgaGFzIHRoZSBhZHZh bnRhZ2Ugb2Ygb2JleWluZyB0aGUgUkZDcy4mbmJzcDsgSXQgaGFzIHRoZSBmbGF3IG9mIGJlaW5n PGJyPg0KJmd0OyBpbmNvbnNpc3RlbnQgKGxvbmcga2V5cyBhcmUgb25seSBhY2NlcHRlZCBmb3Ig SE1BQyksIGFuZCBvZiBlbmNvdXJhZ2luZyBhPGJyPg0KJmd0OyBwcmFjdGljZSB0aGF0IGlzIGlu c2VjdXJlICh0aGUgaGFzaGluZyBmcm9tIFJGQyAyMTA0KS48YnI+DQo8YnI+DQpUaGlzIGlzIGp1 c3QgY29uZnVzaW5nLCBiZWNhdXNlIGl0J3Mgbm90IGRlc2NyaWJpbmcgd2hhdCBnb2VzIGFjcm9z cyB0aGUgd2lyZS4gSXQgc2VlbXMgdGhlIGludGVudCBvZiB0aGlzIGlzIHRoYXQgZm9yIEhNQUMt U0hBMjU2LCB0aGUga2V5IHRoYXQgZ2V0cyBkZWxpdmVyZWQgdG8gYmFiZWwtbWFjIGlzIG1heCBv ZiA2NCBieXRlcy4gU28gaXQgZGV2b2x2ZXMgdG8gY2FzZSAyLiBBbmQgaWYgY2FzZXMgMiBhbmQg MyBhcmUgcmVhbGx5IGV4cGVjdGluZw0KIHRoZSB6ZXJvLXBhZGRpbmcgdG8gYmUgaW5jbHVkZWQg aW4gd2hhdCBnZXRzIGRlbGl2ZXJlZCwgdGhlbiBib3RoIGRldm9sdmUgY29tcGxldGVseSBiYWNr IGludG8gY2FzZSAxLjxicj4NCjxicj4NCklmIENhc2UgMSBpcyB3aGF0IHlvdSB3YW50IGRlbGl2 ZXJlZCB0byBiYWJlbC1tYWMsIGJ1dCB5b3Ugd2FudCBzb21lIFVJIG5pY2VuZXNzIGV4cHJlc3Nl ZCwgSSBjYW4gYWRkIGEgc3RhdGVtZW50IGxpa2UgJnF1b3Q7SWYga2V5cyBhcmUgZ2VuZXJhdGVk IGZyb20gdXNlciBpbnB1dCwgdGhlIHVzZXIgaW50ZXJmYWNlIG9yIG1hbmFnZW1lbnQgc3lzdGVt IGlzIGV4cGVjdGVkIHRvIHplcm8tcGFkIHN0cmluZ3MgdGhhdCBhcmUgbGVzcyB0aGFuIHRoZSBy ZXF1aXJlZA0KIGxlbmd0aCwgYW5kIHByb2hpYml0IHN0cmluZ3MgbG9uZ2VyIHRoYW4gdGhlIHJl cXVpcmVkIGxlbmd0aC4gVGhpcyBlbnN1cmVzIHRoZSBkZWxpdmVyZWQgc3RyaW5nIGlzIGV4YWN0 bHkgdGhlIHJlcXVpcmVkIG51bWJlciBvZiBieXRlcy4mcXVvdDsgVGhpcyB3b3VsZCBlZmZlY3Rp dmVseSBwcm92aWRlIENhc2UgMiwgYnV0IHdpdGggdGhlIHplcm8tcGFkZGluZyBpbiB3aGF0IGdl dHMgZGVsaXZlcmVkIHRvIGJhYmVsLW1hYy48YnI+DQpCYXJiYXJhPGJyPg0KPGJyPg0KJmd0OyBJ IGhhdmUgYSB3ZWFrIHByZWZlcmVuY2UgZm9yICgyKSwgYnV0IGNhbiBsaXZlIHdpdGggKDMpLiZu YnNwOyBJIHJlYWxpc2UgaXQgY29udHJhZGljdHM8YnI+DQomZ3Q7IHdoYXQgSSBhZHZvY2F0ZWQg ZWFybGllci48YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0gSnVsaXVzejxicj4NCjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KYmFiZWwgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmJhYmVsQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+YmFiZWxAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb19iYWJlbCZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZh bXA7cj1Mb0d6aEMtOHNjOFNZOFRxNHZyZm9nJmFtcDttPUpaN3hsTTJDcDlRdW0xbkpkUTBLR091 dklyYkR2amtka195NWtEMXp2LTQmYW1wO3M9bS1yQmZwMklodTNMREtPdEs5TVhVWkpkLTV5TDdY U09BckpKOE95NHdzSSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2JhYmVsPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2D09D61DDFA73D4C884805CC7865E6114E2681C5GAALPA1MSGUSRBF_-- From nobody Tue Aug 13 16:06:55 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 A161E12091A for ; Tue, 13 Aug 2019 16:06: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 WoxRHQ_M2GTv for ; Tue, 13 Aug 2019 16:06: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 DB73C1208FE for ; Tue, 13 Aug 2019 16:06:51 -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 x7DN6idh020585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Aug 2019 01:06:44 +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 x7DN6isE012091; Wed, 14 Aug 2019 01:06:44 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5CDA543788; Wed, 14 Aug 2019 01:06:47 +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 fcpYHcbY8f1T; Wed, 14 Aug 2019 01:06: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 2042243786; Wed, 14 Aug 2019 01:06:42 +0200 (CEST) Date: Wed, 14 Aug 2019 01:06:41 +0200 Message-ID: <87o90su0la.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'babel@ietf.org'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E267FBE@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8736i5ul8p.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E26794B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87v9v0ucba.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267D1B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87r25ou3ri.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267FBE@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 14 Aug 2019 01:06:44 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 14 Aug 2019 01:06:44 +0200 (CEST) X-Miltered: at korolev with ID 5D534284.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D534284.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D534284.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D534284.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 : 5D534284.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D534284.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] HMAC: removed constraint on the key stored in interface table 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, 13 Aug 2019 23:06:54 -0000 > The info model doesn't describe the user interface. We're describing the > bits that get delivered to the babel-mac implementation. What do you > want to see as an input to a babel-mac implementation? Options (1) and (2) are trivial to implement on the fly. Option (3) requires precomputing the hash of the key, which adds a field to a data structure somewhere (unless you discard the provided key and replace it with its hash, which for some reason I find distasteful). Option (1): if(key->length != 64) return -1; ... for(i = 0; i < 64; i++) ibuf = key->value[i] ^ 0x36; Option (2): if(key->length > 64) return -1; ... for(i = 0; i < key->length; i++) ibuf = key->value[i] ^ 0x36; memset(ibuf + key->length, 0x36, 64 - key->length); The UI of babeld currently implements option (2). Having the UI and the information model be congruent gives me a nice, warm feeling. -- Juliusz From nobody Tue Aug 13 16:13:41 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 E048212091D for ; Tue, 13 Aug 2019 16:13: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 nb0RE2sdX7EM for ; Tue, 13 Aug 2019 16:13:38 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2619E1208FE for ; Tue, 13 Aug 2019 16:13:37 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7DNDUTY022706; Wed, 14 Aug 2019 01:13:30 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 92D38437C2; Wed, 14 Aug 2019 01:13:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id jRqe3soPWJGJ; Wed, 14 Aug 2019 01:13:32 +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 98451437C0; Wed, 14 Aug 2019 01:13:32 +0200 (CEST) Date: Wed, 14 Aug 2019 01:13:32 +0200 Message-ID: <87mugcu09v.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'David Schinazi'" , "'babel@ietf.org'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E2681C5@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8736i5ul8p.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E26794B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87v9v0ucba.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267D1B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87r25ou3ri.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267FBE@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E2681C5@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 14 Aug 2019 01:13:30 +0200 (CEST) X-Miltered: at korolev with ID 5D53441A.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D53441A.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 : 5D53441A.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] HMAC: removed constraint on the key stored in interface table 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, 13 Aug 2019 23:13:40 -0000 > See response to Juliusz. The info model is *not* designing a user interface. It > is stating what it will (or is allowed to) deliver to the babel implementation. > What happens to generate the bytes that get delivered to babel by the info > model are outside the control of the info model (so normative language is no > good). Those proposed SHOULD statements mean the info model really can deliver > pretty much any string to a babel implementation and expect interoperable > results. If I read Barbara right: - administrator writes a script that configures his 10000 routers the way he likes it; - administrator buys a new router that interprets the data model differently; - script breaks because the new router requires exactly 64 bytes in a key; - administrator spends the weekend fixing his network rather than going hiking with his children as he promised. Think of the children, David. -- Juliusz From nobody Tue Aug 13 16:42: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 5765F120132 for ; Tue, 13 Aug 2019 16:42:45 -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 R2lvyDF4nvJk for ; Tue, 13 Aug 2019 16:42:43 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 D94111200B2 for ; Tue, 13 Aug 2019 16:42:42 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id n19so9587763lfe.13 for ; Tue, 13 Aug 2019 16:42:42 -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=h2dOyWT+OmdzXL9RJD89QUe4nLtbHr24V7dm9ENVvrE=; b=LwBN/XljxQTwD60pODrw4V5MOWhzSnDc+fuNodbcyrDMLvhMXPTRvPHHdILXnbFiF8 68WipaTwxE8kGLRZrMNqX6+/rOoH61f4oLgNwHAh8sCqBl0G/gQBak9qqkMEGbXuJkRx hwyqIkwSXUaGUhow5XErtkhYr8KccryuEMfUeUPBRNf6AfvjDTkejNfN2o0XCL17Y/Hw Q18kX/VqxXuKcqX11+CHzN3dpP+MfD1yFtO9Z1KtwIfUE5jsluoMTjDxXVsZROSZ17au S5dr+7gAljQCJZfDoU6Mk27wNSwVmEf3rMM6hf4WXX4W5alsgyNmpnYrinpK/KgXgav9 qWog== 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=h2dOyWT+OmdzXL9RJD89QUe4nLtbHr24V7dm9ENVvrE=; b=Qby9MjxASYHat0wCglXt0FsvOrKsE0mz83Lg6b/2xm6Mmubi3S4GvFtiVhR9cBddOK I2E6d+GE0dAeLUOKdLHYlk9bFyEpt5gUbMR9Me+93lPZxkY2m+m5AixiF4AJlZXETgRS mFGcFGNIUKQ1QPbMlPIaHeE9SGXqAef6Kg8luui8AuBfD/eLLSynS3MNGqotidtldase OubqMfsOBv4BMrSv5mflsRh36Wo01ApzmhvUsKdGM34PgPl7lkCb1q0Vao3ErDpIxUXR JnYyJTZ9E1Zo0Ve/GaSMJog4Od3uw+KU2zf1NAYMUEPTV+nFAKbTVsrdor7g0ePPPv/I GEcA== X-Gm-Message-State: APjAAAVg2O1xIk1qFKM6S+sdqj0ng19R7Hz2FAnAu3f/F3FmDWgwmlZL ik1QMqHMN80Q7E0zr1CgoBWnfBDWMWNE3u3ypE0= X-Google-Smtp-Source: APXvYqx3O0q35T5oy3pp4gLUvPbQlAajmk2ekOLG8jTDwKt4hoSHbfLv7OQYmnSX11sg386a+eGEWXjZdhzG9K0Wo4M= X-Received: by 2002:a19:ec0c:: with SMTP id b12mr24213748lfa.107.1565739761001; Tue, 13 Aug 2019 16:42:41 -0700 (PDT) MIME-Version: 1.0 References: <8736i5ul8p.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E26794B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87v9v0ucba.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267D1B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87r25ou3ri.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267FBE@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E2681C5@GAALPA1MSGUSRBF.ITServices.sbc.com> <87mugcu09v.wl-jch@irif.fr> In-Reply-To: <87mugcu09v.wl-jch@irif.fr> From: David Schinazi Date: Tue, 13 Aug 2019 16:42:30 -0700 Message-ID: To: Juliusz Chroboczek Cc: "STARK, BARBARA H" , "babel@ietf.org" Content-Type: multipart/alternative; boundary="00000000000043e91b0590083272" Archived-At: Subject: Re: [babel] HMAC: removed constraint on the key stored in interface table 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, 13 Aug 2019 23:42:46 -0000 --00000000000043e91b0590083272 Content-Type: text/plain; charset="UTF-8" @Juliusz: Revised statement, now with 30% more thinking of the children: (only added second normative statement) - Keys used for Babel-MAC MUST be of a length suitable for that MAC function. - Implementations MUST accept all key lengths that are suitable for the selected MAC function, as defined by the specification of that MAC function. - Implementations MUST reject keys that are not suitable for the MAC function; in other words, implementations MUST NOT preprocess keys of unsuitable lengths to produce a key of suitable length. - Babel management interfaces MUST NOT allow configuring keys of non suitable lengths. - Keys for HMAC-SHA256 SHOULD be 64 bytes long, keys for Blake2s SHOULD be 32 bytes long. @Barbara: I'm not discussing the user interface, only what the information model can deliver to the Babel implementation On Tue, Aug 13, 2019 at 4:13 PM Juliusz Chroboczek wrote: > > See response to Juliusz. The info model is *not* designing a user > interface. It > > is stating what it will (or is allowed to) deliver to the babel > implementation. > > What happens to generate the bytes that get delivered to babel by the > info > > model are outside the control of the info model (so normative language > is no > > good). Those proposed SHOULD statements mean the info model really can > deliver > > pretty much any string to a babel implementation and expect interoperable > > results. > > If I read Barbara right: > > - administrator writes a script that configures his 10000 routers the way > he likes it; > - administrator buys a new router that interprets the data model > differently; > - script breaks because the new router requires exactly 64 bytes in a > key; > - administrator spends the weekend fixing his network rather than going > hiking with his children as he promised. > > Think of the children, David. > > -- Juliusz > > --00000000000043e91b0590083272 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@Juliusz: Revised statement, now with 30% more thinking of= the children:

(only added second normative statement)

- Keys used for Babel-MAC MUST be of a length su= itable for that MAC function.
- Implementations MUST accept all k= ey lengths that are suitable for the selected MAC function, as defined by t= he specification of that MAC function.
- Implementations MUST= reject keys that are not suitable for the MAC function; in other words, im= plementations MUST NOT preprocess keys of unsuitable lengths to produce a k= ey of suitable length.
- Babel management interfaces MUST NOT all= ow configuring keys of non suitable lengths.
- Keys for=C2=A0HMAC-SHA256 SHOULD be 64 b= ytes long, keys for=C2=A0Blake2s SHOULD be 32 bytes long.
=
@Barbara: I'm not discussing the user interface, only wh= at the information model can deliver to the Babel implementation

On Tue, Aug 13, 2019 at 4:13 PM Juliusz Chroboczek <jch@irif.fr> wrote:
> See response to Juliusz= . The info model is *not* designing a user interface. It
> is stating what it will (or is allowed to) deliver to the babel implem= entation.
> What happens to generate the bytes that get delivered to babel by the = info
> model are outside the control of the info model (so normative language= is no
> good). Those proposed SHOULD statements mean the info model really can= deliver
> pretty much any string to a babel implementation and expect interopera= ble
> results.

If I read Barbara right:

=C2=A0 - administrator writes a script that configures his 10000 routers th= e way
=C2=A0 =C2=A0 he likes it;
=C2=A0 - administrator buys a new router that interprets the data model dif= ferently;
=C2=A0 - script breaks because the new router requires exactly 64 bytes in = a key;
=C2=A0 - administrator spends the weekend fixing his network rather than go= ing
=C2=A0 =C2=A0 hiking with his children as he promised.

Think of the children, David.

-- Juliusz

--00000000000043e91b0590083272-- From nobody Tue Aug 13 17:18:41 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 0D0E31200B2 for ; Tue, 13 Aug 2019 17:18:40 -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 SPMIP_oHNVjP for ; Tue, 13 Aug 2019 17:18:37 -0700 (PDT) Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (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 52720120019 for ; Tue, 13 Aug 2019 17:18:37 -0700 (PDT) Received: by mail-pg1-x544.google.com with SMTP id o13so52100798pgp.12 for ; Tue, 13 Aug 2019 17:18:37 -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=Y5ZEFkBCn9zsPnCtKnDBF+fPmFzXdF4lY7ZWINIsURQ=; b=WArKKbHXCDyQiSYn88ZPx5u07LxJhNweUlnBKUemGVGA6N6mgsx0KJtIvTavgf2K3N T5xWq/3vmw/9L2jBgdxhZqp9Qhp7TsGrsfUKibKTacZW1RcBezQNfxKtzLkvbojFNqBl SjmOtIWgValFbN2OfhQnit72rnN8xWi4PwI4pkJErIf78eJib6CT1aB+6K7jkVvqtoXV OuFyHn2lyCl3ue0Cj6DSEEQ7jxrj/MXb3kGSn4jfBEmvuaaCxSxPZMnV050smzWfYSaJ Keyd1h23UHXHn9aoWGy6XROuEkinV7WStx9TCPpubKl+d40YixnQxNVxNF6konJlRFuP ZwYA== 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=Y5ZEFkBCn9zsPnCtKnDBF+fPmFzXdF4lY7ZWINIsURQ=; b=Z7mYaSqOc+ENrWWVs5qkUGThg/++nxOXj3wMmLnAHluFChPgj2Teyag54LlFCGl7CX qkksc02K4ysF5BDE2NnkxK4h+MwRCiCx75eJ1Mq3TP1eNcqPRjSrvSGWqC61kwYf8Hvo 4idClOtJQLU9ffPnJ3k3KJht6/rwOX0nzF6MZf9Wd+QF32zhBHNAUf5S74dcrZthRiHP ZJgMDMlWQt2ic8tjb9hhC42Cih4dW1Mo4cWNf6KkRNGOpa9P0RGOo28X/RFAgt/8Zrfv WjzWUeZjTm+2HtUn2uP/ZUFGS3t1pWd7ack9bxon7SKNxlX6pr6YhX6I0PmuX1xbsZkq XVCA== X-Gm-Message-State: APjAAAUtbdiF4U8WHnRJmIQpSTNx8GYeyyPbAcHCPQdgP9EOwO/USfJh x2QzuvJbrjxuZvbGJ4RBS+E= X-Google-Smtp-Source: APXvYqxZc3/wf5noYUVFJtGbuiq0rADiepmgWl40Wpw0PjZNYPZKKOGgj3Mtx+yECAe0sf7Q4ClHsA== X-Received: by 2002:a63:df06:: with SMTP id u6mr34522391pgg.96.1565741916611; Tue, 13 Aug 2019 17:18:36 -0700 (PDT) Received: from [10.33.122.240] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id k5sm9069416pfg.167.2019.08.13.17.18.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Aug 2019 17:18:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mahesh Jethanandani In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E2680FE@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Tue, 13 Aug 2019 17:18:33 -0700 Cc: Juliusz Chroboczek , =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Babel at IETF Content-Transfer-Encoding: quoted-printable Message-Id: <9554AC75-4674-4EB2-B40D-26CA383E3343@gmail.com> References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr> <87pnlhaixh.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E257961@GAALPA1MSGUSRBF.ITServices.sbc.com> <0B28A1FA-32B4-41E6-B646-C6A3907E9CCC@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114E258CF7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E25905B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87lfw3u52i.fsf@toke.dk> <110D87BA-BBA1-417B-9BC3-77BAD4B201D1@gmail.com> <87ftmbs92f.fsf@toke.dk> <26F1A0CD-1FD2-456E-B295-8A60D93CF8E0@gmail.com> <87sgqbmhhe.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E2680FE@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Example configuration 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: Wed, 14 Aug 2019 00:18:40 -0000 Hi Barbara, et. all,=20 If you are managing a small number of interfaces (< 10 in my mind), then = your approach is simpler. Configure link properties per interface and be = done, even if means repeating the configuration on those 10 interfaces. If we are talking about a larger set, then the complexity might be worth = it, simply to allow changes in one place. The question therefore comes down to, what is the normal number of = interfaces a device will configure to run babeld? Cheers. > On Aug 13, 2019, at 3:51 PM, STARK, BARBARA H wrote: >=20 > I've been ruminating long and hard on this idea of abstracting the = link properties. > I'm thinking this abstraction really is too complex, and I'd prefer to = just stick with the properties under interface. > But, I think it would be reasonable to add language that describes = what link characteristics make a particular choice preferred over other = choices. > If a user really wants to change one of these (and Babel is designed = not to require manual changes to link properties in most cases), then = they just need to know what they're doing.=20 > Complexities creep in wrt user language (so users do need to customize = the name, which means it can't be immutable), growing permutations as = more properties are defined, etc. >=20 > Language I suggest: >=20 > babel-metric-comp-algorithms: List of supported cost computation > algorithms. Possible values include "2-out-of-3", and "ETX". > "2-out-of-3" (a specific case of K-out-of-j ) link sensing is = suitable for wired links that are either > up, in which case they only occasionally drop a packet, or down, = in > which case they drop all packets. "ETX" is a link-quality = estimation algorithm that is > designed to work well with the IEEE 802.11 MAC. >=20 > babel-interface-split-horizon: Indicates whether or not the split > horizon optimization is used when calculating metrics on this > interface. A value of true indicates split horizon optimization > is used. Split horizon optimization is useful when running over a > transitive, symmetric link technology, e.g., a > point-to-point link or a wired LAN technology such as Ethernet.=20= > It is not appropriate for links not known to be symmetric and = transitive; in particular, > split horizon is not appropriate for decentralized wireless link > technologies (e.g., IEEE 802.11 in ad hoc mode) when routing = updates > are sent over multicast. >=20 > Barbara >=20 >>>> In the second example, the operator will define a >>>> babel-link-properties-obj, call it =E2=80=9Cradio=E2=80=9D or = =E2=80=9Cwireless=E2=80=9D or anything >>>> they want, and within that object set the >>>> babel-interface-metric-algorithm (because it a mandatory = parameter), >>>> and set the babel-split-horizon to false. They will then associate = =E2=80=9Cradio=E2=80=9D >> object with eth1 interface. >>>=20 >>> Can the UI simulate the babel-link-properties-obj without it being >>> part of the model? >>=20 >> Before I answer that question, let me know if the following answers = help. If >> they do not, I am afraid that we will need a whiteboard discussion on >> management interface and the role YANG plays in it. >>=20 >>>=20 >>> I.e. the operator defines a set of values called "radio", this set >>> only exists within the UI. >>=20 >> =E2=80=9Cradio=E2=80=9D in my example is what you call UIs, just like = =E2=80=9Cwireless=E2=80=9D. Therefore >> when you say =E2=80=9Cset of values called =E2=80=9Cradio=E2=80=9D=E2=80= =9D, I read it as set of link properties >> that you want to club together and associate with a name, and that = name is >> =E2=80=9Cradio". Is that correct? >>=20 >>> The operator then applies "radio" to a number of interfaces, and the >>> frontend applies the individual values contained in the "radio" >>> dictionary to each of those interfaces. >>=20 >>=20 >> But that is exactly what the new babel-link-properties-obj allows you = to do. It >> allows you to define any number of babel-link-properties-obj, and = name >> them whatever you want, e.g. =E2=80=9Cradio=E2=80=9D, =E2=80=9Cwired=E2= =80=9D, =E2=80=9Cwireless=E2=80=9D etc, or what you >> call =E2=80=9CUI". In each of the babel-link-properties-obj you set = the properties you >> want, e.g. split horizon, rtt, etc. As a final step you associate = any of the >> defined UI with any number of interfaces. When you associate the = given UI >> with an interface, all the link properties defined as part of that UI = are then >> applied on the interface. >>=20 >> Did that answer your question, or confuse you even more? >>=20 >>>=20 >>> Or does YANG require that the UI reflect the model? >>=20 >>>=20 >>> -- Juliusz >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >>=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Wed Aug 14 05:47: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 633F9120803 for ; Wed, 14 Aug 2019 05:47:04 -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 lE5z30YO9p8E for ; Wed, 14 Aug 2019 05:47:02 -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 A6EFF1200A3 for ; Wed, 14 Aug 2019 05:47:02 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1565786819; bh=Wc14KeAxm8Ukk6Vrm017CMEfqBblndsHAwUPLN/+9lo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=YB1dyoj2tAvoTU2r3Kp5YEZxArifzIvMQXn4VJ5dtuW2Sk4RtwGTrkLEXrFBXZzyi /dAalZa9gfqoycxx0XyhQczaiLMVBzcLuRRUXYpvyciMNVxFGwT5lH+qobINCKRQep CdGY+kIc3IBnjKEKRIrt63A6tlYQtCnQGSRW8EoDy+CL3Y3QTTsiYe1kYKmqqnXHxZ kuhZexPUIiF00AxzBA4RJOTwNdOi8HrUN8r/bnh826zD2L7DPYEY0cCW0CwQCj/vFJ KV3imJUMd/ySR//rADmV3u8XxpufY/covohSGPIPAFRAMyeW0bO+KGeW55I7ecnJuX Ku1b/RxHTPgJg== To: Mahesh Jethanandani , "STARK\, BARBARA H" Cc: Juliusz Chroboczek , Babel at IETF In-Reply-To: <9554AC75-4674-4EB2-B40D-26CA383E3343@gmail.com> References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr> <87pnlhaixh.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E257961@GAALPA1MSGUSRBF.ITServices.sbc.com> <0B28A1FA-32B4-41E6-B646-C6A3907E9CCC@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114E258CF7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E25905B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87lfw3u52i.fsf@toke.dk> <110D87BA-BBA1-417B-9BC3-77BAD4B201D1@gmail.com> <87ftmbs92f.fsf@toke.dk> <26F1A0CD-1FD2-456E-B295-8A60D93CF8E0@gmail.com> <87sgqbmhhe.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E2680FE@GAALPA1MSGUSRBF.ITServices.sbc.com> <9554AC75-4674-4EB2-B40D-26CA383E3343@gmail.com> Date: Wed, 14 Aug 2019 14:46:59 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87woffap8c.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Example configuration 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: Wed, 14 Aug 2019 12:47:04 -0000 Mahesh Jethanandani writes: > Hi Barbara, et. all, > > If you are managing a small number of interfaces (< 10 in my mind), > then your approach is simpler. Configure link properties per interface > and be done, even if means repeating the configuration on those 10 > interfaces. > > If we are talking about a larger set, then the complexity might be > worth it, simply to allow changes in one place. > > The question therefore comes down to, what is the normal number of > interfaces a device will configure to run babeld? For most current Babel deployments I'm familiar with: One or two wireless interfaces and maybe a single wired. Definitely less than 10... -Toke From nobody Wed Aug 14 06:50:25 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 4FCA11200F8 for ; Wed, 14 Aug 2019 06:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvL15r7RqAP5 for ; Wed, 14 Aug 2019 06:50:22 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991B012013F for ; Wed, 14 Aug 2019 06:50:22 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7EDkWWg029266; Wed, 14 Aug 2019 09:50:19 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2ucjct215r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 09:50:19 -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 x7EDoHlH002291; Wed, 14 Aug 2019 09:50:17 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7EDo7I3001944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Aug 2019 09:50:07 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id E6EB84005669; Wed, 14 Aug 2019 13:50:07 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30483.vci.att.com (Service) with ESMTPS id D28A24005668; Wed, 14 Aug 2019 13:50:07 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0439.000; Wed, 14 Aug 2019 09:50:07 -0400 From: "STARK, BARBARA H" To: =?iso-8859-1?Q?=27Toke_H=F8iland-J=F8rgensen=27?= , "'Mahesh Jethanandani'" CC: "'Juliusz Chroboczek'" , "'Babel at IETF'" Thread-Topic: [babel] Example configuration Thread-Index: AQHVQysP27rmDxHNmE+dOkameIFP66bcIv6AgBKtMoCAAAmwgIAACWOAgAAV/4CAAC8QgIAAC2UAgABwxXCAAK2IgP//vsCAgABe24D//71TQIABdAyAgAAImACAAGCgAIAAGqGAgAAFboCAB5bYgIAABZVQgABho4CAANEcgP//vm7w Date: Wed, 14 Aug 2019 13:50:06 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E26901D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr> <87pnlhaixh.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E257961@GAALPA1MSGUSRBF.ITServices.sbc.com> <0B28A1FA-32B4-41E6-B646-C6A3907E9CCC@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114E258CF7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E25905B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87lfw3u52i.fsf@toke.dk> <110D87BA-BBA1-417B-9BC3-77BAD4B201D1@gmail.com> <87ftmbs92f.fsf@toke.dk> <26F1A0CD-1FD2-456E-B295-8A60D93CF8E0@gmail.com> <87sgqbmhhe.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E2680FE@GAALPA1MSGUSRBF.ITServices.sbc.com> <9554AC75-4674-4EB2-B40D-26CA383E3343@gmail.com> <87woffap8c.fsf@toke.dk> In-Reply-To: <87woffap8c.fsf@toke.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.174.18.88] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-14_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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=814 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908140142 Archived-At: Subject: Re: [babel] Example configuration 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: Wed, 14 Aug 2019 13:50:24 -0000 > From: Toke H=F8iland-J=F8rgensen > Mahesh Jethanandani writes: >=20 > > Hi Barbara, et. all, > > > > If you are managing a small number of interfaces (< 10 in my mind), > > then your approach is simpler. Configure link properties per interface > > and be done, even if means repeating the configuration on those 10 > > interfaces. > > > > If we are talking about a larger set, then the complexity might be > > worth it, simply to allow changes in one place. > > > > The question therefore comes down to, what is the normal number of > > interfaces a device will configure to run babeld? >=20 > For most current Babel deployments I'm familiar with: One or two wireless > interfaces and maybe a single wired. Definitely less than 10... I agree with Toke. And I think we also need to understand that active confi= guration in Babel is about handling exceptions to the implemented rules. In= almost all cases, the Babel implementation will automatically select the c= orrect link properties for an interface. Only for the small number of cases= where the automatic implementation config is wrong will the configuration = need to be updated/changed. For example, if I attach a wireless bridge to a= n Ethernet port of a router, I need to specifically change the link propert= ies for only that one Ethernet interface on that one router. "Repeating" co= nfigurations doesn't make sense when active configuration is an exception. = I think the normal number of interfaces a *management system* will need to = configure is zero. When RTT is added as a link property, it too will be auto detected by the f= act the interface is a tunnel. [We may want to consider a global configurat= ion option to enable/disable detection of tunneled interfaces and use of RT= T -- for cases where RTT support is implemented -- to be defined in the RTT= draft.] When unicast becomes a property -- well, this is something that a network o= perator will probably expect to set independent of other "link properties".= It isn't really a link property, at all. [We may want a global configurati= on option for this, too, to indicate whether a new interface is set to defa= ult unicast or multicast -- but that's not for now.] Barbara From nobody Wed Aug 14 07:37: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 44F841208D5 for ; Wed, 14 Aug 2019 07:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsWroDbi0Bor for ; Wed, 14 Aug 2019 07:37:28 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078A4120043 for ; Wed, 14 Aug 2019 07:37:28 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x7EEVY2H036468; Wed, 14 Aug 2019 10:37:27 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 2uckwf0mr8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 10:37:26 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7EEbO4u031640; Wed, 14 Aug 2019 10:37:25 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7EEbH5L031354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Aug 2019 10:37:17 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 2B4C64009E67; Wed, 14 Aug 2019 14:37:17 +0000 (GMT) Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (unknown [130.8.218.153]) by zlp30487.vci.att.com (Service) with ESMTPS id 14CE14009E66; Wed, 14 Aug 2019 14:37:17 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0439.000; Wed, 14 Aug 2019 10:37:16 -0400 From: "STARK, BARBARA H" To: "'David Schinazi'" , "'Juliusz Chroboczek'" CC: "'babel@ietf.org'" Thread-Topic: [babel] HMAC: removed constraint on the key stored in interface table Thread-Index: AQHVUe2J94IZUlXvWUGht5ECY/kmSKb5V8HwgABYPID//8teAIAAaDuA//++YOCAAErlAP//wwPwAAkY/AAAAQL7AAAWFp0g Date: Wed, 14 Aug 2019 14:37:15 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E269246@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8736i5ul8p.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E26794B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87v9v0ucba.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267D1B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87r25ou3ri.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267FBE@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E2681C5@GAALPA1MSGUSRBF.ITServices.sbc.com> <87mugcu09v.wl-jch@irif.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.174.18.88] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114E269246GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-14_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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908140149 Archived-At: Subject: Re: [babel] HMAC: removed constraint on the key stored in interface table 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: Wed, 14 Aug 2019 14:37:30 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114E269246GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gdW5jbGVhciDigJMgd2hpY2gg4oCcaW1wbGVtZW50YXRpb27igJ0gYXJlIHdlIHRhbGtp bmcgYWJvdXQ/IEEgYmFiZWwtbWFjIGltcGxlbWVudGF0aW9uIG9yIGEgZGF0YSBtb2RlbD8NCg0K SSBzdGlsbCB0aGluayBJIHdvdWxkIHByZWZlciBzb21ldGhpbmcgaW4gaW5mbyBtb2RlbCBsaWtl ICh0aGUgQ291cmllciBmb250IGlzIGV4aXN0aW5nIHRleHQpOg0KDQogICAgICBUaGUgdmFsdWUg b2YgdGhlIEhNQUMga2V5LiAgQW4gaW1wbGVtZW50YXRpb24gTVVTVA0KICAgICAgTk9UIGFsbG93 IHRoaXMgcGFyYW1ldGVyIHRvIGJlIHJlYWQuICBUaGlzIGNhbiBiZSBkb25lIGJ5IGFsd2F5cw0K ICAgICAgcHJvdmlkaW5nIGFuIGVtcHR5IHN0cmluZyB3aGVuIHJlYWQsIG9yIHRocm91Z2ggcGVy bWlzc2lvbnMsIG9yIG90aGVyIG1lYW5zLg0KICAgICAgVGhpcyB2YWx1ZSBNVVNUIGJlIHByb3Zp ZGVkIHdoZW4gdGhpcyBpbnN0YW5jZSBpcyBjcmVhdGVkLCBhbmQgaXMNCiAgICAgIG5vdCBzdWJz ZXF1ZW50bHkgd3JpdGFibGUuIFRoZSBrZXkgbGVuZ3RoIE1VU1QgYmUgdGhlIG1heGltdW0gbGVu Z3RoIHRoYXQgaXMNCiAgICAgICAgICAgICAgZGVmaW5lZCBmb3IgdGhlIGFzc29jaWF0ZWQgYmFi ZWwtbWFjLWtleS1hbGdvcml0aG0sIHNvIHRoZXJlIGlzIG5vIG5lZWQgZm9yIHRoZSBNQUMgYWxn b3JpdGhtIHRvIHplcm8tcGFkLA0KICAgICAgICAgICAgICB0cnVuY2F0ZSwgb3Igb3RoZXJ3aXNl IG1hbmlwdWxhdGUgdGhlIGtleSBwcmlvciB0byB1c2UuIEZvciBITUFDLVNIQTI1NiwgdGhpcyBp cyBkZWZpbmVkDQogICAgICAgICAgICAgIGluIFJGQzQ4NjggYXMgNjQgYnl0ZXMuIEZvciBCbGFr ZTJzLCB0aGlzIGlzIGRlZmluZWQgaW4gUkZDNzY5MyBhcyAzMiBieXRlcy4gSWYga2V5cyBhcmUN CiAgICAgICAgICAgICAgZ2VuZXJhdGVkIGZyb20gdXNlciBpbnB1dCwgdGhlIHVzZXIgaW50ZXJm YWNlIG9yIG1hbmFnZW1lbnQgc3lzdGVtIGlzIGV4cGVjdGVkIHRvDQogICAgICAgICAgICAgIHpl cm8tcGFkIHN0cmluZ3MgdGhhdCBhcmUgbGVzcyB0aGFuIHRoZSByZXF1aXJlZCBsZW5ndGgsIGFu ZCBwcm9oaWJpdCBzdHJpbmdzIGxvbmdlciB0aGFuDQogICAgICAgICAgICAgIHRoZSByZXF1aXJl ZCBsZW5ndGguIFRoaXMgZW5zdXJlcyB0aGUgZGVsaXZlcmVkIHN0cmluZyBpcyBleGFjdGx5IHRo ZSByZXF1aXJlZCBudW1iZXIgb2YgYnl0ZXMuDQoNCkkgcmVhbGx5IGRpc2xpa2UgU0hPVUxEcyBh bmQgd2lnZ2xlIHJvb20gaW4gdGhpbmdzIGxpa2UgdGhpcyB0aGF0IGNhbiBjYXVzZSBhIGNvbXBs ZXRlIGJyZWFrZG93biBvZiBpbnRlcm9wZXJhYmlsaXR5LiBIYXNoaW5nIGlzIGFuIGFyZWEgd2hl cmUgaXTigJlzIHZlcnkgZWFzeSB0byBhY2hpZXZlIG5vbi1pbnRlcm9wZXJhYmlsaXR5Lg0KQmFy YmFyYQ0KDQpGcm9tOiBEYXZpZCBTY2hpbmF6aSA8ZHNjaGluYXppLmlldGZAZ21haWwuY29tPg0K DQpASnVsaXVzejogUmV2aXNlZCBzdGF0ZW1lbnQsIG5vdyB3aXRoIDMwJSBtb3JlIHRoaW5raW5n IG9mIHRoZSBjaGlsZHJlbjoNCg0KKG9ubHkgYWRkZWQgc2Vjb25kIG5vcm1hdGl2ZSBzdGF0ZW1l bnQpDQoNCi0gS2V5cyB1c2VkIGZvciBCYWJlbC1NQUMgTVVTVCBiZSBvZiBhIGxlbmd0aCBzdWl0 YWJsZSBmb3IgdGhhdCBNQUMgZnVuY3Rpb24uDQotIEltcGxlbWVudGF0aW9ucyBNVVNUIGFjY2Vw dCBhbGwga2V5IGxlbmd0aHMgdGhhdCBhcmUgc3VpdGFibGUgZm9yIHRoZSBzZWxlY3RlZCBNQUMg ZnVuY3Rpb24sIGFzIGRlZmluZWQgYnkgdGhlIHNwZWNpZmljYXRpb24gb2YgdGhhdCBNQUMgZnVu Y3Rpb24uDQotIEltcGxlbWVudGF0aW9ucyBNVVNUIHJlamVjdCBrZXlzIHRoYXQgYXJlIG5vdCBz dWl0YWJsZSBmb3IgdGhlIE1BQyBmdW5jdGlvbjsgaW4gb3RoZXIgd29yZHMsIGltcGxlbWVudGF0 aW9ucyBNVVNUIE5PVCBwcmVwcm9jZXNzIGtleXMgb2YgdW5zdWl0YWJsZSBsZW5ndGhzIHRvIHBy b2R1Y2UgYSBrZXkgb2Ygc3VpdGFibGUgbGVuZ3RoLg0KLSBCYWJlbCBtYW5hZ2VtZW50IGludGVy ZmFjZXMgTVVTVCBOT1QgYWxsb3cgY29uZmlndXJpbmcga2V5cyBvZiBub24gc3VpdGFibGUgbGVu Z3Rocy4NCi0gS2V5cyBmb3IgSE1BQy1TSEEyNTYgU0hPVUxEIGJlIDY0IGJ5dGVzIGxvbmcsIGtl eXMgZm9yIEJsYWtlMnMgU0hPVUxEIGJlIDMyIGJ5dGVzIGxvbmcuDQoNCkBCYXJiYXJhOiBJJ20g bm90IGRpc2N1c3NpbmcgdGhlIHVzZXIgaW50ZXJmYWNlLCBvbmx5IHdoYXQgdGhlIGluZm9ybWF0 aW9uIG1vZGVsIGNhbiBkZWxpdmVyIHRvIHRoZSBCYWJlbCBpbXBsZW1lbnRhdGlvbg0KDQpPbiBU dWUsIEF1ZyAxMywgMjAxOSBhdCA0OjEzIFBNIEp1bGl1c3ogQ2hyb2JvY3playA8amNoQGlyaWYu ZnI8bWFpbHRvOmpjaEBpcmlmLmZyPj4gd3JvdGU6DQo+IFNlZSByZXNwb25zZSB0byBKdWxpdXN6 LiBUaGUgaW5mbyBtb2RlbCBpcyAqbm90KiBkZXNpZ25pbmcgYSB1c2VyIGludGVyZmFjZS4gSXQN Cj4gaXMgc3RhdGluZyB3aGF0IGl0IHdpbGwgKG9yIGlzIGFsbG93ZWQgdG8pIGRlbGl2ZXIgdG8g dGhlIGJhYmVsIGltcGxlbWVudGF0aW9uLg0KPiBXaGF0IGhhcHBlbnMgdG8gZ2VuZXJhdGUgdGhl IGJ5dGVzIHRoYXQgZ2V0IGRlbGl2ZXJlZCB0byBiYWJlbCBieSB0aGUgaW5mbw0KPiBtb2RlbCBh cmUgb3V0c2lkZSB0aGUgY29udHJvbCBvZiB0aGUgaW5mbyBtb2RlbCAoc28gbm9ybWF0aXZlIGxh bmd1YWdlIGlzIG5vDQo+IGdvb2QpLiBUaG9zZSBwcm9wb3NlZCBTSE9VTEQgc3RhdGVtZW50cyBt ZWFuIHRoZSBpbmZvIG1vZGVsIHJlYWxseSBjYW4gZGVsaXZlcg0KPiBwcmV0dHkgbXVjaCBhbnkg c3RyaW5nIHRvIGEgYmFiZWwgaW1wbGVtZW50YXRpb24gYW5kIGV4cGVjdCBpbnRlcm9wZXJhYmxl DQo+IHJlc3VsdHMuDQoNCklmIEkgcmVhZCBCYXJiYXJhIHJpZ2h0Og0KDQogIC0gYWRtaW5pc3Ry YXRvciB3cml0ZXMgYSBzY3JpcHQgdGhhdCBjb25maWd1cmVzIGhpcyAxMDAwMCByb3V0ZXJzIHRo ZSB3YXkNCiAgICBoZSBsaWtlcyBpdDsNCiAgLSBhZG1pbmlzdHJhdG9yIGJ1eXMgYSBuZXcgcm91 dGVyIHRoYXQgaW50ZXJwcmV0cyB0aGUgZGF0YSBtb2RlbCBkaWZmZXJlbnRseTsNCiAgLSBzY3Jp cHQgYnJlYWtzIGJlY2F1c2UgdGhlIG5ldyByb3V0ZXIgcmVxdWlyZXMgZXhhY3RseSA2NCBieXRl cyBpbiBhIGtleTsNCiAgLSBhZG1pbmlzdHJhdG9yIHNwZW5kcyB0aGUgd2Vla2VuZCBmaXhpbmcg aGlzIG5ldHdvcmsgcmF0aGVyIHRoYW4gZ29pbmcNCiAgICBoaWtpbmcgd2l0aCBoaXMgY2hpbGRy ZW4gYXMgaGUgcHJvbWlzZWQuDQoNClRoaW5rIG9mIHRoZSBjaGlsZHJlbiwgRGF2aWQuDQoNCi0t IEp1bGl1c3oNCg== --_000_2D09D61DDFA73D4C884805CC7865E6114E269246GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNv UGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PknigJltIHVuY2xlYXIg4oCTIHdoaWNoIOKAnGltcGxlbWVudGF0aW9u4oCdIGFyZSB3ZSB0YWxr aW5nIGFib3V0PyBBIGJhYmVsLW1hYyBpbXBsZW1lbnRhdGlvbiBvciBhIGRhdGEgbW9kZWw/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc3RpbGwgdGhpbmsgSSB3b3VsZCBwcmVmZXIgc29tZXRo aW5nIGluIGluZm8gbW9kZWwgbGlrZSAodGhlIENvdXJpZXIgZm9udCBpcyBleGlzdGluZyB0ZXh0 KTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBUaGUgdmFsdWUgb2YgdGhlIEhNQUMga2V5LiZuYnNwOyBBbiBpbXBsZW1lbnRh dGlvbiBNVVNUPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOT1QgYWxsb3cgdGhpcyBwYXJh bWV0ZXIgdG8gYmUgcmVhZC4mbmJzcDsgVGhpcyBjYW4gYmUgZG9uZSBieSBhbHdheXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByb3ZpZGluZyBhbiBlbXB0eSBzdHJpbmcgd2hlbiByZWFk LCBvciB0aHJvdWdoIHBlcm1pc3Npb25zLCBvciBvdGhlciBtZWFucy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFRoaXMgdmFsdWUgTVVTVCBiZSBwcm92aWRlZCB3aGVuIHRoaXMgaW5zdGFu Y2UgaXMgY3JlYXRlZCwgYW5kIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBub3Qgc3Vi c2VxdWVudGx5IHdyaXRhYmxlLg0KPC9zcGFuPlRoZSBrZXkgbGVuZ3RoIE1VU1QgYmUgdGhlIG1h eGltdW0gbGVuZ3RoIHRoYXQgaXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZWZpbmVkIGZvciB0aGUgYXNzb2NpYXRlZCBiYWJlbC1t YWMta2V5LWFsZ29yaXRobSwgc28gdGhlcmUgaXMgbm8gbmVlZCBmb3IgdGhlIE1BQyBhbGdvcml0 aG0gdG8gemVyby1wYWQsDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RydW5jYXRlLCBvciBvdGhlcndpc2UgbWFuaXB1bGF0 ZSB0aGUga2V5IHByaW9yIHRvIHVzZS4gRm9yIEhNQUMtU0hBMjU2LCB0aGlzIGlzIGRlZmluZWQN CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7aW4gUkZDNDg2OCBhcyA2NCBieXRlcy4gRm9yIEJsYWtlMnMsIHRoaXMgaXMgZGVm aW5lZCBpbiBSRkM3NjkzIGFzIDMyIGJ5dGVzLiBJZiBrZXlzIGFyZTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO2dlbmVyYXRlZCBmcm9t IHVzZXIgaW5wdXQsIHRoZSB1c2VyIGludGVyZmFjZSBvciBtYW5hZ2VtZW50IHN5c3RlbSBpcyBl eHBlY3RlZCB0bzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZuYnNwO3plcm8tcGFkIHN0cmluZ3MgdGhhdCBhcmUgbGVzcyB0aGFuIHRoZSByZXF1 aXJlZCBsZW5ndGgsIGFuZCBwcm9oaWJpdCBzdHJpbmdzIGxvbmdlciB0aGFuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7dGhlIHJlcXVp cmVkIGxlbmd0aC4gVGhpcyBlbnN1cmVzIHRoZSBkZWxpdmVyZWQgc3RyaW5nIGlzIGV4YWN0bHkg dGhlIHJlcXVpcmVkIG51bWJlciBvZiBieXRlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBy ZWFsbHkgZGlzbGlrZSBTSE9VTERzIGFuZCB3aWdnbGUgcm9vbSBpbiB0aGluZ3MgbGlrZSB0aGlz IHRoYXQgY2FuIGNhdXNlIGEgY29tcGxldGUgYnJlYWtkb3duIG9mIGludGVyb3BlcmFiaWxpdHku IEhhc2hpbmcgaXMgYW4gYXJlYSB3aGVyZSBpdOKAmXMgdmVyeSBlYXN5IHRvIGFjaGlldmUgbm9u LWludGVyb3BlcmFiaWxpdHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5C YXJiYXJhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj5Gcm9tOjwvYj4gRGF2aWQgU2NoaW5hemkgJmx0O2RzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbSZn dDsgPGJyPg0KPGJyPg0KPC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkBKdWxpdXN6 OiBSZXZpc2VkIHN0YXRlbWVudCwgbm93IHdpdGggMzAlIG1vcmUgdGhpbmtpbmcgb2YgdGhlIGNo aWxkcmVuOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KG9u bHkgYWRkZWQgc2Vjb25kIG5vcm1hdGl2ZSBzdGF0ZW1lbnQpPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBLZXlzIHVzZWQgZm9yIEJhYmVsLU1B QyBNVVNUIGJlIG9mIGEgbGVuZ3RoIHN1aXRhYmxlIGZvciB0aGF0IE1BQyBmdW5jdGlvbi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gSW1wbGVt ZW50YXRpb25zIE1VU1QgYWNjZXB0IGFsbCBrZXkgbGVuZ3RocyB0aGF0IGFyZSBzdWl0YWJsZSBm b3IgdGhlIHNlbGVjdGVkIE1BQyBmdW5jdGlvbiwgYXMgZGVmaW5lZCBieSB0aGUgc3BlY2lmaWNh dGlvbiBvZiB0aGF0IE1BQyBmdW5jdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gSW1wbGVtZW50YXRpb25zIE1VU1QgcmVqZWN0IGtleXMg dGhhdCBhcmUgbm90IHN1aXRhYmxlIGZvciB0aGUgTUFDIGZ1bmN0aW9uOyBpbiBvdGhlciB3b3Jk cywgaW1wbGVtZW50YXRpb25zIE1VU1QgTk9UIHByZXByb2Nlc3Mga2V5cyBvZiB1bnN1aXRhYmxl IGxlbmd0aHMgdG8gcHJvZHVjZSBhIGtleSBvZiBzdWl0YWJsZSBsZW5ndGguPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIEJhYmVsIG1hbmFnZW1l bnQgaW50ZXJmYWNlcyBNVVNUIE5PVCBhbGxvdyBjb25maWd1cmluZyBrZXlzIG9mIG5vbiBzdWl0 YWJsZSBsZW5ndGhzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LSBLZXlzIGZvciZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Nv bG9yOmJsYWNrIj5ITUFDLVNIQTI1NiBTSE9VTEQgYmUgNjQgYnl0ZXMgbG9uZywga2V5cyBmb3Im bmJzcDs8L3NwYW4+Qmxha2UycyBTSE9VTEQgYmUgMzIgYnl0ZXMgbG9uZy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QEJhcmJhcmE6IEknbSBu b3QgZGlzY3Vzc2luZyB0aGUgdXNlciBpbnRlcmZhY2UsIG9ubHkgd2hhdCB0aGUgaW5mb3JtYXRp b24gbW9kZWwgY2FuIGRlbGl2ZXIgdG8gdGhlIEJhYmVsIGltcGxlbWVudGF0aW9uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUdWUsIEF1ZyAxMywgMjAxOSBhdCA0OjEzIFBNIEp1bGl1c3ogQ2hyb2JvY3playAm bHQ7PGEgaHJlZj0ibWFpbHRvOmpjaEBpcmlmLmZyIiB0YXJnZXQ9Il9ibGFuayI+amNoQGlyaWYu ZnI8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jmd0OyBTZWUg cmVzcG9uc2UgdG8gSnVsaXVzei4gVGhlIGluZm8gbW9kZWwgaXMgKm5vdCogZGVzaWduaW5nIGEg dXNlciBpbnRlcmZhY2UuIEl0PGJyPg0KJmd0OyBpcyBzdGF0aW5nIHdoYXQgaXQgd2lsbCAob3Ig aXMgYWxsb3dlZCB0bykgZGVsaXZlciB0byB0aGUgYmFiZWwgaW1wbGVtZW50YXRpb24uPGJyPg0K Jmd0OyBXaGF0IGhhcHBlbnMgdG8gZ2VuZXJhdGUgdGhlIGJ5dGVzIHRoYXQgZ2V0IGRlbGl2ZXJl ZCB0byBiYWJlbCBieSB0aGUgaW5mbzxicj4NCiZndDsgbW9kZWwgYXJlIG91dHNpZGUgdGhlIGNv bnRyb2wgb2YgdGhlIGluZm8gbW9kZWwgKHNvIG5vcm1hdGl2ZSBsYW5ndWFnZSBpcyBubzxicj4N CiZndDsgZ29vZCkuIFRob3NlIHByb3Bvc2VkIFNIT1VMRCBzdGF0ZW1lbnRzIG1lYW4gdGhlIGlu Zm8gbW9kZWwgcmVhbGx5IGNhbiBkZWxpdmVyPGJyPg0KJmd0OyBwcmV0dHkgbXVjaCBhbnkgc3Ry aW5nIHRvIGEgYmFiZWwgaW1wbGVtZW50YXRpb24gYW5kIGV4cGVjdCBpbnRlcm9wZXJhYmxlPGJy Pg0KJmd0OyByZXN1bHRzLjxicj4NCjxicj4NCklmIEkgcmVhZCBCYXJiYXJhIHJpZ2h0Ojxicj4N Cjxicj4NCiZuYnNwOyAtIGFkbWluaXN0cmF0b3Igd3JpdGVzIGEgc2NyaXB0IHRoYXQgY29uZmln dXJlcyBoaXMgMTAwMDAgcm91dGVycyB0aGUgd2F5PGJyPg0KJm5ic3A7ICZuYnNwOyBoZSBsaWtl cyBpdDs8YnI+DQombmJzcDsgLSBhZG1pbmlzdHJhdG9yIGJ1eXMgYSBuZXcgcm91dGVyIHRoYXQg aW50ZXJwcmV0cyB0aGUgZGF0YSBtb2RlbCBkaWZmZXJlbnRseTs8YnI+DQombmJzcDsgLSBzY3Jp cHQgYnJlYWtzIGJlY2F1c2UgdGhlIG5ldyByb3V0ZXIgcmVxdWlyZXMgZXhhY3RseSA2NCBieXRl cyBpbiBhIGtleTs8YnI+DQombmJzcDsgLSBhZG1pbmlzdHJhdG9yIHNwZW5kcyB0aGUgd2Vla2Vu ZCBmaXhpbmcgaGlzIG5ldHdvcmsgcmF0aGVyIHRoYW4gZ29pbmc8YnI+DQombmJzcDsgJm5ic3A7 IGhpa2luZyB3aXRoIGhpcyBjaGlsZHJlbiBhcyBoZSBwcm9taXNlZC48YnI+DQo8YnI+DQpUaGlu ayBvZiB0aGUgY2hpbGRyZW4sIERhdmlkLjxicj4NCjxicj4NCi0tIEp1bGl1c3o8bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_2D09D61DDFA73D4C884805CC7865E6114E269246GAALPA1MSGUSRBF_-- From nobody Wed Aug 14 07:52:44 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 AA58E120922; Wed, 14 Aug 2019 07:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDmL9rXgccTv; Wed, 14 Aug 2019 07:52:32 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 6406012091D; Wed, 14 Aug 2019 07:52:32 -0700 (PDT) Received: from [129.192.10.3] (helo=[10.149.1.218]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hxudW-0001cK-S3; Wed, 14 Aug 2019 16:52:26 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <87mugjo9wa.wl-jch@irif.fr> Date: Wed, 14 Aug 2019 16:52:25 +0200 Cc: babel-chairs , Babel at IETF , Donald Eastlake , The IESG , David Schinazi , draft-ietf-babel-dtls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <13919FCC-9655-4B31-BC87-D33C963C82C4@kuehlewind.net> References: <156518163926.8337.14198016212015161206.idtracker@ietfa.amsl.com> <87a7cjq53f.wl-jch@irif.fr> <110AD4FB-186C-4C87-8BAF-7D8F4A04BC6F@kuehlewind.net> <87mugjo9wa.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1565794352;becd471c; X-HE-SMSGID: 1hxudW-0001cK-S3 Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-dtls-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Wed, 14 Aug 2019 14:52:35 -0000 Hi Juliusz, hi David, (Only replying to this mail because it, I think, also covers a reply to = David=E2=80=99s last mail.) Thanks for the detailed explanation. I believe the underlying problem is = that in this approach the Hello is not authenticated. However, I = understand that changing this part, even though it could be desirable, = is much more complex and using a fixed port might indeed be the simplest = solution right now. I will clear my discuss now, however, I would after all appreciate to = have more documentation in the draft why this solution was select and, = more important, what limitations other approach have. Mirja > On 8. Aug 2019, at 19:16, Juliusz Chroboczek wrote: >=20 >>> Could you please explain what happens if an attacker sends out 65535 >>> spoofed multicast Hellos indicating 65535 distinct ports? >=20 >> You maybe rate limit DTLS connection attempts=E2=80=A6? >=20 > That's not the issue I had in mind. What I'm concerned about is that > you're suggesting to use an unauthentifed TLV to negotiate DTLS = connection > parameters. That cannot go well. >=20 > Let A and B be honest nodes, and C an attacker. In the current = protocol: >=20 > A -> multicast: Hello > C spoofing A -> multicast: Hello > B -> A(well-known port): DTLS ClientHello >=20 > The DTLS connection succeeds even though C spoofed a Hello from A -- > a Hello is a Hello, even if it was spoofed. In your suggested = protocol: >=20 > A -> multicast: Hello, port=3D1234 > C spoofing A -> multicast: Hello, port =3D 1235 > C spoofing A -> multicast: Hello, port =3D 1236 > C spoofing A -> multicast: Hello, port =3D 1237 > ... > B -> A(which port?) >=20 > Since B has received a bunch of Hellos ostensiby from A announcing > different ports, it cannot reliably locate the one that's correct. An > on-link attacker can trivially DoS any node of its choosing. >=20 > What is more: >=20 > - You can no longer identify Babel traffic -- it's just encrypted = DTLS > with random ports. What does that mean from a management point of = view? >=20 > - An attacker can cause any Babel node to send a DTLS ClientHello to = an > arbitrary IP and port. What consequences does that have for the > security and DoS-resistance of unrelated protocols? >=20 > Mirja, in the light of the above, you'll doubtless understand that we = feel > little motivation to spend time implementing your suggested protocol = and > experimenting with it. (And this working group has been following the > policy of implementing everythig and listening to implementation = experience, > a policy that we like and do not wish to change.) >=20 > -- Juliusz >=20 From nobody Wed Aug 14 07:54: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 465BF120850; Wed, 14 Aug 2019 07:54:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-babel-dtls@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <156579446827.30579.17393254825602662181.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2019 07:54:28 -0700 Archived-At: Subject: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-babel-dtls-09=3A_=28with_COMMENT=29?= 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: Wed, 14 Aug 2019 14:54:29 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-babel-dtls-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for discussing the port assignment (again)! From nobody Wed Aug 14 08:11: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 1154312023E; Wed, 14 Aug 2019 08:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQsOZ1dDdakp; Wed, 14 Aug 2019 08:11:01 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 4C5DA120871; Wed, 14 Aug 2019 08:11:01 -0700 (PDT) Received: from [129.192.10.3] (helo=[10.149.1.218]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hxuvQ-00053h-DG; Wed, 14 Aug 2019 17:10:56 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <877e7m8b88.wl-jch@irif.fr> Date: Wed, 14 Aug 2019 17:10:55 +0200 Cc: draft-ietf-babel-rfc6126bis@ietf.org, d3e3e3@gmail.com, babel-chairs@ietf.org, The IESG , babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1565795461;d7e73446; X-HE-SMSGID: 1hxuvQ-00053h-DG Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Wed, 14 Aug 2019 15:11:04 -0000 Hi Juliusz, Thanks for the work and relies. Please see inline.=20 > On 9. Aug 2019, at 20:06, Juliusz Chroboczek wrote: >=20 > Dear Mirja, >=20 > The replies in this mail concern -13, which I haven't submitted yet = (still > working on it). My working copy is on >=20 > https://github.com/jech/babel-drafts >=20 >> DISCUSS: >> = ---------------------------------------------------------------------- >=20 >> I have a couple of points that needs addressing before this document = can move >> forward. Most of them should the straight forward to address. My main = point is >> about network load. >=20 > I agree, that's an important point, especially when running over = 802.11. >=20 >> Note that RFC8085 recommend a minimal interval of 3 seconds which >> probably is also a good hard boundary here. >=20 > As mentioned in my previous mail, RFC 8085 deals with UDP packets sent > across the Internet. What we are discussing here is a link-local > protocol, where there are no intermediary routers to congest. Thus, = on > robust link technologies (such as Ethernet) it is enough to ensure = that we > don't overwhelm sender and receiver queues; on more fragile = technologies > (such as 802.11), we need to ensure we don't overwhelm the MAC. >=20 > In short, if the 3 second limitation is to be enforced, then OSPF = cannot exist. I really don=E2=80=99t want to request to enforce a 3 second limit. = However, I would like this draft to specify a limit or at minimum = discuss suitable values for specific scenario. I was just referencing to = the 3 second in absence of a better value, however, I=E2=80=99m sure you = know better what would make sense. >=20 >> More concretely I think there are these cases that need more = guidance: >=20 > I agree. I've added a short discussion of packet pacing at the end of > 3.1, and I refer to it at suitable places. Thanks. I was also hoping that you could make any recommendation on how = to implement that e.g. a fixed delay of a certain (default) value or = based on some other knowledge. If that is a SHOULD and no further = implementation example is given, I would be afraid that the risk is high = that people simple don=E2=80=99t implement this part. >=20 >> - Section 3.7.2. (Triggered Updates) advises to send a message = multiple >> times for redundancy in case of loss. 5 and 2 are mentioned as = example >> values. Please provide a normative default value and a normative = maximum >> value here. Moreover the spec should also require to pace out these >> messages and avoid "tail loss" by overloading the local queue. (See >> also section 3.8.2.1) >=20 > Done for the normative max and recommendation to avoid tail loss. > I haven't made the default values normative. Why not?=20 >=20 >> - Section 3.8.1.1. (Route Requests) says: "Full route dumps MAY be >> rate-limited, especially >> if they are sent over multicast." >> I think this should at least be a SHOULD. >=20 > Agreed. Good. >=20 >> Please also provide further guidance about to appropriately rate = limit >> and think about other cases where a recommend to implement = rate-limiting >> could make sense. >=20 > Done. Thanks! >=20 >> - In section 4.1.1 the update interval needs a lower limit (e.g. 3 = seconds) >=20 > I strongly disagree. Sub-second convergence after a mobility event is > required in some networks. >=20 > To put things into perspective, a full-size Ethernet frame is able to > carry over 60 Babel updates (assuming 50% IPv4 + 50% IPv6 and = reasonably > successful IPv6 prefix compression). Thus, in a network with 1000 = routes, > a full update occupies 16 packets. With an update interval of 0.1 > seconds, we are sending an average of 160 packets per second, which is > very reasonable for a number link technologies. (See above) Maybe then 0.1 seconds is a suitable minimum value=E2=80=A6? >=20 >> and a recommend default value would be could as well (Note that there >> are other part in section 3 where the update value is discussed as >> well). >=20 > Appendix B. I think this needs normative language in the body of the document. >=20 >> - Section 3.8.2.4. mentions network load when requests are sent to = all >> neighbours after reboot. Please provide more guidance about how to = pace out >> these requests. >=20 > I've removed this section altogether. Why? >=20 >> - Section 3.8.1.2. (Seqno Requests) discusses hop count values but >> could maybe also give more concrete guidance. I would assume that the >> hop count value of the current active route is usually know. Maybe = that >> knowledge could be used to pick an appropriate value? >=20 > The hop-count is a last resort mechanism intended to save your network > from catastrophic failure in case everything goes horribly wrong. It > never triggers in normal usage. >=20 > Any value will do. I've made that clear, and suggested the value 64 > (non-normatively). Okay. >=20 >> Two other smaller discuss points/questions/comments: >=20 >> 1) Sec 4.6.8. (Next Hop): If I interpret this correctly, address = compression is >> allowed for the next hop field and therefore this TLV would actually = not be >> self-terminating. What do I miss? >=20 > Address compression is only allowed in Update TLVs (the only = compression > mechanism allowed in NH is AE 3). I've clarified that. Okay. Thanks! >=20 >> 2) This document needs to specify a registration policy also for each = of the >> already existing registries given this document obsoletes RFC7557. >=20 > Ok. Great! >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >=20 >> 1) While this point might not raise discuss-level, it would probably = also be >> good to provide more concrete advise on how to implement jitter: Sec = 3.1.: =E2=80=9C =20 >=20 > Expanded this in 3.1. Removed from Section 4. Similar, as my comment on pacing, I=E2=80=99m wondering if you can be = even more concrete in order to make it easy for people to implement this = correctly.=20 >=20 >> 2) Sec 4.1.2. (Router-Id) should probably state again that the = router-id is >> assumed to be unique within a domain. >=20 > No, this section only defines the datatype, which is carried by = Router-ID > TLVs. It does not define the local Router-ID field, which is part of = the > data structures. Okay. Maybe just provide a pointer then? >=20 >> 3) Sec 4: =E2=80=9CThe most-significant bit of the sub-TLV, called = the mandatory bit, >> indicates how to handle unknown sub-TLVs.=E2=80=9D >=20 > This has been clarified. Thanks! >=20 >> I would recommend to also indicate this bit in the image. >=20 > The mandatory bit is part of the TLV Type (see the discussion with > Alvaro), this has been clarified. I am not aware of a way to describe > that in a packet diagram. Ah I entirely missed that. >=20 >> 4) Sec 4.4: =E2=80=9CIf a TLV has a self-terminating format, then it = MAY allow >> a sequence of sub-TLVs to follow the body.=E2=80=9D Initially I = wasn=E2=80=99t quite >> sure what you wanted to say here. I guess you say that the length = would >> indicate a larger value that needed for the body and therefore a = subTLV >> might be present? I recommend to clarify this here a bit. >=20 > Done. Great. Thanks! Mirja >=20 > Thanks, >=20 > -- Juliusz >=20 >=20 From nobody Wed Aug 14 08:35:33 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 DBDD512098C; Wed, 14 Aug 2019 08:35:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-babel-dtls@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156579693089.30514.17190847374691009855.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2019 08:35:30 -0700 Archived-At: Subject: [babel] Benjamin Kaduk's No Objection on draft-ietf-babel-dtls-09: (with COMMENT) 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: Wed, 14 Aug 2019 15:35:31 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-babel-dtls-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for resolving my Discuss points! From nobody Wed Aug 14 08:44: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 AEA00120130 for ; Wed, 14 Aug 2019 08:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbjt8SgGWbk5 for ; Wed, 14 Aug 2019 08:44:44 -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 230BE1200C1 for ; Wed, 14 Aug 2019 08:44:44 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7EFiNSm008758 for ; Wed, 14 Aug 2019 11:44:41 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 2ucmc2hj4k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 14 Aug 2019 11:44:41 -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 x7EFeaSo003890 for ; Wed, 14 Aug 2019 11:40:36 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7EFeXZt003792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 14 Aug 2019 11:40:33 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 1E8D04009E94 for ; Wed, 14 Aug 2019 15:40:33 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30486.vci.att.com (Service) with ESMTPS id 042E24009E87 for ; Wed, 14 Aug 2019 15:40:33 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0439.000; Wed, 14 Aug 2019 11:40:32 -0400 From: "STARK, BARBARA H" To: "'babel@ietf.org'" Thread-Topic: info-model: preparing -09 on github Thread-Index: AdVSswKr0W4Y1vOsQfS00DtIY7BoYg== Date: Wed, 14 Aug 2019 15:40:31 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.174.18.88] 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-08-14_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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908140153 Archived-At: Subject: [babel] info-model: preparing -09 on github 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: Wed, 14 Aug 2019 15:44:46 -0000 I've got a preview of the upcoming -09 version on my github. https://github.com/bhstark2/babel-information-model The README there has links to the current editor's copy at https://bhstark2.github.io/babel-information-model/draft-ietf-babel-informa= tion-model.html and for a diff between this and -08 at http://tools.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/id/draft-ietf-ba= bel-information-model-08.txt&url2=3Dhttps://bhstark2.github.io/babel-inform= ation-model/draft-ietf-babel-information-model.txt It should have everything that I agreed to do so far, including the nits I = mentioned in request for last call, changes from the 2 initial emails Juliu= sz sent (what I agreed to change was in my response), and changing hmac to = mac in all but a couple of places (the doc reference right now is still to = babel-hmac, and "HMAC-SHA256" wasn't changed). I deleted all the issue and = change log stuff at the end. Things I haven't changed but where changes may still happen based on discus= sion... 1. link properties / metric-comp-algorithm / interface-metric-algorithm / s= plit-horizon: I'm leaning away from any new objects for link property group= ing. It may still be useful to provide additional info to help people under= stand the allowed values.* 2. babel-mac-key-value description to constrain it according to the babel-m= ac-key-algorithm allowed key length Barbara * Proposal was babel-metric-comp-algorithms: List of supported cost computation algorithms. Possible values include "2-out-of-3", and "ETX". "2-out-of-3" (a specific case of K-out-of-j ) link sensing is suitabl= e for wired links that are either up, in which case they only occasionally drop a packet, or down, in which case they drop all packets. "ETX" is a link-quality estimation= algorithm that is designed to work well with the IEEE 802.11 MAC. babel-interface-split-horizon: Indicates whether or not the split horizon optimization is used when calculating metrics on this interface. A value of true indicates split horizon optimization is used. Split horizon optimization is useful when running over a transitive, symmetric link technology, e.g., a point-to-point link or a wired LAN technology such as Ethernet.=20 It is not appropriate for links not known to be symmetric and transit= ive; in particular, split horizon is not appropriate for decentralized wireless link technologies (e.g., IEEE 802.11 in ad hoc mode) when routing updates are sent over multicast. --------------------------------------------- Alternate proposal (since above text was copied straight from rfc6126bis) babel-metric-comp-algorithms: List of supported cost computation algorithms. Possible values include "2-out-of-3", and "ETX". "2-out-of-3" is a specific case of K-out-of-j described in [rfc6126bi= s] A.2.1. "ETX" is described in [rfc6126bis] A.2.2. babel-interface-split-horizon: Indicates whether or not the split horizon optimization is used when calculating metrics on this interface. A value of true indicates split horizon optimization is used. Split horizon optimization is described in [rfc6126bis] 3.7.= 4. From nobody Wed Aug 14 09:51:38 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 A087A120BAD; Wed, 14 Aug 2019 09:51:28 -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 pPZ-kci1wtt3; Wed, 14 Aug 2019 09:51:25 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D878F120B9F; Wed, 14 Aug 2019 09:51:24 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7EGpJAL011255; Wed, 14 Aug 2019 18:51:19 +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 72764475E8; Wed, 14 Aug 2019 18:51:22 +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 mj9F58e8LnRT; Wed, 14 Aug 2019 18:51:21 +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 72376475E3; Wed, 14 Aug 2019 18:51:20 +0200 (CEST) Date: Wed, 14 Aug 2019 18:51:19 +0200 Message-ID: <87imqzu1vc.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mirja Kuehlewind Cc: draft-ietf-babel-rfc6126bis@ietf.org, d3e3e3@gmail.com, babel-chairs@ietf.org, The IESG , babel@ietf.org In-Reply-To: <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> User-Agent: Wanderlust/2.15.9y 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]); Wed, 14 Aug 2019 18:51:19 +0200 (CEST) X-Miltered: at korolev with ID 5D543C07.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D543C07.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 : 5D543C07.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] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Wed, 14 Aug 2019 16:51:29 -0000 > I really don’t want to request to enforce a 3 second limit. However, > I would like this draft to specify a limit or at minimum discuss > suitable values for specific scenario. Appendix B specifies values that were found to be useful in etwo kinds of realistic scenarios. The protocol structurally enforces minimum values of 10ms (time intervals are carried on the wire in units of 10ms). Values that small are not unrealistic over gigabit Ethernet (a full-size frame over GBE is sent in 12µs). >>> More concretely I think there are these cases that need more guidance: >> >> I agree. I've added a short discussion of packet pacing at the end of >> 3.1, and I refer to it at suitable places. > Thanks. I was also hoping that you could make any recommendation on how > to implement that e.g. a fixed delay of a certain (default) value or > based on some other knowledge. If that is a SHOULD and no further > implementation example is given, I would be afraid that the risk is high > that people simple don’t implement this part. You do realise it's a very high bar you're setting? There exist standard techniques for packet pacing (static delay, dynamic delay, deadline-first scheduling, etc.). I hope you're not requesting that I transform this document in a tutorial about packet scheduling. I'll point out that RFC 5340 does not explain how to pace Dijkstra recomputation. There's a good discussion of the issue in Gredler's book about IS-IS. I have no idea whether Gredler's book reflects the behaviour of modern implementations. >>> - Section 3.7.2. (Triggered Updates) advises to send a message multiple >>> times for redundancy in case of loss. 5 and 2 are mentioned as example >>> values. Please provide a normative default value and a normative maximum >>> value here. >> Done for the normative max and recommendation to avoid tail loss. >> I haven't made the default values normative. > Why not? What exact problem are we trying to solve here? Do you expect that the current non-normative language will cause issues? >>> - In section 4.1.1 the update interval needs a lower limit (e.g. 3 seconds) >> >> I strongly disagree. Sub-second convergence after a mobility event is >> required in some networks. > (See above) Maybe then 0.1 seconds is a suitable minimum value…? As mentioned above, the protocol structurally imposes a lower bound of 10ms, which is not unrealistic over GBE. >>> and a recommend default value would be could as well (Note that there >>> are other part in section 3 where the update value is discussed as well). >> Appendix B. > I think this needs normative language in the body of the document. I'm sorry, Mirja, I disagree. See my comments about GBE above. >>> - Section 3.8.2.4. mentions network load when requests are sent to all >>> neighbours after reboot. Please provide more guidance about how to pace out >>> these requests. >> I've removed this section altogether. > Why? The mechanism is not essential, and we're unable to give more precise guidance that applies across a wide range of networks. I prefer to remove the mechanism rather than give bad advice. -- Juliusz From nobody Wed Aug 14 10:10:21 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 BF585120BFE; Wed, 14 Aug 2019 10:10: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 zJ7LPv-5aW-X; Wed, 14 Aug 2019 10:10: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 2342F120BFC; Wed, 14 Aug 2019 10:10:11 -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 x7EHA7R2016155; Wed, 14 Aug 2019 19:10: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 11211476E6; Wed, 14 Aug 2019 19:10:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id MQRP3imYgSGH; Wed, 14 Aug 2019 19:10:09 +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 61C93476E4; Wed, 14 Aug 2019 19:10:06 +0200 (CEST) Date: Wed, 14 Aug 2019 19:10:06 +0200 Message-ID: <87h86ju101.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mirja Kuehlewind Cc: babel-chairs , Babel at IETF , Donald Eastlake , The IESG , David Schinazi , draft-ietf-babel-dtls@ietf.org In-Reply-To: <13919FCC-9655-4B31-BC87-D33C963C82C4@kuehlewind.net> References: <156518163926.8337.14198016212015161206.idtracker@ietfa.amsl.com> <87a7cjq53f.wl-jch@irif.fr> <110AD4FB-186C-4C87-8BAF-7D8F4A04BC6F@kuehlewind.net> <87mugjo9wa.wl-jch@irif.fr> <13919FCC-9655-4B31-BC87-D33C963C82C4@kuehlewind.net> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 14 Aug 2019 19:10:07 +0200 (CEST) X-Miltered: at korolev with ID 5D54406F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D54406F.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 : 5D54406F.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] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-babel-dtls-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Wed, 14 Aug 2019 17:10:14 -0000 > Thanks for the detailed explanation. I believe the underlying problem is > that in this approach the Hello is not authenticated. Exactly. One of the important properties of this protocol is that it uses a previously standardised protocol (DTLS) for all crypto work. David feels that is important. Since the IETF has not standardised any general-purpose security mechanism that is suitable for protecting multicast traffic, we're stuck. (This is not a criticism of DTLS, which has a well-defined scope. This might or might not be a criticism of a now-concluded high-profile IETF WG.) -- Juliusz From nobody Wed Aug 14 10:15:59 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 4DD65120C1A for ; Wed, 14 Aug 2019 10:15:58 -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 TNAMszPwhcA0 for ; Wed, 14 Aug 2019 10:15:56 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27678120C18 for ; Wed, 14 Aug 2019 10:15:56 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id t3so16967168ljj.12 for ; Wed, 14 Aug 2019 10:15:56 -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=gb7OI+rbIkDwjLJXT2HvR2wtVAuOlEmkTX8b9QNtW2s=; b=lefz9bG61Xmj7ZA4nwUjreDHRcw7iKOrdHKPomF7QauUijmBnaiaok+huv1tig2rTE D98RJDh9DRyb9fJFhai4qeMKGLxUZbJoPmjtVaUYfNt0GnJlStN+TRrhnyReeXOJ2k7V BflJ7nfYwSo2sZJ3ryqmm2j36OZlTm68wRhPDy2A/zcchVWU7ZLGKSZ+BUsFk63KWqbo t9tpIvA5pbb0V9r6sjc67tFSL0EJhPKKs+9eS3b2kaJtCbZZv+fxPWu8/qJaSbc3iGBR 6gxNf/xx0uTRuTCoiiT4zRcrZZcjXUvVsBR4Pl5tsOQhpHVFYk2G1tLacYGGfsEGosqH 85OQ== 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=gb7OI+rbIkDwjLJXT2HvR2wtVAuOlEmkTX8b9QNtW2s=; b=av2TJQH6zQFRqPHYHfoYj/e0gIexJ84SoSbBghk6wrwu+/jllqVzVoQYEsIx60nLr6 CjWwQmjoJ3RFr/SDm1GTcPfzGY/Hd7VdgQsSfYTtFmUtnbus8c9Efz5VeriKoJ83p8Bm xZwAslQdHA/iCw0k9VEkhyIKD4w+vkNoIJbpo2UuQNZ+O+NIqwpWL9OX9gnhbbqJy4bq YftDNgYtQWb4R9QLY6SGjQ6wRm0BhJY+Og8Gb0FkGf4ubgvUm0LQO59zrCLZuNmel1Q2 IopVxTyuVMgQapzTvubRcJcKqABKe8PARusqkb5iKgLPMEMjn5fH6FVrk9n77duhFMOB +Amw== X-Gm-Message-State: APjAAAWU3sDew12coVv0M+VubR6M3gdxpabSSzU3VSmegUPcjjt0nNhb Qf5FFzg/Eha5yYKZd1cPnku3LKsbSRxsRjgtmHw= X-Google-Smtp-Source: APXvYqwgb0KYgPFS5xiMXN8A3iWi/7Yke1wVTjlh+mWoPIdR8liXMyIRrZctCMviu9pvyCvzQLbF/CFKcncfTkPmz/I= X-Received: by 2002:a2e:96d5:: with SMTP id d21mr454237ljj.170.1565802954287; Wed, 14 Aug 2019 10:15:54 -0700 (PDT) MIME-Version: 1.0 References: <8736i5ul8p.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E26794B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87v9v0ucba.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267D1B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87r25ou3ri.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267FBE@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E2681C5@GAALPA1MSGUSRBF.ITServices.sbc.com> <87mugcu09v.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269246@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E269246@GAALPA1MSGUSRBF.ITServices.sbc.com> From: David Schinazi Date: Wed, 14 Aug 2019 10:15:43 -0700 Message-ID: To: "STARK, BARBARA H" Cc: Juliusz Chroboczek , "babel@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e0ed12059016e8ab" Archived-At: Subject: Re: [babel] HMAC: removed constraint on the key stored in interface table 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: Wed, 14 Aug 2019 17:15:58 -0000 --000000000000e0ed12059016e8ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Barbara! I meant Babel-MAC implementations. Can you describe which wiggle room exists? If you use different sized keys you'll get interop failure, just like if you use different keys of the same length. David On Wed, Aug 14, 2019 at 7:37 AM STARK, BARBARA H wrote: > I=E2=80=99m unclear =E2=80=93 which =E2=80=9Cimplementation=E2=80=9D are = we talking about? A babel-mac > implementation or a data model? > > > > I still think I would prefer something in info model like (the Courier > font is existing text): > > > > The value of the HMAC key. An implementation MUST > > NOT allow this parameter to be read. This can be done by always > > providing an empty string when read, or through permissions, or > other means. > > This value MUST be provided when this instance is created, and is > > not subsequently writable. The key length MUST be the maximum > length that is > > defined for the associated babel-mac-key-algorithm, so ther= e > is no need for the MAC algorithm to zero-pad, > > truncate, or otherwise manipulate the key prior to use. For > HMAC-SHA256, this is defined > > in RFC4868 as 64 bytes. For Blake2s, this is defined in > RFC7693 as 32 bytes. If keys are > > generated from user input, the user interface or management > system is expected to > > zero-pad strings that are less than the required length, an= d > prohibit strings longer than > > the required length. This ensures the delivered string is > exactly the required number of bytes. > > > > I really dislike SHOULDs and wiggle room in things like this that can > cause a complete breakdown of interoperability. Hashing is an area where > it=E2=80=99s very easy to achieve non-interoperability. > > Barbara > > > > *From:* David Schinazi > > @Juliusz: Revised statement, now with 30% more thinking of the children: > > > > (only added second normative statement) > > > > - Keys used for Babel-MAC MUST be of a length suitable for that MAC > function. > > - Implementations MUST accept all key lengths that are suitable for the > selected MAC function, as defined by the specification of that MAC functi= on. > > - Implementations MUST reject keys that are not suitable for the MAC > function; in other words, implementations MUST NOT preprocess keys of > unsuitable lengths to produce a key of suitable length. > > - Babel management interfaces MUST NOT allow configuring keys of non > suitable lengths. > > - Keys for HMAC-SHA256 SHOULD be 64 bytes long, keys for Blake2s SHOULD > be 32 bytes long. > > > > @Barbara: I'm not discussing the user interface, only what the informatio= n > model can deliver to the Babel implementation > > > > On Tue, Aug 13, 2019 at 4:13 PM Juliusz Chroboczek wrote: > > > See response to Juliusz. The info model is *not* designing a user > interface. It > > is stating what it will (or is allowed to) deliver to the babel > implementation. > > What happens to generate the bytes that get delivered to babel by the > info > > model are outside the control of the info model (so normative language > is no > > good). Those proposed SHOULD statements mean the info model really can > deliver > > pretty much any string to a babel implementation and expect interoperab= le > > results. > > If I read Barbara right: > > - administrator writes a script that configures his 10000 routers the w= ay > he likes it; > - administrator buys a new router that interprets the data model > differently; > - script breaks because the new router requires exactly 64 bytes in a > key; > - administrator spends the weekend fixing his network rather than going > hiking with his children as he promised. > > Think of the children, David. > > -- Juliusz > > --000000000000e0ed12059016e8ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Barbara!

I meant Babe= l-MAC implementations.

Can you describe which wiggle ro= om exists? If you use different sized keys you'll get interop failure, = just like if you use different keys of the same length.

= David


On Wed, Aug 14, 2019 at 7:37 AM STARK, BARBAR= A H <bs7652@att.com<= /a>> wrote:

I=E2=80=99m unclear =E2=80=93 which =E2=80=9Cimpleme= ntation=E2=80=9D are we talking about? A babel-mac implementation or a data= model?

=C2=A0

I still think I would prefer something in info model= like (the Courier font is existing text):

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The value of the HMAC key.=C2= =A0 An implementation MUST

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NOT allow this parameter to b= e read.=C2=A0 This can be done by always

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 providing an empty string whe= n read, or through permissions, or other means.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This value MUST be provided w= hen this instance is created, and is

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 not subsequently writable. The key length MUST be the maximum length that is

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 defined for the associated babel-mac-key-algori= thm, so there is no need for the MAC algorithm to zero-pad,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0truncate, or otherwise manipulate the key = prior to use. For HMAC-SHA256, this is defined

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0in RFC4868 as 64 bytes. For Blake2s, this = is defined in RFC7693 as 32 bytes. If keys are

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0generated from user input, the user interface o= r management system is expected to

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0zero-pad strings that are less than the require= d length, and prohibit strings longer than

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0the required length. This ensures the delivered= string is exactly the required number of bytes.

=C2=A0

I really dislike SHOULDs and wiggle room in things l= ike this that can cause a complete breakdown of interoperability. Hashing i= s an area where it=E2=80=99s very easy to achieve non-interoperability.<= /u>

Barbara

=C2=A0

From: David Schinazi <dschinazi.ietf@gmail.com> =

@Juliusz: Revised statement, now with 30% more think= ing of the children:

=C2=A0

(only added second normative statement)

=C2=A0

- Keys used for Babel-MAC MUST be of a length suitab= le for that MAC function.

- Implementations MUST accept all key lengths that a= re suitable for the selected MAC function, as defined by the specification = of that MAC function.

- Implementations MUST reject keys that are not suit= able for the MAC function; in other words, implementations MUST NOT preproc= ess keys of unsuitable lengths to produce a key of suitable length.<= u>

- Babel management interfaces MUST NOT allow configu= ring keys of non suitable lengths.

- Keys for=C2=A0HMAC-SHA256 SHOULD be 64 bytes long, keys for=C2=A0Blake2s SH= OULD be 32 bytes long.

=C2=A0

@Barbara: I'm not discussing the user interface,= only what the information model can deliver to the Babel implementation=

=C2=A0

On Tue, Aug 13, 2019 at 4:13 PM Juliusz Chroboczek &= lt;jch@irif.fr> wro= te:

> See response to Ju= liusz. The info model is *not* designing a user interface. It
> is stating what it will (or is allowed to) deliver to the babel implem= entation.
> What happens to generate the bytes that get delivered to babel by the = info
> model are outside the control of the info model (so normative language= is no
> good). Those proposed SHOULD statements mean the info model really can= deliver
> pretty much any string to a babel implementation and expect interopera= ble
> results.

If I read Barbara right:

=C2=A0 - administrator writes a script that configures his 10000 routers th= e way
=C2=A0 =C2=A0 he likes it;
=C2=A0 - administrator buys a new router that interprets the data model dif= ferently;
=C2=A0 - script breaks because the new router requires exactly 64 bytes in = a key;
=C2=A0 - administrator spends the weekend fixing his network rather than go= ing
=C2=A0 =C2=A0 hiking with his children as he promised.

Think of the children, David.

-- Juliusz

--000000000000e0ed12059016e8ab-- From nobody Wed Aug 14 10:25:48 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 0D872120C4B for ; Wed, 14 Aug 2019 10:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8X1Kpi7lw8nS for ; Wed, 14 Aug 2019 10:25:44 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C80120C3E for ; Wed, 14 Aug 2019 10:25:43 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7EHPZC3019676; Wed, 14 Aug 2019 19:25:35 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A821F47A6D; Wed, 14 Aug 2019 19:25:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id t7hkZ_4HvTX9; Wed, 14 Aug 2019 19:25:37 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7440347A6B; Wed, 14 Aug 2019 19:25:37 +0200 (CEST) Date: Wed, 14 Aug 2019 19:25:37 +0200 Message-ID: <87ftm3u0a6.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'babel@ietf.org'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 14 Aug 2019 19:25:35 +0200 (CEST) X-Miltered: at korolev with ID 5D54440F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D54440F.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 : 5D54440F.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] info-model: preparing -09 on github 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: Wed, 14 Aug 2019 17:25:46 -0000 Thanks, Barbara. > http://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/id/draft-ietf-babel-information-model-08.txt&url2=https://bhstark2.github.io/babel-information-model/draft-ietf-babel-information-model.txt I didn't see anything wrong. (Nit: "an implementation attempting to comply", I suggest "that purports to comply". It sounds, like, really smart.) > 1. link properties / metric-comp-algorithm / interface-metric-algorithm > / split-horizon: I'm leaning away from any new objects for link property > grouping. I agree, pending further input. > 2. babel-mac-key-value description to constrain it according to the > babel-mac-key-algorithm allowed key length Here's my current proposal (pending further input): This value is of a length suitable for the associated babel-mac-key-algorithm. If algorithm is based on the HMAC construction, this value MUST be between 0 and the block size of the underlying hash inclusive (64 in the case of HMAC-SHA-256); if it is smaller, it is zero-extended before use as specified in Section 2 of RFC 2104. If the algorithm is Blake2s, then it MUST be between 0 and 32 inclusive, and is used as described in Section 3.3 of RFC 7693. -- Juliusz From nobody Wed Aug 14 10:30: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 98EDA120C70 for ; Wed, 14 Aug 2019 10:30:11 -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 Diej76rMRgcq for ; Wed, 14 Aug 2019 10:30:09 -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 C0B12120C60 for ; Wed, 14 Aug 2019 10:30:08 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1565803805; bh=DaRJs0PdZ8Qg8i9FbWnDZDLrGV7fGK6Sp8XHJN5L0yI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=dZKCEKeT5RWw6n/qgUpm7A1J9q0gEeyJTdqwUrS2tKQqyuai3AzGNupEqV7j/HIwP W4bTkB+9b0tmE8Z/W6Jj26yvch+ZP/XN3TQJrDoXOsaIKlaTHBvS0Ra8fYdMNzkLpM qWABMsiLMPinAhJgEW6JXTxVfAfQjVyEzGWylIVrbKoff535PbKVS5nYDLWjlifrwY Q2KunsZuLvJNLu8db1sYKTTWEhNp5zW9qzSvuqDzEl/VXcw3fQ3KQOYLVHLgG/ut/H sszgPX9ZPR60ZNc0re3Arbh1Ci126OuFzPjDWE7yLCxCF2H+j8fabV1cX6p2ASp1fK eGaaMU5eVnU+g== To: "STARK\, BARBARA H" , 'Mahesh Jethanandani' Cc: 'Juliusz Chroboczek' , 'Babel at IETF' In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E26901D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr> <87pnlhaixh.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E257961@GAALPA1MSGUSRBF.ITServices.sbc.com> <0B28A1FA-32B4-41E6-B646-C6A3907E9CCC@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114E258CF7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E25905B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87lfw3u52i.fsf@toke.dk> <110D87BA-BBA1-417B-9BC3-77BAD4B201D1@gmail.com> <87ftmbs92f.fsf@toke.dk> <26F1A0CD-1FD2-456E-B295-8A60D93CF8E0@gmail.com> <87sgqbmhhe.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E2680FE@GAALPA1MSGUSRBF.ITServices.sbc.com> <9554AC75-4674-4EB2-B40D-26CA383E3343@gmail.com> <87woffap8c.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114E26901D@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Wed, 14 Aug 2019 19:30:05 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87lfvvac4i.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Example configuration 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: Wed, 14 Aug 2019 17:30:12 -0000 "STARK, BARBARA H" writes: >> From: Toke H=C3=B8iland-J=C3=B8rgensen >> Mahesh Jethanandani writes: >>=20 >> > Hi Barbara, et. all, >> > >> > If you are managing a small number of interfaces (< 10 in my mind), >> > then your approach is simpler. Configure link properties per interface >> > and be done, even if means repeating the configuration on those 10 >> > interfaces. >> > >> > If we are talking about a larger set, then the complexity might be >> > worth it, simply to allow changes in one place. >> > >> > The question therefore comes down to, what is the normal number of >> > interfaces a device will configure to run babeld? >>=20 >> For most current Babel deployments I'm familiar with: One or two wireless >> interfaces and maybe a single wired. Definitely less than 10... > > I agree with Toke. And I think we also need to understand that active > configuration in Babel is about handling exceptions to the implemented > rules. In almost all cases, the Babel implementation will > automatically select the correct link properties for an interface. > Only for the small number of cases where the automatic implementation > config is wrong will the configuration need to be updated/changed. For > example, if I attach a wireless bridge to an Ethernet port of a > router, I need to specifically change the link properties for only > that one Ethernet interface on that one router. "Repeating" > configurations doesn't make sense when active configuration is an > exception. I think the normal number of interfaces a *management > system* will need to configure is zero. > > When RTT is added as a link property, it too will be auto detected by > the fact the interface is a tunnel. [We may want to consider a global > configuration option to enable/disable detection of tunneled > interfaces and use of RTT -- for cases where RTT support is > implemented -- to be defined in the RTT draft.] Yes. I usually just enable RTT globally :) > When unicast becomes a property -- well, this is something that a > network operator will probably expect to set independent of other > "link properties". It isn't really a link property, at all. [We may > want a global configuration option for this, too, to indicate whether > a new interface is set to default unicast or multicast -- but that's > not for now.] Yeah, when we have some more experience with this there will probably be some relevant settings related to unicast as well... -Toke From nobody Wed Aug 14 10:55:14 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 025FB120CEA for ; Wed, 14 Aug 2019 10:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id expIBdcg2k08 for ; Wed, 14 Aug 2019 10:55:06 -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 706FB120CD2 for ; Wed, 14 Aug 2019 10:55:06 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7EHroxO003501; Wed, 14 Aug 2019 13:55:04 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 2ucpq58kug-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 13:55:04 -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 x7EHt3oi030447; Wed, 14 Aug 2019 13:55:03 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7EHsv8Y030355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Aug 2019 13:54:57 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 812AB4009E78; Wed, 14 Aug 2019 17:54:57 +0000 (GMT) Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (unknown [130.8.218.152]) by zlp30485.vci.att.com (Service) with ESMTPS id 696794009E70; Wed, 14 Aug 2019 17:54:57 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0439.000; Wed, 14 Aug 2019 13:54:57 -0400 From: "STARK, BARBARA H" To: "'David Schinazi'" CC: "'Juliusz Chroboczek'" , "'babel@ietf.org'" Thread-Topic: [babel] HMAC: removed constraint on the key stored in interface table Thread-Index: AQHVUe2J94IZUlXvWUGht5ECY/kmSKb5V8HwgABYPID//8teAIAAaDuA//++YOCAAErlAP//wwPwAAkY/AAAAQL7AAAWFp0gAA6x4YAAB3M04A== Date: Wed, 14 Aug 2019 17:54:56 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E2698C0@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8736i5ul8p.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E26794B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87v9v0ucba.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267D1B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87r25ou3ri.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267FBE@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E2681C5@GAALPA1MSGUSRBF.ITServices.sbc.com> <87mugcu09v.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269246@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.174.18.88] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114E2698C0GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-14_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908140159 Archived-At: Subject: Re: [babel] HMAC: removed constraint on the key stored in interface table 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: Wed, 14 Aug 2019 17:55:09 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114E2698C0GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIHdpdGggPGJocz4uIC0gQmFyYmFyYQ0KDQpUaGFua3MgQmFyYmFyYSENCg0KSSBtZWFu dCBCYWJlbC1NQUMgaW1wbGVtZW50YXRpb25zLg0KPGJocz4gQnV0IEp1bGl1c3ogc2FpZCBoZSB3 YW50cyB0byByZW1vdmUgZnJvbSBiYWJlbC1obWFjIGFsbCByZXF1aXJlbWVudHMgcmVsYXRlZCB0 byB3aGF0IGEga2V5IGlzIG9yIGhvdyBsb25nIGl0IGlzLiBUaGF04oCZcyB3aGF0IHByZWNpcGl0 YXRlZCB0aGlzIGRpc2N1c3Npb24uIFNvIHRoaXMgZW1haWwgdGhyZWFkIGlzIG9ubHkgY29uc2lk ZXJpbmcgcmVxdWlyZW1lbnRzIG9uIChpbnN0YW50aWF0aW9ucyBvciBpbXBsZW1lbnRhdGlvbnMg b2YpIGluZm9ybWF0aW9uLW1vZGVsLiBCdXQgaWYgeW91IGNhbiBnZXQgaGltIHRvIHJlY29uc2lk ZXIgaGF2aW5nIHNvbWV0aGluZyBpbiBiYWJlbC1obWFjLCB0aGF0IHdvdWxkIGJlIGdyZWF0LiBN YXliZSBjb21lIHVwIHdpdGggYSBzY2VuYXJpbyB3aGVyZSBjaGlsZHJlbiB3b3VsZCBjb21lIHRv IGFjdHVhbCBoYXJtIChhbmQgbm90IGp1c3QgbWlzcyBoaWtpbmcpLg0KQ2FuIHlvdSBkZXNjcmli ZSB3aGljaCB3aWdnbGUgcm9vbSBleGlzdHM/IElmIHlvdSB1c2UgZGlmZmVyZW50IHNpemVkIGtl eXMgeW91J2xsIGdldCBpbnRlcm9wIGZhaWx1cmUsIGp1c3QgbGlrZSBpZiB5b3UgdXNlIGRpZmZl cmVudCBrZXlzIG9mIHRoZSBzYW1lIGxlbmd0aC4NCg0KPGJocz4gU0hPVUxEID0gd2lnZ2xlIHJv b20uIEkga25vdyBJRVRGIHBlb3BsZSB0aGluayBTSE9VTEQgbWVhbnMgeW91IHNob3VsZCBoYXZl IGEgcmVhbGx5IGdvb2QgcmVhc29uIG5vdCB0byBkbyBpdC4gTW9zdCBpbXBsZW1lbnRlcnMganVz dCB0cmVhdCBTSE9VTEQgYXMgb3B0aW9uYWwsIHRob3VnaC4gQW5kIOKAnGJlY2F1c2UgSSBkaWRu 4oCZdCBmZWVsIGxpa2UgaXTigJ0gdGVuZHMgdG8gYmUgdGhlaXIg4oCccmVhbGx5IGdvb2QgcmVh c29u4oCdLiBJIHdvdWxkIHByZWZlciB0byBjb25zdHJhaW4ga2V5IGxlbmd0aHMgd2l0aCBNVVNU IHN0YXRlbWVudHMuDQoNCkRhdmlkDQoNCg0KT24gV2VkLCBBdWcgMTQsIDIwMTkgYXQgNzozNyBB TSBTVEFSSywgQkFSQkFSQSBIIDxiczc2NTJAYXR0LmNvbTxtYWlsdG86YnM3NjUyQGF0dC5jb20+ PiB3cm90ZToNCknigJltIHVuY2xlYXIg4oCTIHdoaWNoIOKAnGltcGxlbWVudGF0aW9u4oCdIGFy ZSB3ZSB0YWxraW5nIGFib3V0PyBBIGJhYmVsLW1hYyBpbXBsZW1lbnRhdGlvbiBvciBhIGRhdGEg bW9kZWw/DQoNCkkgc3RpbGwgdGhpbmsgSSB3b3VsZCBwcmVmZXIgc29tZXRoaW5nIGluIGluZm8g bW9kZWwgbGlrZSAodGhlIENvdXJpZXIgZm9udCBpcyBleGlzdGluZyB0ZXh0KToNCg0KICAgICAg VGhlIHZhbHVlIG9mIHRoZSBITUFDIGtleS4gIEFuIGltcGxlbWVudGF0aW9uIE1VU1QNCiAgICAg IE5PVCBhbGxvdyB0aGlzIHBhcmFtZXRlciB0byBiZSByZWFkLiAgVGhpcyBjYW4gYmUgZG9uZSBi eSBhbHdheXMNCiAgICAgIHByb3ZpZGluZyBhbiBlbXB0eSBzdHJpbmcgd2hlbiByZWFkLCBvciB0 aHJvdWdoIHBlcm1pc3Npb25zLCBvciBvdGhlciBtZWFucy4NCiAgICAgIFRoaXMgdmFsdWUgTVVT VCBiZSBwcm92aWRlZCB3aGVuIHRoaXMgaW5zdGFuY2UgaXMgY3JlYXRlZCwgYW5kIGlzDQogICAg ICBub3Qgc3Vic2VxdWVudGx5IHdyaXRhYmxlLiBUaGUga2V5IGxlbmd0aCBNVVNUIGJlIHRoZSBt YXhpbXVtIGxlbmd0aCB0aGF0IGlzDQogICAgICAgICAgICAgIGRlZmluZWQgZm9yIHRoZSBhc3Nv Y2lhdGVkIGJhYmVsLW1hYy1rZXktYWxnb3JpdGhtLCBzbyB0aGVyZSBpcyBubyBuZWVkIGZvciB0 aGUgTUFDIGFsZ29yaXRobSB0byB6ZXJvLXBhZCwNCiAgICAgICAgICAgICAgdHJ1bmNhdGUsIG9y IG90aGVyd2lzZSBtYW5pcHVsYXRlIHRoZSBrZXkgcHJpb3IgdG8gdXNlLiBGb3IgSE1BQy1TSEEy NTYsIHRoaXMgaXMgZGVmaW5lZA0KICAgICAgICAgICAgICBpbiBSRkM0ODY4IGFzIDY0IGJ5dGVz LiBGb3IgQmxha2UycywgdGhpcyBpcyBkZWZpbmVkIGluIFJGQzc2OTMgYXMgMzIgYnl0ZXMuIElm IGtleXMgYXJlDQogICAgICAgICAgICAgIGdlbmVyYXRlZCBmcm9tIHVzZXIgaW5wdXQsIHRoZSB1 c2VyIGludGVyZmFjZSBvciBtYW5hZ2VtZW50IHN5c3RlbSBpcyBleHBlY3RlZCB0bw0KICAgICAg ICAgICAgICB6ZXJvLXBhZCBzdHJpbmdzIHRoYXQgYXJlIGxlc3MgdGhhbiB0aGUgcmVxdWlyZWQg bGVuZ3RoLCBhbmQgcHJvaGliaXQgc3RyaW5ncyBsb25nZXIgdGhhbg0KICAgICAgICAgICAgICB0 aGUgcmVxdWlyZWQgbGVuZ3RoLiBUaGlzIGVuc3VyZXMgdGhlIGRlbGl2ZXJlZCBzdHJpbmcgaXMg ZXhhY3RseSB0aGUgcmVxdWlyZWQgbnVtYmVyIG9mIGJ5dGVzLg0KDQpJIHJlYWxseSBkaXNsaWtl IFNIT1VMRHMgYW5kIHdpZ2dsZSByb29tIGluIHRoaW5ncyBsaWtlIHRoaXMgdGhhdCBjYW4gY2F1 c2UgYSBjb21wbGV0ZSBicmVha2Rvd24gb2YgaW50ZXJvcGVyYWJpbGl0eS4gSGFzaGluZyBpcyBh biBhcmVhIHdoZXJlIGl04oCZcyB2ZXJ5IGVhc3kgdG8gYWNoaWV2ZSBub24taW50ZXJvcGVyYWJp bGl0eS4NCkJhcmJhcmENCg0KRnJvbTogRGF2aWQgU2NoaW5hemkgPGRzY2hpbmF6aS5pZXRmQGdt YWlsLmNvbTxtYWlsdG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tPj4NCkBKdWxpdXN6OiBSZXZp c2VkIHN0YXRlbWVudCwgbm93IHdpdGggMzAlIG1vcmUgdGhpbmtpbmcgb2YgdGhlIGNoaWxkcmVu Og0KDQoob25seSBhZGRlZCBzZWNvbmQgbm9ybWF0aXZlIHN0YXRlbWVudCkNCg0KLSBLZXlzIHVz ZWQgZm9yIEJhYmVsLU1BQyBNVVNUIGJlIG9mIGEgbGVuZ3RoIHN1aXRhYmxlIGZvciB0aGF0IE1B QyBmdW5jdGlvbi4NCi0gSW1wbGVtZW50YXRpb25zIE1VU1QgYWNjZXB0IGFsbCBrZXkgbGVuZ3Ro cyB0aGF0IGFyZSBzdWl0YWJsZSBmb3IgdGhlIHNlbGVjdGVkIE1BQyBmdW5jdGlvbiwgYXMgZGVm aW5lZCBieSB0aGUgc3BlY2lmaWNhdGlvbiBvZiB0aGF0IE1BQyBmdW5jdGlvbi4NCi0gSW1wbGVt ZW50YXRpb25zIE1VU1QgcmVqZWN0IGtleXMgdGhhdCBhcmUgbm90IHN1aXRhYmxlIGZvciB0aGUg TUFDIGZ1bmN0aW9uOyBpbiBvdGhlciB3b3JkcywgaW1wbGVtZW50YXRpb25zIE1VU1QgTk9UIHBy ZXByb2Nlc3Mga2V5cyBvZiB1bnN1aXRhYmxlIGxlbmd0aHMgdG8gcHJvZHVjZSBhIGtleSBvZiBz dWl0YWJsZSBsZW5ndGguDQotIEJhYmVsIG1hbmFnZW1lbnQgaW50ZXJmYWNlcyBNVVNUIE5PVCBh bGxvdyBjb25maWd1cmluZyBrZXlzIG9mIG5vbiBzdWl0YWJsZSBsZW5ndGhzLg0KLSBLZXlzIGZv ciBITUFDLVNIQTI1NiBTSE9VTEQgYmUgNjQgYnl0ZXMgbG9uZywga2V5cyBmb3IgQmxha2UycyBT SE9VTEQgYmUgMzIgYnl0ZXMgbG9uZy4NCg0KQEJhcmJhcmE6IEknbSBub3QgZGlzY3Vzc2luZyB0 aGUgdXNlciBpbnRlcmZhY2UsIG9ubHkgd2hhdCB0aGUgaW5mb3JtYXRpb24gbW9kZWwgY2FuIGRl bGl2ZXIgdG8gdGhlIEJhYmVsIGltcGxlbWVudGF0aW9uDQoNCk9uIFR1ZSwgQXVnIDEzLCAyMDE5 IGF0IDQ6MTMgUE0gSnVsaXVzeiBDaHJvYm9jemVrIDxqY2hAaXJpZi5mcjxtYWlsdG86amNoQGly aWYuZnI+PiB3cm90ZToNCj4gU2VlIHJlc3BvbnNlIHRvIEp1bGl1c3ouIFRoZSBpbmZvIG1vZGVs IGlzICpub3QqIGRlc2lnbmluZyBhIHVzZXIgaW50ZXJmYWNlLiBJdA0KPiBpcyBzdGF0aW5nIHdo YXQgaXQgd2lsbCAob3IgaXMgYWxsb3dlZCB0bykgZGVsaXZlciB0byB0aGUgYmFiZWwgaW1wbGVt ZW50YXRpb24uDQo+IFdoYXQgaGFwcGVucyB0byBnZW5lcmF0ZSB0aGUgYnl0ZXMgdGhhdCBnZXQg ZGVsaXZlcmVkIHRvIGJhYmVsIGJ5IHRoZSBpbmZvDQo+IG1vZGVsIGFyZSBvdXRzaWRlIHRoZSBj b250cm9sIG9mIHRoZSBpbmZvIG1vZGVsIChzbyBub3JtYXRpdmUgbGFuZ3VhZ2UgaXMgbm8NCj4g Z29vZCkuIFRob3NlIHByb3Bvc2VkIFNIT1VMRCBzdGF0ZW1lbnRzIG1lYW4gdGhlIGluZm8gbW9k ZWwgcmVhbGx5IGNhbiBkZWxpdmVyDQo+IHByZXR0eSBtdWNoIGFueSBzdHJpbmcgdG8gYSBiYWJl bCBpbXBsZW1lbnRhdGlvbiBhbmQgZXhwZWN0IGludGVyb3BlcmFibGUNCj4gcmVzdWx0cy4NCg0K SWYgSSByZWFkIEJhcmJhcmEgcmlnaHQ6DQoNCiAgLSBhZG1pbmlzdHJhdG9yIHdyaXRlcyBhIHNj cmlwdCB0aGF0IGNvbmZpZ3VyZXMgaGlzIDEwMDAwIHJvdXRlcnMgdGhlIHdheQ0KICAgIGhlIGxp a2VzIGl0Ow0KICAtIGFkbWluaXN0cmF0b3IgYnV5cyBhIG5ldyByb3V0ZXIgdGhhdCBpbnRlcnBy ZXRzIHRoZSBkYXRhIG1vZGVsIGRpZmZlcmVudGx5Ow0KICAtIHNjcmlwdCBicmVha3MgYmVjYXVz ZSB0aGUgbmV3IHJvdXRlciByZXF1aXJlcyBleGFjdGx5IDY0IGJ5dGVzIGluIGEga2V5Ow0KICAt IGFkbWluaXN0cmF0b3Igc3BlbmRzIHRoZSB3ZWVrZW5kIGZpeGluZyBoaXMgbmV0d29yayByYXRo ZXIgdGhhbiBnb2luZw0KICAgIGhpa2luZyB3aXRoIGhpcyBjaGlsZHJlbiBhcyBoZSBwcm9taXNl ZC4NCg0KVGhpbmsgb2YgdGhlIGNoaWxkcmVuLCBEYXZpZC4NCg0KLS0gSnVsaXVzeg0K --_000_2D09D61DDFA73D4C884805CC7865E6114E2698C0GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J bmxpbmUgd2l0aCAmbHQ7YmhzJmd0Oy4gLSBCYXJiYXJhPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBCYXJiYXJhITxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG1l YW50IEJhYmVsLU1BQyBpbXBsZW1lbnRhdGlvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZsdDtiaHMmZ3Q7IEJ1dCBKdWxpdXN6IHNhaWQgaGUgd2FudHMgdG8gcmVt b3ZlIGZyb20gYmFiZWwtaG1hYyBhbGwgcmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gd2hhdCBhIGtl eSBpcyBvciBob3cgbG9uZyBpdCBpcy4gVGhhdOKAmXMgd2hhdCBwcmVjaXBpdGF0ZWQgdGhpcyBk aXNjdXNzaW9uLiBTbyB0aGlzIGVtYWlsIHRocmVhZA0KIGlzIG9ubHkgY29uc2lkZXJpbmcgcmVx dWlyZW1lbnRzIG9uIChpbnN0YW50aWF0aW9ucyBvciBpbXBsZW1lbnRhdGlvbnMgb2YpIGluZm9y bWF0aW9uLW1vZGVsLiBCdXQgaWYgeW91IGNhbiBnZXQgaGltIHRvIHJlY29uc2lkZXIgaGF2aW5n IHNvbWV0aGluZyBpbiBiYWJlbC1obWFjLCB0aGF0IHdvdWxkIGJlIGdyZWF0LiBNYXliZSBjb21l IHVwIHdpdGggYSBzY2VuYXJpbyB3aGVyZSBjaGlsZHJlbiB3b3VsZCBjb21lIHRvIGFjdHVhbCBo YXJtIChhbmQNCiBub3QganVzdCBtaXNzIGhpa2luZykuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhbiB5b3UgZGVzY3JpYmUgd2hpY2ggd2lnZ2xlIHJvb20g ZXhpc3RzPyBJZiB5b3UgdXNlIGRpZmZlcmVudCBzaXplZCBrZXlzIHlvdSdsbCBnZXQgaW50ZXJv cCBmYWlsdXJlLCBqdXN0IGxpa2UgaWYgeW91IHVzZSBkaWZmZXJlbnQga2V5cyBvZiB0aGUgc2Ft ZSBsZW5ndGguPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtiaHMmZ3Q7IFNIT1VMRCA9IHdp Z2dsZSByb29tLiBJIGtub3cgSUVURiBwZW9wbGUgdGhpbmsgU0hPVUxEIG1lYW5zIHlvdSBzaG91 bGQgaGF2ZSBhIHJlYWxseSBnb29kIHJlYXNvbiBub3QgdG8gZG8gaXQuIE1vc3QgaW1wbGVtZW50 ZXJzIGp1c3QgdHJlYXQgU0hPVUxEIGFzIG9wdGlvbmFsLCB0aG91Z2guIEFuZCDigJxiZWNhdXNl IEkgZGlkbuKAmXQgZmVlbCBsaWtlIGl04oCdIHRlbmRzIHRvIGJlIHRoZWlyIOKAnHJlYWxseQ0K IGdvb2QgcmVhc29u4oCdLiBJIHdvdWxkIHByZWZlciB0byBjb25zdHJhaW4ga2V5IGxlbmd0aHMg d2l0aCBNVVNUIHN0YXRlbWVudHMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5EYXZpZDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXVnIDE0LCAyMDE5IGF0IDc6MzcgQU0gU1RBUkssIEJB UkJBUkEgSCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJzNzY1MkBhdHQuY29tIiB0YXJnZXQ9Il9ibGFu ayI+YnM3NjUyQGF0dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J4oCZbSB1 bmNsZWFyIOKAkyB3aGljaCDigJxpbXBsZW1lbnRhdGlvbuKAnSBhcmUgd2UgdGFsa2luZyBhYm91 dD8gQSBiYWJlbC1tYWMgaW1wbGVtZW50YXRpb24gb3IgYSBkYXRhIG1vZGVsPzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SSBzdGlsbCB0aGluayBJIHdvdWxkIHByZWZlciBzb21ldGhpbmcg aW4gaW5mbyBtb2RlbCBsaWtlICh0aGUgQ291cmllciBmb250IGlzIGV4aXN0aW5nIHRleHQpOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBUaGUgdmFsdWUgb2YgdGhlIEhNQUMga2V5LiZuYnNwOyBBbiBpbXBsZW1lbnRh dGlvbiBNVVNUPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5PVCBhbGxvdyB0aGlzIHBh cmFtZXRlciB0byBiZSByZWFkLiZuYnNwOyBUaGlzIGNhbiBiZSBkb25lIGJ5IGFsd2F5czwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwcm92aWRpbmcgYW4gZW1wdHkgc3RyaW5nIHdoZW4g cmVhZCwgb3IgdGhyb3VnaCBwZXJtaXNzaW9ucywgb3Igb3RoZXIgbWVhbnMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgdmFsdWUgTVVTVCBiZSBwcm92aWRlZCB3aGVuIHRoaXMg aW5zdGFuY2UgaXMgY3JlYXRlZCwgYW5kIGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IG5vdCBzdWJzZXF1ZW50bHkgd3JpdGFibGUuDQo8L3NwYW4+VGhlIGtleSBsZW5ndGggTVVTVCBi ZSB0aGUgbWF4aW11bSBsZW5ndGggdGhhdCBpczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVmaW5lZCBmb3IgdGhlIGFzc29jaWF0 ZWQgYmFiZWwtbWFjLWtleS1hbGdvcml0aG0sIHNvIHRoZXJlIGlzIG5vIG5lZWQgZm9yIHRoZSBN QUMgYWxnb3JpdGhtIHRvIHplcm8tcGFkLA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RydW5jYXRlLCBvciBvdGhlcndp c2UgbWFuaXB1bGF0ZSB0aGUga2V5IHByaW9yIHRvIHVzZS4gRm9yIEhNQUMtU0hBMjU2LCB0aGlz IGlzIGRlZmluZWQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtpbiBSRkM0ODY4IGFzIDY0IGJ5dGVzLiBGb3IgQmxha2Uy cywgdGhpcyBpcyBkZWZpbmVkIGluIFJGQzc2OTMgYXMgMzIgYnl0ZXMuIElmIGtleXMgYXJlPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDtnZW5lcmF0ZWQgZnJvbSB1c2VyIGlucHV0LCB0aGUgdXNlciBpbnRlcmZhY2Ugb3IgbWFuYWdl bWVudCBzeXN0ZW0gaXMgZXhwZWN0ZWQgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO3plcm8tcGFkIHN0cmluZ3MgdGhhdCBhcmUg bGVzcyB0aGFuIHRoZSByZXF1aXJlZCBsZW5ndGgsIGFuZCBwcm9oaWJpdCBzdHJpbmdzIGxvbmdl ciB0aGFuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDt0aGUgcmVxdWlyZWQgbGVuZ3RoLiBUaGlzIGVuc3VyZXMgdGhlIGRlbGl2ZXJl ZCBzdHJpbmcgaXMgZXhhY3RseSB0aGUgcmVxdWlyZWQgbnVtYmVyIG9mIGJ5dGVzLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SSByZWFsbHkgZGlzbGlrZSBTSE9VTERzIGFuZCB3aWdnbGUg cm9vbSBpbiB0aGluZ3MgbGlrZSB0aGlzIHRoYXQgY2FuIGNhdXNlIGEgY29tcGxldGUgYnJlYWtk b3duIG9mIGludGVyb3BlcmFiaWxpdHkuIEhhc2hpbmcgaXMgYW4gYXJlYSB3aGVyZSBpdOKAmXMg dmVyeSBlYXN5IHRvIGFjaGlldmUgbm9uLWludGVyb3BlcmFiaWxpdHkuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJhcmJhcmE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj5Gcm9tOjwvYj4gRGF2aWQgU2NoaW5hemkgJmx0Ozxh IGhyZWY9Im1haWx0bzpkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5k c2NoaW5hemkuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ow0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5ASnVsaXVzejogUmV2aXNlZCBzdGF0ZW1lbnQsIG5vdyB3 aXRoIDMwJSBtb3JlIHRoaW5raW5nIG9mIHRoZSBjaGlsZHJlbjo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4ob25seSBhZGRlZCBzZWNvbmQgbm9ybWF0 aXZlIHN0YXRlbWVudCk8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+LSBLZXlzIHVzZWQgZm9yIEJhYmVsLU1BQyBNVVNUIGJlIG9mIGEgbGVu Z3RoIHN1aXRhYmxlIGZvciB0aGF0IE1BQyBmdW5jdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBJbXBsZW1lbnRhdGlvbnMgTVVTVCBh Y2NlcHQgYWxsIGtleSBsZW5ndGhzIHRoYXQgYXJlIHN1aXRhYmxlIGZvciB0aGUgc2VsZWN0ZWQg TUFDIGZ1bmN0aW9uLCBhcyBkZWZpbmVkIGJ5IHRoZSBzcGVjaWZpY2F0aW9uIG9mIHRoYXQgTUFD IGZ1bmN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4tIEltcGxlbWVudGF0aW9ucyBNVVNUIHJlamVjdCBrZXlzIHRoYXQgYXJlIG5vdCBz dWl0YWJsZSBmb3IgdGhlIE1BQyBmdW5jdGlvbjsgaW4gb3RoZXIgd29yZHMsIGltcGxlbWVudGF0 aW9ucyBNVVNUIE5PVCBwcmVwcm9jZXNzIGtleXMgb2YgdW5zdWl0YWJsZSBsZW5ndGhzIHRvIHBy b2R1Y2UgYSBrZXkgb2YNCiBzdWl0YWJsZSBsZW5ndGguPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gQmFiZWwgbWFuYWdlbWVudCBpbnRlcmZh Y2VzIE1VU1QgTk9UIGFsbG93IGNvbmZpZ3VyaW5nIGtleXMgb2Ygbm9uIHN1aXRhYmxlIGxlbmd0 aHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pi0gS2V5cyBmb3ImbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFj ayI+SE1BQy1TSEEyNTYgU0hPVUxEIGJlIDY0IGJ5dGVzIGxvbmcsIGtleXMgZm9yJm5ic3A7PC9z cGFuPkJsYWtlMnMgU0hPVUxEIGJlIDMyIGJ5dGVzIGxvbmcuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5AQmFyYmFyYTogSSdtIG5vdCBk aXNjdXNzaW5nIHRoZSB1c2VyIGludGVyZmFjZSwgb25seSB3aGF0IHRoZSBpbmZvcm1hdGlvbiBt b2RlbCBjYW4gZGVsaXZlciB0byB0aGUgQmFiZWwgaW1wbGVtZW50YXRpb248bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5PbiBUdWUsIEF1ZyAxMywgMjAxOSBhdCA0OjEzIFBNIEp1bGl1c3ogQ2hyb2JvY3playAm bHQ7PGEgaHJlZj0ibWFpbHRvOmpjaEBpcmlmLmZyIiB0YXJnZXQ9Il9ibGFuayI+amNoQGlyaWYu ZnI8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZndDsg U2VlIHJlc3BvbnNlIHRvIEp1bGl1c3ouIFRoZSBpbmZvIG1vZGVsIGlzICpub3QqIGRlc2lnbmlu ZyBhIHVzZXIgaW50ZXJmYWNlLiBJdDxicj4NCiZndDsgaXMgc3RhdGluZyB3aGF0IGl0IHdpbGwg KG9yIGlzIGFsbG93ZWQgdG8pIGRlbGl2ZXIgdG8gdGhlIGJhYmVsIGltcGxlbWVudGF0aW9uLjxi cj4NCiZndDsgV2hhdCBoYXBwZW5zIHRvIGdlbmVyYXRlIHRoZSBieXRlcyB0aGF0IGdldCBkZWxp dmVyZWQgdG8gYmFiZWwgYnkgdGhlIGluZm88YnI+DQomZ3Q7IG1vZGVsIGFyZSBvdXRzaWRlIHRo ZSBjb250cm9sIG9mIHRoZSBpbmZvIG1vZGVsIChzbyBub3JtYXRpdmUgbGFuZ3VhZ2UgaXMgbm88 YnI+DQomZ3Q7IGdvb2QpLiBUaG9zZSBwcm9wb3NlZCBTSE9VTEQgc3RhdGVtZW50cyBtZWFuIHRo ZSBpbmZvIG1vZGVsIHJlYWxseSBjYW4gZGVsaXZlcjxicj4NCiZndDsgcHJldHR5IG11Y2ggYW55 IHN0cmluZyB0byBhIGJhYmVsIGltcGxlbWVudGF0aW9uIGFuZCBleHBlY3QgaW50ZXJvcGVyYWJs ZTxicj4NCiZndDsgcmVzdWx0cy48YnI+DQo8YnI+DQpJZiBJIHJlYWQgQmFyYmFyYSByaWdodDo8 YnI+DQo8YnI+DQombmJzcDsgLSBhZG1pbmlzdHJhdG9yIHdyaXRlcyBhIHNjcmlwdCB0aGF0IGNv bmZpZ3VyZXMgaGlzIDEwMDAwIHJvdXRlcnMgdGhlIHdheTxicj4NCiZuYnNwOyAmbmJzcDsgaGUg bGlrZXMgaXQ7PGJyPg0KJm5ic3A7IC0gYWRtaW5pc3RyYXRvciBidXlzIGEgbmV3IHJvdXRlciB0 aGF0IGludGVycHJldHMgdGhlIGRhdGEgbW9kZWwgZGlmZmVyZW50bHk7PGJyPg0KJm5ic3A7IC0g c2NyaXB0IGJyZWFrcyBiZWNhdXNlIHRoZSBuZXcgcm91dGVyIHJlcXVpcmVzIGV4YWN0bHkgNjQg Ynl0ZXMgaW4gYSBrZXk7PGJyPg0KJm5ic3A7IC0gYWRtaW5pc3RyYXRvciBzcGVuZHMgdGhlIHdl ZWtlbmQgZml4aW5nIGhpcyBuZXR3b3JrIHJhdGhlciB0aGFuIGdvaW5nPGJyPg0KJm5ic3A7ICZu YnNwOyBoaWtpbmcgd2l0aCBoaXMgY2hpbGRyZW4gYXMgaGUgcHJvbWlzZWQuPGJyPg0KPGJyPg0K VGhpbmsgb2YgdGhlIGNoaWxkcmVuLCBEYXZpZC48YnI+DQo8YnI+DQotLSBKdWxpdXN6PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_2D09D61DDFA73D4C884805CC7865E6114E2698C0GAALPA1MSGUSRBF_-- From nobody Wed Aug 14 11:01: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 1CA91120CB6 for ; Wed, 14 Aug 2019 11:01:36 -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 5qkc2Ruxz84a for ; Wed, 14 Aug 2019 11:01:34 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3122C120C9B for ; Wed, 14 Aug 2019 11:01:33 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7EHwaY4025847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Aug 2019 19:58:36 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x7EHwaRO019971; Wed, 14 Aug 2019 19:58:36 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 077AD47BA5; Wed, 14 Aug 2019 19:58:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Oeqz9GislWHx; Wed, 14 Aug 2019 19:58:38 +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 2BC0D47BA3; Wed, 14 Aug 2019 19:58:38 +0200 (CEST) Date: Wed, 14 Aug 2019 19:58:38 +0200 Message-ID: <87d0h7tyr5.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'David Schinazi'" , "'babel@ietf.org'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E2698C0@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <8736i5ul8p.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E26794B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87v9v0ucba.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267D1B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87r25ou3ri.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267FBE@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E2681C5@GAALPA1MSGUSRBF.ITServices.sbc.com> <87mugcu09v.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269246@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E2698C0@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 14 Aug 2019 19:58:36 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 14 Aug 2019 19:58:36 +0200 (CEST) X-Miltered: at korolev with ID 5D544BCC.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D544BCC.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D544BCC.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D544BCC.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 : 5D544BCC.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D544BCC.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] HMAC: removed constraint on the key stored in interface table 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: Wed, 14 Aug 2019 18:01:36 -0000 > SHOULD = wiggle room. I know IETF people think SHOULD means you should > have a really good reason not to do it. Most implementers just treat SHOULD as > optional, though. And “because I didn’t feel like it” tends to be their “really > good reason”. I would prefer to constrain key lengths with MUST statements. RFC 6126bis takes the following approach: - MUST = not doing it will prevent interoperability; - SHOULD = not doing it is a bad idea, but doing it will not prevent interoperability. From nobody Wed Aug 14 11:06:22 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 4318F120CD5 for ; Wed, 14 Aug 2019 11:06:21 -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 n03bI-Tw7Z1T for ; Wed, 14 Aug 2019 11:06:18 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 40C23120CD2 for ; Wed, 14 Aug 2019 11:05:36 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id bj8so4004419plb.4 for ; Wed, 14 Aug 2019 11:05:36 -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=b3ogIXDNZpeI4X/ezB5ZqoNWoMdSIDvB894Yds5ZAOE=; b=p+f9XmxKHiXWfTYdp+OSaL77Pono1yA/izouplZih04LWIuPZHjms1VOzv0fVD5NoA xBXyXRAnRMiDjWlIPf0WUTWWYoXMrGXtHK7ZmmMyFj5dJoTiMZPLQ/pkUJPdDLqugtq/ wxLHdJkodpctPN+ePLFgL9lI8LEAfvKvaW20KIG7l2KKb31Xqca6wkx19iFOkXXPqWI+ cPXINtx56txR8dyGNQE7cosQ0SJ9PTLHeuMft+GSJpAFew2F1fu07R15LitzqZsKX1bm CJQeJObdbCwYS1MkotCnqjf5EvzK8Fgkf6gAl3LmmW71AWs6jO1oYRd0cssRnRRHSjKk YkHg== 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=b3ogIXDNZpeI4X/ezB5ZqoNWoMdSIDvB894Yds5ZAOE=; b=GvGjQmwQjzOTbjHiotzTS4hItBsplzzZoyN68MC06AB3KTYrbXYBAZ9oQBE+jtI96q rVB0R1+7AimR8OMMU3ZK+FpdGi0fQHiuZgglXfoGToxQEA7JyYfUjQ9O65J0C+YjJcCo IJXD0kDmQGKHya6jsw/rqLGPSkBdEke5R/4rU8C6/xkxKV3xpE174SIR+p2iUMvORS2c yJWiV6eJXR8UScCqf6kIh63oKJs9I+au4w/GULMljG7nTbabFUwz18gu4OZG2Miz23rF eMEHGdAPGXkJkha+NgGJBkqvMQHAvaMbimwaeAGMMO46SSdLHGKsEqokyzzX87MWv3Pk ewxg== X-Gm-Message-State: APjAAAUqNJd/9g8FZy6+MqG+oKUlp4Ixg0z/0/9/SRARbJfYfI825jzl 5nRV1jgtUowPaJ57aLmtAcY= X-Google-Smtp-Source: APXvYqxykRUq7kLIYlT7cPMztx1sbihJRBHr0nJcATItywXpxKk7i9fdhO+bAADEhWcm+U8u2esn7w== X-Received: by 2002:a17:902:9f8e:: with SMTP id g14mr612083plq.67.1565805935655; Wed, 14 Aug 2019 11:05:35 -0700 (PDT) Received: from [10.33.122.240] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id r12sm351890pgb.73.2019.08.14.11.05.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Aug 2019 11:05:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mahesh Jethanandani In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E26901D@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Wed, 14 Aug 2019 11:05:33 -0700 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Juliusz Chroboczek , Babel at IETF Content-Transfer-Encoding: quoted-printable Message-Id: <2AA11403-8C95-4E7B-8878-34D1499415F2@gmail.com> References: <8736itu6j8.wl-jch@irif.fr> <0E0A89B7-3D7A-4605-8776-2CF685B268B0@gmail.com> <877e7qaxte.wl-jch@irif.fr> <1C6F628C-7A3C-4D66-9930-9F0244A20722@gmail.com> <8736ieasm6.wl-jch@irif.fr> <87pnlhaixh.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E257961@GAALPA1MSGUSRBF.ITServices.sbc.com> <0B28A1FA-32B4-41E6-B646-C6A3907E9CCC@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114E258CF7@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E25905B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87lfw3u52i.fsf@toke.dk> <110D87BA-BBA1-417B-9BC3-77BAD4B201D1@gmail.com> <87ftmbs92f.fsf@toke.dk> <26F1A0CD-1FD2-456E-B295-8A60D93CF8E0@gmail.com> <87sgqbmhhe.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E2680FE@GAALPA1MSGUSRBF.ITServices.sbc.com> <9554AC75-4674-4EB2-B40D-26CA383E3343@gmail.com> <87woffap8c.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114E26901D@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Example configuration 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: Wed, 14 Aug 2019 18:06:21 -0000 > On Aug 14, 2019, at 6:50 AM, STARK, BARBARA H wrote: >=20 >=20 >=20 >> From: Toke H=C3=B8iland-J=C3=B8rgensen >> Mahesh Jethanandani writes: >>=20 >>> Hi Barbara, et. all, >>>=20 >>> If you are managing a small number of interfaces (< 10 in my mind), >>> then your approach is simpler. Configure link properties per = interface >>> and be done, even if means repeating the configuration on those 10 >>> interfaces. >>>=20 >>> If we are talking about a larger set, then the complexity might be >>> worth it, simply to allow changes in one place. >>>=20 >>> The question therefore comes down to, what is the normal number of >>> interfaces a device will configure to run babeld? >>=20 >> For most current Babel deployments I'm familiar with: One or two = wireless >> interfaces and maybe a single wired. Definitely less than 10... >=20 > I agree with Toke. And I think we also need to understand that active = configuration in Babel is about handling exceptions to the implemented = rules. In almost all cases, the Babel implementation will automatically = select the correct link properties for an interface. Only for the small = number of cases where the automatic implementation config is wrong will = the configuration need to be updated/changed. For example, if I attach a = wireless bridge to an Ethernet port of a router, I need to specifically = change the link properties for only that one Ethernet interface on that = one router. Ok. Then let us go with link-properties be part of the interface-obj. > "Repeating" configurations doesn't make sense when active = configuration is an exception. I think the normal number of interfaces a = *management system* will need to configure is zero. >=20 > When RTT is added as a link property, it too will be auto detected by = the fact the interface is a tunnel. [We may want to consider a global = configuration option to enable/disable detection of tunneled interfaces = and use of RTT -- for cases where RTT support is implemented -- to be = defined in the RTT draft.] >=20 > When unicast becomes a property -- well, this is something that a = network operator will probably expect to set independent of other "link = properties". It isn't really a link property, at all. [We may want a = global configuration option for this, too, to indicate whether a new = interface is set to default unicast or multicast -- but that's not for = now.] > Barbara Mahesh Jethanandani mjethanandani@gmail.com From nobody Wed Aug 14 11:08: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 9A049120CE4 for ; Wed, 14 Aug 2019 11:08:38 -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 BZsP7pRG2BgB for ; Wed, 14 Aug 2019 11:08:37 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED80C12084A for ; Wed, 14 Aug 2019 11:08:36 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x7EHxWje035881; Wed, 14 Aug 2019 14:08:36 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 2ucpgnhd7s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 14:08:01 -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 x7EI54MX022134; Wed, 14 Aug 2019 14:05:05 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7EI4xkW021956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Aug 2019 14:05:00 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id A902C4009E69; Wed, 14 Aug 2019 18:04:59 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30487.vci.att.com (Service) with ESMTPS id 949E84009E67; Wed, 14 Aug 2019 18:04:59 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0439.000; Wed, 14 Aug 2019 14:04:59 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: "'babel@ietf.org'" Thread-Topic: [babel] info-model: preparing -09 on github Thread-Index: AdVSswKr0W4Y1vOsQfS00DtIY7BoYgAM83CAAAdXLCA= Date: Wed, 14 Aug 2019 18:04:59 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E269981@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> <87ftm3u0a6.wl-jch@irif.fr> In-Reply-To: <87ftm3u0a6.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.174.18.88] 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-08-14_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=606 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908140161 Archived-At: Subject: Re: [babel] info-model: preparing -09 on github 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: Wed, 14 Aug 2019 18:08:39 -0000 > I didn't see anything wrong. (Nit: "an implementation attempting to > comply", I suggest "that purports to comply". It sounds, like, really sm= art.) I'll take this under advisement. > > 1. link properties / metric-comp-algorithm / > > interface-metric-algorithm / split-horizon: I'm leaning away from any > > new objects for link property grouping. >=20 > I agree, pending further input. >=20 > > 2. babel-mac-key-value description to constrain it according to the > > babel-mac-key-algorithm allowed key length >=20 > Here's my current proposal (pending further input): >=20 > This value is of a length suitable for the associated > babel-mac-key-algorithm. If algorithm is based on the HMAC > construction, this value MUST be between 0 and the block size of the > underlying hash inclusive (64 in the case of HMAC-SHA-256); if it is > smaller, it is zero-extended before use as specified in Section 2 of RF= C > 2104. If the algorithm is Blake2s, then it MUST be between 0 and 32 > inclusive, and is used as described in Section 3.3 of RFC 7693. I'm not sure what "use" and "used" mean in the context of info-model. Info-= model doesn't use these values -- that's babel-hmac's job. Is this suggesting that it's ok for info-model to provide babel-hmac with a= ny value between 0 and 64 bytes in length for HMAC-SHA256 or between 0 and = 32 bytes in length for Blake2s and babel-hmac can be expected to zero-pad? = Or are you still expecting info-model to do the zero-padding before providi= ng to babel-hmac? Barbara From nobody Wed Aug 14 11:25:27 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 EAC4B120D2B for ; Wed, 14 Aug 2019 11:25:25 -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 hVMmTrmaLBKS for ; Wed, 14 Aug 2019 11:25:24 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBBDD120127 for ; Wed, 14 Aug 2019 11:25:23 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id t14so28167lji.4 for ; Wed, 14 Aug 2019 11:25:23 -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=LymZzsLnFpl8NkPtrs13W8mwirspp3KZpvMgwnU48Pw=; b=sbQFwgJG3d1y9Glu/+Aj7I+Go7fgYVMIYW93kbb2FVzud0c4fSWxC/2bfIb4dAwBea ufuWSuX5P/rLFe35VB0C6m1UssANyfhv6PwRCM6W12z97gbBblA7wVdn0i0gfTxXc8uQ r7jwkoXYmHftAhvcQtFJT8l4rmwqzYq1sc1c3pNqc8eoXHJZp0Fskh2G4WNFGFoN8sQd xDEYj9S1Kzhci6Qqw3gDFHDGDAt4LssAbiB993ivv/C/BTiOJy/JarJQrqLp2hI3NCig FNSSQFCDE1ZfIiDfFRt16uI0i3g9jmVzgScxJmzXD9QDQ7Y/9tyYMDF+Ac9TnhwVPLas o5wQ== 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=LymZzsLnFpl8NkPtrs13W8mwirspp3KZpvMgwnU48Pw=; b=jERjr7kokDhpdCgfYvjvphWoHds26BXu0wSEJmH/MZxa9gTS0hcd+oG0vzkFAq29d1 bJzbGZiKb8ub9Xc6SGjSsEO/Xa15VZhS7TQUEw8EJ1dEC5duyC7wTDVE4IV7vYDrLtKg M0Hehp5qHMoVj/IqJmPsCaVmoDo9K3b4kGDQ5rJFcS1YSQv53uM4JvXcmIDKYYyoSTD6 lEISpbBRE5iCJ3ewkIymUikZ5VCNs/kJwIvR+IqD8qjiCL/tnoocczOmCFbMerRxbsBV JofgjiC+1vawzZ8LKg8WwqUctmXvZghFlYsYlqTcNw8CigGNDLMBwX6tpALQOR4evt+i k7ww== X-Gm-Message-State: APjAAAX1RQV546lLM0cU7TM4ZS4NHhDMqXaNOzdjoMamsJXsGmkJWaw1 qDEIjh7AgknhyGO+GHRzyAbMAEIn0uwe0TZKMXY= X-Google-Smtp-Source: APXvYqxs70QPJA3mSR10H2oU1GBMel26ruXtULLbyPG6rVMKiWjbb0DrplyivvD6yAsK2kX4NFVva8nrqa6fDNEJEoU= X-Received: by 2002:a2e:7f05:: with SMTP id a5mr573928ljd.190.1565807122085; Wed, 14 Aug 2019 11:25:22 -0700 (PDT) MIME-Version: 1.0 References: <8736i5ul8p.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E26794B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87v9v0ucba.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267D1B@GAALPA1MSGUSRBF.ITServices.sbc.com> <87r25ou3ri.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E267FBE@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E2681C5@GAALPA1MSGUSRBF.ITServices.sbc.com> <87mugcu09v.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269246@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E2698C0@GAALPA1MSGUSRBF.ITServices.sbc.com> <87d0h7tyr5.wl-jch@irif.fr> In-Reply-To: <87d0h7tyr5.wl-jch@irif.fr> From: David Schinazi Date: Wed, 14 Aug 2019 11:25:11 -0700 Message-ID: To: Juliusz Chroboczek Cc: "STARK, BARBARA H" , "babel@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004c7c1f059017e179" Archived-At: Subject: Re: [babel] HMAC: removed constraint on the key stored in interface table 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: Wed, 14 Aug 2019 18:25:26 -0000 --0000000000004c7c1f059017e179 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Juliusz's sentiment here. We need to make sure implementations don't preprocess keys, because that could break interoperability, but other than that we shouldn't restrict users. I don't like the inconsistency of allowing something in the Babel+Babel-MAC specs and not in the information model. As an implementer that would confuse me. On Wed, Aug 14, 2019 at 11:01 AM Juliusz Chroboczek wrote: > > SHOULD =3D wiggle room. I know IETF people think SHOULD means you > should > > have a really good reason not to do it. Most implementers just treat > SHOULD as > > optional, though. And =E2=80=9Cbecause I didn=E2=80=99t feel like it=E2= =80=9D tends to be their > =E2=80=9Creally > > good reason=E2=80=9D. I would prefer to constrain key lengths with MUST > statements. > > RFC 6126bis takes the following approach: > > - MUST =3D not doing it will prevent interoperability; > - SHOULD =3D not doing it is a bad idea, but doing it will not prevent > interoperability. > --0000000000004c7c1f059017e179 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Juliusz's sentiment here. We need to make= sure implementations don't preprocess keys, because that could break i= nteroperability, but other than that we shouldn't restrict users.
<= br>
I don't like the inconsistency of allowing something in t= he Babel+Babel-MAC specs and not in the information model. As an implemente= r that would confuse me.

On Wed, Aug 14, 2019 at 11:01 AM Juliusz Chro= boczek <jch@irif.fr> wrote:
> <bhs> SHOUL= D =3D wiggle room. I know IETF people think SHOULD means you should
> have a really good reason not to do it. Most implementers just treat S= HOULD as
> optional, though. And =E2=80=9Cbecause I didn=E2=80=99t feel like it= =E2=80=9D tends to be their =E2=80=9Creally
> good reason=E2=80=9D. I would prefer to constrain key lengths with MUS= T statements.

RFC 6126bis takes the following approach:

=C2=A0 - MUST =3D not doing it will prevent interoperability;
=C2=A0 - SHOULD =3D not doing it is a bad idea, but doing it will not preve= nt
=C2=A0 =C2=A0 interoperability.
--0000000000004c7c1f059017e179-- From nobody Wed Aug 14 12:34:17 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 D3F53120E2E for ; Wed, 14 Aug 2019 12:34:14 -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 u3BOc9ID2-dS for ; Wed, 14 Aug 2019 12:34:13 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 496D212085D for ; Wed, 14 Aug 2019 12:34:13 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7EJWvVX008026; Wed, 14 Aug 2019 21:32:57 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A4C9F47E8C; Wed, 14 Aug 2019 21:33:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id LpkNfZZuC-66; Wed, 14 Aug 2019 21:32:59 +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 E16EA47E89; Wed, 14 Aug 2019 21:32:58 +0200 (CEST) Date: Wed, 14 Aug 2019 21:32:58 +0200 Message-ID: <87blwrtudx.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'babel@ietf.org'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E269981@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> <87ftm3u0a6.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269981@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 14 Aug 2019 21:32:57 +0200 (CEST) X-Miltered: at korolev with ID 5D5461E9.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D5461E9.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 : 5D5461E9.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] info-model: preparing -09 on github 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: Wed, 14 Aug 2019 19:34:15 -0000 > Is this suggesting that it's ok for info-model to provide babel-hmac > with any value between 0 and 64 bytes in length for HMAC-SHA256 or > between 0 and 32 bytes in length for Blake2s and babel-hmac can be > expected to zero-pad? Or are you still expecting info-model to do the > zero-padding before providing to babel-hmac? The former. You give me anything between 0 and 32/64, and I deal with it. -- Juliusz From nobody Wed Aug 14 12:48:25 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 27453120E71; Wed, 14 Aug 2019 12:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Zb0l0PzrYliK; Wed, 14 Aug 2019 12:48:11 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 E239B120E68; Wed, 14 Aug 2019 12:48:10 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7EJm3GV006408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 15:48:07 -0400 Date: Wed, 14 Aug 2019 14:48:03 -0500 From: Benjamin Kaduk To: Juliusz Chroboczek Cc: The IESG , draft-ietf-babel-hmac@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org Message-ID: <20190814194802.GB88236@kduck.mit.edu> References: <156521429138.8333.12124544758210076970.idtracker@ietfa.amsl.com> <87h86pcmzk.wl-jch@irif.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h86pcmzk.wl-jch@irif.fr> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-hmac-08: (with DISCUSS and COMMENT) 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: Wed, 14 Aug 2019 19:48:16 -0000 On Sat, Aug 10, 2019 at 12:51:11PM +0200, Juliusz Chroboczek wrote: > Dear Benjamin, > > Thank you for your review. > > > Are the HMAC keys required to be the hash function's block size or its > > output size? Section 3.1 says just "the length of each key is exactly > > the hash size of the associated HMAC algorithm", and "hash size" > > conventionally refers to the output length. The referenced Section 2 of > > RFC 2104 concerns itself with the hash's compression function's block > > size B, which is generally different. > > The block size, good catch. > > > Also in Section 3.1, if we are going to claim that a "random string of > > sufficient length" suffices to initialize a fresh index, we need to > > provide guidance on what constitutes "sufficient length" to achieve the > > needed property. > > Section 6 says > > This > property can be satisfied either by using a cryptographically secure > random number generator to generate indices and nonces that contain > enough entropy (64-bit values are believed to be large enough for all > practical applications), or by using a reliably monotonic hardware > clock. And you don't want to make a forward reference to Section 6? > > Blake2s is a keyed MAC, but is not an HMAC construction. If we are to > > allow its usage for providing integrity protection of babel packets > > directly, we therefore cannot refer to the preotection scheme as "HMAC" > > generically. Fixing this will, unfortunately, be somewhat invasive to > > the document, since we mention HMAC all over the place. I believe that > > "Keyed Message Authentication Code (Keyed MAC)" is an appropriate > > replacement description. > > I disagree. While you're technically correct, for the typical network > operator "HMAC" is a familiar term, "Keyed MAC" is not. I think that > renaming this document to "Keyed MAC" would make it less informative. Well, I am pretty uncomfortable about saying things that are not true! I'm willing to accept using "HMAC" as a commonly accepted shorthand for the actual primitives being used, but only if there's a statement explaining that the term is used as a shorthand and that the implementation details can be different. > > The suggestion that the large challenge nonce size admits storage of > > state in a secure "cookie" in the nonce is true, however, implementing > > this properly presents some subtleties, and it seems like something of > > an attractive nuisance to suggest that it is possible without giving > > adequate guidance at how to do it safely. Unfortunately, the best > > reference I can think of, offhand, is the obsoleted RFC 5077. > > I agree. This is something that we considered in the design of the > protocol (which is why Nonces are allowed to be so large), but never > implemented ourselves; it would probably be some work to get it right. > Hence the very careful formulation ("might"). Let me know if you want to > suggest a different formulation. It's probably okay to leave this as speculative (since there's not an existence proof), but I think it's irresponsible to not also include a disclaimer of at least "Note that such schemes will need to consider what degree of "freshness" is required of a challenge and the risk of replay for the encoded state, among other things". > > Let's also have a discussion about whether 64 bits of randomness is > > always sufficient; I left a longer note down in the Comment since I > > don't expect this to end up being a blocking point. > > Let's. See below. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > This is a symmetric-keyed scenario, so most attacks that involve a > > compromised node will be "uninteresting", in that once the key is > > exposed all guarantees are lost. However, it may still be worth noting > > that a compromised node can cause disruption on multi-access links > > without detection since there is no "end of generation" signal when a > > node changes its index. That is, if node B reboots or otherwise resets > > its index/pc, then compromised node C can spoof packets from B with the > > previous index and honest node A will accept them, and B will be unable > > to detect that it has been spoofed. On the flip side, we may want to > > discuss that B can watch for messages that spoof its source address to > > detect compromised nodes. > > I may be misunderstanding what you mean, but I think that's not the case. > If B reboots, then: > > - if A has state about B, then any previous PC will be rejected; > - if A has no state about B, then A will send a challenge which C won't > - be able to reply to. > > Are we misunderstanding each other? A and C both have state about B, which is retained when B reboots. While B is still rebooting or otherwise initializing, C can forge a message "from" B that A will accept, and C can continue to do so until A sees the new (legitimate) index from B and switches over to the new generation. So A has accepted false input but neither A nor B are aware of it. > > Is there any need for initial PC value randomization? > > I don't see why. I don't, either, but just wanted to get a second opinion from an actual expert. > > Do we want to recommend starting at 0 or 1 (or prohibit recipients from > > assuming that the initial value for an index will be that)? > > The initial value as well as the rate of increase are arbitrary. For > example, a node may use a hardware clock (suitably offset to fit in 32 > bits) as the PC. I agree that they're arbitrary, but have a lot of painful experience with protocol participants making assumptions about underspecified behavior that ended up not being protocol invariants, with subsequent breakage. If you think the existing ecosystem is healthy enough that there's not a real risk of problems down the line, I can accept that, but I wanted to raise the topic. > > Section 1 > > > "This document obsoletes RFC 7298" should be in the Introduction as well > > as the abstract. > > Done. > > > Is the capability for an attacker to modify/spoof Babel packets in > > order to cause data to get dropped or cause a routing loop worth > > mentioning here? > > No, that's a particular case of redirecting. > > > Section 1.2 > > > o that the Hashed Message Authentication Code (HMAC) being used is > > invulnerable to pre-image attacks, i.e., that an attacker is > > unable to generate a packet with a correct HMAC; > > > I think it's more conventional to include the caveat "without [access > > to/knowledge of] the secret key" for this sort of statement about HMAC. > > Agreed, done. > > > The first assumption is a property of the HMAC being used. The > > second assumption can be met either by using a robust random number > > generator [RFC4086] and sufficiently large indices and nonces, by > > using a reliable hardware clock, or by rekeying whenever a collision > > becomes likely. > > > Does this rekeying option require an external operation/management actor > > to trigger it? It might be worth mentioning with some operational > > considerations. > > Disagree. I think my main quesetion here is who determines, and how, "whenever a collision becomes likely". Some protocols have in-band mechanisms for peers to make such a determination and initiate rekeying automatically; from what I understand, babel-hmac does not. If we actually expect deployments to encounter scenarios where rekeying is necessary to preserve security, we should be pretty clear about who has the responsibility to do so. > > o among different nodes, it is only vulnerable to immediate replay: > > if a node A has accepted a packet from C as valid, then a node B > > will only accept a copy of that packet as authentic if B has > > accepted an older packet from C and B has received no later packet > > from C. > > > nit: I don't think "A has accepted a packet from C" is quite the right > > precondition; it seems to be more like "A has received a valid packet > > from C", since whether or not A (as an attacker) considers it valid is > > irrelevant to whether (honest) B will. > > C is the attacker here, A is honest. I was (apparently) reading this differently -- "replay" could be initiated by an RFC 3552 attacker in the network even without knowledge of the key. So I thought that all three of A, B, and C could be honest and the risk of replay would still exist. Phrased alternately, A and B make independent assessments of a packet's validity; if they are both honest and properly implemented those assessments will produce identical output, but it is not the case that B accepts a packet as authentic *because* A has already done so. > > Section 4.1 > > > If we had identifiers for symmetric keys or HMAC algorithms, we could > > include those identifiers in the pseudo-header and thereby gain some > > protection from downgrade/HMAC-stripping attacks in the presence of a > > weak keyed MAC algorithm. (I think we have to include both what we are > > sending and what we think the peer can do in order to get substantial > > protection, though, which diminishes the appeal for multicast > > scenarios.) > > This is a symmetric algorithm, for downgrade attacks to work the victim > would need to be configured with a weak key. I therefore don't see how > this added complexity helps. I've seen plenty of cases where systems are still configured with single-DES keys as well as AES keys (whoops!). In this particular case the cost/benefit analysis may not favor the complexity, but I want that to be a conscious decision and not something we slip into by default. > > nit: I don't think the past tense is correct for "packet was carried > > over IPvN", since we're talking about a pseudo-header used in > > computations before the packet is sent. > > Agreed, done. > > > It might be worth reiterating that every time a packet goes on the wire, > > it gets a fresh PC, regardless of whether it's a "retransmit" after a > > timeout or a new message. > > There are no retransmits in this protocol. Hence the scare quotes. Can you guarantee that no one will look at this and say "I'll just cache this challenge I send to a peer and re-send it (rate limited) to that peer in response to traffic I can't authenticate, until I get a valid reply"? > > interface MTU (Section 4 of [RFC6126bis]). For an interface on which > > HMAC protection is configured, the TLV aggregation logic MUST take > > into account the overhead due to PC TLVs (one in each packet) and > > HMAC TLVs (one per configured key). > > > (per configured key, and also per packet, right?) > > Of course. The MTU applies per packet. > > > Does it matter whether the sender increments the PC before or after > > inserting it in the PC TLV? (I think the only potential impact would be > > as it relates to the value sent in response to a challenge nonce, but > > the "increment by a positive not-necessarily-one amount" property may > > provide all the flexibility we need.) > > I don't think so. Thanks for thining about it. > > Section 4.3 > > > Validating the HMACs is the sort of operation that we tend to recommend > > be done in constnt-time to avoid side channel attacks. I don't have a > > concrete attack handy here at the moment, though. > > I frankly have no idea if that's necessary or not. FWIW, the protocol is > asynchronous, and there is jitter applied to packets. My super-quick assessment is that the timing channel could be used to "pick off byte by byte" an attacker's guess at the HMAC of some fixed plaintext that the attacker would later replay (with valid HMAC) to some other participant. But I think the source/destination addresses in the pseudo-header limit the potential scope a fair amount -- the attacker would have to use the intended destination address and spoof the source address for the intended forgery, and once the attacker is doing that, it becomes somewhat similar to an online brute-force attack to achieve the same forgery (since the final transaction would have the actual effect that the spoofed/replayed packet would), and the timing channel becomes harder to observe if the replies are going to a different place. > > When a PC TLV is encountered, the enclosed PC and Index are saved > > for later processing; if multiple PCs are found (which should not > > happen, see Section 4.2 above), only the first one is processed, > > the remaining ones MUST be silently ignored. If a Challenge > > > Any reason to not just drop the whole packet if there are multiple PCs > > present? I see this is not rfc7298bis but don't know what level of > > breaking change is reasonable. > > It doesn't matter much, it's a "cannot happen" case. (Note that the HMAC > has already been validted at this point, so it isn't a security issue.) Oh, it's definitely not a security issue; this is more of a philosophical question of what to do in the face of a peer with a "totally broken" implementation. The TLS ecosystem, for example, has been bitten by the need for historical compatibility quirks and is now (over?)compensating by being quite strict about rejecting malformed things. > > o The preparse phase above has yielded two pieces of data: the PC > > and Index from the first PC TLV, and a bit indicating whether the > > packet contains a successful Challenge Reply. If the packet does > > not contain a PC TLV, the packet MUST be dropped and processing > > stops at this point. If the packet contains a successful > > Challenge Reply, then the PC and Index contained in the PC TLV > > MUST be stored in the Neighbour Table entry corresponding to the > > sender (which already exists in this case), and the packet is > > accepted. > > > I'd suggest explicitly stating that if there is a challenge reply that > > doesn't validate, the packet should be discarded. > > Or are there multicast scenarios where that is not the case? The key > > point being to emphasize that just the presence of a challenge reply > > doesn't mean anything, it has to be valid in order to have significance. > > This is already the case -- a packet with an incorrect challenge reply is > treated just like a packet with no challenge reply. This was an attempt to "consider all the ways in which a peer could misbehave": it could send two, one valid and one invalid; or an invalid challenge reply even though it didn't need to supply one at all; or ... (This is basically the same philosophical question as above.) > I don't feel comfortable with discarding a packet just because it contains > an obsolete challenge reply -- what if the packet also contains a challenge > request? It also complicates the code, by requiring three challenge > verdicts (positive/neutral/negative) rather than just two (positive/neutral). Okay. > > o At this stage, the packet contains no successful challenge reply > > and the Index contained in the PC TLV is equal to the Index in the > > Neighbour Table entry corresponding to the sender. The receiver > > compares the received PC with the PC contained in the Neighbour > > Table; if the received PC is smaller or equal than the PC > > contained in the Neighbour Table, the packet MUST be dropped and > > processing stops (no challenge is sent in this case, since the > > mismatch might be caused by harmless packet reordering on the > > link). Otherwise, the PC contained in the Neighbour Table entry > > is set to the received PC, and the packet is accepted. > > > Does this mean that if packet reordering is encountered, we will just > > not process packets that get reordered later? (AFAIK babel will still > > work fine in such conditions, so I'm just checking my understanding.) > > Correct on both counts. The WG did consider using a sliding window in the > style of DTLS, but we finally decided against it for the sake of simplicity. > Since this is a link-local protocol, packet reordering is unlikely. Thanks for confirming (and sharing the WG's discussions). > > it MAY ignore a challenge request in the case where it it contained > > > nit: s/it it/it is/ > > Done, thanks. > > > The same is true of challenge replies. However, since validating a > > challenge reply is extremely cheap (it's just a bitwise comparison of > > two strings of octets), a similar optimisation for challenge replies > > is not worthwile. > > > Er, challenge reply validation still requires the HMAC validation step, > > right? > > At this stage we've already verified the HMAC. The only thing we could > potentially save would be a bitwise comparison, and that's not worth it. Right, but just "validating a challenge reply" in vacuum could be taken to include validating the HMAC on the containing packet. An editorial comment, to be sure, but "poses minimal incremental cost" would avoid it. > > Section 4.3.1.1 > > > When it encounters a mismatched Index during the preparse phase, a > > node picks a nonce that it has never used with any of the keys > > currently configured on the relevant interface, for example by > > drawing a sufficiently large random string of bytes or by consulting > > > (same comment as above about "sufficiently large") > > See Section 6. > > > Section 4.3.1.2 > > > buffered TLVs in the same packet as the Challenge Reply. However, it > > MUST arrange for the Challenge Reply to be sent in a timely manner > > (within a few seconds), and SHOULD NOT send any other packets over > > the same interface before sending the Challenge Reply, as those would > > be dropped by the challenger. > > > I think this "SHOULD NOT" (or rather, "would be dropped by the > > challenger") is predicated on the challenge request having not been a > > replay, but I do not see anything requiring the recipient to do nonce > > uniqueness validation. > > This doesn't require delaying any packets, quite the opposite, it says > that you SHOULD send out the challenge reply before sending out any more > packets. We seem to be miscommunicating; let me try again. Consider a multi-access link with honest A and B, and attacker C. A sends a challenge request to B, that C observes and records. B sends a challenge reply, and A sends some more traffic. What happens if C starts spamming replayed copies of that challenge request towards B? This note about constructing Challenge Reply is during the preparse stage, before index/PC validation. Can C cause B to spend a lot of time generating challenge replies and reduce the amount of time spent sending actual data? (There's also a variant where C knows the HMAC key and spoofs fresh challenge requests.) > > Section 4.3.1.3 > > > neighbour that sent the Challenge Reply. If no challenge is in > > progress, i.e., if there is no Nonce stored in the Neighbour > > Table entry or the Challenge timer has expired, the Challenge Reply > > MUST be silently ignored and the challenge has failed. > > > I think "the challenge has failed" is predicated on the challenge reply > > being in response to a challenge sent by this node. The previous > > section's "send the Challenge Reply to the unicast address" seems to > > imply that there are no multicast scenarios which would make that not > > the case, but I just wanted to check my understanding. > > That's right. > > > Section 5 > > > Do we need to say whether sub-TLVs are allowed in any of these TLVs? > > (Presumably they are not, since the length is needed in order to > > identify the length of the variable-length fields, but being explicit > > can be useful.) > > 6126bis only specifies which TLVs do allow sub-TLVs, I think it makes > sense to follow the same format. > > > Section 5.1 > > > This [HMAC] TLV is allowed in the packet trailer (see Section 4.2 of > > [RFC6126bis]), and MUST be ignored if it is found in the packet body. > > > side note: Using "MUST ignore" vs. "discard the packet" has some > > protocol evolution consequences -- it in practice then becomes an > > alternative padding technique for use in packet bodies, and if ever used > > as such then could lead to a way to fingerprint an implementation or be > > used as a hidden channel for sending other data. But, I see that > > ignoring at the TLV level is something of a core babel design choice, > > Right. > > > and I don't see any serious consequences that would merit revisiting > > that decision. > > Good. > > > Section 6 > > > This mechanism relies on two assumptions, as described in > > Section 1.2. First, it assumes that the hash being used is > > > s/hash/MAC/ > > I'm confused. This section refers to pre-image attacks, which I was under > the impression is a property of the hash. The thing we're sending over the wire is a MAC (sometimes HMAC-SHA-256; sometimes Blake2s; potentially other things in the future). MACs are almost universally constructed using hash functions, so it's pretty natural to think of them fairly interchangably, but there do exist other constructions like CBC-MAC. (Also, I think technically we're concerned about *second* preimage resistance, since we're effectively sending the first preimage as the message.) Getting this second-preimage resistance from CBC-MAC constructs that take variable-length input requires some care, though! > > It would require a bit more thought to convince me that 64-bit indices > > are sufficient for *all* cases. Specifically, if we want full 64-bit > > strength, then the 64-bit space cannot be controlled or affected by the > > attacker to cause collisions. But I think there will be a reasonable > > risk that an attacker can cause a given node to need to regenerate its > > index on demand (e.g,. but triggering a bug that crashes it, or power > > cycling it) > > Assume the attacker is able to crash the node at will, and that the node > needs 10s to reboot. If we assume the attacker will start seeing > collisions after 2^32 tries, then this will happen after 1360 years, which > is slightly more than the duration of the Byzantine empire. "Attacks only get better; never worse." My point was to show that it's plausible for an attacker to be able to trigger index generation, and that if we want to be robust in the face of future attacks, we should consider a threat model that allows them to do so at will. Just because we can't see how that would happen now doesn't mean very much unless we have some sort of proof to back it up. > The Babel working group recommends rekeying whenever Anatolia is invaded. > > > present at the receiver. If the attacker is able to cause the > > (Index, PC) pair to persist for arbitrary amounts of time (e.g., by > > repeatedly causing failed challenges), then it is able to delay the > > packet by arbitrary amounts of time, even after the sender has left > > the network. > > > I'd suggest adding another sentence describing the potential > > consequences of selectively delayed input (i.e., messing up the > > routing). > > We don't know about any such consequences. Still, we believe it is good > to avoid this situation. Maybe I'm confused, but suppose a node advertises a really-low-metric path to a prefix, but then drops off the network. If we cause an announcement of that path to be delayed for a while, then when ultimately processed it is likely to end up being the lowest-metric path to that prefix for many of its neighbors. Will those neighbors not try to use that path (and fail to deliver traffic since the node is actually down)? > > protocol (the data structures described in Section 3.2 of > > [RFC6126bis] are conceptual, any data structure that yields the same > > result may be used). Implementers might also consider using the fact > > > nit: that's a comma splice in the parenthetical; a semicolon would be better. > > I've added a conjunction, I didn't realise such usage is unacceptable. Introspection suggests that it's a pet peeve of mine, but I do expect it to be on the list of things the RFC Editor staff look for (and if we can fix the easy stuff before it gets to them, they will have more time to do a better job with the stuff we missed). Thanks, Ben From nobody Wed Aug 14 13:09:35 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 262A51208A4 for ; Wed, 14 Aug 2019 13:09:33 -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 L2RplIIx0YVP for ; Wed, 14 Aug 2019 13:09:30 -0700 (PDT) Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (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 96FA7120842 for ; Wed, 14 Aug 2019 13:09:30 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id 4so81471pld.10 for ; Wed, 14 Aug 2019 13:09:30 -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=M3yyaxPQZQ/21bMNVGp1cUgQ5VGJqVrGK6NCx+sH/K4=; b=pHFhx96/V/SzIpwoCpxdhl5cOCrFMrnZT4FKe9sX5nqkzVe0qi31OnHcCobC44nICz aRCcWmZSB7/a5QopUsgWbU+WrTzHkRBDbKXxTEXulIaGTzS0c3rMmvW1uAj845iRClxJ m61BQatE0jiCCJuLU13tSQjT+n0IfCU6eXeKlmZN2NveGt8C13APRIKSsc+xyGBM/a+f BXHN2bHlmkFlx4luCwd+OUTtrfcTrCHDw0lrOuSOYprOztmZA1CzWKGzEsOCKDXLPMuB s1U7zvUHaItmFtVk3GyC1Zv/XLUFPnEyNa7aycM8i1CEX/gvEJ4TXVWOgZrTo3v0KG8O bNEQ== 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=M3yyaxPQZQ/21bMNVGp1cUgQ5VGJqVrGK6NCx+sH/K4=; b=rBIJn1y66L87/P2YtqYMH9DK3aYsnC/LK0Dm8KZzVXqbBTkLp/ZjXSKTixeRfo70Li EOUcfCeN5hUPV/q5j4Q81ayKDPxH0DRExSje4/SyB2fORcesn4CAqa5xyZ+w30CtYRsc ywl0Q0r++25FL7o/trmTSRtdNiLmM1dCy0n2OcsmRuN7ENxeYB6v++hAj1YCv0fkxIQY ESw4fvFeSqSIKKNFQox88xp3bIPe7Psm6Bclg6xGK5TSYF43Kf1Pe1HAede0cNnlOtJB PoBjPruXXOm7NyduozMlTGxSID1GwL89kmEsPvZCZQ92qT8ObfynVSQvaTj/256uzHoX hO0Q== X-Gm-Message-State: APjAAAUW38sDt3pIw5u7d5TOgfFBRZDh4w6KVweeHKadVj8W2wvRKvaA WmRZ4JWIkgv20mPdvDK2Xys= X-Google-Smtp-Source: APXvYqxqBcdbmkzKMQUUaoBq40KmjY8jMPMv/v/DZGi5Tk4mjS4eL8PfXvQhJE5pb6VnZAR5PuGHhg== X-Received: by 2002:a17:902:f30f:: with SMTP id gb15mr1037672plb.233.1565813369990; Wed, 14 Aug 2019 13:09:29 -0700 (PDT) Received: from [10.33.122.240] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id o130sm714824pfg.171.2019.08.14.13.09.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Aug 2019 13:09:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mahesh Jethanandani In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Wed, 14 Aug 2019 13:09:28 -0700 Cc: "babel@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9D88394A-243B-4A3B-9B8D-6253991EC964@gmail.com> References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] info-model: preparing -09 on github 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: Wed, 14 Aug 2019 20:09:33 -0000 Hi Barabar, I have one comment on the draft. Section 3.3 babel-interface-obj has a parameter babel-mac-algorithm, but = there is no corresponding explanation for it below. Possibly this might = suffice: babel-mac-algorithm: The name of the MAC algorithm used on this = interface. The value is one of the identities listed as part of = babel-mac-algorithms at a global level. Cheers. > On Aug 14, 2019, at 8:40 AM, STARK, BARBARA H wrote: >=20 > I've got a preview of the upcoming -09 version on my github. > https://github.com/bhstark2/babel-information-model >=20 > The README there has links to the current editor's copy at > = https://bhstark2.github.io/babel-information-model/draft-ietf-babel-inform= ation-model.html >=20 > and for a diff between this and -08 at > = http://tools.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/id/draft-ietf-b= abel-information-model-08.txt&url2=3Dhttps://bhstark2.github.io/babel-info= rmation-model/draft-ietf-babel-information-model.txt >=20 > It should have everything that I agreed to do so far, including the = nits I mentioned in request for last call, changes from the 2 initial = emails Juliusz sent (what I agreed to change was in my response), and = changing hmac to mac in all but a couple of places (the doc reference = right now is still to babel-hmac, and "HMAC-SHA256" wasn't changed). I = deleted all the issue and change log stuff at the end. >=20 > Things I haven't changed but where changes may still happen based on = discussion... > 1. link properties / metric-comp-algorithm / = interface-metric-algorithm / split-horizon: I'm leaning away from any = new objects for link property grouping. It may still be useful to = provide additional info to help people understand the allowed values.* > 2. babel-mac-key-value description to constrain it according to the = babel-mac-key-algorithm allowed key length > Barbara >=20 > * Proposal was > babel-metric-comp-algorithms: List of supported cost computation > algorithms. Possible values include "2-out-of-3", and "ETX". > "2-out-of-3" (a specific case of K-out-of-j ) link sensing is = suitable for wired links that are either > up, in which case they only occasionally drop a packet, or down, = in > which case they drop all packets. "ETX" is a link-quality = estimation algorithm that is > designed to work well with the IEEE 802.11 MAC. >=20 > babel-interface-split-horizon: Indicates whether or not the split > horizon optimization is used when calculating metrics on this > interface. A value of true indicates split horizon optimization > is used. Split horizon optimization is useful when running over a > transitive, symmetric link technology, e.g., a > point-to-point link or a wired LAN technology such as Ethernet.=20= > It is not appropriate for links not known to be symmetric and = transitive; in particular, > split horizon is not appropriate for decentralized wireless link > technologies (e.g., IEEE 802.11 in ad hoc mode) when routing = updates > are sent over multicast. > --------------------------------------------- > Alternate proposal (since above text was copied straight from = rfc6126bis) > babel-metric-comp-algorithms: List of supported cost computation > algorithms. Possible values include "2-out-of-3", and "ETX". > "2-out-of-3" is a specific case of K-out-of-j described in = [rfc6126bis] A.2.1. > "ETX" is described in [rfc6126bis] A.2.2. >=20 > babel-interface-split-horizon: Indicates whether or not the split > horizon optimization is used when calculating metrics on this > interface. A value of true indicates split horizon optimization > is used. Split horizon optimization is described in [rfc6126bis] = 3.7.4. >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel Mahesh Jethanandani mjethanandani@gmail.com From nobody Wed Aug 14 16:04:22 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 5F480120901 for ; Wed, 14 Aug 2019 16:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VbcN-THq8TCZ for ; Wed, 14 Aug 2019 16:04:20 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 101511208EF for ; Wed, 14 Aug 2019 16:04:20 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7EMtElM015011; Wed, 14 Aug 2019 19:04:19 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2uctwqs1hk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 19:04:18 -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 x7EN4HpN006363; Wed, 14 Aug 2019 19:04:17 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7EN4BY7006189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 14 Aug 2019 19:04:11 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 686D44014665; Wed, 14 Aug 2019 23:04:11 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30483.vci.att.com (Service) with ESMTPS id 567AA4014661; Wed, 14 Aug 2019 23:04:11 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.84]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0439.000; Wed, 14 Aug 2019 19:04:11 -0400 From: "STARK, BARBARA H" To: "'Mahesh Jethanandani'" CC: "'babel@ietf.org'" Thread-Topic: [babel] info-model: preparing -09 on github Thread-Index: AdVSswKr0W4Y1vOsQfS00DtIY7BoYgASrF8AAAJ12gA= Date: Wed, 14 Aug 2019 23:04:10 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E26A102@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> <9D88394A-243B-4A3B-9B8D-6253991EC964@gmail.com> In-Reply-To: <9D88394A-243B-4A3B-9B8D-6253991EC964@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.236.28] 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-08-14_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=960 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908140209 Archived-At: Subject: Re: [babel] info-model: preparing -09 on github 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: Wed, 14 Aug 2019 23:04:22 -0000 > From: Mahesh Jethanandani > Hi Barabar, >=20 > I have one comment on the draft. >=20 > Section 3.3 babel-interface-obj has a parameter babel-mac-algorithm, but > there is no corresponding explanation for it below. Possibly this might > suffice: >=20 > babel-mac-algorithm: The name of the MAC algorithm used on this > interface. The value is one of the identities listed as part of babel-mac= - > algorithms at a global level. >=20 > Cheers. Argh. Thx. That parameter was supposed to have been removed from interfaces= (per one of Juliusz' email). Apparently I only removed the description. It= went into babel-mac-keys-obj as babel-mac-key-algorithm. I'll delete it fr= om babel-interfaces-obj. Barbara From nobody Wed Aug 14 16:05:27 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 D2BAE120901; Wed, 14 Aug 2019 16:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECchWI0z7Qoy; Wed, 14 Aug 2019 16:05:22 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 1D8F31208EF; Wed, 14 Aug 2019 16:05:21 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7EN5F2U022009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 19:05:18 -0400 Date: Wed, 14 Aug 2019 18:05:14 -0500 From: Benjamin Kaduk To: Juliusz Chroboczek Cc: The IESG , draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org Message-ID: <20190814230513.GD88236@kduck.mit.edu> References: <156521599894.8313.13827924927219698158.idtracker@ietfa.amsl.com> <87v9v57pjm.wl-jch@irif.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87v9v57pjm.wl-jch@irif.fr> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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: Wed, 14 Aug 2019 23:05:26 -0000 On Sat, Aug 10, 2019 at 03:54:53AM +0200, Juliusz Chroboczek wrote: > Dear Benjamin, > > Thank you very much for your detailed review. > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > I don't think that all of the arithmetic specified in Section 3.2.1 is > > well defined. Specifcally, the formulations involving bitwise AND > > assume that the input to the bitwise AND is nonnegative, which does not > > seem to be implied by the other stated constraints. (For example, an > > "integer n" may well be negative.) > > I've added "nonnegative" (we never add a negative integer to a seqno, not > even when we undo history in Appendix A.2). > > (The formulation is correct even for negative numbers independently of > precision if we assume two's complement.) Agreed, and thanks. > > It might be simpler to just use the modular arithmetic flavor > > I agree that it would be simpler, but modular arithmetic is a common > source of bugs, especially in languages where the modulo operation does > not yield a nonnegative integer (grr). The bitwise formulations > constitute useful guidance for the implementer. Okay. > > Section 3.5.2 needs to explicitly say that the c and m arguments to M() > > are the local link cost and the advertised metric, > > Done. > > > Section 3.8.2.1 notes that "[d]ue to duplicate suppression, only a small > > number of such requests will actually reach the source." (for seqno > > requests intending to avoid starvation). But Section 3.8.1.2 only has a > > SHOULD-level requirement to suppress duplicate seqno requests, so I > > think there is an internal inconsistency. > > The idea here is that it's a pretty strong SHOULD -- you'd need to be > really constrained for resources to not implement it. If that's okay, > I'll leave it as it stands, if that's okay with you. It still feels like an internal inconsistency to me. How would you feel about s/will actually reach/are expected to actually reach/? > > I think we may need to have a discussion about the feasibility of > > multicast acknowledgment requests with only a 16-bit nonce. > > Section 3.3. An acknowledgment MUST be sent to a unicast destination. I saw that, which is why I specified "acknowledgment requests". > > The discussion in Section 4.6.9 of computing the prefix from an Update > > message (and parser state) seems a little underspecified when the prefix > > length is not a multiple of 8 bits. > > Agreed, I've added the requirement to clear these bits. Thanks. > > (Additionally, "Plen" is not described as measuring bits, explicitly, > > for any of the PDU descriptions that I remember.) > > Fixed. > > > I appreciate that we have some discussion in Section 4.5 about the need > > for a stateful parser for the babel packet body; this seems like one of > > the riskiest areas of the protocol from the implementation perspective. > > I fully agree. I've always had serious misgivings about this encoding, > and we did discuss deprecating it in 6126bis. Here's some background. > > On the one hand, the encoding is inelegant and easy to get wrong, and > hinders the extensibility of the protocol. On the other hand, it is > dramatically effective in some kinds of networks (networks carrying large > numbers of IPv6 host routes sharing a common prefix), leading to > a reduction in the amount of data being sent, on the order of 40%. > Instead of carrying 40 prefixes in a packet, you carry 60. > > We did consider an alternative, which was to start the packet with a set > of common prefixes that the individual updates could refer to. However, > this turned out to have similar complexity at the parser, while making the > formatter slightly more complex. > > An on-list poll of the implementers active at the time (from memory, so > don't hold me accountable): > > - Markus said "the stateful encoding is not that bad"; > - Toke declared he's okay with parsing the encoding, but his > implementation is not going to send any compressed addresses; > - I don't remember if David expressed an opinion, but since he's into > wireless networks, I'd expect him to be in favour of keeping it. > > So we kept it. > > > However, I think it would be even more helpful to explicitly call out > > what pieces of state are needed, what protocol elements affect the > > state, and what ordering requirements (or non-requirements) there are > > for the interactions between the different protocol elements that affect > > parser state. Can we have a discussion about whether it's appropriate > > to add some text along these lines? > > Sure, we may have a discussion. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > Should there be a "changes since RFC 6126" section that is retained in > > the published RFC? (I assume that Appendix F is going to be dropped.) > > Is that a hard requirement? We've updated all implementations, so it > wouldn't be too useful to anyone, and it would be a fair amount of work. This is the non-blocking Comment section, so no, it's not a hard requirement. My personal interest is to be able to get a summary of the protocol's evolution, what worked and what didn't work, and such, but I don't know what kind of other demand there is for such a thing. On the other hand, putting in the effort to do it know means it's done for everyone, and we aren't stuck with each interested person having to do the research themself. > > The secdir review has some good thoughts (e.g., tracking "link-local" > > IPv4 addresses, discussion of non-protection from hostile insiders), but > > I don't see a response to it. > > The review was sent to us off-list, and we replied in kind. Which points > exactly did you find useful, and how would you like to see them integrated > in the document? Huh, I got a copy on the list (https://mailarchive.ietf.org/arch/msg/secdir/YiUUmWlDlmIGpMoo8cMHu1k8WaM#) and it looks like it should have gone to you as well. What I might want to see integrated in the document depends on the nature of the discussion triggered by the review. The points about doing local-address (subnet?) tracking for IPv4 and the potential for discussion about the potential harm caused by a hostile insider are most poigniant to me, and (relatedly) the risk of attack from anywhere in the v4 internet. The points about integration of the DTLS mechanism with DNS/OCSP/etc. are interesting, but of course probably a better fit for the DTLS document, and the general topic of physical location probably merits some discussion (but IIRC we have covered that fairly well already). > > We use the phrase "a small multiple of" a few times, but I don't > > remember seeing any concrete guidance for what factor to use. Is it > > intended to be closer to 1.1 or to 4? > > It's 3.5, see Appendix B. I've added refs at the relevant places. Ah, thanks. > > In a related vein, there are many places in the document where the > > precise details of processing are left intentionally underspecified > > (e.g., computing a link's cost). I understand that due to the protocol > > guarantees the needed routing will still be achieved even if nodes use > > different parameters and algorithms in these cases, > > Right. > > > but do we expect the details to be chosen on a per-implementation basis, > > or in profile documents, or even left up to operator configuration on > > a per-node basis? > > I liken the situation to that of BGP, where routing policies are left to > the implementation or to the network administrator. In the currently > extant implementations, we use different algorithms depending on the link > layer (Ethernet, WiFi or tunnel). > > In this document, we take the following approach: > > - the normative text stresses the properties that the algorithms used > MUST meet; > - we give examples of algorithms that work well in Appendix A; > - we warn the implementer to be careful. > > From an empirical point of view, this has worked pretty well: independent > reimplementations interoperate. Sure. I'll leave it up to you whether it's worth putting in some text about the expected granularity of policy specification. > > Section 1 > > > The introduction should mention obsoleting 6126 and 7557, in addition to > > doing so in the abstract. > > Done. > > > Section 1.1 > > > Finally, Babel is a hybrid routing protocol, in the sense that it can > > carry routes for multiple network-layer protocols (IPv4 and IPv6), > > whichever protocol the Babel packets are themselves being carried > > over. > > > nit: I think "regardless of which" is better than "whichever", > > Agreed, done. > > > Section 1.2 > > > Second, unless the optional algorithm described in Section 3.5.5 is > > implemented, Babel does impose a hold time when a prefix is > > > Similarly to my comment on the applicability doc, I'm not sure if > > there's one or two things in Section 3.5.5 that would match this > > description. > > I'm not sure what's missing. 3.5.5 clearly states that either you wait > for a fixed timeout, or you do something that doesn't involve waiting for > a fixed timeout. Grammatically, an "optional algorithm" is a single thing. When I look at 3.5.5, I see two things and am thinking to myself "which one do I pick?". It sounds like you want me to treat it as if there's a single algorithm, and the algorithm is "arbitrarily choose one of these two things". It would be a lot easier for me to read if we said something like "the optional algorithm for how long to maintain an infinite metric" or "one of the two options described". Maybe I'm the only one confused by this, though; I can't say. > > Section 2 > > > Conceptually, Bellman-Ford is executed in parallel for every source > > of routing information (destination of data traffic). In the > > following discussion, we fix a source S; the reader will recall that > > the same algorithm is executed for all sources. > > > Just to check my understanding: this "source S" is a source of routing > > information, not a source of data-plane traffic being routed? > > Yes. Added paranthetical. Thanks! > > Section 2.4 > > > Is there a reference for AODV? > > Added. > > > To show that this feasibility condition still guarantees loop- > > freedom, recall that at the time when A accepts an update from B, the > > metric D(B) announced by B is no smaller than FD(B); since it is > > smaller than FD(A), at that point in time FD(B) < FD(A). Since this > > property is preserved when A sends updates, it remains true at all > > times, which ensures that the forwarding graph has no loops. > > > I'm trying to walk through this and missing a step or two. "the metric > > D(B) announced by B is no smaller than FD(B)" is pretty clear, since > > FD(B) is just the minimum value of D(B) over time thus far. But I'm not > > sure I follow how A can preserve the property FD(B) < FD(A) when A sends > > updates. Clearly FD(B(T')) <= FD(B(T0)) for any time T' after T0, but > > suppose FD(B) remains constant but A is off interacting with some other > > node C and finds a great path via C, which correspondingly causes D(A) > > to reduce. Can I get into a situation where > > D(A) < FD(B) <= D(A) + C(A,B) (and thus, the subsequent > > FD(A) < FD(B) <= FD(A) + C(A,B)) if A does not interact with B during > > that time? > > We want to prove that the following property is preserved: > > P: NH(A) = B implies FD(B) < FD(A) > > Assume that initially the following are true: > > NH(A) = B (i) > FD(B) < FD(A) (ii) > > A receives an announcement from C. Then either > > - A doesn't switch its next hop, in which case D(A) doesn't change, > and so neither does FD(A); since FD(B) is nonincreasing, (ii) is still > true, and P is true; or > > - A sets NH(A) := C, so (i) becomes false, and P is true. Okay. So it sounds like I'm supposed to read "accepts an update from B" and interpret that as meaning "that causes NH(A) to be B" as opposed to, say, "this is valid metric data and I am recomputing my routing table in response"? I can get behind that conclusion, but don't know if that's just a term of art I missed or some clarification should be added. > > Section 2.5 > > > Using the minusculeu and majuscule forms of the same letter to mean > > different things (e.g., source S and sequence number s) is something of > > a readability anti-pattern. > > I agree. We need Greek letters in RFCs. (No Gothic, please.) sadly, RFC 7997 doesn't really seem to support this cause :-/ > > Section 3.2.6 > > > It would probably be helpful to readers to note that "neighbor that > > advertised" and "next-hop" can be different due to being different > > address families. > > They are completely different data structures. The neighbour is (a > reference to) an entry of the neighbour table, the NH is an IP address. That's true. Do we want to make it more clear to the reader that is going through things quickly? > > Section 3.5.1 > > > (side note: I got a bit confused reading this section and had to go > > double-check several definitions, due to the qualitative difference > > between the "metric" and "metric'" under comparison. Namely, the > > "metric" is for the path from neighbor to S, but the "metric'" is for > > the path from the current node to S, and so in some sense they are > > "measuring different things". > > Yeah, it's tricky. This is written with the implementer in mind, who's > going to be manipulating, in C notation, > > update->metric (metric) > source->metric (metric') > > Since this is the crucial part of the algorithm, it's written in a style > that attempts to make it as easy as possible to check the implementation > against the spec -- you can basically transliterate the RFC into your > favourite programming language. > > > Perhaps using "FD" instead of "metric'" would help disambiguate. > > I think we're fairly consistent at using "metric" for a metric and > "distance" for a pair (seqno, metric). Let me know if you find any > counter-examples. I don't remember any, nor do I have any suggestions for improving readability without breaking these desired properties. > > router-id. Feasibility distances are maintained in the source table, > > the exact procedure is given in Section 3.7.3. > > > nit: this is a comma splice. > > I've made it into a colon; I don't like semicolons. > > > Section 3.5.2 > > > Note that while strict monotonicity is essential to the integrity of > > the network (persistent routing loops may arise if it is not > > satisfied), left distributivity is not: if it is not satisfied, Babel > > will still converge to a loop-free configuration, but might not reach > > a global optimum (in fact, a global optimum may not even exist). > > > I might even go so far as to say that a global optimum "will likely not > > exist", though this is fairly qualitative/intuitive since we don't > > define a configuration space or metric over it in which to evaluate the > > probability. > > I agree with your intuition. I think it should be possible to give > a proof for random graphs, but it's not obvious to me whether they are > representative of real networks. If you're interested, you should have > a chat with Sobrinho. > > > Section 3.5.4 > > > We don't seem to use the "link cost value equal to cost" anywhere in > > this section, so maybe it is superfluous. > > Good catch, thanks. Fixed. > > > If such an entry exists: > > > o if the entry is currently selected, the update is unfeasible, and > > the router-id of the update is equal to the router-id of the > > entry, then the update MAY be ignored; > > > I guess the idea is that we can keep the old one around until it would > > time out, since the initial timeout value for it means it should still > > be workable until our timer expires, but it's only a MAY in case we want > > to be more proactive about noticing that the advertised metric is now > > unfeasible? > > In this case, the local node needs to predict the future in order to make > the optimal decision. The minor details of predicting the future are left > to the implementation. However, the consequences of getting it wrong are > harmless, so predicting the future is left at MAY level. This is unlike > Brexit. > > For this case to trigger, the neighbour needs to have increased its metric > enough to make us unfeasible (intuitively, the feasibility condition is > able to buffer up to one hop of metric instability), but without itself > becoming unfeasible (otherwise it would have sent us a new seqno). That > means that there's some instability exactly one hop upstream. And now > you need to predict the future: > > - either this is just a short-term fluctuation, the metric will decrease > at the next update, so it's best to stick to the current route; > > - or this is indicative of our current route getting bad, so it's better > to drop it and start hunting for a better one. > > My intuition is that it's best to ignore the MAY unless your current route > is the only route to the destination, but I don't have any hard data to > back it. At any rate, it's a fairly rare edge case, one that's not going > to happen much in real networks, and both choices are correct. The MAY is > intended to communicate that the implementer shouldn't bother with this > case, unless he knows better. Thanks for the extra discussion; I agree with your conclusions. > > Section 3.5.5 > > > o sending a retraction with an acknowledgment request (Section 3.3) > > to every reachable neighbour that has not explicitly retracted > > prefix P and waiting for all acknowledgments. > > > nit(?): I'd suggest a comma before "and waiting for all > > acknowledgments", since that's the final gating factor to achieve the > > goal. > > Ack. > > > The former option is simpler and ensures that at that point, any > > routes for prefix P pointing at the current node have expired. > > However, since the expiry time can be as high as a few minutes, doing > > that prevents automatic aggregation by creating spurious black-holes > > for aggregated routes. The latter option is RECOMMENDED as it > > dramatically reduces the time for which a prefix is unreachable in > > the presence of aggregated routes. > > > nit: I don't think this "prevents automatic aggregation" at a technical > > level, but rather that it "makes automatic aggregation rather unusable > > in practice" since if automatic aggregation is used, any route > > retraction will result in a spurious blackhole for the (minutes) expiry > > time, which is unacceptable for most environments. > > From a technical point of view, you're right. I'm leaving the current > formulation, though, I want to be very clear that it doesn't work in > practice (or at least I don't know how to make it work). Okay. > (It pains me. I know of at least one (not public) application of Babel > where automatic aggregation would be useful. So if anyone has any ideas > about how to make it work, I'm listening.) > > > Section 3.7 > > > Additionally, in order to ensure that any black-holes are reliably > > cleared in a timely manner, a Babel node sends retractions (updates > > with an infinite metric) for any recently retracted prefixes. > > > Is the sending of retractions the one described by the SHOULDs in 3.7.2? > > If so, I'm not sure that "a Babel node sends retractions for any > > recently retracted prefixes" is quite accurate (since SHOULD is not a > > mandatory requirement); "can send" or "will generally send" might be > > better. > > Agreed, tweaked. > > > Section 3.7.1 > > > Every Babel speaker periodically advertises all of its selected > > routes on all of its interfaces, including any recently retracted > > routes. Since Babel doesn't suffer from routing loops (there is no > > "counting to infinity") and relies heavily on triggered updates > > (Section 3.7.2), this full dump only needs to happen infrequently. > > > Part of the need for the full dump stems from the potential for > > unreliable links, right? > > My intuition was iniially be the same as yours, but unreliable links turn > out to be the last of our problems. We'd be using Acks more extensively > otherwise. > > The main issue is recovery after mobility: the node has moved away, it has > lost all of its neighbours, you need to rediscover all routes. If you're > using link-quality estimation, you cannot easily detect this situation, so > you cannot simply send a wildcard request. Until you receive a full > update, you're not going to switch to your new neighbours. Ah, good to know. > > Do we want to mention that relationship here, (and that if there are > > particularly unreliable links the frequency may need to be more often)? > > I've tried to clarify this in the new version of Appendix B. > > > Section 3.8.1.2 > > > We haven't introduced "hop count" yet and just mention it in passing > > here as "[if the] hop count is 2 or more". > > DOne. > > > Intuitively, it seems like the routr should send an update if the > > router-ids match and the requested seqno is equal to the route entry's > > seqno, but I don't see this case covered in the current text. > > > o otherwise, if the node has one or more (not necessarily feasible) > > routes to the requested prefix with a next hop that is not the > > > nit: I think the parenthetical can just be "not feasible", as any > > feasible routes in question would have matched the previous bullet > > point. > > Done. > > > neighbours. However, if a seqno request is resent by its originator, > > the subsequent copies MAY be forwarded to a different neighbour than > > the initial one. > > > Is MAY the appropriate level of strength? Trying the same neighbor > > would be effective if the original was unsuccessful due to packet loss, > > but is it possible for a routing pathology to occur that directs the > > request in the "wrong direction" with respect to a link or node failure? > > Yes, that's possible if multiple nodes become unfeasible simultaneously. > (If that happens, then the mechanism in 3.8.2.2 will eventually clear the > blackhole.) > > From an implementation point of view, you route each seqno request > independently. The MAY in this section simply means that you don't need > to keep track of the neighbour you previously sent the request to. Hmm. I might actually suggest a non-normative "may", then, if the idea is to have the decisions be completely independent. To me, the "MAY" suggests a granting of permission to deviate from the expected baseline (the latter being that it always gets sent to the same neighbor). > > Section 3.8.2.4 > > > Is it worth giving some informal guidance about not sending multicast > > wildcard requests if a node observes others doing the same around the > > same time (or similar) to avoid the "serious congestion" issues? > > This section has been removed. > > > Section 4.2 > > > A Babel packet consists of a 4-octet header, followed by a sequence > > of TLVs (the packet body), optionally followed by a second sequence > > of TLVs (the packet trailer). > > > Without mention of the 'body length' field here, a reader might be > > confused at what distinguishes the body TLVs from the trailer TLVs. > > I'm leaving it as it stands, I think the text is clear. > > > The packet body and trailer are both sequences of TLVs. The packet > > Ibody is the normal place to store TLVs; the packet trailer only > > contains specialised TLVs that do not need to be protected by > > cryptographic security mechanisms. > > > I think we need a more explicit statement that the body structure is > > subject to change when security mechanisms are in use, to allow for > > potential confidentiality-protecting cryptographic mechanisms. > > > Section 4.3 > > > Length is still in octets, right? > > Fixed. > > > Section 4.4 > > > Every TLV carries an explicit length in its header; however, most > > TLVs are self-terminating, in the sense that it is possible to > > determine the length of the body without reference to the explicit > > Length field. If a TLV has a self-terminating format, then it MAY > > allow a sequence of sub-TLVs to follow the body. > > > This seems like a statement of fact, for which a lowercase "may" is > > perfectly adequate. > > Fixed. > > > Sub-TLVs have the same structure as TLVs. With the exception of > > PAD1, all TLVs have the following structure: > > > I was going to complain that it's somewhat unfortunate to use the same > > name for a thing that's a TLV and a thing that's a sub-TLV, even if they > > have identical encodings. But then I noticed that in this (sub-TLV) > > section we spell it "PAD1" and in the previous (TLV) section we spell it > > "Pad1", which are different. On the gripping hand, Sections 4.6.1 and > > 4.7.1 both spell it "Pad1", which are the same. So a little bit of > > effort rationalizing things would go a long way. > > This is meant to be Pad1. In practice, we have found that there is no > confusion. > > > The most-significant bit of the sub-TLV, called the mandatory bit, > > > Just to be clear: this is the MSB of the 'type' octet? > > This has been clarified. > > > Also, for similar features in other protocols I've suggested the > > clarifying language of "comprehension-mandatory" which seems to more > > accurately reflect the corresponding behavior. > > I'm afraid it's too long, people won't use it in conversation. > > > Section 4.5 > > > Since the parser state is separate from the bulk of Babel's state, > > and since for correct parsing it must be identical across > > implementations, it is updated before checking for mandatory TLVs: > > > nit: "mandatory sub-TLVs" (right?) > > Fixed, thanks. > > > Section 4.6.2 > > > MBZ Set to 0 on transmission. > > > Is it legal for a receiver to check and abort if any bits are nonzero? > > If we want to be consistent with the rest of Babel, it is legal to check > and to ignore this TLV. Since this TLV is ignored in any case, the > distinction is somewhat uninteresting. > > (I guess you're thinking about adding noise for security purposes. Please > define a new TLV if that's required, I prefer protocol extensions to be > explicit about their intent.) I was originally going for steganographic-like side channels, but that's an option, too. I'll wait until I can think up a use for the noise before I write that draft, though ;) > > Section 4.6.3 > > > Sixteen bits of nonce does not provide much unguessability (I note that > > LISP's rfc6830bis is recommending that their 24-bit nonce echo > > functionality not be relied on for return-routability checks over the > > public Internet). However, since these acknowledgment exchanges are > > only between direct neighbors, it seems that they are only needed for > > correlating responses to requests and not for unguessability. (In this > > case it seems a sequence number would work just as well as a random > > number, and we might want to discourage random assignment in the text to > > avoid the risk of birthday collisions.) > > On the other hand, multicast acknowledgment requests could be > > problematic (and especially so when sequential nonces are used), and if > > they are intended to be allowed then we may need to consider using a > > larger and random nonce. > > Section 3.3: > > An acknowledgment MUST be sent to a unicast destination. I understand that. Nonetheless, any time that an attacker C (e.g., on a shared link) can send a message to A that changes how A interacts with B, that puts up a flag that we need to think about the interaction more carefully. In this case, *probably* B will ignore spurious acks from A, but is that always true? Is that the only case we need to consider? > > Section 4.6.6 > > > I'm getting some sever cognitive dissonance between the "Rxcost" field > > and the "carrying a link's transmission cost" statement. Also, in > > > Rxcost The rxcost according to the sending node of the interface > > whose address is specified in the Address field. The value > > FFFF hexadecimal (infinity) indicates that this interface > > is unreachable. > > > if I insert commas to get "The rxcost, according to the sending node [of > > the TLV], of the interface whose address is specified in the Address > > field", does that preserve the intended meaning? > > nit/aside: It also feels like there's a bit of a mismatch here, in that > > the "rxcost of the interface" probably means the local interface (from > > the perspective of the sender), but that interface is being identified > > by the *remote* address (again, from the perspective of the sender of > > the TLV). So maybe "whose remote address" could resolve the mismatch > > I'm perceiving? (Or maybe I'm completely misunderstanding, of course.) > > > Interval An upper bound, expressed in centiseconds, on the time > > after which the sending node will send a new IHU; this MUST > > NOT be 0. [...] > > > To check my understanding: are the IHUs conceptually a reply to Hellos, > > such that if the Hellos stopped arriving then the peer would stop > > sending IHUs in response? I understand that their intervals are set > > completely independently, so there is not a direct causal relationship, > > but I'm trying to check whether the quoted sentence is a strict > > commitment by the sender of the IHU or could be rescinded due to > > external events. > > This is used to set the IHU timer, described in 3.4.2: > > When a neighbour's IHU timer expires, the neighbour's txcost is set to > infinity. Okay. It sounds like my above description is incorrect, then, and conceptually the IHU is a pure periodic beacon. I'll go a bit further and tell myself that IHU is for reachability confirmation and Hello is for neighbor detection, though I'm sure that's not exactly right; IHU also has the benefit of sending the rxcost values (which are themselves determined by monitoring Hello receipt). > > Section 4.6.9 > > > If the Metric field is finite, the router-id of the originating node > > for this announcement is taken from the prefix advertised by this > > Update if the Router-Id flag is set, computed as described above. > > Otherwise, it is taken either from the preceding Router-Id packet, or > > the preceding Update packet with the Router-Id flag set, whichever > > comes last, even if that TLV is otherwise ignored due to an unknown > > mandatory sub-TLV. > > > Both cases of "packet" here should be "TLV", right? > > Fixed, thanks. > > > Section 5 > > > "Specification Required" also requires Expert Review. What guidance can > > we provide to the experts for making registration decisions? > > I don't think there's WG consensus on this subject. I am in favour of > being very liberal (since the alternative incurs the risk of people > squatting our codepoints), but if memory serves at least one WG member > argued in favour of "RFC required". > > I'm not too worried, though. Right now, there is only one nonofficial > protocol extension used in production that I know of, and it's completely > incompatible with the protocol (it doesn't use sub-TLVs, it savagely > appends extra data to the Update TLV). No self-respecting expert would > approve such an extension. > > I think we can deal with that issue when the problem occurs. It's unlikely to be a timely response if we do that; I expect an RFC would be needed in order to change registry policy/guidance, and that would take at least a few months. > > Section 6 > > This section has been completely rewritten. > > > "periodically" may not be the best advice; coupling such changes to > > mobility events is likely to be more effective at preserving privacy. > > (QUIC has discussed related topics quite extensively, though there's > > enough traffic in the archives that I can neither point you at a > > specific thread or recommend searching for it.) > > Changed to "often enough". > > > Section 8.2 > > > I think at least BABEL-HMAC needs to be normative, since it is > > RECOMMENDED. > > Done. > > > Section A.1 > > > If we're talking about "appending bits" to the history fields, maybe > > describing them as fixed-length queues or something makes more sense > > than vectors. > > I think the current formulation is clear. > > > If the field is maintained in a 16-bit integer, what is done for the > > previously erased bits when we "undo history"? > > It doesn't matter, these are low-order bits, they're not going to > contribute to any of the computed values. 0 is he obvious value. > > > Whenever either Hello timer associated to a neighbour expires, the > > local node adds a 0 bit to this neighbour's Hello history, and > > > We keep two hello histories; we should clarify that the one in question > > is the one corresponding to the timer that expired. > > Done. > > > Section A.2.2 > > > I don't understand the origin of the '256' in the MIN(1, 256/txcost) > > formula (described as a probability estimate). > > We scale the values to fit in a 16-bit integer field without excessive > loss of precision. Sorry; I'm still confused. If alpha is a "probability estimate", shoudln't it be between 0 and 1? MIN(1, .) then serves to cap the top of the range, so I want 256/txcost to be between 0 and 1, aka txcost to be larger than 256. I see that we send the rxcost(/txcost) values in the 16-bit integer IHU field, and use 0xffff to indicate infinity, but within that 0..2^15-2 range, assignment of costs is left fairly arbitrary. So a scaling factor would presumably also be arbitrary, but why is this partial-scale-and-partial-cap procedure useful versus just scaling over the full 16-bit range into a probability estimate from 0 to 1? I also don't see how this operation is scaling "to fit in a 16-bit integer"; presumably alpha is not stored as a 16-bit integer! > > I think a lot more work is needed to convince me that the two given > > formulae for "cost" are equivalent (especially given that 'rxcost' only > > appears once in the entire section, in the second formula). > > I've added explicit mention of the fact that rxcost = beta * 256, which is > possibly what you were missing. Yup, that's the missing link. > 256/(alpha * beta) = 256 / (MIN(1, 256 / txcost) * beta) > = MAX(256 / 1, 256 / (256 / txcost)) * (rxcost / 256) > = (MAX(txcost, 256) * rxcost) / 256 > > > Section A.3.2 > > > Is k "allowed to" (I know this section is just informative) vary on > > non-external data, such as the route or link in question? > > I've removed this paragraph. Nobody's ever implemented this suggestion, > the new appendix about filtering is more informative. > > (Comma splice, I know.) > > > Appendix C > > > I could see this content in the main body of the document. > > I've rewritten this appendix, and referenced it in a few more places in > the body. I've got no strong opinions either way, and unless there's any > strong opinions, I'll leave it as it is. I was deliberately expressing a non-strong opinion :) Thanks, Ben From nobody Wed Aug 14 22:07: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 276EA120044; Wed, 14 Aug 2019 22:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 AV3Sn-v3GE1w; Wed, 14 Aug 2019 22:07:00 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 9824E120041; Wed, 14 Aug 2019 22:07:00 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7F56pJG014926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Aug 2019 01:06:56 -0400 Date: Thu, 15 Aug 2019 00:06:51 -0500 From: Benjamin Kaduk To: Juliusz Chroboczek Cc: Mirja Kuehlewind , babel-chairs , Babel at IETF , David Schinazi , The IESG , Donald Eastlake , draft-ietf-babel-dtls@ietf.org Message-ID: <20190815050650.GP88236@kduck.mit.edu> References: <156518163926.8337.14198016212015161206.idtracker@ietfa.amsl.com> <87a7cjq53f.wl-jch@irif.fr> <110AD4FB-186C-4C87-8BAF-7D8F4A04BC6F@kuehlewind.net> <87mugjo9wa.wl-jch@irif.fr> <13919FCC-9655-4B31-BC87-D33C963C82C4@kuehlewind.net> <87h86ju101.wl-jch@irif.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h86ju101.wl-jch@irif.fr> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [babel] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-babel-dtls-07=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Thu, 15 Aug 2019 05:07:02 -0000 On Wed, Aug 14, 2019 at 07:10:06PM +0200, Juliusz Chroboczek wrote: > > Thanks for the detailed explanation. I believe the underlying problem is > > that in this approach the Hello is not authenticated. > > Exactly. > > One of the important properties of this protocol is that it uses > a previously standardised protocol (DTLS) for all crypto work. David > feels that is important. Since the IETF has not standardised any > general-purpose security mechanism that is suitable for protecting > multicast traffic, we're stuck. There is perhaps some content of note in https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm though it of course does not meet the precondition, at present. -Ben From nobody Wed Aug 14 23:24:17 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 11350120044; Wed, 14 Aug 2019 23:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 emxUsvPWL__u; Wed, 14 Aug 2019 23:24:07 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34EB8120041; Wed, 14 Aug 2019 23:24:07 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id t3so1276336ljj.12; Wed, 14 Aug 2019 23:24:07 -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=0kjfKOv0sofllsDxE/sqpKAPc/5GMQyyfNEW7Xb27PU=; b=g/FHXRqYt5nwkt1nE17lLEAAxqYm0CxtHDDBcQDeDIeHg1kMQ1AAZPOv6tZm00KXkP dAai6ah27cPtCAy+XHFXPgs8rtOY9kt/rMGDCfkvprTdGpj93Makx/gbr2wjosvh+azN 8mppqajr9PqzODca0ALX/xAFxfog4G+6Mj2z8jIVvm4Of6hFoDvlccWL6dO3nWO0+/z5 5/R2kAWWmxHQ5VmXeAQDrXf3xLyGkfQ1vNG+RhCC6Jg9Cb3liAbBmLKn9yNI6WRuSCbU rqI9MotgEjGjsu+zOoNybUNIVniRNFxYHDpyL5enqeHyzCWzdIacDOm68MyaeeInkq8N Cc0A== 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=0kjfKOv0sofllsDxE/sqpKAPc/5GMQyyfNEW7Xb27PU=; b=Ndofgq2lu81YuAW7FTZq72cAkywmBvpM6j4WZtjJtlgkn/AkJKnCYcPRQhg2D2LwO3 gzq5HgU1wwmunYbhRrdpuO3DtKvNwKum5piCAIT1py3z6IaFXxI3XCmY3mUd/O+DLoei FtvMLUbKScRCPif0X7pFbvj1yesq8zlUuzwYzQypI2TKpM5ZPOaM+kij6HBmgXPiLED5 YOXAyIzBBlmeK4WB8job1B2umcmaTiTBcThaWR8PRHSmUde8NUiLYW0snqSFA4WRaQxK iXbIX5Zg4llJKH34q+Zwxna56w07dBr7ixzF65Ltf1CbjFMAVQGimtXGuJmQ4QIAL/9A rt0w== X-Gm-Message-State: APjAAAVY422Bqtt+4Vz3VoxpbBM5RFL+AJfCKSfBF3tX4GCW9DaKT6ec 2FNAQj0IHDtoXVklsS5JODkkqbNiDevIHlNa1uU= X-Google-Smtp-Source: APXvYqxbGzqarRTXpSANiDV7fCI0HtHY2gy+aDaHeJ3LWPc+RdV4Kt5W6ApP33cyxuhFOU9qCdf6Ox3Ondf3wrfALKg= X-Received: by 2002:a2e:1459:: with SMTP id 25mr1718414lju.153.1565850245088; Wed, 14 Aug 2019 23:24:05 -0700 (PDT) MIME-Version: 1.0 References: <156105440578.3118.4917846383408119793.idtracker@ietfa.amsl.com> <9C5FD3EFA72E1740A3D41BADDE0B461FCFC76069@DGGEMM528-MBX.china.huawei.com> <87y305alt8.wl-jch@irif.fr> In-Reply-To: From: Henning Rogge Date: Thu, 15 Aug 2019 08:23:38 +0200 Message-ID: To: David Schinazi Cc: The IESG , Juliusz Chroboczek , "Yemin (Amy)" , =?UTF-8?Q?Antonin_D=C3=A9cimo?= , Martin Vigoureux , =?UTF-8?Q?LucAndr=C3=A9_Burdet?= , Babel at IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] rtgdir Last Call Review requested: draft-ietf-babel-dtls 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: Thu, 15 Aug 2019 06:24:10 -0000 Hi, I have looked through the changes you made from draft-06 to draft 09 and I think they help the draft a lot. It now spells out quite a few common pit traps either explaining how to avoid them or explaining what to expect. This is a good thing for a security document. Henning Rogge On Wed, Aug 7, 2019 at 7:46 PM David Schinazi wrote: > > [Adding the IESG to this thread since there might be overlap between conversations] > > On Wed, Aug 7, 2019 at 9:59 AM David Schinazi wrote: >> >> I think this thread may have forked... >> >> Henning's original email from July 5: >> https://mailarchive.ietf.org/arch/msg/babel/_Jt5gfUMQbnPJFdfvR7HhqO6vSc >> >> Juliusz and I replied shortly after: >> https://mailarchive.ietf.org/arch/msg/babel/yNGgOauQHCp5EyMj8ivQxdTcdJI >> https://mailarchive.ietf.org/arch/msg/babel/wZOOhPjOBK1xF6EsuxLTCdctcQE >> >> And Juliusz sent a new reply yesterday to which Henning responded: >> https://mailarchive.ietf.org/arch/msg/babel/vaJowPOfLBKblh5LYpwSstS7Ins >> https://mailarchive.ietf.org/arch/msg/babel/cDvi0BzZoJXUo3TOpkq4YlfZvcY >> >> To summarize the discussions in all these threads. >> >> (1) Bidirectional reachability is protected by DTLS by requiring IHU to be sent >> protected, this reduces the security boundary of the protocol. >> >> (2) We've added text documenting what to do when a node receives a new >> connection, this prevents attackers from impacting the neighbor table >> >> (3) We've added text discussing that different ciphers can have different >> overheads and that needs to be taken into account when computing MTU >> >> (4) An attacker can create state on a victim by creating many DTLS >> connection attempts. We rely on DTLS's DoS prevention mechanisms >> (such as cookies) to avoid these issues. >> >> We've made changes to the draft from these comments, and they landed in draft -07: >> https://tools.ietf.org/html/draft-ietf-babel-dtls-07 >> >> Please let me know if I missed anything. >> >> Thanks, >> David >> >> >> >> On Wed, Aug 7, 2019 at 3:57 AM Henning Rogge wrote: >>> >>> On Wed, Aug 7, 2019 at 1:58 AM Juliusz Chroboczek wrote: >>> > >>> > Hi Henning, >>> > >>> > Good to hear from you again. >>> > >>> > The two main authors of this draft appear to be on holiday, so I'll answer >>> > your review to the best of my capacities. >>> > >>> > > Chapter 2.3: >>> > > I wonder if using DTLS protected unicast Hellos should be mandatory... >>> > > using unprotected multicast to determine bidirectional reachability >>> > > looks like a good way to do a cheap denial ofa service attack. >>> > >>> > In Babel, bidirectional reachability is established by a Hello/IHU >>> > exchange. This document requires IHUs to be authenticated, therefore >>> > bidirectional reachability will never be established with an attacker. >>> > >>> > However, this doesn't prevent DoS attacks: >>> > >>> > - an attacker could send cleartext Hellos from spoofed addresses, thus >>> > causing the victim to create unbounded numbers of neighbour entries; >>> > - an attacker could send DTLS ClientHello packets from spoofed >>> > addresses, with a similar effect. >>> >>> As long as this "unverified" links are not used for global routing I >>> would not be worried... >>> >>> you can never prevent a direct neighbor from doing a DoS. >>> >>> > Requiring an authenticated Hello is not workable, since an authenticated >>> > Hello cannot be sent until after the DTLS handshake has completed. >>> >>> And there is also the point that DTLS and Multicast don't mix well... >>> >>> > This is somewhat mitigated by the fact that only packets from link-local >>> > addresses are accepted (see Section 2.1 of this draft and Section 4 of >>> > RFC 6126bis). This is what the draft has to say on the subject (Section 5): >>> >>> > A malicious client might attempt to perform a high number of DTLS >>> > handshakes with a server. As the clients are not uniquely identified >>> > by the protocol and can be obfuscated with IPv6 temporary addresses, >>> > a server needs to mitigate the impact of such an attack. Such >>> > mitigation might involve rate limiting handshakes from a given subnet >>> > or more advanced denial of service avoidance techniques beyond the >>> > scope of this document. >>> > >>> > I'm not happy with this either. >>> >>> I think some parts of this information could be useful for the >>> Security Considerations section. >>> >>> Most people don't know BABEL that deep, so giving them some advise >>> what has already been considered and what no is always good. >>> >>> > > Chapter 2.5: >>> >>> > > What happens when a node starts a new DTLS connection and there is >>> > > already one in the neighbor table? This could both be an attempt to >>> > > attack Babel, a reboot of a node or just a matter of misconfiguration >>> > > of two nodes. >>> > >>> > Section 2.1: >>> > >>> > If a node receives a new DTLS connection from a neighbour to whom it >>> > already has a connection, the node MUST NOT discard the older >>> > connection until it has completed the handshake of the new one and >>> > validated the identity of the peer. >>> >>> Sorry, missed that... good to see it has already dealt with. >>> >>> > > Chapter 3: >>> > > Different pairs of nodes could select different ciphers, resulting in >>> > > different MTUs. I assume this is no problem for Babel (could be >>> > > mentioned in the chapter). >>> > >>> > I am not competent to answer this, we'll need to wait for David or >>> > Antonin to resurface. >>> >>> Sure... I was away fore quite a while too after my post. >>> >>> Henning Rogge From nobody Thu Aug 15 09:02: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 C2D7F1200D8; Thu, 15 Aug 2019 09:01:53 -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 zNloHHp4sXJX; Thu, 15 Aug 2019 09:01:49 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 477381200B7; Thu, 15 Aug 2019 09:01:49 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id b29so2004919lfq.1; Thu, 15 Aug 2019 09:01:49 -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=tpxb5DH3CsGCZacyMXf/0lNCQ+n8/C7JPBTwNLOvWJA=; b=HogQL1PTfd+5wg/UGsg2I5h379T1McBmmgnH0vkmaixAtwE/5/LcDVMPSco8mr/QBC /pa+ISfj0YCLEbKI0XvEqcbeUiA7hE76hMMU7yTyzt+g7O4CVfZ1gAmKE+ecPsoxNka1 kK7f1fDL1ZjeX3bdYStNjUEQfGDcu+cq/t92NninEoPUoQd3kra7fAxcPMRBBQDdv5pd c5pNvqXDgUs10Y6CP4eLAXbc4WoebdwmpnY+4biwpf8ddwkvqxDRWDMgqgxU2YXuZVLR 6cIsgB33Nj7ZB+nQXF6Di/p2I+yD6mq4+Zc0Zu4eDnLFL5pDHH0CetD3+S/7//U3OyKO I8Og== 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=tpxb5DH3CsGCZacyMXf/0lNCQ+n8/C7JPBTwNLOvWJA=; b=czFBe8AcK6C5QvO62vL7EhlDVKswMFkR2A1UPhL3VlG4apsedywUz+xKvGLi0Kt34Q tER3VteOcgCwTPUpOlNsMfyMYhbLST5aRYrOadPhTbVmvct3p96r7f8vPBWAkXEE2W3+ mwF1CltmiQ/H+6573Qoi24GmaiB8jY1NS0V0i0PcXA93OU9fMhOyDvhlLv6fn8s6ZX3s CNOrPxPoV2x2dxI2ZQTeSMSlmDtA07g2wZxOC11xrV+kLompSOb8mRLrac77ZlAU7ngM xCkN2kJKCktFVD+gE5axvJsuSdReiAcVKF3KJlixCZOkOTb6jUDSQuT5H7ULMu0GE0WL mcbA== X-Gm-Message-State: APjAAAVXqvCwl1ZzElpUEK6Gtn0BSNDjNCa3YwJggbqsjR9D1AWjdhM3 HUhwBFKnk2oLD5bB5oBGcrkPDhFJWVJBR481j0c= X-Google-Smtp-Source: APXvYqxGjt0Yn9OSSM4UC7ySUctC1qJPF3K88q+I2N3ltl+6UY1Mx/ePUWrHAe8SEfhsRIi7/bTlDS4VpKpc26MoUHg= X-Received: by 2002:a19:ec0c:: with SMTP id b12mr2801636lfa.107.1565884907375; Thu, 15 Aug 2019 09:01:47 -0700 (PDT) MIME-Version: 1.0 References: <156105440578.3118.4917846383408119793.idtracker@ietfa.amsl.com> <9C5FD3EFA72E1740A3D41BADDE0B461FCFC76069@DGGEMM528-MBX.china.huawei.com> <87y305alt8.wl-jch@irif.fr> In-Reply-To: From: David Schinazi Date: Thu, 15 Aug 2019 09:01:36 -0700 Message-ID: To: Henning Rogge Cc: The IESG , Juliusz Chroboczek , "Yemin (Amy)" , =?UTF-8?Q?Antonin_D=C3=A9cimo?= , Martin Vigoureux , =?UTF-8?Q?LucAndr=C3=A9_Burdet?= , Babel at IETF Content-Type: multipart/alternative; boundary="000000000000a9d26d059029fd8d" Archived-At: Subject: Re: [babel] rtgdir Last Call Review requested: draft-ietf-babel-dtls 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: Thu, 15 Aug 2019 16:01:54 -0000 --000000000000a9d26d059029fd8d Content-Type: text/plain; charset="UTF-8" Thanks for your helpful comments and for taking another look Henning! David On Wed, Aug 14, 2019 at 11:24 PM Henning Rogge wrote: > Hi, > > I have looked through the changes you made from draft-06 to draft 09 > and I think they help the draft a lot. It now spells out quite a few > common pit traps either explaining how to avoid them or explaining > what to expect. This is a good thing for a security document. > > Henning Rogge > > On Wed, Aug 7, 2019 at 7:46 PM David Schinazi > wrote: > > > > [Adding the IESG to this thread since there might be overlap between > conversations] > > > > On Wed, Aug 7, 2019 at 9:59 AM David Schinazi > wrote: > >> > >> I think this thread may have forked... > >> > >> Henning's original email from July 5: > >> https://mailarchive.ietf.org/arch/msg/babel/_Jt5gfUMQbnPJFdfvR7HhqO6vSc > >> > >> Juliusz and I replied shortly after: > >> https://mailarchive.ietf.org/arch/msg/babel/yNGgOauQHCp5EyMj8ivQxdTcdJI > >> https://mailarchive.ietf.org/arch/msg/babel/wZOOhPjOBK1xF6EsuxLTCdctcQE > >> > >> And Juliusz sent a new reply yesterday to which Henning responded: > >> https://mailarchive.ietf.org/arch/msg/babel/vaJowPOfLBKblh5LYpwSstS7Ins > >> https://mailarchive.ietf.org/arch/msg/babel/cDvi0BzZoJXUo3TOpkq4YlfZvcY > >> > >> To summarize the discussions in all these threads. > >> > >> (1) Bidirectional reachability is protected by DTLS by requiring IHU to > be sent > >> protected, this reduces the security boundary of the protocol. > >> > >> (2) We've added text documenting what to do when a node receives a new > >> connection, this prevents attackers from impacting the neighbor table > >> > >> (3) We've added text discussing that different ciphers can have > different > >> overheads and that needs to be taken into account when computing MTU > >> > >> (4) An attacker can create state on a victim by creating many DTLS > >> connection attempts. We rely on DTLS's DoS prevention mechanisms > >> (such as cookies) to avoid these issues. > >> > >> We've made changes to the draft from these comments, and they landed in > draft -07: > >> https://tools.ietf.org/html/draft-ietf-babel-dtls-07 > >> > >> Please let me know if I missed anything. > >> > >> Thanks, > >> David > >> > >> > >> > >> On Wed, Aug 7, 2019 at 3:57 AM Henning Rogge wrote: > >>> > >>> On Wed, Aug 7, 2019 at 1:58 AM Juliusz Chroboczek wrote: > >>> > > >>> > Hi Henning, > >>> > > >>> > Good to hear from you again. > >>> > > >>> > The two main authors of this draft appear to be on holiday, so I'll > answer > >>> > your review to the best of my capacities. > >>> > > >>> > > Chapter 2.3: > >>> > > I wonder if using DTLS protected unicast Hellos should be > mandatory... > >>> > > using unprotected multicast to determine bidirectional reachability > >>> > > looks like a good way to do a cheap denial ofa service attack. > >>> > > >>> > In Babel, bidirectional reachability is established by a Hello/IHU > >>> > exchange. This document requires IHUs to be authenticated, therefore > >>> > bidirectional reachability will never be established with an > attacker. > >>> > > >>> > However, this doesn't prevent DoS attacks: > >>> > > >>> > - an attacker could send cleartext Hellos from spoofed addresses, > thus > >>> > causing the victim to create unbounded numbers of neighbour > entries; > >>> > - an attacker could send DTLS ClientHello packets from spoofed > >>> > addresses, with a similar effect. > >>> > >>> As long as this "unverified" links are not used for global routing I > >>> would not be worried... > >>> > >>> you can never prevent a direct neighbor from doing a DoS. > >>> > >>> > Requiring an authenticated Hello is not workable, since an > authenticated > >>> > Hello cannot be sent until after the DTLS handshake has completed. > >>> > >>> And there is also the point that DTLS and Multicast don't mix well... > >>> > >>> > This is somewhat mitigated by the fact that only packets from > link-local > >>> > addresses are accepted (see Section 2.1 of this draft and Section 4 > of > >>> > RFC 6126bis). This is what the draft has to say on the subject > (Section 5): > >>> > >>> > A malicious client might attempt to perform a high number of DTLS > >>> > handshakes with a server. As the clients are not uniquely > identified > >>> > by the protocol and can be obfuscated with IPv6 temporary > addresses, > >>> > a server needs to mitigate the impact of such an attack. Such > >>> > mitigation might involve rate limiting handshakes from a given > subnet > >>> > or more advanced denial of service avoidance techniques beyond the > >>> > scope of this document. > >>> > > >>> > I'm not happy with this either. > >>> > >>> I think some parts of this information could be useful for the > >>> Security Considerations section. > >>> > >>> Most people don't know BABEL that deep, so giving them some advise > >>> what has already been considered and what no is always good. > >>> > >>> > > Chapter 2.5: > >>> > >>> > > What happens when a node starts a new DTLS connection and there is > >>> > > already one in the neighbor table? This could both be an attempt to > >>> > > attack Babel, a reboot of a node or just a matter of > misconfiguration > >>> > > of two nodes. > >>> > > >>> > Section 2.1: > >>> > > >>> > If a node receives a new DTLS connection from a neighbour to whom > it > >>> > already has a connection, the node MUST NOT discard the older > >>> > connection until it has completed the handshake of the new one and > >>> > validated the identity of the peer. > >>> > >>> Sorry, missed that... good to see it has already dealt with. > >>> > >>> > > Chapter 3: > >>> > > Different pairs of nodes could select different ciphers, resulting > in > >>> > > different MTUs. I assume this is no problem for Babel (could be > >>> > > mentioned in the chapter). > >>> > > >>> > I am not competent to answer this, we'll need to wait for David or > >>> > Antonin to resurface. > >>> > >>> Sure... I was away fore quite a while too after my post. > >>> > >>> Henning Rogge > --000000000000a9d26d059029fd8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your helpful comments and for taking another lo= ok Henning!

David

On Wed, Aug 14, 2019 at 11:24 PM = Henning Rogge <hrogge@gmail.com&= gt; wrote:
Hi,
I have looked through the changes you made from draft-06 to draft 09
and I think they help the draft a lot. It now spells out quite a few
common pit traps either explaining how to avoid them or explaining
what to expect. This is a good thing for a security document.

Henning Rogge

On Wed, Aug 7, 2019 at 7:46 PM David Schinazi <dschinazi.ietf@gmail.com> wrote= :
>
> [Adding the IESG to this thread since there might be overlap between c= onversations]
>
> On Wed, Aug 7, 2019 at 9:59 AM David Schinazi <dschinazi.ietf@gmail.com> = wrote:
>>
>> I think this thread may have forked...
>>
>> Henning's original email from July 5:
>> https://mailarchive.= ietf.org/arch/msg/babel/_Jt5gfUMQbnPJFdfvR7HhqO6vSc
>>
>> Juliusz and I replied shortly after:
>> https://mailarchive.= ietf.org/arch/msg/babel/yNGgOauQHCp5EyMj8ivQxdTcdJI
>> https://mailarchive.= ietf.org/arch/msg/babel/wZOOhPjOBK1xF6EsuxLTCdctcQE
>>
>> And Juliusz sent a new reply yesterday to which Henning responded:=
>> https://mailarchive.= ietf.org/arch/msg/babel/vaJowPOfLBKblh5LYpwSstS7Ins
>> https://mailarchive.= ietf.org/arch/msg/babel/cDvi0BzZoJXUo3TOpkq4YlfZvcY
>>
>> To summarize the discussions in all these threads.
>>
>> (1) Bidirectional reachability is protected by DTLS by requiring I= HU to be sent
>> protected, this reduces the security boundary of the protocol.
>>
>> (2) We've added text documenting what to do when a node receiv= es a new
>> connection, this prevents attackers from impacting the neighbor ta= ble
>>
>> (3) We've added text discussing that different ciphers can hav= e different
>> overheads and that needs to be taken into account when computing M= TU
>>
>> (4) An attacker can create state on a victim by creating many DTLS=
>> connection attempts. We rely on DTLS's DoS prevention mechanis= ms
>> (such as cookies) to avoid these issues.
>>
>> We've made changes to the draft from these comments, and they = landed in draft -07:
>> https://tools.ietf.org/html/draft-ietf-= babel-dtls-07
>>
>> Please let me know if I missed anything.
>>
>> Thanks,
>> David
>>
>>
>>
>> On Wed, Aug 7, 2019 at 3:57 AM Henning Rogge <hrogge@gmail.com> wrote:
>>>
>>> On Wed, Aug 7, 2019 at 1:58 AM Juliusz Chroboczek <jch@irif.fr> wrote:
>>> >
>>> > Hi Henning,
>>> >
>>> > Good to hear from you again.
>>> >
>>> > The two main authors of this draft appear to be on holida= y, so I'll answer
>>> > your review to the best of my capacities.
>>> >
>>> > > Chapter 2.3:
>>> > > I wonder if using DTLS protected unicast Hellos shou= ld be mandatory...
>>> > > using unprotected multicast to determine bidirection= al reachability
>>> > > looks like a good way to do a cheap denial ofa servi= ce attack.
>>> >
>>> > In Babel, bidirectional reachability is established by a = Hello/IHU
>>> > exchange.=C2=A0 This document requires IHUs to be authent= icated, therefore
>>> > bidirectional reachability will never be established with= an attacker.
>>> >
>>> > However, this doesn't prevent DoS attacks:
>>> >
>>> >=C2=A0 =C2=A0- an attacker could send cleartext Hellos fro= m spoofed addresses, thus
>>> >=C2=A0 =C2=A0 =C2=A0causing the victim to create unbounded= numbers of neighbour entries;
>>> >=C2=A0 =C2=A0- an attacker could send DTLS ClientHello pac= kets from spoofed
>>> >=C2=A0 =C2=A0 =C2=A0addresses, with a similar effect.
>>>
>>> As long as this "unverified" links are not used for = global routing I
>>> would not be worried...
>>>
>>> you can never prevent a direct neighbor from doing a DoS.
>>>
>>> > Requiring an authenticated Hello is not workable, since a= n authenticated
>>> > Hello cannot be sent until after the DTLS handshake has c= ompleted.
>>>
>>> And there is also the point that DTLS and Multicast don't = mix well...
>>>
>>> > This is somewhat mitigated by the fact that only packets = from link-local
>>> > addresses are accepted (see Section 2.1 of this draft and= Section 4 of
>>> > RFC 6126bis).=C2=A0 This is what the draft has to say on = the subject (Section 5):
>>>
>>> >=C2=A0 =C2=A0 A malicious client might attempt to perform = a high number of DTLS
>>> >=C2=A0 =C2=A0 handshakes with a server.=C2=A0 As the clien= ts are not uniquely identified
>>> >=C2=A0 =C2=A0 by the protocol and can be obfuscated with I= Pv6 temporary addresses,
>>> >=C2=A0 =C2=A0 a server needs to mitigate the impact of suc= h an attack.=C2=A0 Such
>>> >=C2=A0 =C2=A0 mitigation might involve rate limiting hands= hakes from a given subnet
>>> >=C2=A0 =C2=A0 or more advanced denial of service avoidance= techniques beyond the
>>> >=C2=A0 =C2=A0 scope of this document.
>>> >
>>> > I'm not happy with this either.
>>>
>>> I think some parts of this information could be useful for the=
>>> Security Considerations section.
>>>
>>> Most people don't know BABEL that deep, so giving them som= e advise
>>> what has already been considered and what no is always good. >>>
>>> > > Chapter 2.5:
>>>
>>> > > What happens when a node starts a new DTLS connectio= n and there is
>>> > > already one in the neighbor table? This could both b= e an attempt to
>>> > > attack Babel, a reboot of a node or just a matter of= misconfiguration
>>> > > of two nodes.
>>> >
>>> > Section 2.1:
>>> >
>>> >=C2=A0 =C2=A0 If a node receives a new DTLS connection fro= m a neighbour to whom it
>>> >=C2=A0 =C2=A0 already has a connection, the node MUST NOT = discard the older
>>> >=C2=A0 =C2=A0 connection until it has completed the handsh= ake of the new one and
>>> >=C2=A0 =C2=A0 validated the identity of the peer.
>>>
>>> Sorry, missed that... good to see it has already dealt with. >>>
>>> > > Chapter 3:
>>> > > Different pairs of nodes could select different ciph= ers, resulting in
>>> > > different MTUs. I assume this is no problem for Babe= l (could be
>>> > > mentioned in the chapter).
>>> >
>>> > I am not competent to answer this, we'll need to wait= for David or
>>> > Antonin to resurface.
>>>
>>> Sure... I was away fore quite a while too after my post.
>>>
>>> Henning Rogge
--000000000000a9d26d059029fd8d-- From nobody Thu Aug 15 09:58:28 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 5F0851200C3 for ; Thu, 15 Aug 2019 09:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 QmqNwJSC0uUB for ; Thu, 15 Aug 2019 09:58:25 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825181200C1 for ; Thu, 15 Aug 2019 09:58:25 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7FGmHYJ046859; Thu, 15 Aug 2019 12:58:25 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 2udb4k0gw0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Aug 2019 12:58:24 -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 x7FGwNGm000959; Thu, 15 Aug 2019 12:58:23 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7FGwKjr000918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 15 Aug 2019 12:58:20 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 2ECFD4009E65; Thu, 15 Aug 2019 16:58:20 +0000 (GMT) Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30488.vci.att.com (Service) with ESMTPS id 1AD3940002DD; Thu, 15 Aug 2019 16:58:20 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.177]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0439.000; Thu, 15 Aug 2019 12:58:19 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" CC: "'babel@ietf.org'" Thread-Topic: [babel] info-model: preparing -09 on github Thread-Index: AdVSswKr0W4Y1vOsQfS00DtIY7BoYgAM83CAAAdXLCD//+jbAP//C3ug Date: Thu, 15 Aug 2019 16:58:19 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E275E65@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> <87ftm3u0a6.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269981@GAALPA1MSGUSRBF.ITServices.sbc.com> <87blwrtudx.wl-jch@irif.fr> In-Reply-To: <87blwrtudx.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.196.183] 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-08-15_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=784 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908150164 Archived-At: Subject: Re: [babel] info-model: preparing -09 on github 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: Thu, 15 Aug 2019 16:58:27 -0000 > > Is this suggesting that it's ok for info-model to provide babel-hmac > > with any value between 0 and 64 bytes in length for HMAC-SHA256 or > > between 0 and 32 bytes in length for Blake2s and babel-hmac can be > > expected to zero-pad? Or are you still expecting info-model to do the > > zero-padding before providing to babel-hmac? >=20 > The former. You give me anything between 0 and 32/64, and I deal with it= . Cool. Then from a purely info-model perspective, it sounds like the key-val= ue parameter length constraints are: This value is of a length suitable for the associated babel-mac-key-algorithm. If the algorithm is based on the HMAC construction, the length MUST be between 0 and the block size of the underlying hash inclusive (where "HMAC-SHA256" block size is 64 bytes as described in {{RFC4868}}). If the algorithm is "BLAKE2s", the length MUST be between 0 and 32 bytes inclusive, as described in {{RFC7693}}. Anything complying with info-model won't supply anything longer than the id= entified max length. A babel-hmac implementation may get something as short as zero length, but = will be expected to deal with it. Info-model doesn't care and doesn't need = to know what "deal with it" means. For HMAC and Blake2s algorithms, "deal with it" means hmac-babel will zero-= pad shorter strings, because that's what the algorithm RFCs say to do (and = not because babel-hmac has any extra requirements going beyond the algorith= m specs). Info-model won't send strings longer than the indicated length. If there is= a UI to info model that accepts a longer string, hashes it, and then info-= model provides the hashed value, that is what it is. Neither info-model nor= babel-hmac care or know or need to know about this. If a babel-hmac implementation does have special handling for longer string= s, that's fine, too. But a value coming from info-model will never trigger = this special code. Does that sound right? Barbara From nobody Thu Aug 15 12:26:44 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 224FE1200BA for ; Thu, 15 Aug 2019 12:26:42 -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 Ws-qeSIQX4BK for ; Thu, 15 Aug 2019 12:26:39 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 5A7D1120074 for ; Thu, 15 Aug 2019 12:26:39 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id p197so2412521lfa.2 for ; Thu, 15 Aug 2019 12:26:39 -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=fsYHq3uc96OJ93xMcYb7o4ltrA3h/h73XCrx2dS1OKQ=; b=ZhjVIe8LQSbEmVZmRrWb3DNojf9mXLs6Atrc/TNXaNxmldkPIUNwv89nGGg+cfD4ZA EK9kFQRNMm2MEBGj0uWuAUObx3oXiSWEIM62OS5K2Rz4M0geQpKuV8OOJiBiw7Iq1T8t uJuPWBbjBKGmbK1begane1KNsU2eyF34aPFSPt/N5lzmB9XDag5H1R5pYJKhQWoJVfeb S0luuqcdhO6AvNSLKX0asoA/x1PDfOJ3gFwaXWdg/5Ocmyb1B11bDtfMm/utBnRdU4KS WqnVIoQ3zfII6ISq/ix/uLFj4eYr/lrpDgmuxZRelQTzv9zGDoAuP+za0iVhL8jyaNTp LE0A== 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=fsYHq3uc96OJ93xMcYb7o4ltrA3h/h73XCrx2dS1OKQ=; b=suLOjWmb1piYNF/6dwJnjW7vGSBDyX8jKq5PxnQ5SI04WXQCeHXlq2OtkTfxQZoscR D/z+6IUC/FHepi3k9QTgOzQ5hj+IDPKjHF+Bji0mxjalyxlyASdEDBOnkXWvUS0rE/Di MeOAtSLmjsCYjQWdgxVLKyYfmMfqWr0j0z4Xv9yVuXsQfhsMFvVW9P7zanPKsLv91iEK q4biDdyouE7EfejTf6JrNS1fR+fnkZE5lgFl9v5mVTTqO83Y1bGD+4oukTMEVIeAuP7k /F6PR3QAJUfkH2d0ZwxjbLu4MSS8KWnBe5MRoCqeVamvcoZPCdtl2LXK6iIWXViwCgtM UlsA== X-Gm-Message-State: APjAAAXZsr1DvpWj9LXq7c23oo0GB+OpfA9bTRp3x8WobNVzBnNyklaW sVgmqU5oR3SOwAey1UdSyNvT0qaNpKj/9i0955o= X-Google-Smtp-Source: APXvYqz3pDq5wDTOU3LLFsBOZ9ZmxNfuz9eE7Td5du0BKwGKRUeBm4wAjv8xV/mtxjXexEbkFdKA/YnE8mG3N2wjYMI= X-Received: by 2002:a19:ec0c:: with SMTP id b12mr3246623lfa.107.1565897197522; Thu, 15 Aug 2019 12:26:37 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> <87ftm3u0a6.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269981@GAALPA1MSGUSRBF.ITServices.sbc.com> <87blwrtudx.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E275E65@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E275E65@GAALPA1MSGUSRBF.ITServices.sbc.com> From: David Schinazi Date: Thu, 15 Aug 2019 12:26:26 -0700 Message-ID: To: "STARK, BARBARA H" Cc: Juliusz Chroboczek , "babel@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003691fe05902cdadc" Archived-At: Subject: Re: [babel] info-model: preparing -09 on github 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: Thu, 15 Aug 2019 19:26:42 -0000 --0000000000003691fe05902cdadc Content-Type: text/plain; charset="UTF-8" According to RFC 7693, Blake2s keys must be of length kk where 0 <= kk <= 32. So having the info model dictate that keys MUST follow that is perfectly reasonable to me. However, according to RFC 6234, HMAC-SHA-256 allows all key lengths kk where 0 <= kk. I don't think the information model should express an opinion as to whether keys longer than 64 bytes are safe or not. If we choose to add that distinction we'll need to justify why we think the key hashing is unsafe, and I don't think there is an RFC we can cite for that. So going back to Juliusz's listed options in the other thread < https://mailarchive.ietf.org/arch/msg/babel/QlvsPB9yYFPTPwQxaLcWIN3Hl2Y>, I would argue for option 3 "bureaucratic" because it follows the design principle "The Babel WG does not make security decisions, we follow what RFCs tell us". David On Thu, Aug 15, 2019 at 9:58 AM STARK, BARBARA H wrote: > > > Is this suggesting that it's ok for info-model to provide babel-hmac > > > with any value between 0 and 64 bytes in length for HMAC-SHA256 or > > > between 0 and 32 bytes in length for Blake2s and babel-hmac can be > > > expected to zero-pad? Or are you still expecting info-model to do the > > > zero-padding before providing to babel-hmac? > > > > The former. You give me anything between 0 and 32/64, and I deal with > it. > > Cool. Then from a purely info-model perspective, it sounds like the > key-value parameter length constraints are: > > This value is of a length suitable for the associated > babel-mac-key-algorithm. If the algorithm is based on the HMAC > construction, the length MUST be between 0 and the block size of the > underlying hash inclusive (where "HMAC-SHA256" block size is 64 bytes > as described in {{RFC4868}}). > If the algorithm is "BLAKE2s", the length MUST be between 0 and 32 bytes > inclusive, as described in {{RFC7693}}. > > Anything complying with info-model won't supply anything longer than the > identified max length. > A babel-hmac implementation may get something as short as zero length, but > will be expected to deal with it. Info-model doesn't care and doesn't need > to know what "deal with it" means. > For HMAC and Blake2s algorithms, "deal with it" means hmac-babel will > zero-pad shorter strings, because that's what the algorithm RFCs say to do > (and not because babel-hmac has any extra requirements going beyond the > algorithm specs). > Info-model won't send strings longer than the indicated length. If there > is a UI to info model that accepts a longer string, hashes it, and then > info-model provides the hashed value, that is what it is. Neither > info-model nor babel-hmac care or know or need to know about this. > If a babel-hmac implementation does have special handling for longer > strings, that's fine, too. But a value coming from info-model will never > trigger this special code. > Does that sound right? > Barbara > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --0000000000003691fe05902cdadc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
According to RFC 7693, Blake2s keys must be of length= kk where=C2=A00 <=3D kk <=3D 32. So having the info model dictate th= at keys MUST follow that is perfectly reasonable to me.

However, according to RFC 6234, HMAC-SHA-256 allows all key lengths k= k where 0 <=3D kk. I don't think the information model should expres= s an opinion as to whether keys longer than 64 bytes are safe or not. If we= choose to add that distinction we'll need to justify why we think the = key hashing is unsafe, and I don't think there is an RFC we can cite fo= r that.

So going back to Juliusz's listed opti= ons in the other thread <https://mailarchive.ietf.org/arch/msg/= babel/QlvsPB9yYFPTPwQxaLcWIN3Hl2Y>, I would argue for option 3 "= ;bureaucratic" because it follows the design principle "The Babel= WG does not make security decisions, we follow what RFCs tell us".

David

On Thu, Aug 15, 2019 at 9:58 AM STARK, BA= RBARA H <bs7652@att.com> wrote:=
> > Is th= is suggesting that it's ok for info-model to provide babel-hmac
> > with any value between 0 and 64 bytes in length for HMAC-SHA256 o= r
> > between 0 and 32 bytes in length for Blake2s and babel-hmac can b= e
> > expected to zero-pad? Or are you still expecting info-model to do= the
> > zero-padding before providing to babel-hmac?
>
> The former.=C2=A0 You give me anything between 0 and 32/64, and I deal= with it.

Cool. Then from a purely info-model perspective, it sounds like the key-val= ue parameter length constraints are:

=C2=A0 This value is of a length suitable for the associated
=C2=A0 babel-mac-key-algorithm.=C2=A0 If the algorithm is based on the HMAC=
=C2=A0 construction, the length MUST be between 0 and the block size of the=
=C2=A0 underlying hash inclusive (where "HMAC-SHA256" block size = is 64 bytes
=C2=A0 as described in {{RFC4868}}).
=C2=A0 If the algorithm is "BLAKE2s", the length MUST be between = 0 and 32 bytes
=C2=A0 inclusive, as described in {{RFC7693}}.

Anything complying with info-model won't supply anything longer than th= e identified max length.
A babel-hmac implementation may get something as short as zero length, but = will be expected to deal with it. Info-model doesn't care and doesn'= ;t need to know what "deal with it" means.
For HMAC and Blake2s algorithms, "deal with it" means hmac-babel = will zero-pad shorter strings, because that's what the algorithm RFCs s= ay to do (and not because babel-hmac has any extra requirements going beyon= d the algorithm specs).
Info-model won't send strings longer than the indicated length. If ther= e is a UI to info model that accepts a longer string, hashes it, and then i= nfo-model provides the hashed value, that is what it is. Neither info-model= nor babel-hmac care or know or need to know about this.
If a babel-hmac implementation does have special handling for longer string= s, that's fine, too. But a value coming from info-model will never trig= ger this special code.
Does that sound right?
Barbara

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--0000000000003691fe05902cdadc-- From nobody Thu Aug 15 14:46:18 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 CEE4F1200EC for ; Thu, 15 Aug 2019 14:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 TlcUSWrq-tAt for ; Thu, 15 Aug 2019 14:46:12 -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 68EEB1200DB for ; Thu, 15 Aug 2019 14:46:12 -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 x7FLcKCR003939; Thu, 15 Aug 2019 17:46:08 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2udffkr6a8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Aug 2019 17:46:08 -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 x7FLk6H0019682; Thu, 15 Aug 2019 17:46:07 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7FLk2kP019531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 15 Aug 2019 17:46:02 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 95EF44009E83; Thu, 15 Aug 2019 21:46:02 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30486.vci.att.com (Service) with ESMTPS id 7CC584009E7E; Thu, 15 Aug 2019 21:46:02 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.177]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0439.000; Thu, 15 Aug 2019 17:46:02 -0400 From: "STARK, BARBARA H" To: "'David Schinazi'" CC: "'babel@ietf.org'" , "'Juliusz Chroboczek'" Thread-Topic: [babel] info-model: preparing -09 on github Thread-Index: AdVSswKr0W4Y1vOsQfS00DtIY7BoYgAM83CAAAdXLCD//+jbAP//C3uggAKFBgCAAC70cA== Date: Thu, 15 Aug 2019 21:46:01 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E27796E@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> <87ftm3u0a6.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269981@GAALPA1MSGUSRBF.ITServices.sbc.com> <87blwrtudx.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E275E65@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.196.183] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114E27796EGAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-15_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908150202 Archived-At: Subject: Re: [babel] info-model: preparing -09 on github 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: Thu, 15 Aug 2019 21:46:17 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114E27796EGAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkaXNhZ3JlZS4NCg0KVGhlIEhNQUMgc3BlY3MgKFJGQzIxMDQpIHNheXM6DQogICBBcHBsaWNh dGlvbnMgdGhhdCB1c2Uga2V5cyBsb25nZXINCiAgIHRoYW4gQiBbYmxvY2sgc2l6ZV0gYnl0ZXMg d2lsbCBmaXJzdCBoYXNoIHRoZSBrZXkgdXNpbmcgSCBhbmQgdGhlbiB1c2UgdGhlDQogICByZXN1 bHRhbnQgTCBbaGFzaCBvdXRwdXQgc2l6ZV0gYnl0ZSBzdHJpbmcgYXMgdGhlIGFjdHVhbCBrZXkg dG8gSE1BQy4gSW4gYW55IGNhc2UgdGhlDQogICBtaW5pbWFsIHJlY29tbWVuZGVkIGxlbmd0aCBm b3IgSyBpcyBMIGJ5dGVzIChhcyB0aGUgaGFzaCBvdXRwdXQNCiAgIGxlbmd0aCkuIFNlZSBzZWN0 aW9uIDMgZm9yIG1vcmUgaW5mb3JtYXRpb24gb24ga2V5cy4NCmFuZCBmcm9tIHNlY3Rpb24gMw0K DQogICBUaGUga2V5IGZvciBITUFDIGNhbiBiZSBvZiBhbnkgbGVuZ3RoIChrZXlzIGxvbmdlciB0 aGFuIEIgYnl0ZXMgYXJlDQoNCiAgIGZpcnN0IGhhc2hlZCB1c2luZyBIKS4gIEhvd2V2ZXIsIGxl c3MgdGhhbiBMIGJ5dGVzIGlzIHN0cm9uZ2x5DQoNCiAgIGRpc2NvdXJhZ2VkIGFzIGl0IHdvdWxk IGRlY3JlYXNlIHRoZSBzZWN1cml0eSBzdHJlbmd0aCBvZiB0aGUNCg0KICAgZnVuY3Rpb24uICBL ZXlzIGxvbmdlciB0aGFuIEwgYnl0ZXMgYXJlIGFjY2VwdGFibGUgYnV0IHRoZSBleHRyYQ0KDQog ICBsZW5ndGggd291bGQgbm90IHNpZ25pZmljYW50bHkgaW5jcmVhc2UgdGhlIGZ1bmN0aW9uIHN0 cmVuZ3RoLiAoQQ0KDQogICBsb25nZXIga2V5IG1heSBiZSBhZHZpc2FibGUgaWYgdGhlIHJhbmRv bW5lc3Mgb2YgdGhlIGtleSBpcw0KDQogICBjb25zaWRlcmVkIHdlYWsuKQ0KDQpJbiB0aGlzIGxh bmd1YWdlLCB0aGVyZSBpcyBubyByZXF1aXJlbWVudCBmb3IgYXBwbGljYXRpb25zIHVzaW5nIEhN QUMgdG8gYWNjZXB0IChvciBiZSBhYmxlIHRvIHVzZSkga2V5cyBsb25nZXIgdGhhbiBCIGJ5dGVz LiBUaGUgdHdvIHN0YXRlbWVudHMgZG8gc2F5IHdoYXQgbXVzdCBoYXBwZW4gKmlmKiBhIGtleSBs b25nZXIgdGhhbiBCIGJ5dGVzIGlzIHByb3ZpZGVkLiBCdXQgaWYgQmFiZWwgd2FudHMgdG8gcmVz dHJpY3Qga2V5cyB0byBubyBtb3JlIHRoYW4gQiBieXRlcywgdGhhdCBpcyB3ZWxsIHdpdGhpbiBC YWJlbOKAmXMgcHVydmlldyB0byBkbyBzby4gUkZDMjEwNiB2ZXJ5IGNsZWFybHkgdGVsbHMgYXBw bGljYXRpb25zIGdldCB0byBkZWNpZGUgd2hhdCB0byB1c2UuDQoNClRoZSBvdGhlciB0aGluZyBJ IGdldCBmcm9tIHRoaXMsIHRob3VnaCwgaXMgdGhhdCBpdOKAmXMgcmVjb21tZW5kZWQgdG8gaGF2 ZSBhdCBsZWFzdCBMIGJ5dGVzIGZvciBhbiBITUFDIGtleSAoTCA9IDMyIGZvciBTSEEtMjU2KS4g SSB0aGluayB3ZSBzaG91bGQgcmVmbGVjdCB0aGlzIHJlY29tbWVuZGF0aW9uLiBXZSBjb3VsZCBk byBpdCBlaXRoZXIgd2l0aCBhIOKAnFNIT1VMROKAnSBvciDigJxNVVNU4oCdIGJlIGF0IGxlYXN0 IHRoZSBvdXRwdXQgaGFzaCBsZW5ndGggKG5vdCBzZXQgdGhlIG1pbmltdW0gYXQgMCkuIEkgc2Vl IG5vIHJlYXNvbiBub3QgdG8gdXBncmFkZSB0aGF0IHRvIGEgTVVTVCBmb3IgQmFiZWwsIGlmIHdl IHdhbnQuIFtJdOKAmXMgYWx3YXlzIG9rIHRvIGJlIHN0cmljdGVyIHRoYW4gYSByZWZlcmVuY2Vk IHNwZWMgKGUuZy4sIGNoYW5nZSBTSE9VTEQgdG8gTVVTVCkg4oCTIGl04oCZcyBqdXN0IG5vdCBv ayB0byBkbyBvciBhbGxvdyBzb21ldGhpbmcgdGhhdCB2aW9sYXRlcyBhIHJlcXVpcmVtZW50IGZy b20gdGhlIHNwZWMgKGUuZy4sIGNoYW5nZSBNVVNUIHRvIFNIT1VMRCkuXSBJIHRoaW5rIGF0IGxl YXN0IGEgTVVTVCBiZSBhdCBsZWFzdCA4IGJ5dGVz4oCdIHdpdGggYSDigJxTSE9VTEQgYmUgYXQg bGVhc3QgdGhlIG91dHB1dCBoYXNoIGxlbmd0aOKAnSB3b3VsZCBiZSBnb29kIGZvciBITUFDLiBJ dOKAmXMgYWxzbyBvayBmb3IgdGhlIGluZm9ybWF0aW9uIG1vZGVsIHRvIGJlIHN0cmljdGVyIHRo YW4gdGhlIGJhYmVsLWhtYWMgaW1wbGVtZW50YXRpb24uDQoNCkJsYWtlMnMgZG9lcyBzcGVjaWZp Y2FsbHkgYWxsb3cgemVyby1sZW5ndGgga2V5cyDigJMgdGhvdWdoIEkgZG9u4oCZdCBrbm93IGhv dyBhZHZpc2FibGUgdGhhdCBpcyBpbiBhIEJhYmVsIHVzYWdlIHNjZW5hcmlvLiBJIGRvbuKAmXQg a25vdyB3aGVuIGtleSBsZW5ndGggb2YgMCBpcyB1c2VmdWwuIEJ1dCB0aGVyZSBpcyBkZWZpbml0 ZWx5IG5vdGhpbmcgdGhhdCBwcmV2ZW50cyB1cyBmcm9tIGJlaW5nIHN0cmljdGVyLCBpZiB3ZSB3 YW50ZWQgdG8gaW5zaXN0IG9uIGEga2V5IGxvbmdlciB0aGFuIDAuIEFnYWluLCB0aGlzIHN0cmlj dG5lc3MgY2FuIGJlIGluIGluZm8tbW9kZWwgb25seSBhbmQgZG9lc27igJl0IGhhdmUgdG8gYmUg cmVmbGVjdGVkIGluIGJhYmVsLWhtYWMuDQoNCkkgZG8gbmVlZCBzb21lIG1heGltdW0gc2l6ZSBv biB0aGUgcGFyYW1ldGVyIChpbmRlcGVuZGVudCBvZiBrZXkgYWxnb3JpdGhtKSDigJMgc28gaXQg d29u4oCZdCBiZSB1bmxpbWl0ZWQgbGVuZ3RoLCBhbnl3YXkuIEnigJltIHRoaW5raW5nIDEyOCBi eXRlcyBhcyBhbiBhYnNvbHV0ZSB1cHBlciBsaW1pdCBhdCB0aGlzIHRpbWUuDQpCYXJiYXJhDQoN CkFjY29yZGluZyB0byBSRkMgNzY5MywgQmxha2UycyBrZXlzIG11c3QgYmUgb2YgbGVuZ3RoIGtr IHdoZXJlIDAgPD0ga2sgPD0gMzIuIFNvIGhhdmluZyB0aGUgaW5mbyBtb2RlbCBkaWN0YXRlIHRo YXQga2V5cyBNVVNUIGZvbGxvdyB0aGF0IGlzIHBlcmZlY3RseSByZWFzb25hYmxlIHRvIG1lLg0K DQpIb3dldmVyLCBhY2NvcmRpbmcgdG8gUkZDIDYyMzQsIEhNQUMtU0hBLTI1NiBhbGxvd3MgYWxs IGtleSBsZW5ndGhzIGtrIHdoZXJlIDAgPD0ga2suIEkgZG9uJ3QgdGhpbmsgdGhlIGluZm9ybWF0 aW9uIG1vZGVsIHNob3VsZCBleHByZXNzIGFuIG9waW5pb24gYXMgdG8gd2hldGhlciBrZXlzIGxv bmdlciB0aGFuIDY0IGJ5dGVzIGFyZSBzYWZlIG9yIG5vdC4gSWYgd2UgY2hvb3NlIHRvIGFkZCB0 aGF0IGRpc3RpbmN0aW9uIHdlJ2xsIG5lZWQgdG8ganVzdGlmeSB3aHkgd2UgdGhpbmsgdGhlIGtl eSBoYXNoaW5nIGlzIHVuc2FmZSwgYW5kIEkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYW4gUkZDIHdl IGNhbiBjaXRlIGZvciB0aGF0Lg0KDQpTbyBnb2luZyBiYWNrIHRvIEp1bGl1c3oncyBsaXN0ZWQg b3B0aW9ucyBpbiB0aGUgb3RoZXIgdGhyZWFkIDxodHRwczovL21haWxhcmNoaXZlLmlldGYub3Jn L2FyY2gvbXNnL2JhYmVsL1FsdnNQQjl5WUZQVFB3UXhhTGNXSU4zSGwyWTxodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX21haWxhcmNoaXZlLmlldGYu b3JnX2FyY2hfbXNnX2JhYmVsX1FsdnNQQjl5WUZQVFB3UXhhTGNXSU4zSGwyWSZkPUR3TUZhUSZj PUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1Mb0d6aEMtOHNjOFNZOFRxNHZyZm9nJm09cjRkS1cw SE5TcmpOUFhkWElkSl8za0djM1hyUkl4ZEJhYzYwRHVhOUY5USZzPWhjd2k1UUR3Rzd3cTk2Y0U1 dlViSjZMWUowbU5uNnAwaUdzdFBvc2t6TzgmZT0+PiwgSSB3b3VsZCBhcmd1ZSBmb3Igb3B0aW9u IDMgImJ1cmVhdWNyYXRpYyIgYmVjYXVzZSBpdCBmb2xsb3dzIHRoZSBkZXNpZ24gcHJpbmNpcGxl ICJUaGUgQmFiZWwgV0cgZG9lcyBub3QgbWFrZSBzZWN1cml0eSBkZWNpc2lvbnMsIHdlIGZvbGxv dyB3aGF0IFJGQ3MgdGVsbCB1cyIuDQoNCkRhdmlkDQoNCk9uIFRodSwgQXVnIDE1LCAyMDE5IGF0 IDk6NTggQU0gU1RBUkssIEJBUkJBUkEgSCA8YnM3NjUyQGF0dC5jb208bWFpbHRvOmJzNzY1MkBh dHQuY29tPj4gd3JvdGU6DQo+ID4gSXMgdGhpcyBzdWdnZXN0aW5nIHRoYXQgaXQncyBvayBmb3Ig aW5mby1tb2RlbCB0byBwcm92aWRlIGJhYmVsLWhtYWMNCj4gPiB3aXRoIGFueSB2YWx1ZSBiZXR3 ZWVuIDAgYW5kIDY0IGJ5dGVzIGluIGxlbmd0aCBmb3IgSE1BQy1TSEEyNTYgb3INCj4gPiBiZXR3 ZWVuIDAgYW5kIDMyIGJ5dGVzIGluIGxlbmd0aCBmb3IgQmxha2UycyBhbmQgYmFiZWwtaG1hYyBj YW4gYmUNCj4gPiBleHBlY3RlZCB0byB6ZXJvLXBhZD8gT3IgYXJlIHlvdSBzdGlsbCBleHBlY3Rp bmcgaW5mby1tb2RlbCB0byBkbyB0aGUNCj4gPiB6ZXJvLXBhZGRpbmcgYmVmb3JlIHByb3ZpZGlu ZyB0byBiYWJlbC1obWFjPw0KPg0KPiBUaGUgZm9ybWVyLiAgWW91IGdpdmUgbWUgYW55dGhpbmcg YmV0d2VlbiAwIGFuZCAzMi82NCwgYW5kIEkgZGVhbCB3aXRoIGl0Lg0KDQpDb29sLiBUaGVuIGZy b20gYSBwdXJlbHkgaW5mby1tb2RlbCBwZXJzcGVjdGl2ZSwgaXQgc291bmRzIGxpa2UgdGhlIGtl eS12YWx1ZSBwYXJhbWV0ZXIgbGVuZ3RoIGNvbnN0cmFpbnRzIGFyZToNCg0KICBUaGlzIHZhbHVl IGlzIG9mIGEgbGVuZ3RoIHN1aXRhYmxlIGZvciB0aGUgYXNzb2NpYXRlZA0KICBiYWJlbC1tYWMt a2V5LWFsZ29yaXRobS4gIElmIHRoZSBhbGdvcml0aG0gaXMgYmFzZWQgb24gdGhlIEhNQUMNCiAg Y29uc3RydWN0aW9uLCB0aGUgbGVuZ3RoIE1VU1QgYmUgYmV0d2VlbiAwIGFuZCB0aGUgYmxvY2sg c2l6ZSBvZiB0aGUNCiAgdW5kZXJseWluZyBoYXNoIGluY2x1c2l2ZSAod2hlcmUgIkhNQUMtU0hB MjU2IiBibG9jayBzaXplIGlzIDY0IGJ5dGVzDQogIGFzIGRlc2NyaWJlZCBpbiB7e1JGQzQ4Njh9 fSkuDQogIElmIHRoZSBhbGdvcml0aG0gaXMgIkJMQUtFMnMiLCB0aGUgbGVuZ3RoIE1VU1QgYmUg YmV0d2VlbiAwIGFuZCAzMiBieXRlcw0KICBpbmNsdXNpdmUsIGFzIGRlc2NyaWJlZCBpbiB7e1JG Qzc2OTN9fS4NCg0KQW55dGhpbmcgY29tcGx5aW5nIHdpdGggaW5mby1tb2RlbCB3b24ndCBzdXBw bHkgYW55dGhpbmcgbG9uZ2VyIHRoYW4gdGhlIGlkZW50aWZpZWQgbWF4IGxlbmd0aC4NCkEgYmFi ZWwtaG1hYyBpbXBsZW1lbnRhdGlvbiBtYXkgZ2V0IHNvbWV0aGluZyBhcyBzaG9ydCBhcyB6ZXJv IGxlbmd0aCwgYnV0IHdpbGwgYmUgZXhwZWN0ZWQgdG8gZGVhbCB3aXRoIGl0LiBJbmZvLW1vZGVs IGRvZXNuJ3QgY2FyZSBhbmQgZG9lc24ndCBuZWVkIHRvIGtub3cgd2hhdCAiZGVhbCB3aXRoIGl0 IiBtZWFucy4NCkZvciBITUFDIGFuZCBCbGFrZTJzIGFsZ29yaXRobXMsICJkZWFsIHdpdGggaXQi IG1lYW5zIGhtYWMtYmFiZWwgd2lsbCB6ZXJvLXBhZCBzaG9ydGVyIHN0cmluZ3MsIGJlY2F1c2Ug dGhhdCdzIHdoYXQgdGhlIGFsZ29yaXRobSBSRkNzIHNheSB0byBkbyAoYW5kIG5vdCBiZWNhdXNl IGJhYmVsLWhtYWMgaGFzIGFueSBleHRyYSByZXF1aXJlbWVudHMgZ29pbmcgYmV5b25kIHRoZSBh bGdvcml0aG0gc3BlY3MpLg0KSW5mby1tb2RlbCB3b24ndCBzZW5kIHN0cmluZ3MgbG9uZ2VyIHRo YW4gdGhlIGluZGljYXRlZCBsZW5ndGguIElmIHRoZXJlIGlzIGEgVUkgdG8gaW5mbyBtb2RlbCB0 aGF0IGFjY2VwdHMgYSBsb25nZXIgc3RyaW5nLCBoYXNoZXMgaXQsIGFuZCB0aGVuIGluZm8tbW9k ZWwgcHJvdmlkZXMgdGhlIGhhc2hlZCB2YWx1ZSwgdGhhdCBpcyB3aGF0IGl0IGlzLiBOZWl0aGVy IGluZm8tbW9kZWwgbm9yIGJhYmVsLWhtYWMgY2FyZSBvciBrbm93IG9yIG5lZWQgdG8ga25vdyBh Ym91dCB0aGlzLg0KSWYgYSBiYWJlbC1obWFjIGltcGxlbWVudGF0aW9uIGRvZXMgaGF2ZSBzcGVj aWFsIGhhbmRsaW5nIGZvciBsb25nZXIgc3RyaW5ncywgdGhhdCdzIGZpbmUsIHRvby4gQnV0IGEg dmFsdWUgY29taW5nIGZyb20gaW5mby1tb2RlbCB3aWxsIG5ldmVyIHRyaWdnZXIgdGhpcyBzcGVj aWFsIGNvZGUuDQpEb2VzIHRoYXQgc291bmQgcmlnaHQ/DQpCYXJiYXJhDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpiYWJlbCBtYWlsaW5nIGxpc3QN CmJhYmVsQGlldGYub3JnPG1haWx0bzpiYWJlbEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYmFiZWw8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19iYWJl bCZkPUR3TUZhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1Mb0d6aEMtOHNjOFNZOFRxNHZy Zm9nJm09cjRkS1cwSE5TcmpOUFhkWElkSl8za0djM1hyUkl4ZEJhYzYwRHVhOUY5USZzPTVoVU5q Ni1WZHpLX05xY1Bfak9Pb1JKdVFfVzM4OHY1WVQ2WmwyUnF4RGcmZT0+DQo= --_000_2D09D61DDFA73D4C884805CC7865E6114E27796EGAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBk aXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRpc2FncmVlLiA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIEhNQUMgc3BlY3MgKFJGQzIxMDQpIHNheXM6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEFw cGxpY2F0aW9ucyB0aGF0IHVzZSBrZXlzIGxvbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdGhhbiBCDQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+W2Jsb2NrIHNpemVdPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4gYnl0ZXMgd2lsbCBm aXJzdCBoYXNoIHRoZSBrZXkgdXNpbmcgSCBhbmQgdGhlbiB1c2UgdGhlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyByZXN1 bHRhbnQgTA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPltoYXNoIG91dHB1dCBzaXplXQ0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5ieXRlIHN0cmluZyBhcyB0aGUgYWN0dWFsIGtleSB0byBITUFDLiBJbiBhbnkg Y2FzZSB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IG1pbmltYWwgcmVjb21tZW5kZWQgbGVuZ3RoIGZvciBLIGlzIEwg Ynl0ZXMgKGFzIHRoZSBoYXNoIG91dHB1dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgbGVuZ3RoKS4gU2VlIHNlY3Rpb24g MyBmb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBrZXlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmFuZCBmcm9tIHNlY3Rpb24gMyA8bzpwPjwvbzpwPjwvcD4NCjxw cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIGtleSBmb3IgSE1BQyBjYW4gYmUgb2YgYW55IGxlbmd0 aCAoa2V5cyBsb25nZXIgdGhhbiBCIGJ5dGVzIGFyZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyBmaXJzdCBoYXNoZWQgdXNpbmcgSCkuJm5ic3A7IEhvd2V2ZXIsIGxlc3MgdGhh biBMIGJ5dGVzIGlzIHN0cm9uZ2x5PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IGRpc2NvdXJhZ2VkIGFzIGl0IHdvdWxkIGRlY3JlYXNlIHRoZSBzZWN1cml0eSBzdHJlbmd0aCBv ZiB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZnVuY3Rpb24uJm5ic3A7 IEtleXMgbG9uZ2VyIHRoYW4gTCBieXRlcyBhcmUgYWNjZXB0YWJsZSBidXQgdGhlIGV4dHJhPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGxlbmd0aCB3b3VsZCBub3Qgc2lnbmlm aWNhbnRseSBpbmNyZWFzZSB0aGUgZnVuY3Rpb24gc3RyZW5ndGguIChBPG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGxvbmdlciBrZXkgbWF5IGJlIGFkdmlzYWJsZSBpZiB0aGUg cmFuZG9tbmVzcyBvZiB0aGUga2V5IGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7IGNvbnNpZGVyZWQgd2Vhay4pPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhpcyBs YW5ndWFnZSwgdGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgZm9yIGFwcGxpY2F0aW9ucyB1c2luZyBI TUFDIHRvIGFjY2VwdCAob3IgYmUgYWJsZSB0byB1c2UpIGtleXMgbG9uZ2VyIHRoYW4gQiBieXRl cy4gVGhlIHR3byBzdGF0ZW1lbnRzIGRvIHNheSB3aGF0IG11c3QgaGFwcGVuICo8Yj5pZjwvYj4q IGEga2V5IGxvbmdlciB0aGFuIEIgYnl0ZXMgaXMgcHJvdmlkZWQuIEJ1dCBpZiBCYWJlbCB3YW50 cw0KIHRvIHJlc3RyaWN0IGtleXMgdG8gbm8gbW9yZSB0aGFuIEIgYnl0ZXMsIHRoYXQgaXMgd2Vs bCB3aXRoaW4gQmFiZWzigJlzIHB1cnZpZXcgdG8gZG8gc28uIFJGQzIxMDYgdmVyeSBjbGVhcmx5 IHRlbGxzIGFwcGxpY2F0aW9ucyBnZXQgdG8gZGVjaWRlIHdoYXQgdG8gdXNlLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGUgb3RoZXIgdGhpbmcgSSBnZXQgZnJvbSB0aGlzLCB0aG91Z2gsIGlz IHRoYXQgaXTigJlzIHJlY29tbWVuZGVkIHRvIGhhdmUgYXQgbGVhc3QgTCBieXRlcyBmb3IgYW4g SE1BQyBrZXkgKEwgPSAzMiBmb3IgU0hBLTI1NikuIEkgdGhpbmsgd2Ugc2hvdWxkIHJlZmxlY3Qg dGhpcyByZWNvbW1lbmRhdGlvbi4gV2UgY291bGQgZG8gaXQgZWl0aGVyIHdpdGggYSDigJxTSE9V TETigJ0gb3Ig4oCcTVVTVOKAnSBiZSBhdCBsZWFzdA0KIHRoZSBvdXRwdXQgaGFzaCBsZW5ndGgg KG5vdCBzZXQgdGhlIG1pbmltdW0gYXQgMCkuIEkgc2VlIG5vIHJlYXNvbiBub3QgdG8gdXBncmFk ZSB0aGF0IHRvIGEgTVVTVCBmb3IgQmFiZWwsIGlmIHdlIHdhbnQuIFtJdOKAmXMgYWx3YXlzIG9r IHRvIGJlIHN0cmljdGVyIHRoYW4gYSByZWZlcmVuY2VkIHNwZWMgKGUuZy4sIGNoYW5nZSBTSE9V TEQgdG8gTVVTVCkg4oCTIGl04oCZcyBqdXN0IG5vdCBvayB0byBkbyBvciBhbGxvdyBzb21ldGhp bmcgdGhhdCB2aW9sYXRlcw0KIGEgcmVxdWlyZW1lbnQgZnJvbSB0aGUgc3BlYyAoZS5nLiwgY2hh bmdlIE1VU1QgdG8gU0hPVUxEKS5dIEkgdGhpbmsgYXQgbGVhc3QgYSBNVVNUIGJlIGF0IGxlYXN0 IDggYnl0ZXPigJ0gd2l0aCBhIOKAnFNIT1VMRCBiZSBhdCBsZWFzdCB0aGUgb3V0cHV0IGhhc2gg bGVuZ3Ro4oCdIHdvdWxkIGJlIGdvb2QgZm9yIEhNQUMuIEl04oCZcyBhbHNvIG9rIGZvciB0aGUg aW5mb3JtYXRpb24gbW9kZWwgdG8gYmUgc3RyaWN0ZXIgdGhhbiB0aGUgYmFiZWwtaG1hYyBpbXBs ZW1lbnRhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Qmxha2UycyBkb2VzIHNwZWNpZmlj YWxseSBhbGxvdyB6ZXJvLWxlbmd0aCBrZXlzIOKAkyB0aG91Z2ggSSBkb27igJl0IGtub3cgaG93 IGFkdmlzYWJsZSB0aGF0IGlzIGluIGEgQmFiZWwgdXNhZ2Ugc2NlbmFyaW8uIEkgZG9u4oCZdCBr bm93IHdoZW4ga2V5IGxlbmd0aCBvZiAwIGlzIHVzZWZ1bC4gQnV0IHRoZXJlIGlzIGRlZmluaXRl bHkgbm90aGluZyB0aGF0IHByZXZlbnRzIHVzIGZyb20gYmVpbmcgc3RyaWN0ZXIsIGlmDQogd2Ug d2FudGVkIHRvIGluc2lzdCBvbiBhIGtleSBsb25nZXIgdGhhbiAwLiBBZ2FpbiwgdGhpcyBzdHJp Y3RuZXNzIGNhbiBiZSBpbiBpbmZvLW1vZGVsIG9ubHkgYW5kIGRvZXNu4oCZdCBoYXZlIHRvIGJl IHJlZmxlY3RlZCBpbiBiYWJlbC1obWFjLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIG5l ZWQgc29tZSBtYXhpbXVtIHNpemUgb24gdGhlIHBhcmFtZXRlciAoaW5kZXBlbmRlbnQgb2Yga2V5 IGFsZ29yaXRobSkg4oCTIHNvIGl0IHdvbuKAmXQgYmUgdW5saW1pdGVkIGxlbmd0aCwgYW55d2F5 LiBJ4oCZbSB0aGlua2luZyAxMjggYnl0ZXMgYXMgYW4gYWJzb2x1dGUgdXBwZXIgbGltaXQgYXQg dGhpcyB0aW1lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFyYmFyYTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BY2NvcmRpbmcgdG8gUkZDIDc2OTMsIEJsYWtlMnMga2V5cyBtdXN0IGJlIG9mIGxlbmd0 aCBrayB3aGVyZSZuYnNwOzAgJmx0Oz0ga2sgJmx0Oz0gMzIuIFNvIGhhdmluZyB0aGUgaW5mbyBt b2RlbCBkaWN0YXRlIHRoYXQga2V5cyBNVVNUIGZvbGxvdyB0aGF0IGlzIHBlcmZlY3RseSByZWFz b25hYmxlIHRvIG1lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Ib3dldmVyLCBhY2NvcmRpbmcgdG8gUkZDIDYyMzQsIEhNQUMtU0hBLTI1NiBh bGxvd3MgYWxsIGtleSBsZW5ndGhzIGtrIHdoZXJlIDAgJmx0Oz0ga2suIEkgZG9uJ3QgdGhpbmsg dGhlIGluZm9ybWF0aW9uIG1vZGVsIHNob3VsZCBleHByZXNzIGFuIG9waW5pb24gYXMgdG8gd2hl dGhlciBrZXlzIGxvbmdlciB0aGFuIDY0IGJ5dGVzIGFyZSBzYWZlIG9yIG5vdC4gSWYgd2UgY2hv b3NlIHRvIGFkZCB0aGF0IGRpc3RpbmN0aW9uDQogd2UnbGwgbmVlZCB0byBqdXN0aWZ5IHdoeSB3 ZSB0aGluayB0aGUga2V5IGhhc2hpbmcgaXMgdW5zYWZlLCBhbmQgSSBkb24ndCB0aGluayB0aGVy ZSBpcyBhbiBSRkMgd2UgY2FuIGNpdGUgZm9yIHRoYXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGdvaW5nIGJhY2sgdG8gSnVsaXVzeidz IGxpc3RlZCBvcHRpb25zIGluIHRoZSBvdGhlciB0aHJlYWQgJmx0OzxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fbWFpbGFyY2hpdmUu aWV0Zi5vcmdfYXJjaF9tc2dfYmFiZWxfUWx2c1BCOXlZRlBUUHdReGFMY1dJTjNIbDJZJmFtcDtk PUR3TUZhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPUxvR3poQy04c2M4U1k4 VHE0dnJmb2cmYW1wO209cjRkS1cwSE5TcmpOUFhkWElkSl8za0djM1hyUkl4ZEJhYzYwRHVhOUY5 USZhbXA7cz1oY3dpNVFEd0c3d3E5NmNFNXZVYko2TFlKMG1ObjZwMGlHc3RQb3Nrek84JmFtcDtl PSI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9iYWJlbC9RbHZzUEI5eVlG UFRQd1F4YUxjV0lOM0hsMlk8L2E+Jmd0OywNCiBJIHdvdWxkIGFyZ3VlIGZvciBvcHRpb24gMyAm cXVvdDtidXJlYXVjcmF0aWMmcXVvdDsgYmVjYXVzZSBpdCBmb2xsb3dzIHRoZSBkZXNpZ24gcHJp bmNpcGxlICZxdW90O1RoZSBCYWJlbCBXRyBkb2VzIG5vdCBtYWtlIHNlY3VyaXR5IGRlY2lzaW9u cywgd2UgZm9sbG93IHdoYXQgUkZDcyB0ZWxsIHVzJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXZpZDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEF1ZyAxNSwgMjAx OSBhdCA5OjU4IEFNIFNUQVJLLCBCQVJCQVJBIEggJmx0OzxhIGhyZWY9Im1haWx0bzpiczc2NTJA YXR0LmNvbSI+YnM3NjUyQGF0dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgJmd0OyBJcyB0aGlz IHN1Z2dlc3RpbmcgdGhhdCBpdCdzIG9rIGZvciBpbmZvLW1vZGVsIHRvIHByb3ZpZGUgYmFiZWwt aG1hYzxicj4NCiZndDsgJmd0OyB3aXRoIGFueSB2YWx1ZSBiZXR3ZWVuIDAgYW5kIDY0IGJ5dGVz IGluIGxlbmd0aCBmb3IgSE1BQy1TSEEyNTYgb3I8YnI+DQomZ3Q7ICZndDsgYmV0d2VlbiAwIGFu ZCAzMiBieXRlcyBpbiBsZW5ndGggZm9yIEJsYWtlMnMgYW5kIGJhYmVsLWhtYWMgY2FuIGJlPGJy Pg0KJmd0OyAmZ3Q7IGV4cGVjdGVkIHRvIHplcm8tcGFkPyBPciBhcmUgeW91IHN0aWxsIGV4cGVj dGluZyBpbmZvLW1vZGVsIHRvIGRvIHRoZTxicj4NCiZndDsgJmd0OyB6ZXJvLXBhZGRpbmcgYmVm b3JlIHByb3ZpZGluZyB0byBiYWJlbC1obWFjPzxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgZm9y bWVyLiZuYnNwOyBZb3UgZ2l2ZSBtZSBhbnl0aGluZyBiZXR3ZWVuIDAgYW5kIDMyLzY0LCBhbmQg SSBkZWFsIHdpdGggaXQuPGJyPg0KPGJyPg0KQ29vbC4gVGhlbiBmcm9tIGEgcHVyZWx5IGluZm8t bW9kZWwgcGVyc3BlY3RpdmUsIGl0IHNvdW5kcyBsaWtlIHRoZSBrZXktdmFsdWUgcGFyYW1ldGVy IGxlbmd0aCBjb25zdHJhaW50cyBhcmU6PGJyPg0KPGJyPg0KJm5ic3A7IFRoaXMgdmFsdWUgaXMg b2YgYSBsZW5ndGggc3VpdGFibGUgZm9yIHRoZSBhc3NvY2lhdGVkPGJyPg0KJm5ic3A7IGJhYmVs LW1hYy1rZXktYWxnb3JpdGhtLiZuYnNwOyBJZiB0aGUgYWxnb3JpdGhtIGlzIGJhc2VkIG9uIHRo ZSBITUFDPGJyPg0KJm5ic3A7IGNvbnN0cnVjdGlvbiwgdGhlIGxlbmd0aCBNVVNUIGJlIGJldHdl ZW4gMCBhbmQgdGhlIGJsb2NrIHNpemUgb2YgdGhlPGJyPg0KJm5ic3A7IHVuZGVybHlpbmcgaGFz aCBpbmNsdXNpdmUgKHdoZXJlICZxdW90O0hNQUMtU0hBMjU2JnF1b3Q7IGJsb2NrIHNpemUgaXMg NjQgYnl0ZXM8YnI+DQombmJzcDsgYXMgZGVzY3JpYmVkIGluIHt7UkZDNDg2OH19KS48YnI+DQom bmJzcDsgSWYgdGhlIGFsZ29yaXRobSBpcyAmcXVvdDtCTEFLRTJzJnF1b3Q7LCB0aGUgbGVuZ3Ro IE1VU1QgYmUgYmV0d2VlbiAwIGFuZCAzMiBieXRlczxicj4NCiZuYnNwOyBpbmNsdXNpdmUsIGFz IGRlc2NyaWJlZCBpbiB7e1JGQzc2OTN9fS48YnI+DQo8YnI+DQpBbnl0aGluZyBjb21wbHlpbmcg d2l0aCBpbmZvLW1vZGVsIHdvbid0IHN1cHBseSBhbnl0aGluZyBsb25nZXIgdGhhbiB0aGUgaWRl bnRpZmllZCBtYXggbGVuZ3RoLjxicj4NCkEgYmFiZWwtaG1hYyBpbXBsZW1lbnRhdGlvbiBtYXkg Z2V0IHNvbWV0aGluZyBhcyBzaG9ydCBhcyB6ZXJvIGxlbmd0aCwgYnV0IHdpbGwgYmUgZXhwZWN0 ZWQgdG8gZGVhbCB3aXRoIGl0LiBJbmZvLW1vZGVsIGRvZXNuJ3QgY2FyZSBhbmQgZG9lc24ndCBu ZWVkIHRvIGtub3cgd2hhdCAmcXVvdDtkZWFsIHdpdGggaXQmcXVvdDsgbWVhbnMuPGJyPg0KRm9y IEhNQUMgYW5kIEJsYWtlMnMgYWxnb3JpdGhtcywgJnF1b3Q7ZGVhbCB3aXRoIGl0JnF1b3Q7IG1l YW5zIGhtYWMtYmFiZWwgd2lsbCB6ZXJvLXBhZCBzaG9ydGVyIHN0cmluZ3MsIGJlY2F1c2UgdGhh dCdzIHdoYXQgdGhlIGFsZ29yaXRobSBSRkNzIHNheSB0byBkbyAoYW5kIG5vdCBiZWNhdXNlIGJh YmVsLWhtYWMgaGFzIGFueSBleHRyYSByZXF1aXJlbWVudHMgZ29pbmcgYmV5b25kIHRoZSBhbGdv cml0aG0gc3BlY3MpLjxicj4NCkluZm8tbW9kZWwgd29uJ3Qgc2VuZCBzdHJpbmdzIGxvbmdlciB0 aGFuIHRoZSBpbmRpY2F0ZWQgbGVuZ3RoLiBJZiB0aGVyZSBpcyBhIFVJIHRvIGluZm8gbW9kZWwg dGhhdCBhY2NlcHRzIGEgbG9uZ2VyIHN0cmluZywgaGFzaGVzIGl0LCBhbmQgdGhlbiBpbmZvLW1v ZGVsIHByb3ZpZGVzIHRoZSBoYXNoZWQgdmFsdWUsIHRoYXQgaXMgd2hhdCBpdCBpcy4gTmVpdGhl ciBpbmZvLW1vZGVsIG5vciBiYWJlbC1obWFjIGNhcmUgb3Iga25vdyBvciBuZWVkDQogdG8ga25v dyBhYm91dCB0aGlzLjxicj4NCklmIGEgYmFiZWwtaG1hYyBpbXBsZW1lbnRhdGlvbiBkb2VzIGhh dmUgc3BlY2lhbCBoYW5kbGluZyBmb3IgbG9uZ2VyIHN0cmluZ3MsIHRoYXQncyBmaW5lLCB0b28u IEJ1dCBhIHZhbHVlIGNvbWluZyBmcm9tIGluZm8tbW9kZWwgd2lsbCBuZXZlciB0cmlnZ2VyIHRo aXMgc3BlY2lhbCBjb2RlLjxicj4NCkRvZXMgdGhhdCBzb3VuZCByaWdodD88YnI+DQpCYXJiYXJh PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpiYWJlbCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86YmFiZWxAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5iYWJlbEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5p ZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2JhYmVsJmFtcDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85 X0hVTWVNVFNRaWN2aklnJmFtcDtyPUxvR3poQy04c2M4U1k4VHE0dnJmb2cmYW1wO209cjRkS1cw SE5TcmpOUFhkWElkSl8za0djM1hyUkl4ZEJhYzYwRHVhOUY5USZhbXA7cz01aFVOajYtVmR6S19O cWNQX2pPT29SSnVRX1czODh2NVlUNlpsMlJxeERnJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmFiZWw8L2E+PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_2D09D61DDFA73D4C884805CC7865E6114E27796EGAALPA1MSGUSRBF_-- From nobody Thu Aug 15 15:56:45 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 0242E1200F1 for ; Thu, 15 Aug 2019 15:56:44 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 DH3tw0-WeqJr for ; Thu, 15 Aug 2019 15:56:40 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4731200E7 for ; Thu, 15 Aug 2019 15:56:40 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id x18so3657937ljh.1 for ; Thu, 15 Aug 2019 15:56:40 -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=O4hw2HdOUAdicILTKSm7n/yaTq+QHrNZJtlVW99QmNM=; b=RfZrwu1euclxzlOq++SQsU1U/geEzaP6TJC0P3TyCvgkafHjhq1T8V2E3IIbHoXPy+ Nx+9QMi/whC8FVbzBf+ZEDW+LOgMjHpW5Fi2WimBwqguTxkqpPDMEMcppI1hj4opumib +GRjcQWyzVlvQLD5CR1D7LmRoU3fR9guUskslEFKKLHNu+BE6E7ufP128kaUp/Ovsa4d PZFqZ6zCMfUQA9vYk7mbEspHkGGIVGYrfIADjvKKhwxcHFWbLfAPE1EV1pjSdCgunfnJ +kaWW//TPYCBKK9BmEK6XdYOkDfFMwXpilEBSq45vLM5hOi5ND8YrpSm2oUL66AaQ8JE XInQ== 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=O4hw2HdOUAdicILTKSm7n/yaTq+QHrNZJtlVW99QmNM=; b=QhvBrZX/ojMak+psjFCe8sFdHmirxh8UMzxTjRt4bd8FPbvEI7k4GrmRMmgibSYSEs hg4sLpoKDEXYSMbEOdb2jdGP6DgNxQJ5rnLfZUfzjz8OqX8ARgKmaT4YA+p9eHUNF7l3 piE4aky4cZu7rvSI4xunOpE0jANdqg+xeAhPByD7MVVhSJBLUviv5laSKPTq2zuEtoo/ sD2UM/M9VhaqH6yv/E/iBs2MoUxcan81fLy4iUEs/ptCMCCSbJyfj9hliOKIrCeLGAQQ ByDob6UL3EgkIad66vlyOon+mpfw+JYUoOLqYZ6qEQZLxD5Y0GjmbLLhdKBsg5NkJxMF cM+g== X-Gm-Message-State: APjAAAUaoqSggrUaJWYjqGPDch7Pl5nVIlTidwHa+N8kvbR9TFLJ5ez5 KkCWywKGWvgl/XLWsena2l0ez67bse7UwMGQXWE= X-Google-Smtp-Source: APXvYqzPS3uftFNdmPK+zLU5XtppHRHOsG3PH/Tfj8SNXk78mNYATNKzhF/0DvUBl6e1WI/SUxNiqnGZfO3xeaFOLFg= X-Received: by 2002:a2e:81c3:: with SMTP id s3mr3922241ljg.70.1565909798445; Thu, 15 Aug 2019 15:56:38 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> <87ftm3u0a6.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269981@GAALPA1MSGUSRBF.ITServices.sbc.com> <87blwrtudx.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E275E65@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E27796E@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E27796E@GAALPA1MSGUSRBF.ITServices.sbc.com> From: David Schinazi Date: Thu, 15 Aug 2019 15:56:27 -0700 Message-ID: To: "STARK, BARBARA H" Cc: "babel@ietf.org" , Juliusz Chroboczek Content-Type: multipart/alternative; boundary="00000000000049657805902fc920" Archived-At: Subject: Re: [babel] info-model: preparing -09 on github 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: Thu, 15 Aug 2019 22:56:44 -0000 --00000000000049657805902fc920 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If we're considering adding restrictions specific to Babel (and/or the info model), I think we should take a principled approach. What fundamental principles are we using to decide these restrictions? If we allow a 1-byte key but disallow a 65-byte key, then the principle we're after is not improving security? On Thu, Aug 15, 2019 at 2:46 PM STARK, BARBARA H wrote: > I disagree. > > > > The HMAC specs (RFC2104) says: > > Applications that use keys longer > > than B [block size] bytes will first hash the key using H and then use > the > > resultant L [hash output size] byte string as the actual key to HMAC. > In any case the > > minimal recommended length for K is L bytes (as the hash output > > length). See section 3 for more information on keys. > > and from section 3 > > The key for HMAC can be of any length (keys longer than B bytes are > > first hashed using H). However, less than L bytes is strongly > > discouraged as it would decrease the security strength of the > > function. Keys longer than L bytes are acceptable but the extra > > length would not significantly increase the function strength. (A > > longer key may be advisable if the randomness of the key is > > considered weak.) > > > > In this language, there is no requirement for applications using HMAC to > accept (or be able to use) keys longer than B bytes. The two statements d= o > say what must happen **if** a key longer than B bytes is provided. But if > Babel wants to restrict keys to no more than B bytes, that is well within > Babel=E2=80=99s purview to do so. RFC2106 very clearly tells applications= get to > decide what to use. > > > > The other thing I get from this, though, is that it=E2=80=99s recommended= to have > at least L bytes for an HMAC key (L =3D 32 for SHA-256). I think we shoul= d > reflect this recommendation. We could do it either with a =E2=80=9CSHOULD= =E2=80=9D or > =E2=80=9CMUST=E2=80=9D be at least the output hash length (not set the mi= nimum at 0). I see > no reason not to upgrade that to a MUST for Babel, if we want. [It=E2=80= =99s always > ok to be stricter than a referenced spec (e.g., change SHOULD to MUST) = =E2=80=93 > it=E2=80=99s just not ok to do or allow something that violates a require= ment from > the spec (e.g., change MUST to SHOULD).] I think at least a MUST be at > least 8 bytes=E2=80=9D with a =E2=80=9CSHOULD be at least the output hash= length=E2=80=9D would be > good for HMAC. It=E2=80=99s also ok for the information model to be stric= ter than > the babel-hmac implementation. > > > > Blake2s does specifically allow zero-length keys =E2=80=93 though I don= =E2=80=99t know how > advisable that is in a Babel usage scenario. I don=E2=80=99t know when ke= y length > of 0 is useful. But there is definitely nothing that prevents us from bei= ng > stricter, if we wanted to insist on a key longer than 0. Again, this > strictness can be in info-model only and doesn=E2=80=99t have to be refle= cted in > babel-hmac. > > > > I do need some maximum size on the parameter (independent of key > algorithm) =E2=80=93 so it won=E2=80=99t be unlimited length, anyway. I= =E2=80=99m thinking 128 > bytes as an absolute upper limit at this time. > > Barbara > > > > According to RFC 7693, Blake2s keys must be of length kk where 0 <=3D kk = <=3D > 32. So having the info model dictate that keys MUST follow that is > perfectly reasonable to me. > > > > However, according to RFC 6234, HMAC-SHA-256 allows all key lengths kk > where 0 <=3D kk. I don't think the information model should express an > opinion as to whether keys longer than 64 bytes are safe or not. If we > choose to add that distinction we'll need to justify why we think the key > hashing is unsafe, and I don't think there is an RFC we can cite for that= . > > > > So going back to Juliusz's listed options in the other thread < > https://mailarchive.ietf.org/arch/msg/babel/QlvsPB9yYFPTPwQxaLcWIN3Hl2Y > >, > I would argue for option 3 "bureaucratic" because it follows the design > principle "The Babel WG does not make security decisions, we follow what > RFCs tell us". > > > > David > > > > On Thu, Aug 15, 2019 at 9:58 AM STARK, BARBARA H wrote: > > > > Is this suggesting that it's ok for info-model to provide babel-hmac > > > with any value between 0 and 64 bytes in length for HMAC-SHA256 or > > > between 0 and 32 bytes in length for Blake2s and babel-hmac can be > > > expected to zero-pad? Or are you still expecting info-model to do the > > > zero-padding before providing to babel-hmac? > > > > The former. You give me anything between 0 and 32/64, and I deal with > it. > > Cool. Then from a purely info-model perspective, it sounds like the > key-value parameter length constraints are: > > This value is of a length suitable for the associated > babel-mac-key-algorithm. If the algorithm is based on the HMAC > construction, the length MUST be between 0 and the block size of the > underlying hash inclusive (where "HMAC-SHA256" block size is 64 bytes > as described in {{RFC4868}}). > If the algorithm is "BLAKE2s", the length MUST be between 0 and 32 byte= s > inclusive, as described in {{RFC7693}}. > > Anything complying with info-model won't supply anything longer than the > identified max length. > A babel-hmac implementation may get something as short as zero length, bu= t > will be expected to deal with it. Info-model doesn't care and doesn't nee= d > to know what "deal with it" means. > For HMAC and Blake2s algorithms, "deal with it" means hmac-babel will > zero-pad shorter strings, because that's what the algorithm RFCs say to d= o > (and not because babel-hmac has any extra requirements going beyond the > algorithm specs). > Info-model won't send strings longer than the indicated length. If there > is a UI to info model that accepts a longer string, hashes it, and then > info-model provides the hashed value, that is what it is. Neither > info-model nor babel-hmac care or know or need to know about this. > If a babel-hmac implementation does have special handling for longer > strings, that's fine, too. But a value coming from info-model will never > trigger this special code. > Does that sound right? > Barbara > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > > > --00000000000049657805902fc920 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If we're considering adding restrictions specific to B= abel (and/or the info model), I think we should take a principled approach.= What fundamental principles are we using to decide these restrictions? If = we allow a 1-byte key but disallow a 65-byte key, then the principle we'= ;re after is not improving security?

On Thu, Aug 15, 2019 at 2:46 PM STARK, = BARBARA H <bs7652@att.com> wrot= e:

I disagree.

=C2=A0

The HMAC specs (RFC2104) says:

=C2=A0=C2=A0 Applications that use keys longer=

=C2=A0=C2=A0 than B [block s= ize] bytes will first hash the key using H and then use the

=C2=A0=C2=A0 resultant L [hash ou= tput size] b= yte string as the actual key to HMAC. In any case the<= /p>

=C2=A0=C2=A0 minimal recommended length for K is L bytes (as= the hash output

=C2=A0=C2=A0 length). See section 3 for more information on = keys.

and from section 3 

=C2=A0=C2=A0=C2=A0The key for HMAC can be of any length (keys longer t=
han B bytes are
=C2=A0=C2=A0 first hashed using H).=C2=A0 However, less than L bytes i=
s strongly
=C2=A0=C2=A0 discouraged as it would decrease the security strength of=
 the
=C2=A0=C2=A0 function.=C2=A0 Keys longer than L bytes are acceptable b=
ut the extra
=C2=A0=C2=A0 length would not significantly increase the function stre=
ngth. (A
=C2=A0=C2=A0 longer key may be advisable if the randomness of the key =
is
=C2=A0=C2=A0 considered weak.)

=C2=A0

In this language, there is no requirement for applic= ations using HMAC to accept (or be able to use) keys longer than B bytes. T= he two statements do say what must happen *if* a key longer than B b= ytes is provided. But if Babel wants to restrict keys to no more than B bytes, that is well within Babel=E2=80= =99s purview to do so. RFC2106 very clearly tells applications get to decid= e what to use.

=C2=A0

The other thing I get from this, though, is that it= =E2=80=99s recommended to have at least L bytes for an HMAC key (L =3D 32 f= or SHA-256). I think we should reflect this recommendation. We could do it = either with a =E2=80=9CSHOULD=E2=80=9D or =E2=80=9CMUST=E2=80=9D be at leas= t the output hash length (not set the minimum at 0). I see no reason not to = upgrade that to a MUST for Babel, if we want. [It=E2=80=99s always ok to be= stricter than a referenced spec (e.g., change SHOULD to MUST) =E2=80=93 it= =E2=80=99s just not ok to do or allow something that violates a requirement from the spec (e.g., change MUST to SHOULD).] I think at lea= st a MUST be at least 8 bytes=E2=80=9D with a =E2=80=9CSHOULD be at least t= he output hash length=E2=80=9D would be good for HMAC. It=E2=80=99s also ok= for the information model to be stricter than the babel-hmac implementatio= n.

=C2=A0

Blake2s does specifically allow zero-length keys =E2= =80=93 though I don=E2=80=99t know how advisable that is in a Babel usage s= cenario. I don=E2=80=99t know when key length of 0 is useful. But there is = definitely nothing that prevents us from being stricter, if we wanted to insist on a key longer than 0. Again, this strictness can be = in info-model only and doesn=E2=80=99t have to be reflected in babel-hmac.<= u>

=C2=A0

I do need some maximum size on the parameter (indepe= ndent of key algorithm) =E2=80=93 so it won=E2=80=99t be unlimited length, = anyway. I=E2=80=99m thinking 128 bytes as an absolute upper limit at this t= ime.

Barbara

=C2=A0

According to RFC 7693, Blake2s keys must be of lengt= h kk where=C2=A00 <=3D kk <=3D 32. So having the info model dictate t= hat keys MUST follow that is perfectly reasonable to me.

=C2=A0

However, according to RFC 6234, HMAC-SHA-256 allows = all key lengths kk where 0 <=3D kk. I don't think the information mo= del should express an opinion as to whether keys longer than 64 bytes are s= afe or not. If we choose to add that distinction we'll need to justify why we think the key hashing is unsafe, and I do= n't think there is an RFC we can cite for that.

=C2=A0

So going back to Juliusz's listed options in the= other thread <https://mailarchiv= e.ietf.org/arch/msg/babel/QlvsPB9yYFPTPwQxaLcWIN3Hl2Y>, I would argue for option 3 "bureaucratic" because it follows the= design principle "The Babel WG does not make security decisions, we f= ollow what RFCs tell us".

=C2=A0

David

=C2=A0

On Thu, Aug 15, 2019 at 9:58 AM STARK, BARBARA H <= ;bs7652@att.com>= wrote:

> > Is this suggesting that it's ok for in= fo-model to provide babel-hmac
> > with any value between 0 and 64 bytes in length for HMAC-SHA256 o= r
> > between 0 and 32 bytes in length for Blake2s and babel-hmac can b= e
> > expected to zero-pad? Or are you still expecting info-model to do= the
> > zero-padding before providing to babel-hmac?
>
> The former.=C2=A0 You give me anything between 0 and 32/64, and I deal= with it.

Cool. Then from a purely info-model perspective, it sounds like the key-val= ue parameter length constraints are:

=C2=A0 This value is of a length suitable for the associated
=C2=A0 babel-mac-key-algorithm.=C2=A0 If the algorithm is based on the HMAC=
=C2=A0 construction, the length MUST be between 0 and the block size of the=
=C2=A0 underlying hash inclusive (where "HMAC-SHA256" block size = is 64 bytes
=C2=A0 as described in {{RFC4868}}).
=C2=A0 If the algorithm is "BLAKE2s", the length MUST be between = 0 and 32 bytes
=C2=A0 inclusive, as described in {{RFC7693}}.

Anything complying with info-model won't supply anything longer than th= e identified max length.
A babel-hmac implementation may get something as short as zero length, but = will be expected to deal with it. Info-model doesn't care and doesn'= ;t need to know what "deal with it" means.
For HMAC and Blake2s algorithms, "deal with it" means hmac-babel = will zero-pad shorter strings, because that's what the algorithm RFCs s= ay to do (and not because babel-hmac has any extra requirements going beyon= d the algorithm specs).
Info-model won't send strings longer than the indicated length. If ther= e is a UI to info model that accepts a longer string, hashes it, and then i= nfo-model provides the hashed value, that is what it is. Neither info-model= nor babel-hmac care or know or need to know about this.
If a babel-hmac implementation does have special handling for longer string= s, that's fine, too. But a value coming from info-model will never trig= ger this special code.
Does that sound right?
Barbara

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

--00000000000049657805902fc920-- From nobody Thu Aug 15 16:40:17 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 672721200F3 for ; Thu, 15 Aug 2019 16:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 PCQfLtEopmM9 for ; Thu, 15 Aug 2019 16:40:11 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29351200E9 for ; Thu, 15 Aug 2019 16:40:07 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7FNbTvW008333; Thu, 15 Aug 2019 19:40:06 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2udfpvt1qx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Aug 2019 19:40:05 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7FNe4dN028514; Thu, 15 Aug 2019 19:40:04 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7FNe0px028431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 15 Aug 2019 19:40:00 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 10A8E4005C35; Thu, 15 Aug 2019 23:40:00 +0000 (GMT) Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30485.vci.att.com (Service) with ESMTPS id E8D1C4005C34; Thu, 15 Aug 2019 23:39:59 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.177]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0439.000; Thu, 15 Aug 2019 19:39:59 -0400 From: "STARK, BARBARA H" To: "'David Schinazi'" CC: "'babel@ietf.org'" , "'Juliusz Chroboczek'" Thread-Topic: [babel] info-model: preparing -09 on github Thread-Index: AdVSswKr0W4Y1vOsQfS00DtIY7BoYgAM83CAAAdXLCD//+jbAP//C3uggAKFBgCAAC70cIAAC7qAgABBMvA= Date: Thu, 15 Aug 2019 23:39:59 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E277CFA@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> <87ftm3u0a6.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269981@GAALPA1MSGUSRBF.ITServices.sbc.com> <87blwrtudx.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E275E65@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E27796E@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.196.183] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114E277CFAGAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-15_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908150226 Archived-At: Subject: Re: [babel] info-model: preparing -09 on github 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: Thu, 15 Aug 2019 23:40:15 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114E277CFAGAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgUkZDMjEwNCBzYXlzOiDigJxLZXlzIGxvbmdlciB0aGFuIEwgYnl0ZXMgYXJlIGFjY2VwdGFi bGUgYnV0IHRoZSBleHRyYSBsZW5ndGggd291bGQgbm90IHNpZ25pZmljYW50bHkgaW5jcmVhc2Ug dGhlIGZ1bmN0aW9uIHN0cmVuZ3RoLuKAnSBTaW5jZSA2NCA9IDIqTCBmb3IgU0hBLTI1NiwgYSBr ZXkgbG9uZ2VyIHRoYW4gNjQgaXMgZXZlbiBsZXNzIGxpa2VseSB0byBpbmNyZWFzZSB0aGUgZnVu Y3Rpb24gc3RyZW5ndGguIFNvIGtleSBsZW5ndGggPiA2NCBwcm92aWRlcyBubyBhZGRlZCB2YWx1 ZS4gQnV0IGl0IGRvZXMgaW5jcmVhc2UgY29tcGxleGl0eSBmb3IgY3JlYXRpbmcgdGhlIOKAnHJl YWzigJ0ga2V5LiBJbmNyZWFzZWQgY29tcGxleGl0eSBtZWFucyBtb3JlIHRoaW5ncyBjYW4gZ28g d3JvbmcuDQoNCkkgZG9u4oCZdCB0aGluayB3ZSBzaG91bGQgYWxsb3cgYSAxLWJ5dGUga2V5LiBN eSByZWNvbW1lbmRhdGlvbiBmb3IgU0hBLTI1NiB3YXMgTVVTVCBiZSA+IDguIEkgZm91bmQgdGhp cyBzaXRlOiBodHRwczovL3d3dy5rZXlsZW5ndGguY29tL2VuLzQvIHdoaWNoIHNheXMgTklTVCBy ZWNvbW1lbmRzIG1pbmltdW0gb2YgMTYgYnl0ZXMgZm9yIFNIQS0yNTYga2V5cy4gSeKAmW0gZ29v ZCB3aXRoIHJlcXVpcmluZyB0aGF0LCB0b28uIEl0IHdvdWxkIGNlcnRhaW5seSBtYWtlIHVzIGN1 cnJlbnQgb24gYmVzdCBwcmFjdGljZSBzZWN1cml0eSByZWNvbW1lbmRhdGlvbnMuIFRoZXJl4oCZ cyBzb21ldGhpbmcgdG8gYmUgc2FpZCBmb3IgZm9sbG93aW5nIGJlc3QgcHJhY3RpY2VzLg0KDQpJ IGhhdmUgbm8gaWRlYSB3aGF0IHRvIGRvIGZvciBCbGFrZTJzLiBJIGNhbuKAmXQgZmluZCBhIG1p bmltdW0ga2V5IGxlbmd0aCByZWNvbW1lbmRhdGlvbi4gQnV0IHplcm8tbGVuZ3RoICh1bmtleWVk KSB1c2FnZSBwcm92aWRlcyBubyBtZWFuaW5nZnVsIHNlY3VyaXR5IGluIHRoZSBCYWJlbCB1c2Ug Y2FzZS4gWmVyby1sZW5ndGggaXMgcHJvYmFibHkgdGhlIGZpcnN0IHRoaW5nIGFuIGF0dGFja2Vy IHdvdWxkIHRyeS4gQW5kIHRoZXnigJlkIGJlIGltbWVkaWF0ZWx5IHJpZ2h0LiBUaGF0IGhhcmRs eSBjb3VudHMgYXMgYSBicnV0ZSBmb3JjZSBhdHRhY2suIFNvIEnigJltIG5vdCBjb21mb3J0YWJs ZSB3aXRoIGFsbG93aW5nIHplcm8tbGVuZ3RoIGluIGluZm8tbW9kZWwuDQoNCkFuZCBqdXN0IHRv IGJlIGNsZWFyLCBJ4oCZbSBub3Qgc3VnZ2VzdGluZyBhbnkgb2YgdGhlc2UgcmVzdHJpY3Rpb25z IGdvIGluIGJhYmVsLWhtYWMuIEp1c3QgaW5mby1tb2RlbC4NCkJhcmJhcmENCg0KRnJvbTogRGF2 aWQgU2NoaW5hemkgPGRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbT4NClNlbnQ6IFRodXJzZGF5LCBB dWd1c3QgMTUsIDIwMTkgNjo1NiBQTQ0KVG86IFNUQVJLLCBCQVJCQVJBIEggPGJzNzY1MkBhdHQu Y29tPg0KQ2M6IGJhYmVsQGlldGYub3JnOyBKdWxpdXN6IENocm9ib2N6ZWsgPGpjaEBpcmlmLmZy Pg0KU3ViamVjdDogUmU6IFtiYWJlbF0gaW5mby1tb2RlbDogcHJlcGFyaW5nIC0wOSBvbiBnaXRo dWINCg0KSWYgd2UncmUgY29uc2lkZXJpbmcgYWRkaW5nIHJlc3RyaWN0aW9ucyBzcGVjaWZpYyB0 byBCYWJlbCAoYW5kL29yIHRoZSBpbmZvIG1vZGVsKSwgSSB0aGluayB3ZSBzaG91bGQgdGFrZSBh IHByaW5jaXBsZWQgYXBwcm9hY2guIFdoYXQgZnVuZGFtZW50YWwgcHJpbmNpcGxlcyBhcmUgd2Ug dXNpbmcgdG8gZGVjaWRlIHRoZXNlIHJlc3RyaWN0aW9ucz8gSWYgd2UgYWxsb3cgYSAxLWJ5dGUg a2V5IGJ1dCBkaXNhbGxvdyBhIDY1LWJ5dGUga2V5LCB0aGVuIHRoZSBwcmluY2lwbGUgd2UncmUg YWZ0ZXIgaXMgbm90IGltcHJvdmluZyBzZWN1cml0eT8NCg0KT24gVGh1LCBBdWcgMTUsIDIwMTkg YXQgMjo0NiBQTSBTVEFSSywgQkFSQkFSQSBIIDxiczc2NTJAYXR0LmNvbTxtYWlsdG86YnM3NjUy QGF0dC5jb20+PiB3cm90ZToNCkkgZGlzYWdyZWUuDQoNClRoZSBITUFDIHNwZWNzIChSRkMyMTA0 KSBzYXlzOg0KICAgQXBwbGljYXRpb25zIHRoYXQgdXNlIGtleXMgbG9uZ2VyDQogICB0aGFuIEIg W2Jsb2NrIHNpemVdIGJ5dGVzIHdpbGwgZmlyc3QgaGFzaCB0aGUga2V5IHVzaW5nIEggYW5kIHRo ZW4gdXNlIHRoZQ0KICAgcmVzdWx0YW50IEwgW2hhc2ggb3V0cHV0IHNpemVdIGJ5dGUgc3RyaW5n IGFzIHRoZSBhY3R1YWwga2V5IHRvIEhNQUMuIEluIGFueSBjYXNlIHRoZQ0KICAgbWluaW1hbCBy ZWNvbW1lbmRlZCBsZW5ndGggZm9yIEsgaXMgTCBieXRlcyAoYXMgdGhlIGhhc2ggb3V0cHV0DQog ICBsZW5ndGgpLiBTZWUgc2VjdGlvbiAzIGZvciBtb3JlIGluZm9ybWF0aW9uIG9uIGtleXMuDQph bmQgZnJvbSBzZWN0aW9uIDMNCg0KICAgVGhlIGtleSBmb3IgSE1BQyBjYW4gYmUgb2YgYW55IGxl bmd0aCAoa2V5cyBsb25nZXIgdGhhbiBCIGJ5dGVzIGFyZQ0KDQogICBmaXJzdCBoYXNoZWQgdXNp bmcgSCkuICBIb3dldmVyLCBsZXNzIHRoYW4gTCBieXRlcyBpcyBzdHJvbmdseQ0KDQogICBkaXNj b3VyYWdlZCBhcyBpdCB3b3VsZCBkZWNyZWFzZSB0aGUgc2VjdXJpdHkgc3RyZW5ndGggb2YgdGhl DQoNCiAgIGZ1bmN0aW9uLiAgS2V5cyBsb25nZXIgdGhhbiBMIGJ5dGVzIGFyZSBhY2NlcHRhYmxl IGJ1dCB0aGUgZXh0cmENCg0KICAgbGVuZ3RoIHdvdWxkIG5vdCBzaWduaWZpY2FudGx5IGluY3Jl YXNlIHRoZSBmdW5jdGlvbiBzdHJlbmd0aC4gKEENCg0KICAgbG9uZ2VyIGtleSBtYXkgYmUgYWR2 aXNhYmxlIGlmIHRoZSByYW5kb21uZXNzIG9mIHRoZSBrZXkgaXMNCg0KICAgY29uc2lkZXJlZCB3 ZWFrLikNCg0KSW4gdGhpcyBsYW5ndWFnZSwgdGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgZm9yIGFw cGxpY2F0aW9ucyB1c2luZyBITUFDIHRvIGFjY2VwdCAob3IgYmUgYWJsZSB0byB1c2UpIGtleXMg bG9uZ2VyIHRoYW4gQiBieXRlcy4gVGhlIHR3byBzdGF0ZW1lbnRzIGRvIHNheSB3aGF0IG11c3Qg aGFwcGVuICppZiogYSBrZXkgbG9uZ2VyIHRoYW4gQiBieXRlcyBpcyBwcm92aWRlZC4gQnV0IGlm IEJhYmVsIHdhbnRzIHRvIHJlc3RyaWN0IGtleXMgdG8gbm8gbW9yZSB0aGFuIEIgYnl0ZXMsIHRo YXQgaXMgd2VsbCB3aXRoaW4gQmFiZWzigJlzIHB1cnZpZXcgdG8gZG8gc28uIFJGQzIxMDYgdmVy eSBjbGVhcmx5IHRlbGxzIGFwcGxpY2F0aW9ucyBnZXQgdG8gZGVjaWRlIHdoYXQgdG8gdXNlLg0K DQpUaGUgb3RoZXIgdGhpbmcgSSBnZXQgZnJvbSB0aGlzLCB0aG91Z2gsIGlzIHRoYXQgaXTigJlz IHJlY29tbWVuZGVkIHRvIGhhdmUgYXQgbGVhc3QgTCBieXRlcyBmb3IgYW4gSE1BQyBrZXkgKEwg PSAzMiBmb3IgU0hBLTI1NikuIEkgdGhpbmsgd2Ugc2hvdWxkIHJlZmxlY3QgdGhpcyByZWNvbW1l bmRhdGlvbi4gV2UgY291bGQgZG8gaXQgZWl0aGVyIHdpdGggYSDigJxTSE9VTETigJ0gb3Ig4oCc TVVTVOKAnSBiZSBhdCBsZWFzdCB0aGUgb3V0cHV0IGhhc2ggbGVuZ3RoIChub3Qgc2V0IHRoZSBt aW5pbXVtIGF0IDApLiBJIHNlZSBubyByZWFzb24gbm90IHRvIHVwZ3JhZGUgdGhhdCB0byBhIE1V U1QgZm9yIEJhYmVsLCBpZiB3ZSB3YW50LiBbSXTigJlzIGFsd2F5cyBvayB0byBiZSBzdHJpY3Rl ciB0aGFuIGEgcmVmZXJlbmNlZCBzcGVjIChlLmcuLCBjaGFuZ2UgU0hPVUxEIHRvIE1VU1QpIOKA kyBpdOKAmXMganVzdCBub3Qgb2sgdG8gZG8gb3IgYWxsb3cgc29tZXRoaW5nIHRoYXQgdmlvbGF0 ZXMgYSByZXF1aXJlbWVudCBmcm9tIHRoZSBzcGVjIChlLmcuLCBjaGFuZ2UgTVVTVCB0byBTSE9V TEQpLl0gSSB0aGluayBhdCBsZWFzdCBhIE1VU1QgYmUgYXQgbGVhc3QgOCBieXRlc+KAnSB3aXRo IGEg4oCcU0hPVUxEIGJlIGF0IGxlYXN0IHRoZSBvdXRwdXQgaGFzaCBsZW5ndGjigJ0gd291bGQg YmUgZ29vZCBmb3IgSE1BQy4gSXTigJlzIGFsc28gb2sgZm9yIHRoZSBpbmZvcm1hdGlvbiBtb2Rl bCB0byBiZSBzdHJpY3RlciB0aGFuIHRoZSBiYWJlbC1obWFjIGltcGxlbWVudGF0aW9uLg0KDQpC bGFrZTJzIGRvZXMgc3BlY2lmaWNhbGx5IGFsbG93IHplcm8tbGVuZ3RoIGtleXMg4oCTIHRob3Vn aCBJIGRvbuKAmXQga25vdyBob3cgYWR2aXNhYmxlIHRoYXQgaXMgaW4gYSBCYWJlbCB1c2FnZSBz Y2VuYXJpby4gSSBkb27igJl0IGtub3cgd2hlbiBrZXkgbGVuZ3RoIG9mIDAgaXMgdXNlZnVsLiBC dXQgdGhlcmUgaXMgZGVmaW5pdGVseSBub3RoaW5nIHRoYXQgcHJldmVudHMgdXMgZnJvbSBiZWlu ZyBzdHJpY3RlciwgaWYgd2Ugd2FudGVkIHRvIGluc2lzdCBvbiBhIGtleSBsb25nZXIgdGhhbiAw LiBBZ2FpbiwgdGhpcyBzdHJpY3RuZXNzIGNhbiBiZSBpbiBpbmZvLW1vZGVsIG9ubHkgYW5kIGRv ZXNu4oCZdCBoYXZlIHRvIGJlIHJlZmxlY3RlZCBpbiBiYWJlbC1obWFjLg0KDQpJIGRvIG5lZWQg c29tZSBtYXhpbXVtIHNpemUgb24gdGhlIHBhcmFtZXRlciAoaW5kZXBlbmRlbnQgb2Yga2V5IGFs Z29yaXRobSkg4oCTIHNvIGl0IHdvbuKAmXQgYmUgdW5saW1pdGVkIGxlbmd0aCwgYW55d2F5LiBJ 4oCZbSB0aGlua2luZyAxMjggYnl0ZXMgYXMgYW4gYWJzb2x1dGUgdXBwZXIgbGltaXQgYXQgdGhp cyB0aW1lLg0KQmFyYmFyYQ0KDQpBY2NvcmRpbmcgdG8gUkZDIDc2OTMsIEJsYWtlMnMga2V5cyBt dXN0IGJlIG9mIGxlbmd0aCBrayB3aGVyZSAwIDw9IGtrIDw9IDMyLiBTbyBoYXZpbmcgdGhlIGlu Zm8gbW9kZWwgZGljdGF0ZSB0aGF0IGtleXMgTVVTVCBmb2xsb3cgdGhhdCBpcyBwZXJmZWN0bHkg cmVhc29uYWJsZSB0byBtZS4NCg0KSG93ZXZlciwgYWNjb3JkaW5nIHRvIFJGQyA2MjM0LCBITUFD LVNIQS0yNTYgYWxsb3dzIGFsbCBrZXkgbGVuZ3RocyBrayB3aGVyZSAwIDw9IGtrLiBJIGRvbid0 IHRoaW5rIHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBzaG91bGQgZXhwcmVzcyBhbiBvcGluaW9uIGFz IHRvIHdoZXRoZXIga2V5cyBsb25nZXIgdGhhbiA2NCBieXRlcyBhcmUgc2FmZSBvciBub3QuIElm IHdlIGNob29zZSB0byBhZGQgdGhhdCBkaXN0aW5jdGlvbiB3ZSdsbCBuZWVkIHRvIGp1c3RpZnkg d2h5IHdlIHRoaW5rIHRoZSBrZXkgaGFzaGluZyBpcyB1bnNhZmUsIGFuZCBJIGRvbid0IHRoaW5r IHRoZXJlIGlzIGFuIFJGQyB3ZSBjYW4gY2l0ZSBmb3IgdGhhdC4NCg0KU28gZ29pbmcgYmFjayB0 byBKdWxpdXN6J3MgbGlzdGVkIG9wdGlvbnMgaW4gdGhlIG90aGVyIHRocmVhZCA8aHR0cHM6Ly9t YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9iYWJlbC9RbHZzUEI5eVlGUFRQd1F4YUxjV0lO M0hsMlk8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X19tYWlsYXJjaGl2ZS5pZXRmLm9yZ19hcmNoX21zZ19iYWJlbF9RbHZzUEI5eVlGUFRQd1F4YUxj V0lOM0hsMlkmZD1Ed01GYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9TG9HemhDLThzYzhT WThUcTR2cmZvZyZtPXI0ZEtXMEhOU3JqTlBYZFhJZEpfM2tHYzNYclJJeGRCYWM2MER1YTlGOVEm cz1oY3dpNVFEd0c3d3E5NmNFNXZVYko2TFlKMG1ObjZwMGlHc3RQb3Nrek84JmU9Pj4sIEkgd291 bGQgYXJndWUgZm9yIG9wdGlvbiAzICJidXJlYXVjcmF0aWMiIGJlY2F1c2UgaXQgZm9sbG93cyB0 aGUgZGVzaWduIHByaW5jaXBsZSAiVGhlIEJhYmVsIFdHIGRvZXMgbm90IG1ha2Ugc2VjdXJpdHkg ZGVjaXNpb25zLCB3ZSBmb2xsb3cgd2hhdCBSRkNzIHRlbGwgdXMiLg0KDQpEYXZpZA0KDQpPbiBU aHUsIEF1ZyAxNSwgMjAxOSBhdCA5OjU4IEFNIFNUQVJLLCBCQVJCQVJBIEggPGJzNzY1MkBhdHQu Y29tPG1haWx0bzpiczc2NTJAYXR0LmNvbT4+IHdyb3RlOg0KPiA+IElzIHRoaXMgc3VnZ2VzdGlu ZyB0aGF0IGl0J3Mgb2sgZm9yIGluZm8tbW9kZWwgdG8gcHJvdmlkZSBiYWJlbC1obWFjDQo+ID4g d2l0aCBhbnkgdmFsdWUgYmV0d2VlbiAwIGFuZCA2NCBieXRlcyBpbiBsZW5ndGggZm9yIEhNQUMt U0hBMjU2IG9yDQo+ID4gYmV0d2VlbiAwIGFuZCAzMiBieXRlcyBpbiBsZW5ndGggZm9yIEJsYWtl MnMgYW5kIGJhYmVsLWhtYWMgY2FuIGJlDQo+ID4gZXhwZWN0ZWQgdG8gemVyby1wYWQ/IE9yIGFy ZSB5b3Ugc3RpbGwgZXhwZWN0aW5nIGluZm8tbW9kZWwgdG8gZG8gdGhlDQo+ID4gemVyby1wYWRk aW5nIGJlZm9yZSBwcm92aWRpbmcgdG8gYmFiZWwtaG1hYz8NCj4NCj4gVGhlIGZvcm1lci4gIFlv dSBnaXZlIG1lIGFueXRoaW5nIGJldHdlZW4gMCBhbmQgMzIvNjQsIGFuZCBJIGRlYWwgd2l0aCBp dC4NCg0KQ29vbC4gVGhlbiBmcm9tIGEgcHVyZWx5IGluZm8tbW9kZWwgcGVyc3BlY3RpdmUsIGl0 IHNvdW5kcyBsaWtlIHRoZSBrZXktdmFsdWUgcGFyYW1ldGVyIGxlbmd0aCBjb25zdHJhaW50cyBh cmU6DQoNCiAgVGhpcyB2YWx1ZSBpcyBvZiBhIGxlbmd0aCBzdWl0YWJsZSBmb3IgdGhlIGFzc29j aWF0ZWQNCiAgYmFiZWwtbWFjLWtleS1hbGdvcml0aG0uICBJZiB0aGUgYWxnb3JpdGhtIGlzIGJh c2VkIG9uIHRoZSBITUFDDQogIGNvbnN0cnVjdGlvbiwgdGhlIGxlbmd0aCBNVVNUIGJlIGJldHdl ZW4gMCBhbmQgdGhlIGJsb2NrIHNpemUgb2YgdGhlDQogIHVuZGVybHlpbmcgaGFzaCBpbmNsdXNp dmUgKHdoZXJlICJITUFDLVNIQTI1NiIgYmxvY2sgc2l6ZSBpcyA2NCBieXRlcw0KICBhcyBkZXNj cmliZWQgaW4ge3tSRkM0ODY4fX0pLg0KICBJZiB0aGUgYWxnb3JpdGhtIGlzICJCTEFLRTJzIiwg dGhlIGxlbmd0aCBNVVNUIGJlIGJldHdlZW4gMCBhbmQgMzIgYnl0ZXMNCiAgaW5jbHVzaXZlLCBh cyBkZXNjcmliZWQgaW4ge3tSRkM3NjkzfX0uDQoNCkFueXRoaW5nIGNvbXBseWluZyB3aXRoIGlu Zm8tbW9kZWwgd29uJ3Qgc3VwcGx5IGFueXRoaW5nIGxvbmdlciB0aGFuIHRoZSBpZGVudGlmaWVk IG1heCBsZW5ndGguDQpBIGJhYmVsLWhtYWMgaW1wbGVtZW50YXRpb24gbWF5IGdldCBzb21ldGhp bmcgYXMgc2hvcnQgYXMgemVybyBsZW5ndGgsIGJ1dCB3aWxsIGJlIGV4cGVjdGVkIHRvIGRlYWwg d2l0aCBpdC4gSW5mby1tb2RlbCBkb2Vzbid0IGNhcmUgYW5kIGRvZXNuJ3QgbmVlZCB0byBrbm93 IHdoYXQgImRlYWwgd2l0aCBpdCIgbWVhbnMuDQpGb3IgSE1BQyBhbmQgQmxha2UycyBhbGdvcml0 aG1zLCAiZGVhbCB3aXRoIGl0IiBtZWFucyBobWFjLWJhYmVsIHdpbGwgemVyby1wYWQgc2hvcnRl ciBzdHJpbmdzLCBiZWNhdXNlIHRoYXQncyB3aGF0IHRoZSBhbGdvcml0aG0gUkZDcyBzYXkgdG8g ZG8gKGFuZCBub3QgYmVjYXVzZSBiYWJlbC1obWFjIGhhcyBhbnkgZXh0cmEgcmVxdWlyZW1lbnRz IGdvaW5nIGJleW9uZCB0aGUgYWxnb3JpdGhtIHNwZWNzKS4NCkluZm8tbW9kZWwgd29uJ3Qgc2Vu ZCBzdHJpbmdzIGxvbmdlciB0aGFuIHRoZSBpbmRpY2F0ZWQgbGVuZ3RoLiBJZiB0aGVyZSBpcyBh IFVJIHRvIGluZm8gbW9kZWwgdGhhdCBhY2NlcHRzIGEgbG9uZ2VyIHN0cmluZywgaGFzaGVzIGl0 LCBhbmQgdGhlbiBpbmZvLW1vZGVsIHByb3ZpZGVzIHRoZSBoYXNoZWQgdmFsdWUsIHRoYXQgaXMg d2hhdCBpdCBpcy4gTmVpdGhlciBpbmZvLW1vZGVsIG5vciBiYWJlbC1obWFjIGNhcmUgb3Iga25v dyBvciBuZWVkIHRvIGtub3cgYWJvdXQgdGhpcy4NCklmIGEgYmFiZWwtaG1hYyBpbXBsZW1lbnRh dGlvbiBkb2VzIGhhdmUgc3BlY2lhbCBoYW5kbGluZyBmb3IgbG9uZ2VyIHN0cmluZ3MsIHRoYXQn cyBmaW5lLCB0b28uIEJ1dCBhIHZhbHVlIGNvbWluZyBmcm9tIGluZm8tbW9kZWwgd2lsbCBuZXZl ciB0cmlnZ2VyIHRoaXMgc3BlY2lhbCBjb2RlLg0KRG9lcyB0aGF0IHNvdW5kIHJpZ2h0Pw0KQmFy YmFyYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K YmFiZWwgbWFpbGluZyBsaXN0DQpiYWJlbEBpZXRmLm9yZzxtYWlsdG86YmFiZWxAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JhYmVsPGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21h aWxtYW5fbGlzdGluZm9fYmFiZWwmZD1Ed01GYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9 TG9HemhDLThzYzhTWThUcTR2cmZvZyZtPXI0ZEtXMEhOU3JqTlBYZFhJZEpfM2tHYzNYclJJeGRC YWM2MER1YTlGOVEmcz01aFVOajYtVmR6S19OcWNQX2pPT29SSnVRX1czODh2NVlUNlpsMlJxeERn JmU9Pg0K --_000_2D09D61DDFA73D4C884805CC7865E6114E277CFAGAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBSRkMy MTA0IHNheXM6IOKAnEtleXMgbG9uZ2VyIHRoYW4gTCBieXRlcyBhcmUgYWNjZXB0YWJsZSBidXQg dGhlIGV4dHJhIGxlbmd0aCB3b3VsZCBub3Qgc2lnbmlmaWNhbnRseSBpbmNyZWFzZSB0aGUgZnVu Y3Rpb24gc3RyZW5ndGgu4oCdIFNpbmNlIDY0ID0gMipMIGZvciBTSEEtMjU2LCBhIGtleSBsb25n ZXIgdGhhbiA2NCBpcyBldmVuIGxlc3MgbGlrZWx5IHRvIGluY3JlYXNlIHRoZSBmdW5jdGlvbiBz dHJlbmd0aC4NCiBTbyBrZXkgbGVuZ3RoICZndDsgNjQgcHJvdmlkZXMgbm8gYWRkZWQgdmFsdWUu IEJ1dCBpdCBkb2VzIGluY3JlYXNlIGNvbXBsZXhpdHkgZm9yIGNyZWF0aW5nIHRoZSDigJxyZWFs 4oCdIGtleS4gSW5jcmVhc2VkIGNvbXBsZXhpdHkgbWVhbnMgbW9yZSB0aGluZ3MgY2FuIGdvIHdy b25nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbuKAmXQgdGhpbmsgd2Ugc2hvdWxkIGFs bG93IGEgMS1ieXRlIGtleS4gTXkgcmVjb21tZW5kYXRpb24gZm9yIFNIQS0yNTYgd2FzIE1VU1Qg YmUgJmd0OyA4LiBJIGZvdW5kIHRoaXMgc2l0ZToNCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmtleWxl bmd0aC5jb20vZW4vNC8iPmh0dHBzOi8vd3d3LmtleWxlbmd0aC5jb20vZW4vNC88L2E+IHdoaWNo IHNheXMgTklTVCByZWNvbW1lbmRzIG1pbmltdW0gb2YgMTYgYnl0ZXMgZm9yIFNIQS0yNTYga2V5 cy4gSeKAmW0gZ29vZCB3aXRoIHJlcXVpcmluZyB0aGF0LCB0b28uIEl0IHdvdWxkIGNlcnRhaW5s eSBtYWtlIHVzIGN1cnJlbnQgb24gYmVzdCBwcmFjdGljZSBzZWN1cml0eSByZWNvbW1lbmRhdGlv bnMuIFRoZXJl4oCZcw0KIHNvbWV0aGluZyB0byBiZSBzYWlkIGZvciBmb2xsb3dpbmcgYmVzdCBw cmFjdGljZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBubyBpZGVhIHdoYXQgdG8g ZG8gZm9yIEJsYWtlMnMuIEkgY2Fu4oCZdCBmaW5kIGEgbWluaW11bSBrZXkgbGVuZ3RoIHJlY29t bWVuZGF0aW9uLiBCdXQgemVyby1sZW5ndGggKHVua2V5ZWQpIHVzYWdlIHByb3ZpZGVzIG5vIG1l YW5pbmdmdWwgc2VjdXJpdHkgaW4gdGhlIEJhYmVsIHVzZSBjYXNlLiBaZXJvLWxlbmd0aCBpcyBw cm9iYWJseSB0aGUgZmlyc3QgdGhpbmcgYW4gYXR0YWNrZXIgd291bGQgdHJ5Lg0KIEFuZCB0aGV5 4oCZZCBiZSBpbW1lZGlhdGVseSByaWdodC4gVGhhdCBoYXJkbHkgY291bnRzIGFzIGEgYnJ1dGUg Zm9yY2UgYXR0YWNrLiBTbyBJ4oCZbSBub3QgY29tZm9ydGFibGUgd2l0aCBhbGxvd2luZyB6ZXJv LWxlbmd0aCBpbiBpbmZvLW1vZGVsLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBqdXN0 IHRvIGJlIGNsZWFyLCBJ4oCZbSBub3Qgc3VnZ2VzdGluZyBhbnkgb2YgdGhlc2UgcmVzdHJpY3Rp b25zIGdvIGluIGJhYmVsLWhtYWMuIEp1c3QgaW5mby1tb2RlbC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkJhcmJhcmE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5G cm9tOjwvYj4gRGF2aWQgU2NoaW5hemkgJmx0O2RzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbSZndDsg PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBdWd1c3QgMTUsIDIwMTkgNjo1NiBQTTxicj4N CjxiPlRvOjwvYj4gU1RBUkssIEJBUkJBUkEgSCAmbHQ7YnM3NjUyQGF0dC5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBiYWJlbEBpZXRmLm9yZzsgSnVsaXVzeiBDaHJvYm9jemVrICZsdDtqY2hAaXJp Zi5mciZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtiYWJlbF0gaW5mby1tb2RlbDogcHJl cGFyaW5nIC0wOSBvbiBnaXRodWI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JZiB3ZSdyZSBjb25zaWRlcmluZyBhZGRpbmcgcmVzdHJpY3Rpb25zIHNwZWNp ZmljIHRvIEJhYmVsIChhbmQvb3IgdGhlIGluZm8gbW9kZWwpLCBJIHRoaW5rIHdlIHNob3VsZCB0 YWtlIGEgcHJpbmNpcGxlZCBhcHByb2FjaC4gV2hhdCBmdW5kYW1lbnRhbCBwcmluY2lwbGVzIGFy ZSB3ZSB1c2luZyB0byBkZWNpZGUgdGhlc2UgcmVzdHJpY3Rpb25zPyBJZiB3ZSBhbGxvdyBhIDEt Ynl0ZSBrZXkgYnV0IGRpc2FsbG93DQogYSA2NS1ieXRlIGtleSwgdGhlbiB0aGUgcHJpbmNpcGxl IHdlJ3JlIGFmdGVyIGlzIG5vdCBpbXByb3Zpbmcgc2VjdXJpdHk/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEF1ZyAxNSwgMjAxOSBhdCAyOjQ2 IFBNIFNUQVJLLCBCQVJCQVJBIEggJmx0OzxhIGhyZWY9Im1haWx0bzpiczc2NTJAYXR0LmNvbSI+ YnM3NjUyQGF0dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGRpc2FncmVl Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgSE1BQyBzcGVjcyAoUkZDMjEwNCkg c2F5czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyBBcHBsaWNhdGlvbnMgdGhhdCB1c2Uga2V5cyBsb25nZXI8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg dGhhbiBCDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+W2Jsb2NrIHNpemVdPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4gYnl0ZXMgd2lsbCBmaXJzdCBoYXNoIHRoZSBrZXkgdXNpbmcgSCBhbmQgdGhlbiB1c2UgdGhl PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IHJlc3VsdGFudCBMDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+W2hhc2ggb3V0 cHV0IHNpemVdDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmJ5dGUgc3RyaW5nIGFzIHRoZSBhY3R1YWwga2V5 IHRvIEhNQUMuIEluIGFueSBjYXNlIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBtaW5pbWFsIHJlY29tbWVuZGVk IGxlbmd0aCBmb3IgSyBpcyBMIGJ5dGVzIChhcyB0aGUgaGFzaCBvdXRwdXQ8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg bGVuZ3RoKS4gU2VlIHNlY3Rpb24gMyBmb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBrZXlzLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+YW5kIGZyb20gc2VjdGlv biAzDQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIGtleSBmb3Ig SE1BQyBjYW4gYmUgb2YgYW55IGxlbmd0aCAoa2V5cyBsb25nZXIgdGhhbiBCIGJ5dGVzIGFyZTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBmaXJzdCBoYXNoZWQgdXNpbmcgSCku Jm5ic3A7IEhvd2V2ZXIsIGxlc3MgdGhhbiBMIGJ5dGVzIGlzIHN0cm9uZ2x5PG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGRpc2NvdXJhZ2VkIGFzIGl0IHdvdWxkIGRlY3JlYXNl IHRoZSBzZWN1cml0eSBzdHJlbmd0aCBvZiB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsgZnVuY3Rpb24uJm5ic3A7IEtleXMgbG9uZ2VyIHRoYW4gTCBieXRlcyBhcmUgYWNj ZXB0YWJsZSBidXQgdGhlIGV4dHJhPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IGxlbmd0aCB3b3VsZCBub3Qgc2lnbmlmaWNhbnRseSBpbmNyZWFzZSB0aGUgZnVuY3Rpb24gc3Ry ZW5ndGguIChBPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGxvbmdlciBrZXkg bWF5IGJlIGFkdmlzYWJsZSBpZiB0aGUgcmFuZG9tbmVzcyBvZiB0aGUga2V5IGlzPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGNvbnNpZGVyZWQgd2Vhay4pPG86cD48L286cD48 L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkluIHRoaXMgbGFuZ3VhZ2UsIHRoZXJlIGlzIG5vIHJlcXVpcmVt ZW50IGZvciBhcHBsaWNhdGlvbnMgdXNpbmcgSE1BQyB0byBhY2NlcHQgKG9yIGJlIGFibGUgdG8g dXNlKSBrZXlzIGxvbmdlciB0aGFuIEIgYnl0ZXMuIFRoZSB0d28gc3RhdGVtZW50cyBkbyBzYXkg d2hhdCBtdXN0IGhhcHBlbiAqPGI+aWY8L2I+Kg0KIGEga2V5IGxvbmdlciB0aGFuIEIgYnl0ZXMg aXMgcHJvdmlkZWQuIEJ1dCBpZiBCYWJlbCB3YW50cyB0byByZXN0cmljdCBrZXlzIHRvIG5vIG1v cmUgdGhhbiBCIGJ5dGVzLCB0aGF0IGlzIHdlbGwgd2l0aGluIEJhYmVs4oCZcyBwdXJ2aWV3IHRv IGRvIHNvLiBSRkMyMTA2IHZlcnkgY2xlYXJseSB0ZWxscyBhcHBsaWNhdGlvbnMgZ2V0IHRvIGRl Y2lkZSB3aGF0IHRvIHVzZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBvdGhlciB0 aGluZyBJIGdldCBmcm9tIHRoaXMsIHRob3VnaCwgaXMgdGhhdCBpdOKAmXMgcmVjb21tZW5kZWQg dG8gaGF2ZSBhdCBsZWFzdCBMIGJ5dGVzIGZvciBhbiBITUFDIGtleSAoTCA9IDMyIGZvciBTSEEt MjU2KS4gSSB0aGluayB3ZSBzaG91bGQgcmVmbGVjdCB0aGlzIHJlY29tbWVuZGF0aW9uLiBXZQ0K IGNvdWxkIGRvIGl0IGVpdGhlciB3aXRoIGEg4oCcU0hPVUxE4oCdIG9yIOKAnE1VU1TigJ0gYmUg YXQgbGVhc3QgdGhlIG91dHB1dCBoYXNoIGxlbmd0aCAobm90IHNldCB0aGUgbWluaW11bSBhdCAw KS4gSSBzZWUgbm8gcmVhc29uIG5vdCB0byB1cGdyYWRlIHRoYXQgdG8gYSBNVVNUIGZvciBCYWJl bCwgaWYgd2Ugd2FudC4gW0l04oCZcyBhbHdheXMgb2sgdG8gYmUgc3RyaWN0ZXIgdGhhbiBhIHJl ZmVyZW5jZWQgc3BlYyAoZS5nLiwgY2hhbmdlIFNIT1VMRCB0byBNVVNUKQ0KIOKAkyBpdOKAmXMg anVzdCBub3Qgb2sgdG8gZG8gb3IgYWxsb3cgc29tZXRoaW5nIHRoYXQgdmlvbGF0ZXMgYSByZXF1 aXJlbWVudCBmcm9tIHRoZSBzcGVjIChlLmcuLCBjaGFuZ2UgTVVTVCB0byBTSE9VTEQpLl0gSSB0 aGluayBhdCBsZWFzdCBhIE1VU1QgYmUgYXQgbGVhc3QgOCBieXRlc+KAnSB3aXRoIGEg4oCcU0hP VUxEIGJlIGF0IGxlYXN0IHRoZSBvdXRwdXQgaGFzaCBsZW5ndGjigJ0gd291bGQgYmUgZ29vZCBm b3IgSE1BQy4gSXTigJlzIGFsc28gb2sgZm9yIHRoZQ0KIGluZm9ybWF0aW9uIG1vZGVsIHRvIGJl IHN0cmljdGVyIHRoYW4gdGhlIGJhYmVsLWhtYWMgaW1wbGVtZW50YXRpb24uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5CbGFrZTJzIGRvZXMgc3BlY2lmaWNhbGx5IGFsbG93IHplcm8tbGVu Z3RoIGtleXMg4oCTIHRob3VnaCBJIGRvbuKAmXQga25vdyBob3cgYWR2aXNhYmxlIHRoYXQgaXMg aW4gYSBCYWJlbCB1c2FnZSBzY2VuYXJpby4gSSBkb27igJl0IGtub3cgd2hlbiBrZXkgbGVuZ3Ro IG9mIDAgaXMgdXNlZnVsLiBCdXQgdGhlcmUgaXMNCiBkZWZpbml0ZWx5IG5vdGhpbmcgdGhhdCBw cmV2ZW50cyB1cyBmcm9tIGJlaW5nIHN0cmljdGVyLCBpZiB3ZSB3YW50ZWQgdG8gaW5zaXN0IG9u IGEga2V5IGxvbmdlciB0aGFuIDAuIEFnYWluLCB0aGlzIHN0cmljdG5lc3MgY2FuIGJlIGluIGlu Zm8tbW9kZWwgb25seSBhbmQgZG9lc27igJl0IGhhdmUgdG8gYmUgcmVmbGVjdGVkIGluIGJhYmVs LWhtYWMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGRvIG5lZWQgc29tZSBtYXhpbXVt IHNpemUgb24gdGhlIHBhcmFtZXRlciAoaW5kZXBlbmRlbnQgb2Yga2V5IGFsZ29yaXRobSkg4oCT IHNvIGl0IHdvbuKAmXQgYmUgdW5saW1pdGVkIGxlbmd0aCwgYW55d2F5LiBJ4oCZbSB0aGlua2lu ZyAxMjggYnl0ZXMgYXMgYW4gYWJzb2x1dGUgdXBwZXIgbGltaXQgYXQgdGhpcw0KIHRpbWUuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJhcmJhcmE8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFj Y29yZGluZyB0byBSRkMgNzY5MywgQmxha2UycyBrZXlzIG11c3QgYmUgb2YgbGVuZ3RoIGtrIHdo ZXJlJm5ic3A7MCAmbHQ7PSBrayAmbHQ7PSAzMi4gU28gaGF2aW5nIHRoZSBpbmZvIG1vZGVsIGRp Y3RhdGUgdGhhdCBrZXlzIE1VU1QgZm9sbG93IHRoYXQgaXMgcGVyZmVjdGx5IHJlYXNvbmFibGUg dG8gbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5Ib3dldmVyLCBhY2NvcmRpbmcgdG8gUkZDIDYyMzQsIEhNQUMtU0hBLTI1NiBhbGxv d3MgYWxsIGtleSBsZW5ndGhzIGtrIHdoZXJlIDAgJmx0Oz0ga2suIEkgZG9uJ3QgdGhpbmsgdGhl IGluZm9ybWF0aW9uIG1vZGVsIHNob3VsZCBleHByZXNzIGFuIG9waW5pb24gYXMgdG8gd2hldGhl ciBrZXlzIGxvbmdlciB0aGFuDQogNjQgYnl0ZXMgYXJlIHNhZmUgb3Igbm90LiBJZiB3ZSBjaG9v c2UgdG8gYWRkIHRoYXQgZGlzdGluY3Rpb24gd2UnbGwgbmVlZCB0byBqdXN0aWZ5IHdoeSB3ZSB0 aGluayB0aGUga2V5IGhhc2hpbmcgaXMgdW5zYWZlLCBhbmQgSSBkb24ndCB0aGluayB0aGVyZSBp cyBhbiBSRkMgd2UgY2FuIGNpdGUgZm9yIHRoYXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TbyBnb2luZyBiYWNrIHRvIEp1bGl1c3on cyBsaXN0ZWQgb3B0aW9ucyBpbiB0aGUgb3RoZXIgdGhyZWFkICZsdDs8YSBocmVmPSJodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX21haWxhcmNoaXZl LmlldGYub3JnX2FyY2hfbXNnX2JhYmVsX1FsdnNQQjl5WUZQVFB3UXhhTGNXSU4zSGwyWSZhbXA7 ZD1Ed01GYVEmYW1wO2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj1Mb0d6aEMtOHNjOFNZ OFRxNHZyZm9nJmFtcDttPXI0ZEtXMEhOU3JqTlBYZFhJZEpfM2tHYzNYclJJeGRCYWM2MER1YTlG OVEmYW1wO3M9aGN3aTVRRHdHN3dxOTZjRTV2VWJKNkxZSjBtTm42cDBpR3N0UG9za3pPOCZhbXA7 ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L2JhYmVsL1FsdnNQQjl5WUZQVFB3UXhhTGNXSU4zSGwyWTwvYT4mZ3Q7LA0KIEkgd291bGQgYXJn dWUgZm9yIG9wdGlvbiAzICZxdW90O2J1cmVhdWNyYXRpYyZxdW90OyBiZWNhdXNlIGl0IGZvbGxv d3MgdGhlIGRlc2lnbiBwcmluY2lwbGUgJnF1b3Q7VGhlIEJhYmVsIFdHIGRvZXMgbm90IG1ha2Ug c2VjdXJpdHkgZGVjaXNpb25zLCB3ZSBmb2xsb3cgd2hhdCBSRkNzIHRlbGwgdXMmcXVvdDsuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5E YXZpZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+T24gVGh1LCBBdWcgMTUsIDIwMTkgYXQgOTo1OCBBTSBTVEFSSywgQkFSQkFSQSBIICZs dDs8YSBocmVmPSJtYWlsdG86YnM3NjUyQGF0dC5jb20iIHRhcmdldD0iX2JsYW5rIj5iczc2NTJA YXR0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jmd0OyAmZ3Q7IElzIHRoaXMgc3VnZ2VzdGluZyB0aGF0IGl0J3Mgb2sgZm9yIGluZm8t bW9kZWwgdG8gcHJvdmlkZSBiYWJlbC1obWFjPGJyPg0KJmd0OyAmZ3Q7IHdpdGggYW55IHZhbHVl IGJldHdlZW4gMCBhbmQgNjQgYnl0ZXMgaW4gbGVuZ3RoIGZvciBITUFDLVNIQTI1NiBvcjxicj4N CiZndDsgJmd0OyBiZXR3ZWVuIDAgYW5kIDMyIGJ5dGVzIGluIGxlbmd0aCBmb3IgQmxha2UycyBh bmQgYmFiZWwtaG1hYyBjYW4gYmU8YnI+DQomZ3Q7ICZndDsgZXhwZWN0ZWQgdG8gemVyby1wYWQ/ IE9yIGFyZSB5b3Ugc3RpbGwgZXhwZWN0aW5nIGluZm8tbW9kZWwgdG8gZG8gdGhlPGJyPg0KJmd0 OyAmZ3Q7IHplcm8tcGFkZGluZyBiZWZvcmUgcHJvdmlkaW5nIHRvIGJhYmVsLWhtYWM/PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFRoZSBmb3JtZXIuJm5ic3A7IFlvdSBnaXZlIG1lIGFueXRoaW5nIGJl dHdlZW4gMCBhbmQgMzIvNjQsIGFuZCBJIGRlYWwgd2l0aCBpdC48YnI+DQo8YnI+DQpDb29sLiBU aGVuIGZyb20gYSBwdXJlbHkgaW5mby1tb2RlbCBwZXJzcGVjdGl2ZSwgaXQgc291bmRzIGxpa2Ug dGhlIGtleS12YWx1ZSBwYXJhbWV0ZXIgbGVuZ3RoIGNvbnN0cmFpbnRzIGFyZTo8YnI+DQo8YnI+ DQombmJzcDsgVGhpcyB2YWx1ZSBpcyBvZiBhIGxlbmd0aCBzdWl0YWJsZSBmb3IgdGhlIGFzc29j aWF0ZWQ8YnI+DQombmJzcDsgYmFiZWwtbWFjLWtleS1hbGdvcml0aG0uJm5ic3A7IElmIHRoZSBh bGdvcml0aG0gaXMgYmFzZWQgb24gdGhlIEhNQUM8YnI+DQombmJzcDsgY29uc3RydWN0aW9uLCB0 aGUgbGVuZ3RoIE1VU1QgYmUgYmV0d2VlbiAwIGFuZCB0aGUgYmxvY2sgc2l6ZSBvZiB0aGU8YnI+ DQombmJzcDsgdW5kZXJseWluZyBoYXNoIGluY2x1c2l2ZSAod2hlcmUgJnF1b3Q7SE1BQy1TSEEy NTYmcXVvdDsgYmxvY2sgc2l6ZSBpcyA2NCBieXRlczxicj4NCiZuYnNwOyBhcyBkZXNjcmliZWQg aW4ge3tSRkM0ODY4fX0pLjxicj4NCiZuYnNwOyBJZiB0aGUgYWxnb3JpdGhtIGlzICZxdW90O0JM QUtFMnMmcXVvdDssIHRoZSBsZW5ndGggTVVTVCBiZSBiZXR3ZWVuIDAgYW5kIDMyIGJ5dGVzPGJy Pg0KJm5ic3A7IGluY2x1c2l2ZSwgYXMgZGVzY3JpYmVkIGluIHt7UkZDNzY5M319Ljxicj4NCjxi cj4NCkFueXRoaW5nIGNvbXBseWluZyB3aXRoIGluZm8tbW9kZWwgd29uJ3Qgc3VwcGx5IGFueXRo aW5nIGxvbmdlciB0aGFuIHRoZSBpZGVudGlmaWVkIG1heCBsZW5ndGguPGJyPg0KQSBiYWJlbC1o bWFjIGltcGxlbWVudGF0aW9uIG1heSBnZXQgc29tZXRoaW5nIGFzIHNob3J0IGFzIHplcm8gbGVu Z3RoLCBidXQgd2lsbCBiZSBleHBlY3RlZCB0byBkZWFsIHdpdGggaXQuIEluZm8tbW9kZWwgZG9l c24ndCBjYXJlIGFuZCBkb2Vzbid0IG5lZWQgdG8ga25vdyB3aGF0ICZxdW90O2RlYWwgd2l0aCBp dCZxdW90OyBtZWFucy48YnI+DQpGb3IgSE1BQyBhbmQgQmxha2UycyBhbGdvcml0aG1zLCAmcXVv dDtkZWFsIHdpdGggaXQmcXVvdDsgbWVhbnMgaG1hYy1iYWJlbCB3aWxsIHplcm8tcGFkIHNob3J0 ZXIgc3RyaW5ncywgYmVjYXVzZSB0aGF0J3Mgd2hhdCB0aGUgYWxnb3JpdGhtIFJGQ3Mgc2F5IHRv IGRvIChhbmQgbm90IGJlY2F1c2UgYmFiZWwtaG1hYyBoYXMgYW55IGV4dHJhIHJlcXVpcmVtZW50 cyBnb2luZyBiZXlvbmQgdGhlIGFsZ29yaXRobSBzcGVjcykuPGJyPg0KSW5mby1tb2RlbCB3b24n dCBzZW5kIHN0cmluZ3MgbG9uZ2VyIHRoYW4gdGhlIGluZGljYXRlZCBsZW5ndGguIElmIHRoZXJl IGlzIGEgVUkgdG8gaW5mbyBtb2RlbCB0aGF0IGFjY2VwdHMgYSBsb25nZXIgc3RyaW5nLCBoYXNo ZXMgaXQsIGFuZCB0aGVuIGluZm8tbW9kZWwgcHJvdmlkZXMgdGhlIGhhc2hlZCB2YWx1ZSwgdGhh dCBpcyB3aGF0IGl0IGlzLiBOZWl0aGVyIGluZm8tbW9kZWwgbm9yIGJhYmVsLWhtYWMgY2FyZSBv ciBrbm93IG9yIG5lZWQNCiB0byBrbm93IGFib3V0IHRoaXMuPGJyPg0KSWYgYSBiYWJlbC1obWFj IGltcGxlbWVudGF0aW9uIGRvZXMgaGF2ZSBzcGVjaWFsIGhhbmRsaW5nIGZvciBsb25nZXIgc3Ry aW5ncywgdGhhdCdzIGZpbmUsIHRvby4gQnV0IGEgdmFsdWUgY29taW5nIGZyb20gaW5mby1tb2Rl bCB3aWxsIG5ldmVyIHRyaWdnZXIgdGhpcyBzcGVjaWFsIGNvZGUuPGJyPg0KRG9lcyB0aGF0IHNv dW5kIHJpZ2h0Pzxicj4NCkJhcmJhcmE8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmJhYmVsIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpiYWJlbEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJhYmVsQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fYmFiZWwmYW1w O2Q9RHdNRmFRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9TG9HemhDLThzYzhT WThUcTR2cmZvZyZhbXA7bT1yNGRLVzBITlNyak5QWGRYSWRKXzNrR2MzWHJSSXhkQmFjNjBEdWE5 RjlRJmFtcDtzPTVoVU5qNi1WZHpLX05xY1Bfak9Pb1JKdVFfVzM4OHY1WVQ2WmwyUnF4RGcmYW1w O2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9iYWJlbDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_2D09D61DDFA73D4C884805CC7865E6114E277CFAGAALPA1MSGUSRBF_-- From nobody Thu Aug 15 16:55:18 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 7CB331200F3 for ; Thu, 15 Aug 2019 16:55:16 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 UCMwZOSq1k1B for ; Thu, 15 Aug 2019 16:55:12 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 044ED1200E9 for ; Thu, 15 Aug 2019 16:55:12 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id n19so2789894lfe.13 for ; Thu, 15 Aug 2019 16:55:11 -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=qYOAf9TZxcpkj3vZZabQVKXuJa7cFHUqdThhxL2SxQo=; b=LtCz70f12juDrzWiv961T3gmfpn1S4RvOYj0xj/4KTRsHTQ+LauqZRnFzl7lJi/XXP rW/a/LUpOGqejNfh+rC69oN4fU+HFr6bheP7l9S9AFuJx4gFybYrveZ82/clNJE1fatb wa6jNtJi04ijgI3ZIxZsMbh1zUG4moKwGz/VTkkzDBp4nuZ+niukAxa4AXhe1eBk5N9A VJHeJ/rO2SKpJWSMVq3O9NcYqBkUzAZ87gODcobmVwZgTesLaaI9visjkcNTMzpBIQ1/ gtRLoOeXlVi+yvkovTmvT27lQFZ0CSSOO+629/5ACxioeEkxvafMRWniB/BBThFp6Ebv YoCw== 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=qYOAf9TZxcpkj3vZZabQVKXuJa7cFHUqdThhxL2SxQo=; b=aPPO48DMzD0bOQLpB8ljrTM2rvT5LV+wk93neDgbSogZ5E+42flAz+ajg4JrDVC8Sp IE+YmKmc0M+wS2b5ZiA+dTTftltAFabniL/GKPSRe8YHZnGr7KdB5qZR8l6wtD6D7kt4 VGRgOM9ADHeJK1jNaRgs0rT+9lmAAIXOSMXqbIyq88Uc+faUk4iq9TYMkFyJOXjiR1ZC Omq/mF83pkG/SnxDOHbgtWrwTEB+4hfpCaddto/9Mxcc3DXus0DG0CJblRnwbD7XSyWu sKxIhs0iGRE6FfLjuIQFFKLJdYPtRDAGXfUj4vg8DG5/F7otPeCzqFSSYqCkeg6Nt1jD ttDA== X-Gm-Message-State: APjAAAXUtVs07+jqL0g2W1l86nvNHOzDzO4Kx2UbIoH6mYI95kYWUFcE 9wP28foOP2Juv93PZTcRDCycRDO9ClMh+yyUpiA= X-Google-Smtp-Source: APXvYqxDYsoz6fEfiBv1Cy3h3hI7mvurk+yW9Lf9MQOKhVE7HocqzcllRDpa0LVQrtoSZqt1Kuj6Pz10T+S/RtmtYj8= X-Received: by 2002:a19:428c:: with SMTP id p134mr3370309lfa.166.1565913310211; Thu, 15 Aug 2019 16:55:10 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> <87ftm3u0a6.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269981@GAALPA1MSGUSRBF.ITServices.sbc.com> <87blwrtudx.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E275E65@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E27796E@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E277CFA@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E277CFA@GAALPA1MSGUSRBF.ITServices.sbc.com> From: David Schinazi Date: Thu, 15 Aug 2019 16:54:59 -0700 Message-ID: To: "STARK, BARBARA H" Cc: "babel@ietf.org" , Juliusz Chroboczek Content-Type: multipart/alternative; boundary="0000000000009ab40e0590309af2" Archived-At: Subject: Re: [babel] info-model: preparing -09 on github 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: Thu, 15 Aug 2019 23:55:17 -0000 --0000000000009ab40e0590309af2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Why add restrictions to the info model and not to babel-hmac? If we believe something is insecure shouldn't we ban it even when the info model isn't being used? On Thu, Aug 15, 2019 at 4:40 PM STARK, BARBARA H wrote: > As RFC2104 says: =E2=80=9CKeys longer than L bytes are acceptable but the= extra > length would not significantly increase the function strength.=E2=80=9D S= ince 64 =3D > 2*L for SHA-256, a key longer than 64 is even less likely to increase the > function strength. So key length > 64 provides no added value. But it doe= s > increase complexity for creating the =E2=80=9Creal=E2=80=9D key. Increase= d complexity means > more things can go wrong. > > > > I don=E2=80=99t think we should allow a 1-byte key. My recommendation for= SHA-256 > was MUST be > 8. I found this site: https://www.keylength.com/en/4/ which > says NIST recommends minimum of 16 bytes for SHA-256 keys. I=E2=80=99m go= od with > requiring that, too. It would certainly make us current on best practice > security recommendations. There=E2=80=99s something to be said for follow= ing best > practices. > > > > I have no idea what to do for Blake2s. I can=E2=80=99t find a minimum key= length > recommendation. But zero-length (unkeyed) usage provides no meaningful > security in the Babel use case. Zero-length is probably the first thing a= n > attacker would try. And they=E2=80=99d be immediately right. That hardly = counts as > a brute force attack. So I=E2=80=99m not comfortable with allowing zero-l= ength in > info-model. > > > > And just to be clear, I=E2=80=99m not suggesting any of these restriction= s go in > babel-hmac. Just info-model. > > Barbara > > > > *From:* David Schinazi > *Sent:* Thursday, August 15, 2019 6:56 PM > *To:* STARK, BARBARA H > *Cc:* babel@ietf.org; Juliusz Chroboczek > *Subject:* Re: [babel] info-model: preparing -09 on github > > > > If we're considering adding restrictions specific to Babel (and/or the > info model), I think we should take a principled approach. What fundament= al > principles are we using to decide these restrictions? If we allow a 1-byt= e > key but disallow a 65-byte key, then the principle we're after is not > improving security? > > > > On Thu, Aug 15, 2019 at 2:46 PM STARK, BARBARA H wrote: > > I disagree. > > > > The HMAC specs (RFC2104) says: > > Applications that use keys longer > > than B [block size] bytes will first hash the key using H and then use > the > > resultant L [hash output size] byte string as the actual key to HMAC. > In any case the > > minimal recommended length for K is L bytes (as the hash output > > length). See section 3 for more information on keys. > > and from section 3 > > The key for HMAC can be of any length (keys longer than B bytes are > > first hashed using H). However, less than L bytes is strongly > > discouraged as it would decrease the security strength of the > > function. Keys longer than L bytes are acceptable but the extra > > length would not significantly increase the function strength. (A > > longer key may be advisable if the randomness of the key is > > considered weak.) > > > > In this language, there is no requirement for applications using HMAC to > accept (or be able to use) keys longer than B bytes. The two statements d= o > say what must happen **if** a key longer than B bytes is provided. But if > Babel wants to restrict keys to no more than B bytes, that is well within > Babel=E2=80=99s purview to do so. RFC2106 very clearly tells applications= get to > decide what to use. > > > > The other thing I get from this, though, is that it=E2=80=99s recommended= to have > at least L bytes for an HMAC key (L =3D 32 for SHA-256). I think we shoul= d > reflect this recommendation. We could do it either with a =E2=80=9CSHOULD= =E2=80=9D or > =E2=80=9CMUST=E2=80=9D be at least the output hash length (not set the mi= nimum at 0). I see > no reason not to upgrade that to a MUST for Babel, if we want. [It=E2=80= =99s always > ok to be stricter than a referenced spec (e.g., change SHOULD to MUST) = =E2=80=93 > it=E2=80=99s just not ok to do or allow something that violates a require= ment from > the spec (e.g., change MUST to SHOULD).] I think at least a MUST be at > least 8 bytes=E2=80=9D with a =E2=80=9CSHOULD be at least the output hash= length=E2=80=9D would be > good for HMAC. It=E2=80=99s also ok for the information model to be stric= ter than > the babel-hmac implementation. > > > > Blake2s does specifically allow zero-length keys =E2=80=93 though I don= =E2=80=99t know how > advisable that is in a Babel usage scenario. I don=E2=80=99t know when ke= y length > of 0 is useful. But there is definitely nothing that prevents us from bei= ng > stricter, if we wanted to insist on a key longer than 0. Again, this > strictness can be in info-model only and doesn=E2=80=99t have to be refle= cted in > babel-hmac. > > > > I do need some maximum size on the parameter (independent of key > algorithm) =E2=80=93 so it won=E2=80=99t be unlimited length, anyway. I= =E2=80=99m thinking 128 > bytes as an absolute upper limit at this time. > > Barbara > > > > According to RFC 7693, Blake2s keys must be of length kk where 0 <=3D kk = <=3D > 32. So having the info model dictate that keys MUST follow that is > perfectly reasonable to me. > > > > However, according to RFC 6234, HMAC-SHA-256 allows all key lengths kk > where 0 <=3D kk. I don't think the information model should express an > opinion as to whether keys longer than 64 bytes are safe or not. If we > choose to add that distinction we'll need to justify why we think the key > hashing is unsafe, and I don't think there is an RFC we can cite for that= . > > > > So going back to Juliusz's listed options in the other thread < > https://mailarchive.ietf.org/arch/msg/babel/QlvsPB9yYFPTPwQxaLcWIN3Hl2Y > >, > I would argue for option 3 "bureaucratic" because it follows the design > principle "The Babel WG does not make security decisions, we follow what > RFCs tell us". > > > > David > > > > On Thu, Aug 15, 2019 at 9:58 AM STARK, BARBARA H wrote: > > > > Is this suggesting that it's ok for info-model to provide babel-hmac > > > with any value between 0 and 64 bytes in length for HMAC-SHA256 or > > > between 0 and 32 bytes in length for Blake2s and babel-hmac can be > > > expected to zero-pad? Or are you still expecting info-model to do the > > > zero-padding before providing to babel-hmac? > > > > The former. You give me anything between 0 and 32/64, and I deal with > it. > > Cool. Then from a purely info-model perspective, it sounds like the > key-value parameter length constraints are: > > This value is of a length suitable for the associated > babel-mac-key-algorithm. If the algorithm is based on the HMAC > construction, the length MUST be between 0 and the block size of the > underlying hash inclusive (where "HMAC-SHA256" block size is 64 bytes > as described in {{RFC4868}}). > If the algorithm is "BLAKE2s", the length MUST be between 0 and 32 byte= s > inclusive, as described in {{RFC7693}}. > > Anything complying with info-model won't supply anything longer than the > identified max length. > A babel-hmac implementation may get something as short as zero length, bu= t > will be expected to deal with it. Info-model doesn't care and doesn't nee= d > to know what "deal with it" means. > For HMAC and Blake2s algorithms, "deal with it" means hmac-babel will > zero-pad shorter strings, because that's what the algorithm RFCs say to d= o > (and not because babel-hmac has any extra requirements going beyond the > algorithm specs). > Info-model won't send strings longer than the indicated length. If there > is a UI to info model that accepts a longer string, hashes it, and then > info-model provides the hashed value, that is what it is. Neither > info-model nor babel-hmac care or know or need to know about this. > If a babel-hmac implementation does have special handling for longer > strings, that's fine, too. But a value coming from info-model will never > trigger this special code. > Does that sound right? > Barbara > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > > > --0000000000009ab40e0590309af2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why add restrictions to the info model and not to babel-hm= ac? If we believe something is insecure shouldn't we ban it even when t= he info model isn't being used?

On Thu, Aug 15, 2019 at 4:40 PM STARK, B= ARBARA H <bs7652@att.com> wrote= :

As RFC2104 says: =E2=80=9CKeys longer than L bytes a= re acceptable but the extra length would not significantly increase the fun= ction strength.=E2=80=9D Since 64 =3D 2*L for SHA-256, a key longer than 64= is even less likely to increase the function strength. So key length > 64 provides no added value. But it does increase comple= xity for creating the =E2=80=9Creal=E2=80=9D key. Increased complexity mean= s more things can go wrong.

=C2=A0

I don=E2=80=99t think we should allow a 1-byte key. = My recommendation for SHA-256 was MUST be > 8. I found this site: https://www.k= eylength.com/en/4/ which says NIST recommends minimum of 16 bytes for S= HA-256 keys. I=E2=80=99m good with requiring that, too. It would certainly = make us current on best practice security recommendations. There=E2=80=99s something to be said for following best practices.

=C2=A0

I have no idea what to do for Blake2s. I can=E2=80= =99t find a minimum key length recommendation. But zero-length (unkeyed) us= age provides no meaningful security in the Babel use case. Zero-length is p= robably the first thing an attacker would try. And they=E2=80=99d be immediately right. That hardly counts as a brute for= ce attack. So I=E2=80=99m not comfortable with allowing zero-length in info= -model.

=C2=A0

And just to be clear, I=E2=80=99m not suggesting any= of these restrictions go in babel-hmac. Just info-model.

Barbara

=C2=A0

From: David Schinazi <dschinazi.ietf@gmail.com> =
Sent: Thursday, August 15, 2019 6:56 PM
To: STARK, BARBARA H <bs7652@att.com>
Cc: babel@ietf.o= rg; Juliusz Chroboczek <jch@irif.fr>
Subject: Re: [babel] info-model: preparing -09 on github

=C2=A0

If we're considering adding restrictions specifi= c to Babel (and/or the info model), I think we should take a principled app= roach. What fundamental principles are we using to decide these restriction= s? If we allow a 1-byte key but disallow a 65-byte key, then the principle we're after is not improving securit= y?

=C2=A0

On Thu, Aug 15, 2019 at 2:46 PM STARK, BARBARA H <= ;bs7652@att.com>= wrote:

I disagree.

=C2=A0

The HMAC specs (RFC2104) says:

=C2=A0=C2=A0 Applications that use keys longer=

=C2=A0=C2=A0 than B [block s= ize] bytes will first hash the key using H and then use the=

=C2=A0=C2=A0 resultant L [hash ou= tput size] b= yte string as the actual key to HMAC. In any case the<= /p>

=C2=A0=C2=A0 minimal recommended length for K is L bytes (as= the hash output

=C2=A0=C2=A0 length). See section 3 for more information on = keys.

and from section 3 

=C2=A0=C2=A0=C2=A0The key for HMAC can be of any length (keys longer t=
han B bytes are
=C2=A0=C2=A0 first hashed using H).=C2=A0 However, less than L bytes i=
s strongly
=C2=A0=C2=A0 discouraged as it would decrease the security strength of=
 the
=C2=A0=C2=A0 function.=C2=A0 Keys longer than L bytes are acceptable b=
ut the extra
=C2=A0=C2=A0 length would not significantly increase the function stre=
ngth. (A
=C2=A0=C2=A0 longer key may be advisable if the randomness of the key =
is
=C2=A0=C2=A0 considered weak.)

=C2=A0

In this language, there is no requirement for applic= ations using HMAC to accept (or be able to use) keys longer than B bytes. T= he two statements do say what must happen *if* a key longer than B bytes is provided. But if Babel wants to restrict keys= to no more than B bytes, that is well within Babel=E2=80=99s purview to do= so. RFC2106 very clearly tells applications get to decide what to use.<= /u>

=C2=A0

The other thing I get from this, though, is that it= =E2=80=99s recommended to have at least L bytes for an HMAC key (L =3D 32 f= or SHA-256). I think we should reflect this recommendation. We could do it either with a =E2=80=9CSHOULD=E2=80=9D or =E2=80=9CMUST=E2=80= =9D be at least the output hash length (not set the minimum at 0). I see no= reason not to upgrade that to a MUST for Babel, if we want. [It=E2=80=99s = always ok to be stricter than a referenced spec (e.g., change SHOULD to MUS= T) =E2=80=93 it=E2=80=99s just not ok to do or allow something that violates = a requirement from the spec (e.g., change MUST to SHOULD).] I think at leas= t a MUST be at least 8 bytes=E2=80=9D with a =E2=80=9CSHOULD be at least th= e output hash length=E2=80=9D would be good for HMAC. It=E2=80=99s also ok = for the information model to be stricter than the babel-hmac implementation.

=C2=A0

Blake2s does specifically allow zero-length keys =E2= =80=93 though I don=E2=80=99t know how advisable that is in a Babel usage s= cenario. I don=E2=80=99t know when key length of 0 is useful. But there is definitely nothing that prevents us from being stricter, if we wanted to i= nsist on a key longer than 0. Again, this strictness can be in info-model o= nly and doesn=E2=80=99t have to be reflected in babel-hmac.

=C2=A0

I do need some maximum size on the parameter (indepe= ndent of key algorithm) =E2=80=93 so it won=E2=80=99t be unlimited length, = anyway. I=E2=80=99m thinking 128 bytes as an absolute upper limit at this time.

Barbara

=C2=A0

According to RFC 7693, Blake2s keys must be of lengt= h kk where=C2=A00 <=3D kk <=3D 32. So having the info model dictate t= hat keys MUST follow that is perfectly reasonable to me.

=C2=A0

However, according to RFC 6234, HMAC-SHA-256 allows = all key lengths kk where 0 <=3D kk. I don't think the information mo= del should express an opinion as to whether keys longer than 64 bytes are safe or not. If we choose to add that distinction we'll n= eed to justify why we think the key hashing is unsafe, and I don't thin= k there is an RFC we can cite for that.

=C2=A0

So going back to Juliusz's listed options in the= other thread <https://mailarchiv= e.ietf.org/arch/msg/babel/QlvsPB9yYFPTPwQxaLcWIN3Hl2Y>, I would argue for option 3 "bureaucratic" because it follows the= design principle "The Babel WG does not make security decisions, we f= ollow what RFCs tell us".

=C2=A0

David

=C2=A0

On Thu, Aug 15, 2019 at 9:58 AM STARK, BARBARA H <= ;bs7652@att.com>= wrote:

> > Is this suggesting that it's ok for in= fo-model to provide babel-hmac
> > with any value between 0 and 64 bytes in length for HMAC-SHA256 o= r
> > between 0 and 32 bytes in length for Blake2s and babel-hmac can b= e
> > expected to zero-pad? Or are you still expecting info-model to do= the
> > zero-padding before providing to babel-hmac?
>
> The former.=C2=A0 You give me anything between 0 and 32/64, and I deal= with it.

Cool. Then from a purely info-model perspective, it sounds like the key-val= ue parameter length constraints are:

=C2=A0 This value is of a length suitable for the associated
=C2=A0 babel-mac-key-algorithm.=C2=A0 If the algorithm is based on the HMAC=
=C2=A0 construction, the length MUST be between 0 and the block size of the=
=C2=A0 underlying hash inclusive (where "HMAC-SHA256" block size = is 64 bytes
=C2=A0 as described in {{RFC4868}}).
=C2=A0 If the algorithm is "BLAKE2s", the length MUST be between = 0 and 32 bytes
=C2=A0 inclusive, as described in {{RFC7693}}.

Anything complying with info-model won't supply anything longer than th= e identified max length.
A babel-hmac implementation may get something as short as zero length, but = will be expected to deal with it. Info-model doesn't care and doesn'= ;t need to know what "deal with it" means.
For HMAC and Blake2s algorithms, "deal with it" means hmac-babel = will zero-pad shorter strings, because that's what the algorithm RFCs s= ay to do (and not because babel-hmac has any extra requirements going beyon= d the algorithm specs).
Info-model won't send strings longer than the indicated length. If ther= e is a UI to info model that accepts a longer string, hashes it, and then i= nfo-model provides the hashed value, that is what it is. Neither info-model= nor babel-hmac care or know or need to know about this.
If a babel-hmac implementation does have special handling for longer string= s, that's fine, too. But a value coming from info-model will never trig= ger this special code.
Does that sound right?
Barbara

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

--0000000000009ab40e0590309af2-- From nobody Thu Aug 15 17:04: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 BE35E1200F7 for ; Thu, 15 Aug 2019 17:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXXVDlgscJRb for ; Thu, 15 Aug 2019 17:04:07 -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 529C31200F3 for ; Thu, 15 Aug 2019 17:04:07 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7FNvWlC001064; Thu, 15 Aug 2019 20:04:01 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 2udfxhj274-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Aug 2019 20:04:01 -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 x7G040OE002798; Thu, 15 Aug 2019 20:04:00 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7G03rYs002734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 15 Aug 2019 20:03:54 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id E46704009E7B; Fri, 16 Aug 2019 00:03:53 +0000 (GMT) Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (unknown [130.8.218.152]) by zlp30488.vci.att.com (Service) with ESMTPS id C68C54009E65; Fri, 16 Aug 2019 00:03:53 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.177]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0439.000; Thu, 15 Aug 2019 20:03:53 -0400 From: "STARK, BARBARA H" To: "'David Schinazi'" CC: "'babel@ietf.org'" , "'Juliusz Chroboczek'" Thread-Topic: [babel] info-model: preparing -09 on github Thread-Index: AdVSswKr0W4Y1vOsQfS00DtIY7BoYgAM83CAAAdXLCD//+jbAP//C3uggAKFBgCAAC70cIAAC7qAgABBMvD//88pgIAAQcZw Date: Fri, 16 Aug 2019 00:03:53 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E277F28@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> <87ftm3u0a6.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269981@GAALPA1MSGUSRBF.ITServices.sbc.com> <87blwrtudx.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E275E65@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E27796E@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E277CFA@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.196.183] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114E277F28GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-15_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908150230 Archived-At: Subject: Re: [babel] info-model: preparing -09 on github 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, 16 Aug 2019 00:04:12 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114E277F28GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IkJlIGxpYmVyYWwgaW4gd2hhdCB5b3UgYWNjZXB0LCBhbmQgY29uc2VydmF0aXZlIGluIHdoYXQg eW91IHNlbmQiDQpUbyBiZSByb2J1c3QsIGluZm8tbW9kZWwgbmVlZHMgdG8gYmUgY29uc2VydmF0 aXZlIGluIHdoYXQgaXQgc2VuZHMgdG8gYSBiYWJlbC1obWFjIGltcGxlbWVudGF0aW9uLiBBbmQg YmFiZWwtaG1hYyBuZWVkcyB0byBiZSBsaWJlcmFsIGluIHdoYXQgaXQgYWNjZXB0cy4NCg0KQnV0 IGlmIHlvdSBjYW4gZ2V0IEp1bGl1c3ogdG8gYWdyZWUgdG8gcmVzdHJpY3Rpb25zIGluIGJhYmVs LWhtYWMsIGFuZCBhbGwgdGhlIHJldmlld2VycyAoYmVjYXVzZSBpdOKAmXMgYSBzaWduaWZpY2Fu dCBjaGFuZ2UpLCBJ4oCZbSBmaW5lIHdpdGggdGhhdC4gSSBkbyB0aGluayBpdOKAmXMgZGFuZ2Vy b3VzIGF0IHRoaXMgcG9pbnQgaW4gdGhlIHJldmlldyBwcm9jZXNzICh1bmxlc3MgdGhlcmUgd2Vy ZSBjb21tZW50cyB0aGF0IGNvdWxkIGJlIHJlc29sdmVkIGJ5IHN1Y2ggcmVzdHJpY3Rpb25zPyku IE9UT0gsIGl0IG1pZ2h0IG1ha2UgcmV2aWV3ZXJzIGhhcHBpZXIgdG8gc2VlIHN1Y2ggcmVzdHJp Y3Rpb25zLg0KQmFyYmFyYQ0KDQpGcm9tOiBEYXZpZCBTY2hpbmF6aSA8ZHNjaGluYXppLmlldGZA Z21haWwuY29tPg0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxNSwgMjAxOSA3OjU1IFBNDQpUbzog U1RBUkssIEJBUkJBUkEgSCA8YnM3NjUyQGF0dC5jb20+DQpDYzogYmFiZWxAaWV0Zi5vcmc7IEp1 bGl1c3ogQ2hyb2JvY3playA8amNoQGlyaWYuZnI+DQpTdWJqZWN0OiBSZTogW2JhYmVsXSBpbmZv LW1vZGVsOiBwcmVwYXJpbmcgLTA5IG9uIGdpdGh1Yg0KDQpXaHkgYWRkIHJlc3RyaWN0aW9ucyB0 byB0aGUgaW5mbyBtb2RlbCBhbmQgbm90IHRvIGJhYmVsLWhtYWM/IElmIHdlIGJlbGlldmUgc29t ZXRoaW5nIGlzIGluc2VjdXJlIHNob3VsZG4ndCB3ZSBiYW4gaXQgZXZlbiB3aGVuIHRoZSBpbmZv IG1vZGVsIGlzbid0IGJlaW5nIHVzZWQ/DQoNCk9uIFRodSwgQXVnIDE1LCAyMDE5IGF0IDQ6NDAg UE0gU1RBUkssIEJBUkJBUkEgSCA8YnM3NjUyQGF0dC5jb208bWFpbHRvOmJzNzY1MkBhdHQuY29t Pj4gd3JvdGU6DQpBcyBSRkMyMTA0IHNheXM6IOKAnEtleXMgbG9uZ2VyIHRoYW4gTCBieXRlcyBh cmUgYWNjZXB0YWJsZSBidXQgdGhlIGV4dHJhIGxlbmd0aCB3b3VsZCBub3Qgc2lnbmlmaWNhbnRs eSBpbmNyZWFzZSB0aGUgZnVuY3Rpb24gc3RyZW5ndGgu4oCdIFNpbmNlIDY0ID0gMipMIGZvciBT SEEtMjU2LCBhIGtleSBsb25nZXIgdGhhbiA2NCBpcyBldmVuIGxlc3MgbGlrZWx5IHRvIGluY3Jl YXNlIHRoZSBmdW5jdGlvbiBzdHJlbmd0aC4gU28ga2V5IGxlbmd0aCA+IDY0IHByb3ZpZGVzIG5v IGFkZGVkIHZhbHVlLiBCdXQgaXQgZG9lcyBpbmNyZWFzZSBjb21wbGV4aXR5IGZvciBjcmVhdGlu ZyB0aGUg4oCccmVhbOKAnSBrZXkuIEluY3JlYXNlZCBjb21wbGV4aXR5IG1lYW5zIG1vcmUgdGhp bmdzIGNhbiBnbyB3cm9uZy4NCg0KSSBkb27igJl0IHRoaW5rIHdlIHNob3VsZCBhbGxvdyBhIDEt Ynl0ZSBrZXkuIE15IHJlY29tbWVuZGF0aW9uIGZvciBTSEEtMjU2IHdhcyBNVVNUIGJlID4gOC4g SSBmb3VuZCB0aGlzIHNpdGU6IGh0dHBzOi8vd3d3LmtleWxlbmd0aC5jb20vZW4vNC88aHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cua2V5bGVu Z3RoLmNvbV9lbl80XyZkPUR3TUZhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1Mb0d6aEMt OHNjOFNZOFRxNHZyZm9nJm09Q1ZuV1VXbVhpdjJlR2xVdklEcnNieHF2bmtRMENKZXRaSjNveno5 U0lqcyZzPWV6enZ4elpxeWkyM2t6RXZCZGhWdUwyU2ZuaktNc2E3V2N2ZTh5c1piYXMmZT0+IHdo aWNoIHNheXMgTklTVCByZWNvbW1lbmRzIG1pbmltdW0gb2YgMTYgYnl0ZXMgZm9yIFNIQS0yNTYg a2V5cy4gSeKAmW0gZ29vZCB3aXRoIHJlcXVpcmluZyB0aGF0LCB0b28uIEl0IHdvdWxkIGNlcnRh aW5seSBtYWtlIHVzIGN1cnJlbnQgb24gYmVzdCBwcmFjdGljZSBzZWN1cml0eSByZWNvbW1lbmRh dGlvbnMuIFRoZXJl4oCZcyBzb21ldGhpbmcgdG8gYmUgc2FpZCBmb3IgZm9sbG93aW5nIGJlc3Qg cHJhY3RpY2VzLg0KDQpJIGhhdmUgbm8gaWRlYSB3aGF0IHRvIGRvIGZvciBCbGFrZTJzLiBJIGNh buKAmXQgZmluZCBhIG1pbmltdW0ga2V5IGxlbmd0aCByZWNvbW1lbmRhdGlvbi4gQnV0IHplcm8t bGVuZ3RoICh1bmtleWVkKSB1c2FnZSBwcm92aWRlcyBubyBtZWFuaW5nZnVsIHNlY3VyaXR5IGlu IHRoZSBCYWJlbCB1c2UgY2FzZS4gWmVyby1sZW5ndGggaXMgcHJvYmFibHkgdGhlIGZpcnN0IHRo aW5nIGFuIGF0dGFja2VyIHdvdWxkIHRyeS4gQW5kIHRoZXnigJlkIGJlIGltbWVkaWF0ZWx5IHJp Z2h0LiBUaGF0IGhhcmRseSBjb3VudHMgYXMgYSBicnV0ZSBmb3JjZSBhdHRhY2suIFNvIEnigJlt IG5vdCBjb21mb3J0YWJsZSB3aXRoIGFsbG93aW5nIHplcm8tbGVuZ3RoIGluIGluZm8tbW9kZWwu DQoNCkFuZCBqdXN0IHRvIGJlIGNsZWFyLCBJ4oCZbSBub3Qgc3VnZ2VzdGluZyBhbnkgb2YgdGhl c2UgcmVzdHJpY3Rpb25zIGdvIGluIGJhYmVsLWhtYWMuIEp1c3QgaW5mby1tb2RlbC4NCkJhcmJh cmENCg0KRnJvbTogRGF2aWQgU2NoaW5hemkgPGRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbTxtYWls dG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tPj4NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTUs IDIwMTkgNjo1NiBQTQ0KVG86IFNUQVJLLCBCQVJCQVJBIEggPGJzNzY1MkBhdHQuY29tPG1haWx0 bzpiczc2NTJAYXR0LmNvbT4+DQpDYzogYmFiZWxAaWV0Zi5vcmc8bWFpbHRvOmJhYmVsQGlldGYu b3JnPjsgSnVsaXVzeiBDaHJvYm9jemVrIDxqY2hAaXJpZi5mcjxtYWlsdG86amNoQGlyaWYuZnI+ Pg0KU3ViamVjdDogUmU6IFtiYWJlbF0gaW5mby1tb2RlbDogcHJlcGFyaW5nIC0wOSBvbiBnaXRo dWINCg0KSWYgd2UncmUgY29uc2lkZXJpbmcgYWRkaW5nIHJlc3RyaWN0aW9ucyBzcGVjaWZpYyB0 byBCYWJlbCAoYW5kL29yIHRoZSBpbmZvIG1vZGVsKSwgSSB0aGluayB3ZSBzaG91bGQgdGFrZSBh IHByaW5jaXBsZWQgYXBwcm9hY2guIFdoYXQgZnVuZGFtZW50YWwgcHJpbmNpcGxlcyBhcmUgd2Ug dXNpbmcgdG8gZGVjaWRlIHRoZXNlIHJlc3RyaWN0aW9ucz8gSWYgd2UgYWxsb3cgYSAxLWJ5dGUg a2V5IGJ1dCBkaXNhbGxvdyBhIDY1LWJ5dGUga2V5LCB0aGVuIHRoZSBwcmluY2lwbGUgd2UncmUg YWZ0ZXIgaXMgbm90IGltcHJvdmluZyBzZWN1cml0eT8NCg0KT24gVGh1LCBBdWcgMTUsIDIwMTkg YXQgMjo0NiBQTSBTVEFSSywgQkFSQkFSQSBIIDxiczc2NTJAYXR0LmNvbTxtYWlsdG86YnM3NjUy QGF0dC5jb20+PiB3cm90ZToNCkkgZGlzYWdyZWUuDQoNClRoZSBITUFDIHNwZWNzIChSRkMyMTA0 KSBzYXlzOg0KICAgQXBwbGljYXRpb25zIHRoYXQgdXNlIGtleXMgbG9uZ2VyDQogICB0aGFuIEIg W2Jsb2NrIHNpemVdIGJ5dGVzIHdpbGwgZmlyc3QgaGFzaCB0aGUga2V5IHVzaW5nIEggYW5kIHRo ZW4gdXNlIHRoZQ0KICAgcmVzdWx0YW50IEwgW2hhc2ggb3V0cHV0IHNpemVdIGJ5dGUgc3RyaW5n IGFzIHRoZSBhY3R1YWwga2V5IHRvIEhNQUMuIEluIGFueSBjYXNlIHRoZQ0KICAgbWluaW1hbCBy ZWNvbW1lbmRlZCBsZW5ndGggZm9yIEsgaXMgTCBieXRlcyAoYXMgdGhlIGhhc2ggb3V0cHV0DQog ICBsZW5ndGgpLiBTZWUgc2VjdGlvbiAzIGZvciBtb3JlIGluZm9ybWF0aW9uIG9uIGtleXMuDQph bmQgZnJvbSBzZWN0aW9uIDMNCg0KICAgVGhlIGtleSBmb3IgSE1BQyBjYW4gYmUgb2YgYW55IGxl bmd0aCAoa2V5cyBsb25nZXIgdGhhbiBCIGJ5dGVzIGFyZQ0KDQogICBmaXJzdCBoYXNoZWQgdXNp bmcgSCkuICBIb3dldmVyLCBsZXNzIHRoYW4gTCBieXRlcyBpcyBzdHJvbmdseQ0KDQogICBkaXNj b3VyYWdlZCBhcyBpdCB3b3VsZCBkZWNyZWFzZSB0aGUgc2VjdXJpdHkgc3RyZW5ndGggb2YgdGhl DQoNCiAgIGZ1bmN0aW9uLiAgS2V5cyBsb25nZXIgdGhhbiBMIGJ5dGVzIGFyZSBhY2NlcHRhYmxl IGJ1dCB0aGUgZXh0cmENCg0KICAgbGVuZ3RoIHdvdWxkIG5vdCBzaWduaWZpY2FudGx5IGluY3Jl YXNlIHRoZSBmdW5jdGlvbiBzdHJlbmd0aC4gKEENCg0KICAgbG9uZ2VyIGtleSBtYXkgYmUgYWR2 aXNhYmxlIGlmIHRoZSByYW5kb21uZXNzIG9mIHRoZSBrZXkgaXMNCg0KICAgY29uc2lkZXJlZCB3 ZWFrLikNCg0KSW4gdGhpcyBsYW5ndWFnZSwgdGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgZm9yIGFw cGxpY2F0aW9ucyB1c2luZyBITUFDIHRvIGFjY2VwdCAob3IgYmUgYWJsZSB0byB1c2UpIGtleXMg bG9uZ2VyIHRoYW4gQiBieXRlcy4gVGhlIHR3byBzdGF0ZW1lbnRzIGRvIHNheSB3aGF0IG11c3Qg aGFwcGVuICppZiogYSBrZXkgbG9uZ2VyIHRoYW4gQiBieXRlcyBpcyBwcm92aWRlZC4gQnV0IGlm IEJhYmVsIHdhbnRzIHRvIHJlc3RyaWN0IGtleXMgdG8gbm8gbW9yZSB0aGFuIEIgYnl0ZXMsIHRo YXQgaXMgd2VsbCB3aXRoaW4gQmFiZWzigJlzIHB1cnZpZXcgdG8gZG8gc28uIFJGQzIxMDYgdmVy eSBjbGVhcmx5IHRlbGxzIGFwcGxpY2F0aW9ucyBnZXQgdG8gZGVjaWRlIHdoYXQgdG8gdXNlLg0K DQpUaGUgb3RoZXIgdGhpbmcgSSBnZXQgZnJvbSB0aGlzLCB0aG91Z2gsIGlzIHRoYXQgaXTigJlz IHJlY29tbWVuZGVkIHRvIGhhdmUgYXQgbGVhc3QgTCBieXRlcyBmb3IgYW4gSE1BQyBrZXkgKEwg PSAzMiBmb3IgU0hBLTI1NikuIEkgdGhpbmsgd2Ugc2hvdWxkIHJlZmxlY3QgdGhpcyByZWNvbW1l bmRhdGlvbi4gV2UgY291bGQgZG8gaXQgZWl0aGVyIHdpdGggYSDigJxTSE9VTETigJ0gb3Ig4oCc TVVTVOKAnSBiZSBhdCBsZWFzdCB0aGUgb3V0cHV0IGhhc2ggbGVuZ3RoIChub3Qgc2V0IHRoZSBt aW5pbXVtIGF0IDApLiBJIHNlZSBubyByZWFzb24gbm90IHRvIHVwZ3JhZGUgdGhhdCB0byBhIE1V U1QgZm9yIEJhYmVsLCBpZiB3ZSB3YW50LiBbSXTigJlzIGFsd2F5cyBvayB0byBiZSBzdHJpY3Rl ciB0aGFuIGEgcmVmZXJlbmNlZCBzcGVjIChlLmcuLCBjaGFuZ2UgU0hPVUxEIHRvIE1VU1QpIOKA kyBpdOKAmXMganVzdCBub3Qgb2sgdG8gZG8gb3IgYWxsb3cgc29tZXRoaW5nIHRoYXQgdmlvbGF0 ZXMgYSByZXF1aXJlbWVudCBmcm9tIHRoZSBzcGVjIChlLmcuLCBjaGFuZ2UgTVVTVCB0byBTSE9V TEQpLl0gSSB0aGluayBhdCBsZWFzdCBhIE1VU1QgYmUgYXQgbGVhc3QgOCBieXRlc+KAnSB3aXRo IGEg4oCcU0hPVUxEIGJlIGF0IGxlYXN0IHRoZSBvdXRwdXQgaGFzaCBsZW5ndGjigJ0gd291bGQg YmUgZ29vZCBmb3IgSE1BQy4gSXTigJlzIGFsc28gb2sgZm9yIHRoZSBpbmZvcm1hdGlvbiBtb2Rl bCB0byBiZSBzdHJpY3RlciB0aGFuIHRoZSBiYWJlbC1obWFjIGltcGxlbWVudGF0aW9uLg0KDQpC bGFrZTJzIGRvZXMgc3BlY2lmaWNhbGx5IGFsbG93IHplcm8tbGVuZ3RoIGtleXMg4oCTIHRob3Vn aCBJIGRvbuKAmXQga25vdyBob3cgYWR2aXNhYmxlIHRoYXQgaXMgaW4gYSBCYWJlbCB1c2FnZSBz Y2VuYXJpby4gSSBkb27igJl0IGtub3cgd2hlbiBrZXkgbGVuZ3RoIG9mIDAgaXMgdXNlZnVsLiBC dXQgdGhlcmUgaXMgZGVmaW5pdGVseSBub3RoaW5nIHRoYXQgcHJldmVudHMgdXMgZnJvbSBiZWlu ZyBzdHJpY3RlciwgaWYgd2Ugd2FudGVkIHRvIGluc2lzdCBvbiBhIGtleSBsb25nZXIgdGhhbiAw LiBBZ2FpbiwgdGhpcyBzdHJpY3RuZXNzIGNhbiBiZSBpbiBpbmZvLW1vZGVsIG9ubHkgYW5kIGRv ZXNu4oCZdCBoYXZlIHRvIGJlIHJlZmxlY3RlZCBpbiBiYWJlbC1obWFjLg0KDQpJIGRvIG5lZWQg c29tZSBtYXhpbXVtIHNpemUgb24gdGhlIHBhcmFtZXRlciAoaW5kZXBlbmRlbnQgb2Yga2V5IGFs Z29yaXRobSkg4oCTIHNvIGl0IHdvbuKAmXQgYmUgdW5saW1pdGVkIGxlbmd0aCwgYW55d2F5LiBJ 4oCZbSB0aGlua2luZyAxMjggYnl0ZXMgYXMgYW4gYWJzb2x1dGUgdXBwZXIgbGltaXQgYXQgdGhp cyB0aW1lLg0KQmFyYmFyYQ0KDQpBY2NvcmRpbmcgdG8gUkZDIDc2OTMsIEJsYWtlMnMga2V5cyBt dXN0IGJlIG9mIGxlbmd0aCBrayB3aGVyZSAwIDw9IGtrIDw9IDMyLiBTbyBoYXZpbmcgdGhlIGlu Zm8gbW9kZWwgZGljdGF0ZSB0aGF0IGtleXMgTVVTVCBmb2xsb3cgdGhhdCBpcyBwZXJmZWN0bHkg cmVhc29uYWJsZSB0byBtZS4NCg0KSG93ZXZlciwgYWNjb3JkaW5nIHRvIFJGQyA2MjM0LCBITUFD LVNIQS0yNTYgYWxsb3dzIGFsbCBrZXkgbGVuZ3RocyBrayB3aGVyZSAwIDw9IGtrLiBJIGRvbid0 IHRoaW5rIHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBzaG91bGQgZXhwcmVzcyBhbiBvcGluaW9uIGFz IHRvIHdoZXRoZXIga2V5cyBsb25nZXIgdGhhbiA2NCBieXRlcyBhcmUgc2FmZSBvciBub3QuIElm IHdlIGNob29zZSB0byBhZGQgdGhhdCBkaXN0aW5jdGlvbiB3ZSdsbCBuZWVkIHRvIGp1c3RpZnkg d2h5IHdlIHRoaW5rIHRoZSBrZXkgaGFzaGluZyBpcyB1bnNhZmUsIGFuZCBJIGRvbid0IHRoaW5r IHRoZXJlIGlzIGFuIFJGQyB3ZSBjYW4gY2l0ZSBmb3IgdGhhdC4NCg0KU28gZ29pbmcgYmFjayB0 byBKdWxpdXN6J3MgbGlzdGVkIG9wdGlvbnMgaW4gdGhlIG90aGVyIHRocmVhZCA8aHR0cHM6Ly9t YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9iYWJlbC9RbHZzUEI5eVlGUFRQd1F4YUxjV0lO M0hsMlk8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X19tYWlsYXJjaGl2ZS5pZXRmLm9yZ19hcmNoX21zZ19iYWJlbF9RbHZzUEI5eVlGUFRQd1F4YUxj V0lOM0hsMlkmZD1Ed01GYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9TG9HemhDLThzYzhT WThUcTR2cmZvZyZtPXI0ZEtXMEhOU3JqTlBYZFhJZEpfM2tHYzNYclJJeGRCYWM2MER1YTlGOVEm cz1oY3dpNVFEd0c3d3E5NmNFNXZVYko2TFlKMG1ObjZwMGlHc3RQb3Nrek84JmU9Pj4sIEkgd291 bGQgYXJndWUgZm9yIG9wdGlvbiAzICJidXJlYXVjcmF0aWMiIGJlY2F1c2UgaXQgZm9sbG93cyB0 aGUgZGVzaWduIHByaW5jaXBsZSAiVGhlIEJhYmVsIFdHIGRvZXMgbm90IG1ha2Ugc2VjdXJpdHkg ZGVjaXNpb25zLCB3ZSBmb2xsb3cgd2hhdCBSRkNzIHRlbGwgdXMiLg0KDQpEYXZpZA0KDQpPbiBU aHUsIEF1ZyAxNSwgMjAxOSBhdCA5OjU4IEFNIFNUQVJLLCBCQVJCQVJBIEggPGJzNzY1MkBhdHQu Y29tPG1haWx0bzpiczc2NTJAYXR0LmNvbT4+IHdyb3RlOg0KPiA+IElzIHRoaXMgc3VnZ2VzdGlu ZyB0aGF0IGl0J3Mgb2sgZm9yIGluZm8tbW9kZWwgdG8gcHJvdmlkZSBiYWJlbC1obWFjDQo+ID4g d2l0aCBhbnkgdmFsdWUgYmV0d2VlbiAwIGFuZCA2NCBieXRlcyBpbiBsZW5ndGggZm9yIEhNQUMt U0hBMjU2IG9yDQo+ID4gYmV0d2VlbiAwIGFuZCAzMiBieXRlcyBpbiBsZW5ndGggZm9yIEJsYWtl MnMgYW5kIGJhYmVsLWhtYWMgY2FuIGJlDQo+ID4gZXhwZWN0ZWQgdG8gemVyby1wYWQ/IE9yIGFy ZSB5b3Ugc3RpbGwgZXhwZWN0aW5nIGluZm8tbW9kZWwgdG8gZG8gdGhlDQo+ID4gemVyby1wYWRk aW5nIGJlZm9yZSBwcm92aWRpbmcgdG8gYmFiZWwtaG1hYz8NCj4NCj4gVGhlIGZvcm1lci4gIFlv dSBnaXZlIG1lIGFueXRoaW5nIGJldHdlZW4gMCBhbmQgMzIvNjQsIGFuZCBJIGRlYWwgd2l0aCBp dC4NCg0KQ29vbC4gVGhlbiBmcm9tIGEgcHVyZWx5IGluZm8tbW9kZWwgcGVyc3BlY3RpdmUsIGl0 IHNvdW5kcyBsaWtlIHRoZSBrZXktdmFsdWUgcGFyYW1ldGVyIGxlbmd0aCBjb25zdHJhaW50cyBh cmU6DQoNCiAgVGhpcyB2YWx1ZSBpcyBvZiBhIGxlbmd0aCBzdWl0YWJsZSBmb3IgdGhlIGFzc29j aWF0ZWQNCiAgYmFiZWwtbWFjLWtleS1hbGdvcml0aG0uICBJZiB0aGUgYWxnb3JpdGhtIGlzIGJh c2VkIG9uIHRoZSBITUFDDQogIGNvbnN0cnVjdGlvbiwgdGhlIGxlbmd0aCBNVVNUIGJlIGJldHdl ZW4gMCBhbmQgdGhlIGJsb2NrIHNpemUgb2YgdGhlDQogIHVuZGVybHlpbmcgaGFzaCBpbmNsdXNp dmUgKHdoZXJlICJITUFDLVNIQTI1NiIgYmxvY2sgc2l6ZSBpcyA2NCBieXRlcw0KICBhcyBkZXNj cmliZWQgaW4ge3tSRkM0ODY4fX0pLg0KICBJZiB0aGUgYWxnb3JpdGhtIGlzICJCTEFLRTJzIiwg dGhlIGxlbmd0aCBNVVNUIGJlIGJldHdlZW4gMCBhbmQgMzIgYnl0ZXMNCiAgaW5jbHVzaXZlLCBh cyBkZXNjcmliZWQgaW4ge3tSRkM3NjkzfX0uDQoNCkFueXRoaW5nIGNvbXBseWluZyB3aXRoIGlu Zm8tbW9kZWwgd29uJ3Qgc3VwcGx5IGFueXRoaW5nIGxvbmdlciB0aGFuIHRoZSBpZGVudGlmaWVk IG1heCBsZW5ndGguDQpBIGJhYmVsLWhtYWMgaW1wbGVtZW50YXRpb24gbWF5IGdldCBzb21ldGhp bmcgYXMgc2hvcnQgYXMgemVybyBsZW5ndGgsIGJ1dCB3aWxsIGJlIGV4cGVjdGVkIHRvIGRlYWwg d2l0aCBpdC4gSW5mby1tb2RlbCBkb2Vzbid0IGNhcmUgYW5kIGRvZXNuJ3QgbmVlZCB0byBrbm93 IHdoYXQgImRlYWwgd2l0aCBpdCIgbWVhbnMuDQpGb3IgSE1BQyBhbmQgQmxha2UycyBhbGdvcml0 aG1zLCAiZGVhbCB3aXRoIGl0IiBtZWFucyBobWFjLWJhYmVsIHdpbGwgemVyby1wYWQgc2hvcnRl ciBzdHJpbmdzLCBiZWNhdXNlIHRoYXQncyB3aGF0IHRoZSBhbGdvcml0aG0gUkZDcyBzYXkgdG8g ZG8gKGFuZCBub3QgYmVjYXVzZSBiYWJlbC1obWFjIGhhcyBhbnkgZXh0cmEgcmVxdWlyZW1lbnRz IGdvaW5nIGJleW9uZCB0aGUgYWxnb3JpdGhtIHNwZWNzKS4NCkluZm8tbW9kZWwgd29uJ3Qgc2Vu ZCBzdHJpbmdzIGxvbmdlciB0aGFuIHRoZSBpbmRpY2F0ZWQgbGVuZ3RoLiBJZiB0aGVyZSBpcyBh IFVJIHRvIGluZm8gbW9kZWwgdGhhdCBhY2NlcHRzIGEgbG9uZ2VyIHN0cmluZywgaGFzaGVzIGl0 LCBhbmQgdGhlbiBpbmZvLW1vZGVsIHByb3ZpZGVzIHRoZSBoYXNoZWQgdmFsdWUsIHRoYXQgaXMg d2hhdCBpdCBpcy4gTmVpdGhlciBpbmZvLW1vZGVsIG5vciBiYWJlbC1obWFjIGNhcmUgb3Iga25v dyBvciBuZWVkIHRvIGtub3cgYWJvdXQgdGhpcy4NCklmIGEgYmFiZWwtaG1hYyBpbXBsZW1lbnRh dGlvbiBkb2VzIGhhdmUgc3BlY2lhbCBoYW5kbGluZyBmb3IgbG9uZ2VyIHN0cmluZ3MsIHRoYXQn cyBmaW5lLCB0b28uIEJ1dCBhIHZhbHVlIGNvbWluZyBmcm9tIGluZm8tbW9kZWwgd2lsbCBuZXZl ciB0cmlnZ2VyIHRoaXMgc3BlY2lhbCBjb2RlLg0KRG9lcyB0aGF0IHNvdW5kIHJpZ2h0Pw0KQmFy YmFyYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K YmFiZWwgbWFpbGluZyBsaXN0DQpiYWJlbEBpZXRmLm9yZzxtYWlsdG86YmFiZWxAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JhYmVsPGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21h aWxtYW5fbGlzdGluZm9fYmFiZWwmZD1Ed01GYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9 TG9HemhDLThzYzhTWThUcTR2cmZvZyZtPXI0ZEtXMEhOU3JqTlBYZFhJZEpfM2tHYzNYclJJeGRC YWM2MER1YTlGOVEmcz01aFVOajYtVmR6S19OcWNQX2pPT29SSnVRX1czODh2NVlUNlpsMlJxeERn JmU9Pg0K --_000_2D09D61DDFA73D4C884805CC7865E6114E277F28GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mcXVvdDtCZSBsaWJlcmFsIGluIHdoYXQgeW91IGFjY2VwdCwgYW5kIGNv bnNlcnZhdGl2ZSBpbiB3aGF0IHlvdSBzZW5kJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UbyBiZSByb2J1c3QsIGluZm8tbW9kZWwgbmVlZHMgdG8gYmUgY29uc2Vy dmF0aXZlIGluIHdoYXQgaXQgc2VuZHMgdG8gYSBiYWJlbC1obWFjIGltcGxlbWVudGF0aW9uLiBB bmQgYmFiZWwtaG1hYyBuZWVkcyB0byBiZSBsaWJlcmFsIGluIHdoYXQgaXQgYWNjZXB0cy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IGlmIHlvdSBjYW4gZ2V0IEp1bGl1c3ogdG8gYWdyZWUg dG8gcmVzdHJpY3Rpb25zIGluIGJhYmVsLWhtYWMsIGFuZCBhbGwgdGhlIHJldmlld2VycyAoYmVj YXVzZSBpdOKAmXMgYSBzaWduaWZpY2FudCBjaGFuZ2UpLCBJ4oCZbSBmaW5lIHdpdGggdGhhdC4g SSBkbyB0aGluayBpdOKAmXMgZGFuZ2Vyb3VzIGF0IHRoaXMgcG9pbnQgaW4gdGhlIHJldmlldyBw cm9jZXNzICh1bmxlc3MgdGhlcmUgd2VyZSBjb21tZW50cw0KIHRoYXQgY291bGQgYmUgcmVzb2x2 ZWQgYnkgc3VjaCByZXN0cmljdGlvbnM/KS4gT1RPSCwgaXQgbWlnaHQgbWFrZSByZXZpZXdlcnMg aGFwcGllciB0byBzZWUgc3VjaCByZXN0cmljdGlvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5CYXJiYXJhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8 L2I+IERhdmlkIFNjaGluYXppICZsdDtkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20mZ3Q7IDxicj4N CjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDE1LCAyMDE5IDc6NTUgUE08YnI+DQo8Yj5U bzo8L2I+IFNUQVJLLCBCQVJCQVJBIEggJmx0O2JzNzY1MkBhdHQuY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gYmFiZWxAaWV0Zi5vcmc7IEp1bGl1c3ogQ2hyb2JvY3playAmbHQ7amNoQGlyaWYuZnIm Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbYmFiZWxdIGluZm8tbW9kZWw6IHByZXBhcmlu ZyAtMDkgb24gZ2l0aHViPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+V2h5IGFkZCByZXN0cmljdGlvbnMgdG8gdGhlIGluZm8gbW9kZWwgYW5kIG5vdCB0byBi YWJlbC1obWFjPyBJZiB3ZSBiZWxpZXZlIHNvbWV0aGluZyBpcyBpbnNlY3VyZSBzaG91bGRuJ3Qg d2UgYmFuIGl0IGV2ZW4gd2hlbiB0aGUgaW5mbyBtb2RlbCBpc24ndCBiZWluZyB1c2VkPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBBdWcgMTUs IDIwMTkgYXQgNDo0MCBQTSBTVEFSSywgQkFSQkFSQSBIICZsdDs8YSBocmVmPSJtYWlsdG86YnM3 NjUyQGF0dC5jb20iPmJzNzY1MkBhdHQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+QXMgUkZDMjEwNCBzYXlzOiDigJxLZXlzIGxvbmdlciB0aGFuIEwgYnl0ZXMgYXJlIGFjY2Vw dGFibGUgYnV0IHRoZSBleHRyYSBsZW5ndGggd291bGQgbm90IHNpZ25pZmljYW50bHkgaW5jcmVh c2UgdGhlIGZ1bmN0aW9uIHN0cmVuZ3RoLuKAnSBTaW5jZSA2NCA9IDIqTCBmb3IgU0hBLTI1Niwg YSBrZXkgbG9uZ2VyDQogdGhhbiA2NCBpcyBldmVuIGxlc3MgbGlrZWx5IHRvIGluY3JlYXNlIHRo ZSBmdW5jdGlvbiBzdHJlbmd0aC4gU28ga2V5IGxlbmd0aCAmZ3Q7IDY0IHByb3ZpZGVzIG5vIGFk ZGVkIHZhbHVlLiBCdXQgaXQgZG9lcyBpbmNyZWFzZSBjb21wbGV4aXR5IGZvciBjcmVhdGluZyB0 aGUg4oCccmVhbOKAnSBrZXkuIEluY3JlYXNlZCBjb21wbGV4aXR5IG1lYW5zIG1vcmUgdGhpbmdz IGNhbiBnbyB3cm9uZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZG9u4oCZdCB0aGlu ayB3ZSBzaG91bGQgYWxsb3cgYSAxLWJ5dGUga2V5LiBNeSByZWNvbW1lbmRhdGlvbiBmb3IgU0hB LTI1NiB3YXMgTVVTVCBiZSAmZ3Q7IDguIEkgZm91bmQgdGhpcyBzaXRlOg0KPGEgaHJlZj0iaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cua2V5 bGVuZ3RoLmNvbV9lbl80XyZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJ ZyZhbXA7cj1Mb0d6aEMtOHNjOFNZOFRxNHZyZm9nJmFtcDttPUNWbldVV21YaXYyZUdsVXZJRHJz Ynhxdm5rUTBDSmV0Wkozb3p6OVNJanMmYW1wO3M9ZXp6dnh6WnF5aTIza3pFdkJkaFZ1TDJTZm5q S01zYTdXY3ZlOHlzWmJhcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3Lmtl eWxlbmd0aC5jb20vZW4vNC88L2E+IHdoaWNoIHNheXMgTklTVCByZWNvbW1lbmRzIG1pbmltdW0g b2YgMTYgYnl0ZXMgZm9yIFNIQS0yNTYga2V5cy4gSeKAmW0gZ29vZCB3aXRoIHJlcXVpcmluZyB0 aGF0LCB0b28uIEl0IHdvdWxkIGNlcnRhaW5seSBtYWtlIHVzIGN1cnJlbnQgb24gYmVzdCBwcmFj dGljZSBzZWN1cml0eSByZWNvbW1lbmRhdGlvbnMuIFRoZXJl4oCZcyBzb21ldGhpbmcgdG8gYmUg c2FpZCBmb3IgZm9sbG93aW5nDQogYmVzdCBwcmFjdGljZXMuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5JIGhhdmUgbm8gaWRlYSB3aGF0IHRvIGRvIGZvciBCbGFrZTJzLiBJIGNhbuKAmXQg ZmluZCBhIG1pbmltdW0ga2V5IGxlbmd0aCByZWNvbW1lbmRhdGlvbi4gQnV0IHplcm8tbGVuZ3Ro ICh1bmtleWVkKSB1c2FnZSBwcm92aWRlcyBubyBtZWFuaW5nZnVsIHNlY3VyaXR5IGluIHRoZSBC YWJlbCB1c2UgY2FzZS4gWmVyby1sZW5ndGgNCiBpcyBwcm9iYWJseSB0aGUgZmlyc3QgdGhpbmcg YW4gYXR0YWNrZXIgd291bGQgdHJ5LiBBbmQgdGhleeKAmWQgYmUgaW1tZWRpYXRlbHkgcmlnaHQu IFRoYXQgaGFyZGx5IGNvdW50cyBhcyBhIGJydXRlIGZvcmNlIGF0dGFjay4gU28gSeKAmW0gbm90 IGNvbWZvcnRhYmxlIHdpdGggYWxsb3dpbmcgemVyby1sZW5ndGggaW4gaW5mby1tb2RlbC4NCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5kIGp1c3QgdG8gYmUgY2xlYXIsIEnigJltIG5v dCBzdWdnZXN0aW5nIGFueSBvZiB0aGVzZSByZXN0cmljdGlvbnMgZ28gaW4gYmFiZWwtaG1hYy4g SnVzdCBpbmZvLW1vZGVsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5C YXJiYXJhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBEYXZpZCBT Y2hpbmF6aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7DQo8YnI+DQo8Yj5T ZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAxNSwgMjAxOSA2OjU2IFBNPGJyPg0KPGI+VG86PC9i PiBTVEFSSywgQkFSQkFSQSBIICZsdDs8YSBocmVmPSJtYWlsdG86YnM3NjUyQGF0dC5jb20iIHRh cmdldD0iX2JsYW5rIj5iczc2NTJAYXR0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBo cmVmPSJtYWlsdG86YmFiZWxAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5iYWJlbEBpZXRmLm9y ZzwvYT47IEp1bGl1c3ogQ2hyb2JvY3playAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpjaEBpcmlmLmZy IiB0YXJnZXQ9Il9ibGFuayI+amNoQGlyaWYuZnI8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW2JhYmVsXSBpbmZvLW1vZGVsOiBwcmVwYXJpbmcgLTA5IG9uIGdpdGh1YjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiB3ZSdyZSBjb25z aWRlcmluZyBhZGRpbmcgcmVzdHJpY3Rpb25zIHNwZWNpZmljIHRvIEJhYmVsIChhbmQvb3IgdGhl IGluZm8gbW9kZWwpLCBJIHRoaW5rIHdlIHNob3VsZCB0YWtlIGEgcHJpbmNpcGxlZCBhcHByb2Fj aC4gV2hhdCBmdW5kYW1lbnRhbCBwcmluY2lwbGVzIGFyZSB3ZSB1c2luZyB0byBkZWNpZGUNCiB0 aGVzZSByZXN0cmljdGlvbnM/IElmIHdlIGFsbG93IGEgMS1ieXRlIGtleSBidXQgZGlzYWxsb3cg YSA2NS1ieXRlIGtleSwgdGhlbiB0aGUgcHJpbmNpcGxlIHdlJ3JlIGFmdGVyIGlzIG5vdCBpbXBy b3Zpbmcgc2VjdXJpdHk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T24gVGh1LCBBdWcgMTUsIDIwMTkgYXQgMjo0NiBQTSBTVEFSSywgQkFSQkFSQSBI ICZsdDs8YSBocmVmPSJtYWlsdG86YnM3NjUyQGF0dC5jb20iIHRhcmdldD0iX2JsYW5rIj5iczc2 NTJAYXR0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGRpc2FncmVlLg0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5UaGUgSE1BQyBzcGVjcyAoUkZDMjEwNCkgc2F5czo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBBcHBsaWNhdGlvbnMg dGhhdCB1c2Uga2V5cyBsb25nZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdGhhbiBCDQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+W2Jsb2NrIHNpemVdPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4gYnl0ZXMgd2lsbCBmaXJzdCBoYXNo IHRoZSBrZXkgdXNpbmcgSCBhbmQgdGhlbiB1c2UgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHJlc3VsdGFudCBM DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+W2hhc2ggb3V0cHV0IHNpemVdDQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPmJ5dGUgc3RyaW5nIGFzIHRoZSBhY3R1YWwga2V5IHRvIEhNQUMuIEluIGFueSBjYXNlIHRo ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyBtaW5pbWFsIHJlY29tbWVuZGVkIGxlbmd0aCBmb3IgSyBpcyBMIGJ5dGVz IChhcyB0aGUgaGFzaCBvdXRwdXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgbGVuZ3RoKS4gU2VlIHNlY3Rpb24gMyBm b3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBrZXlzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+YW5kIGZyb20gc2VjdGlvbiAzDQo8bzpwPjwvbzpwPjwvcD4NCjxw cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIGtleSBmb3IgSE1BQyBjYW4gYmUgb2YgYW55IGxlbmd0 aCAoa2V5cyBsb25nZXIgdGhhbiBCIGJ5dGVzIGFyZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyBmaXJzdCBoYXNoZWQgdXNpbmcgSCkuJm5ic3A7IEhvd2V2ZXIsIGxlc3MgdGhh biBMIGJ5dGVzIGlzIHN0cm9uZ2x5PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IGRpc2NvdXJhZ2VkIGFzIGl0IHdvdWxkIGRlY3JlYXNlIHRoZSBzZWN1cml0eSBzdHJlbmd0aCBv ZiB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZnVuY3Rpb24uJm5ic3A7 IEtleXMgbG9uZ2VyIHRoYW4gTCBieXRlcyBhcmUgYWNjZXB0YWJsZSBidXQgdGhlIGV4dHJhPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGxlbmd0aCB3b3VsZCBub3Qgc2lnbmlm aWNhbnRseSBpbmNyZWFzZSB0aGUgZnVuY3Rpb24gc3RyZW5ndGguIChBPG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGxvbmdlciBrZXkgbWF5IGJlIGFkdmlzYWJsZSBpZiB0aGUg cmFuZG9tbmVzcyBvZiB0aGUga2V5IGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7IGNvbnNpZGVyZWQgd2Vhay4pPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIHRo aXMgbGFuZ3VhZ2UsIHRoZXJlIGlzIG5vIHJlcXVpcmVtZW50IGZvciBhcHBsaWNhdGlvbnMgdXNp bmcgSE1BQyB0byBhY2NlcHQgKG9yIGJlIGFibGUgdG8gdXNlKSBrZXlzIGxvbmdlciB0aGFuIEIg Ynl0ZXMuIFRoZSB0d28gc3RhdGVtZW50cyBkbyBzYXkgd2hhdCBtdXN0IGhhcHBlbiAqPGI+aWY8 L2I+Kg0KIGEga2V5IGxvbmdlciB0aGFuIEIgYnl0ZXMgaXMgcHJvdmlkZWQuIEJ1dCBpZiBCYWJl bCB3YW50cyB0byByZXN0cmljdCBrZXlzIHRvIG5vIG1vcmUgdGhhbiBCIGJ5dGVzLCB0aGF0IGlz IHdlbGwgd2l0aGluIEJhYmVs4oCZcyBwdXJ2aWV3IHRvIGRvIHNvLiBSRkMyMTA2IHZlcnkgY2xl YXJseSB0ZWxscyBhcHBsaWNhdGlvbnMgZ2V0IHRvIGRlY2lkZSB3aGF0IHRvIHVzZS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBvdGhlciB0aGluZyBJIGdldCBmcm9tIHRoaXMsIHRo b3VnaCwgaXMgdGhhdCBpdOKAmXMgcmVjb21tZW5kZWQgdG8gaGF2ZSBhdCBsZWFzdCBMIGJ5dGVz IGZvciBhbiBITUFDIGtleSAoTCA9IDMyIGZvciBTSEEtMjU2KS4gSSB0aGluayB3ZSBzaG91bGQg cmVmbGVjdCB0aGlzIHJlY29tbWVuZGF0aW9uLiBXZQ0KIGNvdWxkIGRvIGl0IGVpdGhlciB3aXRo IGEg4oCcU0hPVUxE4oCdIG9yIOKAnE1VU1TigJ0gYmUgYXQgbGVhc3QgdGhlIG91dHB1dCBoYXNo IGxlbmd0aCAobm90IHNldCB0aGUgbWluaW11bSBhdCAwKS4gSSBzZWUgbm8gcmVhc29uIG5vdCB0 byB1cGdyYWRlIHRoYXQgdG8gYSBNVVNUIGZvciBCYWJlbCwgaWYgd2Ugd2FudC4gW0l04oCZcyBh bHdheXMgb2sgdG8gYmUgc3RyaWN0ZXIgdGhhbiBhIHJlZmVyZW5jZWQgc3BlYyAoZS5nLiwgY2hh bmdlIFNIT1VMRCB0byBNVVNUKQ0KIOKAkyBpdOKAmXMganVzdCBub3Qgb2sgdG8gZG8gb3IgYWxs b3cgc29tZXRoaW5nIHRoYXQgdmlvbGF0ZXMgYSByZXF1aXJlbWVudCBmcm9tIHRoZSBzcGVjIChl LmcuLCBjaGFuZ2UgTVVTVCB0byBTSE9VTEQpLl0gSSB0aGluayBhdCBsZWFzdCBhIE1VU1QgYmUg YXQgbGVhc3QgOCBieXRlc+KAnSB3aXRoIGEg4oCcU0hPVUxEIGJlIGF0IGxlYXN0IHRoZSBvdXRw dXQgaGFzaCBsZW5ndGjigJ0gd291bGQgYmUgZ29vZCBmb3IgSE1BQy4gSXTigJlzIGFsc28gb2sg Zm9yIHRoZQ0KIGluZm9ybWF0aW9uIG1vZGVsIHRvIGJlIHN0cmljdGVyIHRoYW4gdGhlIGJhYmVs LWhtYWMgaW1wbGVtZW50YXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CbGFrZTJz IGRvZXMgc3BlY2lmaWNhbGx5IGFsbG93IHplcm8tbGVuZ3RoIGtleXMg4oCTIHRob3VnaCBJIGRv buKAmXQga25vdyBob3cgYWR2aXNhYmxlIHRoYXQgaXMgaW4gYSBCYWJlbCB1c2FnZSBzY2VuYXJp by4gSSBkb27igJl0IGtub3cgd2hlbiBrZXkgbGVuZ3RoIG9mIDAgaXMgdXNlZnVsLiBCdXQgdGhl cmUgaXMNCiBkZWZpbml0ZWx5IG5vdGhpbmcgdGhhdCBwcmV2ZW50cyB1cyBmcm9tIGJlaW5nIHN0 cmljdGVyLCBpZiB3ZSB3YW50ZWQgdG8gaW5zaXN0IG9uIGEga2V5IGxvbmdlciB0aGFuIDAuIEFn YWluLCB0aGlzIHN0cmljdG5lc3MgY2FuIGJlIGluIGluZm8tbW9kZWwgb25seSBhbmQgZG9lc27i gJl0IGhhdmUgdG8gYmUgcmVmbGVjdGVkIGluIGJhYmVsLWhtYWMuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5JIGRvIG5lZWQgc29tZSBtYXhpbXVtIHNpemUgb24gdGhlIHBhcmFtZXRlciAo aW5kZXBlbmRlbnQgb2Yga2V5IGFsZ29yaXRobSkg4oCTIHNvIGl0IHdvbuKAmXQgYmUgdW5saW1p dGVkIGxlbmd0aCwgYW55d2F5LiBJ4oCZbSB0aGlua2luZyAxMjggYnl0ZXMgYXMgYW4gYWJzb2x1 dGUgdXBwZXIgbGltaXQgYXQgdGhpcw0KIHRpbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkJhcmJhcmE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFjY29yZGluZyB0byBSRkMgNzY5MywgQmxh a2UycyBrZXlzIG11c3QgYmUgb2YgbGVuZ3RoIGtrIHdoZXJlJm5ic3A7MCAmbHQ7PSBrayAmbHQ7 PSAzMi4gU28gaGF2aW5nIHRoZSBpbmZvIG1vZGVsIGRpY3RhdGUgdGhhdCBrZXlzIE1VU1QgZm9s bG93IHRoYXQgaXMgcGVyZmVjdGx5IHJlYXNvbmFibGUgdG8gbWUuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ib3dldmVyLCBhY2NvcmRp bmcgdG8gUkZDIDYyMzQsIEhNQUMtU0hBLTI1NiBhbGxvd3MgYWxsIGtleSBsZW5ndGhzIGtrIHdo ZXJlIDAgJmx0Oz0ga2suIEkgZG9uJ3QgdGhpbmsgdGhlIGluZm9ybWF0aW9uIG1vZGVsIHNob3Vs ZCBleHByZXNzIGFuIG9waW5pb24gYXMgdG8gd2hldGhlciBrZXlzIGxvbmdlciB0aGFuDQogNjQg Ynl0ZXMgYXJlIHNhZmUgb3Igbm90LiBJZiB3ZSBjaG9vc2UgdG8gYWRkIHRoYXQgZGlzdGluY3Rp b24gd2UnbGwgbmVlZCB0byBqdXN0aWZ5IHdoeSB3ZSB0aGluayB0aGUga2V5IGhhc2hpbmcgaXMg dW5zYWZlLCBhbmQgSSBkb24ndCB0aGluayB0aGVyZSBpcyBhbiBSRkMgd2UgY2FuIGNpdGUgZm9y IHRoYXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5TbyBnb2luZyBiYWNrIHRvIEp1bGl1c3oncyBsaXN0ZWQgb3B0aW9ucyBpbiB0aGUg b3RoZXIgdGhyZWFkICZsdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX21haWxhcmNoaXZlLmlldGYub3JnX2FyY2hfbXNnX2JhYmVs X1FsdnNQQjl5WUZQVFB3UXhhTGNXSU4zSGwyWSZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZWi1vOV9I VU1lTVRTUWljdmpJZyZhbXA7cj1Mb0d6aEMtOHNjOFNZOFRxNHZyZm9nJmFtcDttPXI0ZEtXMEhO U3JqTlBYZFhJZEpfM2tHYzNYclJJeGRCYWM2MER1YTlGOVEmYW1wO3M9aGN3aTVRRHdHN3dxOTZj RTV2VWJKNkxZSjBtTm42cDBpR3N0UG9za3pPOCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2JhYmVsL1FsdnNQQjl5WUZQVFB3UXhh TGNXSU4zSGwyWTwvYT4mZ3Q7LA0KIEkgd291bGQgYXJndWUgZm9yIG9wdGlvbiAzICZxdW90O2J1 cmVhdWNyYXRpYyZxdW90OyBiZWNhdXNlIGl0IGZvbGxvd3MgdGhlIGRlc2lnbiBwcmluY2lwbGUg JnF1b3Q7VGhlIEJhYmVsIFdHIGRvZXMgbm90IG1ha2Ugc2VjdXJpdHkgZGVjaXNpb25zLCB3ZSBm b2xsb3cgd2hhdCBSRkNzIHRlbGwgdXMmcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5EYXZpZDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBBdWcgMTUsIDIw MTkgYXQgOTo1OCBBTSBTVEFSSywgQkFSQkFSQSBIICZsdDs8YSBocmVmPSJtYWlsdG86YnM3NjUy QGF0dC5jb20iIHRhcmdldD0iX2JsYW5rIj5iczc2NTJAYXR0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyAmZ3Q7IElzIHRoaXMg c3VnZ2VzdGluZyB0aGF0IGl0J3Mgb2sgZm9yIGluZm8tbW9kZWwgdG8gcHJvdmlkZSBiYWJlbC1o bWFjPGJyPg0KJmd0OyAmZ3Q7IHdpdGggYW55IHZhbHVlIGJldHdlZW4gMCBhbmQgNjQgYnl0ZXMg aW4gbGVuZ3RoIGZvciBITUFDLVNIQTI1NiBvcjxicj4NCiZndDsgJmd0OyBiZXR3ZWVuIDAgYW5k IDMyIGJ5dGVzIGluIGxlbmd0aCBmb3IgQmxha2UycyBhbmQgYmFiZWwtaG1hYyBjYW4gYmU8YnI+ DQomZ3Q7ICZndDsgZXhwZWN0ZWQgdG8gemVyby1wYWQ/IE9yIGFyZSB5b3Ugc3RpbGwgZXhwZWN0 aW5nIGluZm8tbW9kZWwgdG8gZG8gdGhlPGJyPg0KJmd0OyAmZ3Q7IHplcm8tcGFkZGluZyBiZWZv cmUgcHJvdmlkaW5nIHRvIGJhYmVsLWhtYWM/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBmb3Jt ZXIuJm5ic3A7IFlvdSBnaXZlIG1lIGFueXRoaW5nIGJldHdlZW4gMCBhbmQgMzIvNjQsIGFuZCBJ IGRlYWwgd2l0aCBpdC48YnI+DQo8YnI+DQpDb29sLiBUaGVuIGZyb20gYSBwdXJlbHkgaW5mby1t b2RlbCBwZXJzcGVjdGl2ZSwgaXQgc291bmRzIGxpa2UgdGhlIGtleS12YWx1ZSBwYXJhbWV0ZXIg bGVuZ3RoIGNvbnN0cmFpbnRzIGFyZTo8YnI+DQo8YnI+DQombmJzcDsgVGhpcyB2YWx1ZSBpcyBv ZiBhIGxlbmd0aCBzdWl0YWJsZSBmb3IgdGhlIGFzc29jaWF0ZWQ8YnI+DQombmJzcDsgYmFiZWwt bWFjLWtleS1hbGdvcml0aG0uJm5ic3A7IElmIHRoZSBhbGdvcml0aG0gaXMgYmFzZWQgb24gdGhl IEhNQUM8YnI+DQombmJzcDsgY29uc3RydWN0aW9uLCB0aGUgbGVuZ3RoIE1VU1QgYmUgYmV0d2Vl biAwIGFuZCB0aGUgYmxvY2sgc2l6ZSBvZiB0aGU8YnI+DQombmJzcDsgdW5kZXJseWluZyBoYXNo IGluY2x1c2l2ZSAod2hlcmUgJnF1b3Q7SE1BQy1TSEEyNTYmcXVvdDsgYmxvY2sgc2l6ZSBpcyA2 NCBieXRlczxicj4NCiZuYnNwOyBhcyBkZXNjcmliZWQgaW4ge3tSRkM0ODY4fX0pLjxicj4NCiZu YnNwOyBJZiB0aGUgYWxnb3JpdGhtIGlzICZxdW90O0JMQUtFMnMmcXVvdDssIHRoZSBsZW5ndGgg TVVTVCBiZSBiZXR3ZWVuIDAgYW5kIDMyIGJ5dGVzPGJyPg0KJm5ic3A7IGluY2x1c2l2ZSwgYXMg ZGVzY3JpYmVkIGluIHt7UkZDNzY5M319Ljxicj4NCjxicj4NCkFueXRoaW5nIGNvbXBseWluZyB3 aXRoIGluZm8tbW9kZWwgd29uJ3Qgc3VwcGx5IGFueXRoaW5nIGxvbmdlciB0aGFuIHRoZSBpZGVu dGlmaWVkIG1heCBsZW5ndGguPGJyPg0KQSBiYWJlbC1obWFjIGltcGxlbWVudGF0aW9uIG1heSBn ZXQgc29tZXRoaW5nIGFzIHNob3J0IGFzIHplcm8gbGVuZ3RoLCBidXQgd2lsbCBiZSBleHBlY3Rl ZCB0byBkZWFsIHdpdGggaXQuIEluZm8tbW9kZWwgZG9lc24ndCBjYXJlIGFuZCBkb2Vzbid0IG5l ZWQgdG8ga25vdyB3aGF0ICZxdW90O2RlYWwgd2l0aCBpdCZxdW90OyBtZWFucy48YnI+DQpGb3Ig SE1BQyBhbmQgQmxha2UycyBhbGdvcml0aG1zLCAmcXVvdDtkZWFsIHdpdGggaXQmcXVvdDsgbWVh bnMgaG1hYy1iYWJlbCB3aWxsIHplcm8tcGFkIHNob3J0ZXIgc3RyaW5ncywgYmVjYXVzZSB0aGF0 J3Mgd2hhdCB0aGUgYWxnb3JpdGhtIFJGQ3Mgc2F5IHRvIGRvIChhbmQgbm90IGJlY2F1c2UgYmFi ZWwtaG1hYyBoYXMgYW55IGV4dHJhIHJlcXVpcmVtZW50cyBnb2luZyBiZXlvbmQgdGhlIGFsZ29y aXRobSBzcGVjcykuPGJyPg0KSW5mby1tb2RlbCB3b24ndCBzZW5kIHN0cmluZ3MgbG9uZ2VyIHRo YW4gdGhlIGluZGljYXRlZCBsZW5ndGguIElmIHRoZXJlIGlzIGEgVUkgdG8gaW5mbyBtb2RlbCB0 aGF0IGFjY2VwdHMgYSBsb25nZXIgc3RyaW5nLCBoYXNoZXMgaXQsIGFuZCB0aGVuIGluZm8tbW9k ZWwgcHJvdmlkZXMgdGhlIGhhc2hlZCB2YWx1ZSwgdGhhdCBpcyB3aGF0IGl0IGlzLiBOZWl0aGVy IGluZm8tbW9kZWwgbm9yIGJhYmVsLWhtYWMgY2FyZSBvciBrbm93IG9yIG5lZWQNCiB0byBrbm93 IGFib3V0IHRoaXMuPGJyPg0KSWYgYSBiYWJlbC1obWFjIGltcGxlbWVudGF0aW9uIGRvZXMgaGF2 ZSBzcGVjaWFsIGhhbmRsaW5nIGZvciBsb25nZXIgc3RyaW5ncywgdGhhdCdzIGZpbmUsIHRvby4g QnV0IGEgdmFsdWUgY29taW5nIGZyb20gaW5mby1tb2RlbCB3aWxsIG5ldmVyIHRyaWdnZXIgdGhp cyBzcGVjaWFsIGNvZGUuPGJyPg0KRG9lcyB0aGF0IHNvdW5kIHJpZ2h0Pzxicj4NCkJhcmJhcmE8 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCmJhYmVsIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpiYWJlbEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJhYmVsQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll dGYub3JnX21haWxtYW5fbGlzdGluZm9fYmFiZWwmYW1wO2Q9RHdNRmFRJmFtcDtjPUxGWVotbzlf SFVNZU1UU1FpY3ZqSWcmYW1wO3I9TG9HemhDLThzYzhTWThUcTR2cmZvZyZhbXA7bT1yNGRLVzBI TlNyak5QWGRYSWRKXzNrR2MzWHJSSXhkQmFjNjBEdWE5RjlRJmFtcDtzPTVoVU5qNi1WZHpLX05x Y1Bfak9Pb1JKdVFfVzM4OHY1WVQ2WmwyUnF4RGcmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iYWJlbDwvYT48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2D09D61DDFA73D4C884805CC7865E6114E277F28GAALPA1MSGUSRBF_-- From nobody Thu Aug 15 17:56: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 F39921200F3 for ; Thu, 15 Aug 2019 17:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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, HTTPS_HTTP_MISMATCH=0.1, 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 vBVPtnD0KoIt for ; Thu, 15 Aug 2019 17:56:48 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 9A754120103 for ; Thu, 15 Aug 2019 17:56:47 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id b29so2919558lfq.1 for ; Thu, 15 Aug 2019 17:56:47 -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=25U0gANr5Bx/49Mqsl3B9PJ7FENS/mULPBrl8jrZags=; b=krJyEb26lZFwzHY66xHII9BXGZSJX+/rr814ApAeqec1A5dwWR9gmpSmH/6EWhXA2f pCHX4WyUmKF2FlKPhUKqg+ArH5MsXwk96q2xhO8VApfyC8SbXODTu4aT6I3+fL1kD1vi 0KwiZGhiSaNS1EnF/z0Y6XeQ+VePAaPz1A8AT2MUn79RHAYR1vgQWuh75F0y66Ephlik fM4FYKgBvHHp+YYFNlWQPWJfBrbWgs0W21Ryr7wGKsbN75tbbXsDLRnAFtNG0590JojX ASl/I/Ss+/5K2QMHvQBTXuOLHM3ex7qs+HmAqGzcmE7FoIIL2BJnp8YFST3sxR26D91s SJ+Q== 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=25U0gANr5Bx/49Mqsl3B9PJ7FENS/mULPBrl8jrZags=; b=MbjEQ2p4/l/Ei6oNORw0RKhUmjnhivPWa+lV2yQZ1QJGtw6k2oCSbLeAXD/kUJ8X/m SLRFLTHZL3P/YWlNdhUnbN0PGDMZNu5TaL6TWbbr8pOuu3GbGpHwGXVTOIoS6Em6EWR1 spTDQ5AHhg/JNw5UTFna2pBll6AOQ5ie6crnPgrmUdyr/QnD3egrcT2OnJHLaQJUKBJX F9453QHQQvhpAXuOzH3qW99Fz5rmPRxHexVJuLo0lbhdX2cZ2RTVRkSYI+dDEP7a/8HI QOb6tDZUB01C8drrT49T3KIWsrff61dKKkxwyEv2V/BatMSDSd1U/FkDU970NzwFPoXe 57LQ== X-Gm-Message-State: APjAAAWvhD+zz7/XrsD6zmlngLxW5spkR6SqnpjazvKlvbUp7Pk6drEq qLYb4RvVQNkojTDovD0bOsNDt1PYGQdRZ7ahRFo= X-Google-Smtp-Source: APXvYqx7RC3GNjyDKT0cTxmLZJX5l9Qu+od3paaCqYwvITji/qbGs89MAojp9q/ef6E2RSapLh2zNhTjBZFlFDp7+eA= X-Received: by 2002:a05:6512:403:: with SMTP id u3mr3839003lfk.10.1565917005680; Thu, 15 Aug 2019 17:56:45 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> <87ftm3u0a6.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269981@GAALPA1MSGUSRBF.ITServices.sbc.com> <87blwrtudx.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E275E65@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E27796E@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E277CFA@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E277F28@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E277F28@GAALPA1MSGUSRBF.ITServices.sbc.com> From: David Schinazi Date: Thu, 15 Aug 2019 17:56:34 -0700 Message-ID: To: "STARK, BARBARA H" Cc: "babel@ietf.org" , Juliusz Chroboczek Content-Type: multipart/alternative; boundary="000000000000df14da059031761b" Archived-At: Subject: Re: [babel] info-model: preparing -09 on github 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, 16 Aug 2019 00:56:52 -0000 --000000000000df14da059031761b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Postel's Law isn't something we should be following in this day and age (further reading: < https://tools.ietf.org/html/draft-iab-protocol-maintenance-03>). I worry that if you add restrictions at the info model layer, the UI layer will preprocess the keys outside of all standards and that could lead to interoperability issues. On Thu, Aug 15, 2019 at 5:04 PM STARK, BARBARA H wrote: > "Be liberal in what you accept, and conservative in what you send" > > To be robust, info-model needs to be conservative in what it sends to a > babel-hmac implementation. And babel-hmac needs to be liberal in what it > accepts. > > > > But if you can get Juliusz to agree to restrictions in babel-hmac, and al= l > the reviewers (because it=E2=80=99s a significant change), I=E2=80=99m fi= ne with that. I do > think it=E2=80=99s dangerous at this point in the review process (unless = there were > comments that could be resolved by such restrictions?). OTOH, it might ma= ke > reviewers happier to see such restrictions. > > Barbara > > > > *From:* David Schinazi > *Sent:* Thursday, August 15, 2019 7:55 PM > *To:* STARK, BARBARA H > *Cc:* babel@ietf.org; Juliusz Chroboczek > *Subject:* Re: [babel] info-model: preparing -09 on github > > > > Why add restrictions to the info model and not to babel-hmac? If we > believe something is insecure shouldn't we ban it even when the info mode= l > isn't being used? > > > > On Thu, Aug 15, 2019 at 4:40 PM STARK, BARBARA H wrote: > > As RFC2104 says: =E2=80=9CKeys longer than L bytes are acceptable but the= extra > length would not significantly increase the function strength.=E2=80=9D S= ince 64 =3D > 2*L for SHA-256, a key longer than 64 is even less likely to increase the > function strength. So key length > 64 provides no added value. But it doe= s > increase complexity for creating the =E2=80=9Creal=E2=80=9D key. Increase= d complexity means > more things can go wrong. > > > > I don=E2=80=99t think we should allow a 1-byte key. My recommendation for= SHA-256 > was MUST be > 8. I found this site: https://www.keylength.com/en/4/ > > which says NIST recommends minimum of 16 bytes for SHA-256 keys. I=E2=80= =99m good > with requiring that, too. It would certainly make us current on best > practice security recommendations. There=E2=80=99s something to be said f= or > following best practices. > > > > I have no idea what to do for Blake2s. I can=E2=80=99t find a minimum key= length > recommendation. But zero-length (unkeyed) usage provides no meaningful > security in the Babel use case. Zero-length is probably the first thing a= n > attacker would try. And they=E2=80=99d be immediately right. That hardly = counts as > a brute force attack. So I=E2=80=99m not comfortable with allowing zero-l= ength in > info-model. > > > > And just to be clear, I=E2=80=99m not suggesting any of these restriction= s go in > babel-hmac. Just info-model. > > Barbara > > > > *From:* David Schinazi > *Sent:* Thursday, August 15, 2019 6:56 PM > *To:* STARK, BARBARA H > *Cc:* babel@ietf.org; Juliusz Chroboczek > *Subject:* Re: [babel] info-model: preparing -09 on github > > > > If we're considering adding restrictions specific to Babel (and/or the > info model), I think we should take a principled approach. What fundament= al > principles are we using to decide these restrictions? If we allow a 1-byt= e > key but disallow a 65-byte key, then the principle we're after is not > improving security? > > > > On Thu, Aug 15, 2019 at 2:46 PM STARK, BARBARA H wrote: > > I disagree. > > > > The HMAC specs (RFC2104) says: > > Applications that use keys longer > > than B [block size] bytes will first hash the key using H and then use > the > > resultant L [hash output size] byte string as the actual key to HMAC. > In any case the > > minimal recommended length for K is L bytes (as the hash output > > length). See section 3 for more information on keys. > > and from section 3 > > The key for HMAC can be of any length (keys longer than B bytes are > > first hashed using H). However, less than L bytes is strongly > > discouraged as it would decrease the security strength of the > > function. Keys longer than L bytes are acceptable but the extra > > length would not significantly increase the function strength. (A > > longer key may be advisable if the randomness of the key is > > considered weak.) > > > > In this language, there is no requirement for applications using HMAC to > accept (or be able to use) keys longer than B bytes. The two statements d= o > say what must happen **if** a key longer than B bytes is provided. But if > Babel wants to restrict keys to no more than B bytes, that is well within > Babel=E2=80=99s purview to do so. RFC2106 very clearly tells applications= get to > decide what to use. > > > > The other thing I get from this, though, is that it=E2=80=99s recommended= to have > at least L bytes for an HMAC key (L =3D 32 for SHA-256). I think we shoul= d > reflect this recommendation. We could do it either with a =E2=80=9CSHOULD= =E2=80=9D or > =E2=80=9CMUST=E2=80=9D be at least the output hash length (not set the mi= nimum at 0). I see > no reason not to upgrade that to a MUST for Babel, if we want. [It=E2=80= =99s always > ok to be stricter than a referenced spec (e.g., change SHOULD to MUST) = =E2=80=93 > it=E2=80=99s just not ok to do or allow something that violates a require= ment from > the spec (e.g., change MUST to SHOULD).] I think at least a MUST be at > least 8 bytes=E2=80=9D with a =E2=80=9CSHOULD be at least the output hash= length=E2=80=9D would be > good for HMAC. It=E2=80=99s also ok for the information model to be stric= ter than > the babel-hmac implementation. > > > > Blake2s does specifically allow zero-length keys =E2=80=93 though I don= =E2=80=99t know how > advisable that is in a Babel usage scenario. I don=E2=80=99t know when ke= y length > of 0 is useful. But there is definitely nothing that prevents us from bei= ng > stricter, if we wanted to insist on a key longer than 0. Again, this > strictness can be in info-model only and doesn=E2=80=99t have to be refle= cted in > babel-hmac. > > > > I do need some maximum size on the parameter (independent of key > algorithm) =E2=80=93 so it won=E2=80=99t be unlimited length, anyway. I= =E2=80=99m thinking 128 > bytes as an absolute upper limit at this time. > > Barbara > > > > According to RFC 7693, Blake2s keys must be of length kk where 0 <=3D kk = <=3D > 32. So having the info model dictate that keys MUST follow that is > perfectly reasonable to me. > > > > However, according to RFC 6234, HMAC-SHA-256 allows all key lengths kk > where 0 <=3D kk. I don't think the information model should express an > opinion as to whether keys longer than 64 bytes are safe or not. If we > choose to add that distinction we'll need to justify why we think the key > hashing is unsafe, and I don't think there is an RFC we can cite for that= . > > > > So going back to Juliusz's listed options in the other thread < > https://mailarchive.ietf.org/arch/msg/babel/QlvsPB9yYFPTPwQxaLcWIN3Hl2Y > >, > I would argue for option 3 "bureaucratic" because it follows the design > principle "The Babel WG does not make security decisions, we follow what > RFCs tell us". > > > > David > > > > On Thu, Aug 15, 2019 at 9:58 AM STARK, BARBARA H wrote: > > > > Is this suggesting that it's ok for info-model to provide babel-hmac > > > with any value between 0 and 64 bytes in length for HMAC-SHA256 or > > > between 0 and 32 bytes in length for Blake2s and babel-hmac can be > > > expected to zero-pad? Or are you still expecting info-model to do the > > > zero-padding before providing to babel-hmac? > > > > The former. You give me anything between 0 and 32/64, and I deal with > it. > > Cool. Then from a purely info-model perspective, it sounds like the > key-value parameter length constraints are: > > This value is of a length suitable for the associated > babel-mac-key-algorithm. If the algorithm is based on the HMAC > construction, the length MUST be between 0 and the block size of the > underlying hash inclusive (where "HMAC-SHA256" block size is 64 bytes > as described in {{RFC4868}}). > If the algorithm is "BLAKE2s", the length MUST be between 0 and 32 byte= s > inclusive, as described in {{RFC7693}}. > > Anything complying with info-model won't supply anything longer than the > identified max length. > A babel-hmac implementation may get something as short as zero length, bu= t > will be expected to deal with it. Info-model doesn't care and doesn't nee= d > to know what "deal with it" means. > For HMAC and Blake2s algorithms, "deal with it" means hmac-babel will > zero-pad shorter strings, because that's what the algorithm RFCs say to d= o > (and not because babel-hmac has any extra requirements going beyond the > algorithm specs). > Info-model won't send strings longer than the indicated length. If there > is a UI to info model that accepts a longer string, hashes it, and then > info-model provides the hashed value, that is what it is. Neither > info-model nor babel-hmac care or know or need to know about this. > If a babel-hmac implementation does have special handling for longer > strings, that's fine, too. But a value coming from info-model will never > trigger this special code. > Does that sound right? > Barbara > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > > > --000000000000df14da059031761b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Postel's Law isn't something we should be followin= g in this day and age (further reading: <https://tools.ietf.org/html/draf= t-iab-protocol-maintenance-03>).

I worry that if = you add restrictions at the info model layer, the UI layer will preprocess = the keys outside of all standards and that could lead to interoperability i= ssues.

On Thu, Aug 15, 2019 at 5:04 PM STARK, BARBARA H <bs7652@att.com> wrote:

"Be liberal in what you accept, and conservativ= e in what you send"

To be robust, info-model needs to be conservative in= what it sends to a babel-hmac implementation. And babel-hmac needs to be l= iberal in what it accepts.

=C2=A0

But if you can get Juliusz to agree to restrictions = in babel-hmac, and all the reviewers (because it=E2=80=99s a significant ch= ange), I=E2=80=99m fine with that. I do think it=E2=80=99s dangerous at thi= s point in the review process (unless there were comments that could be resolved by such restrictions?). OTOH, it might make reviewe= rs happier to see such restrictions.

Barbara

=C2=A0

From: David Schinazi <dschinazi.ietf@gmail.com> =
Sent: Thursday, August 15, 2019 7:55 PM
To: STARK, BARBARA H <bs7652@att.com>
Cc: babel@ietf.o= rg; Juliusz Chroboczek <jch@irif.fr>
Subject: Re: [babel] info-model: preparing -09 on github

=C2=A0

Why add restrictions to the info model and not to ba= bel-hmac? If we believe something is insecure shouldn't we ban it even = when the info model isn't being used?

=C2=A0

On Thu, Aug 15, 2019 at 4:40 PM STARK, BARBARA H <= ;bs7652@att.com>= wrote:

As RFC2104 says: =E2=80=9CKeys longer than L bytes a= re acceptable but the extra length would not significantly increase the fun= ction strength.=E2=80=9D Since 64 =3D 2*L for SHA-256, a key longer than 64 is even less likely to increase the function strength. So key leng= th > 64 provides no added value. But it does increase complexity for cre= ating the =E2=80=9Creal=E2=80=9D key. Increased complexity means more thing= s can go wrong.

=C2=A0

I don=E2=80=99t think we should allow a 1-byte key. = My recommendation for SHA-256 was MUST be > 8. I found this site: https://www.keylength.com/en/4/ which says NIST recommends minimum of 1= 6 bytes for SHA-256 keys. I=E2=80=99m good with requiring that, too. It wou= ld certainly make us current on best practice security recommendations. The= re=E2=80=99s something to be said for following best practices.

=C2=A0

I have no idea what to do for Blake2s. I can=E2=80= =99t find a minimum key length recommendation. But zero-length (unkeyed) us= age provides no meaningful security in the Babel use case. Zero-length is probably the first thing an attacker would try. And they=E2=80=99d be i= mmediately right. That hardly counts as a brute force attack. So I=E2=80=99= m not comfortable with allowing zero-length in info-model.

=C2=A0

And just to be clear, I=E2=80=99m not suggesting any= of these restrictions go in babel-hmac. Just info-model.

Barbara

=C2=A0

From: David Schinazi <dschinazi.ietf@gmail.com>
Sent: Thursday, August 15, 2019 6:56 PM
To: STARK, BARBARA H <bs7652@att.com>
Cc: babel@ietf.o= rg; Juliusz Chroboczek <jch@irif.fr>
Subject: Re: [babel] info-model: preparing -09 on github

=C2=A0

If we're considering adding restrictions specifi= c to Babel (and/or the info model), I think we should take a principled app= roach. What fundamental principles are we using to decide these restrictions? If we allow a 1-byte key but disallow a 65-byte key, t= hen the principle we're after is not improving security?<= /p>

=C2=A0

On Thu, Aug 15, 2019 at 2:46 PM STARK, BARBARA H <= ;bs7652@att.com>= wrote:

I disagree.

=C2=A0

The HMAC specs (RFC2104) says:

=C2=A0=C2=A0 Applications that use keys longer=

=C2=A0=C2=A0 than B [block s= ize] bytes will first hash the key using H and then use the=

=C2=A0=C2=A0 resultant L [hash ou= tput size] b= yte string as the actual key to HMAC. In any case the<= /p>

=C2=A0=C2=A0 minimal recommended length for K is L bytes (as= the hash output

=C2=A0=C2=A0 length). See section 3 for more information on = keys.

and from section 3 

=C2=A0=C2=A0=C2=A0The key for HMAC can be of any length (keys longer t=
han B bytes are
=C2=A0=C2=A0 first hashed using H).=C2=A0 However, less than L bytes i=
s strongly
=C2=A0=C2=A0 discouraged as it would decrease the security strength of=
 the
=C2=A0=C2=A0 function.=C2=A0 Keys longer than L bytes are acceptable b=
ut the extra
=C2=A0=C2=A0 length would not significantly increase the function stre=
ngth. (A
=C2=A0=C2=A0 longer key may be advisable if the randomness of the key =
is
=C2=A0=C2=A0 considered weak.)

=C2=A0

In this language, there is no requirement for applic= ations using HMAC to accept (or be able to use) keys longer than B bytes. T= he two statements do say what must happen *if* a key longer than B bytes is provided. But if Babel wants to restrict keys= to no more than B bytes, that is well within Babel=E2=80=99s purview to do= so. RFC2106 very clearly tells applications get to decide what to use.<= /u>

=C2=A0

The other thing I get from this, though, is that it= =E2=80=99s recommended to have at least L bytes for an HMAC key (L =3D 32 f= or SHA-256). I think we should reflect this recommendation. We could do it either with a =E2=80=9CSHOULD=E2=80=9D or =E2=80=9CMUST=E2=80= =9D be at least the output hash length (not set the minimum at 0). I see no= reason not to upgrade that to a MUST for Babel, if we want. [It=E2=80=99s = always ok to be stricter than a referenced spec (e.g., change SHOULD to MUS= T) =E2=80=93 it=E2=80=99s just not ok to do or allow something that violates = a requirement from the spec (e.g., change MUST to SHOULD).] I think at leas= t a MUST be at least 8 bytes=E2=80=9D with a =E2=80=9CSHOULD be at least th= e output hash length=E2=80=9D would be good for HMAC. It=E2=80=99s also ok = for the information model to be stricter than the babel-hmac implementation.

=C2=A0

Blake2s does specifically allow zero-length keys =E2= =80=93 though I don=E2=80=99t know how advisable that is in a Babel usage s= cenario. I don=E2=80=99t know when key length of 0 is useful. But there is definitely nothing that prevents us from being stricter, if we wanted to i= nsist on a key longer than 0. Again, this strictness can be in info-model o= nly and doesn=E2=80=99t have to be reflected in babel-hmac.

=C2=A0

I do need some maximum size on the parameter (indepe= ndent of key algorithm) =E2=80=93 so it won=E2=80=99t be unlimited length, = anyway. I=E2=80=99m thinking 128 bytes as an absolute upper limit at this time.

Barbara

=C2=A0

According to RFC 7693, Blake2s keys must be of lengt= h kk where=C2=A00 <=3D kk <=3D 32. So having the info model dictate t= hat keys MUST follow that is perfectly reasonable to me.

=C2=A0

However, according to RFC 6234, HMAC-SHA-256 allows = all key lengths kk where 0 <=3D kk. I don't think the information mo= del should express an opinion as to whether keys longer than 64 bytes are safe or not. If we choose to add that distinction we'll n= eed to justify why we think the key hashing is unsafe, and I don't thin= k there is an RFC we can cite for that.

=C2=A0

So going back to Juliusz's listed options in the= other thread <https://mailarchiv= e.ietf.org/arch/msg/babel/QlvsPB9yYFPTPwQxaLcWIN3Hl2Y>, I would argue for option 3 "bureaucratic" because it follows the= design principle "The Babel WG does not make security decisions, we f= ollow what RFCs tell us".

=C2=A0

David

=C2=A0

On Thu, Aug 15, 2019 at 9:58 AM STARK, BARBARA H <= ;bs7652@att.com>= wrote:

> > Is this suggesting that it's ok for in= fo-model to provide babel-hmac
> > with any value between 0 and 64 bytes in length for HMAC-SHA256 o= r
> > between 0 and 32 bytes in length for Blake2s and babel-hmac can b= e
> > expected to zero-pad? Or are you still expecting info-model to do= the
> > zero-padding before providing to babel-hmac?
>
> The former.=C2=A0 You give me anything between 0 and 32/64, and I deal= with it.

Cool. Then from a purely info-model perspective, it sounds like the key-val= ue parameter length constraints are:

=C2=A0 This value is of a length suitable for the associated
=C2=A0 babel-mac-key-algorithm.=C2=A0 If the algorithm is based on the HMAC=
=C2=A0 construction, the length MUST be between 0 and the block size of the=
=C2=A0 underlying hash inclusive (where "HMAC-SHA256" block size = is 64 bytes
=C2=A0 as described in {{RFC4868}}).
=C2=A0 If the algorithm is "BLAKE2s", the length MUST be between = 0 and 32 bytes
=C2=A0 inclusive, as described in {{RFC7693}}.

Anything complying with info-model won't supply anything longer than th= e identified max length.
A babel-hmac implementation may get something as short as zero length, but = will be expected to deal with it. Info-model doesn't care and doesn'= ;t need to know what "deal with it" means.
For HMAC and Blake2s algorithms, "deal with it" means hmac-babel = will zero-pad shorter strings, because that's what the algorithm RFCs s= ay to do (and not because babel-hmac has any extra requirements going beyon= d the algorithm specs).
Info-model won't send strings longer than the indicated length. If ther= e is a UI to info model that accepts a longer string, hashes it, and then i= nfo-model provides the hashed value, that is what it is. Neither info-model= nor babel-hmac care or know or need to know about this.
If a babel-hmac implementation does have special handling for longer string= s, that's fine, too. But a value coming from info-model will never trig= ger this special code.
Does that sound right?
Barbara

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

--000000000000df14da059031761b-- From nobody Fri Aug 16 07:33:32 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 5E73C1207FE for ; Fri, 16 Aug 2019 07:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_Om-vB-zDTz for ; Fri, 16 Aug 2019 07:33:26 -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 A94401201DE for ; Fri, 16 Aug 2019 07:33:26 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7GESWHQ029914; Fri, 16 Aug 2019 10:33:22 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 2udwywrrkp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Aug 2019 10:33:21 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7GEXKdm014759; Fri, 16 Aug 2019 10:33:21 -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 x7GEXC8W014457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Aug 2019 10:33:12 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 0AB484009E72; Fri, 16 Aug 2019 14:33:12 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30484.vci.att.com (Service) with ESMTPS id D273E4009E73; Fri, 16 Aug 2019 14:33:11 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.177]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0439.000; Fri, 16 Aug 2019 10:33:11 -0400 From: "STARK, BARBARA H" To: "'David Schinazi'" CC: "'Juliusz Chroboczek'" , "'babel@ietf.org'" Thread-Topic: [babel] info-model: preparing -09 on github Thread-Index: AdVSswKr0W4Y1vOsQfS00DtIY7BoYgAM83CAAAdXLCD//+jbAP//C3uggAKFBgCAAC70cIAAC7qAgABBMvD//88pgIAAQcZw///PbgD//3t3MA== Date: Fri, 16 Aug 2019 14:33:10 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E279084@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> <87ftm3u0a6.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269981@GAALPA1MSGUSRBF.ITServices.sbc.com> <87blwrtudx.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E275E65@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E27796E@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E277CFA@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E277F28@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.216.153] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114E279084GAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-16_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908160152 Archived-At: Subject: Re: [babel] info-model: preparing -09 on github 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, 16 Aug 2019 14:33:31 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114E279084GAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpbmtpbmcgb24gdGhpcyBvdmVybmlnaHQuLi4NCkkgdGhpbmsgbWluaW11bSBrZXkgbGVuZ3Ro cyBhcmUgbmVlZGVkLg0KDQogICogICBJZiBpbmZvLW1vZGVsIG1pbiA+PSBiYWJlbC1obWFjIG1p biAod2hpY2ggaW5jbHVkZXMgdGhlIGNhc2Ugd2hlcmUgYmFiZWwtaG1hYyBtaW4gaXMgemVybyks IHRoZXJlIGlzIG5vIHByZS1wcm9jZXNzaW5nIHRoYXQgaGFwcGVucyBhdCB0aGUgVUkgLyBpbmZv LW1vZGVsIGxheWVyIGFzIGEgcmVzdWx0LiBFbnRlcmluZyB0aGUgc2FtZSB2YWx1ZSBkaXJlY3Rs eSB0byBiYWJlbC1obWFjIHRoYXQgaXMgYWxsb3dlZCBhbmQgcHJvdmlkZWQgdmlhIGluZm8tbW9k ZWwgd2lsbCBwcm9kdWNlIHRoZSBzYW1lIHJlc3VsdHMuDQogICogICBJZiBpbmZvLW1vZGVsIG1p biA8IGJhYmVsLWhtYWMgbWluICh3aGljaCBpbmNsdWRlcyB0aGUgY2FzZSB3aGVyZSBiYWJlbC1o bWFjIHNldHMgYSBtaW4gYnV0IGluZm8tbW9kZWwgZG9lc27igJl0KSwgdGhlbiB3ZeKAmWxsIGdl dCBlcnJvcnMgZnJvbSBzaG9ydCB2YWx1ZXMgc2VudCB2aWEgaW5mby1tb2RlbC4gVGhpcyBpcyB1 bmRlc2lyYWJsZS4gVXBzdHJlYW0gcmVzdHJpY3Rpb25zIGFsd2F5cyBuZWVkIHRvIGJlIGdyZWF0 ZXIgdGhhbiBvciBlcXVhbCB0byBkb3duc3RyZWFtIG1pbmltdW0gcmVzdHJpY3Rpb25zLg0KDQpU aGVyZWZvcmUsIEkgd291bGQgbGlrZSB0byBoYXZlIG1pbmltdW1zIHNwZWNpZmllZCBpbiBpbmZv LW1vZGVsLiBJZiB3ZSBoYXZlIHRoZW0gaW4gYmFiZWwtaG1hYywgdGhhdOKAmXMgb2ssIGJ1dCB0 aGVuIEkgbmVlZCB0byBtYWtlIHN1cmUgaW5mby1tb2RlbCBtaW5zID49IGJhYmVsLWhtYWMgbWlu czsgYnV0IGlmIGJhYmVsLWhtYWMgaGFzIG5vIG1pbmltdW1zLCBpdCB3b27igJl0IGNhdXNlIHBy b2JsZW1zLg0KDQpXZSBhbHNvIG5lZWQgdG8gc2F5IHNvbWV0aGluZyBhYm91dCB1cHBlciBsaW1p dHMuIEkgdW5kZXJzdGFuZCB3aGF0IHlvdeKAmXJlIHNheWluZyBhYm91dCBub3Qgd2FudGluZyBw cmUtcHJvY2Vzc2luZyBhdCB0aGUgVUkgdGhhdCBtYXkgb3IgbWF5IG5vdCBmb2xsb3cgc3RhbmRh cmRzLiBJIHRoaW5rIHRoYXTigJlzIHJlYXNvbmFibGUuIEkgY2FuIGluY2x1ZGUgVUkgYWR2aWNl IHRvIGV4cGxhaW4gdGhpcyB3b3VsZCBiZSBhIGJhZCBpZGVhLiBJbmZvLW1vZGVsIGNhbuKAmXQg bm9ybWF0aXZlbHkgcmVxdWlyZSBhIGZyb250LWVuZGluZyBVSSB0byBkbyBvciBub3QgZG8gc29t ZXRoaW5nLCBidXQgYWR2aWNlIGlzIG9rLg0KQmxha2VzMnMgZGVmaW5lcyBubyBtZWNoYW5pc20g Zm9yIHByb2Nlc3Npbmcga2V5cyBsb25nZXIgdGhhbiAzMi4gVGhpcyBpcyBhIGhhcmQgbGltaXQg cGVyIHRoZSBSRkMuIEkgd291bGQgZXhwZWN0IGEgYmFiZWwtaG1hYyBpbXBsZW1lbnRhdGlvbiB0 byBlbmZvcmNlIHRoaXMgbGltaXQsIGltcGxpY2l0bHkgKGJlY2F1c2UgUkZDNzY5MyBzYXlzIHNv KS4gSSBuZWVkIHRvIGVuZm9yY2UgaXQgaW4gaW5mby1tb2RlbCwgdG9vLCBvciBleHBlY3QgZXJy b3JzLg0KRm9yIEhNQUMsIGtleXMgbG9uZ2VyIHRoYW4gdGhlIGJsb2NrIHNpemUgZG9u4oCZdCBh ZGQgdmFsdWUvc2VjdXJpdHkuIFNvIGlmIGluZm8tbW9kZWwgcmVzdHJpY3RzIHNpemUsIGJ1dCBh bHNvIHN0YXRlcyB0aGF0IGFueSBVSSBmZWVkaW5nIGl0IGlzIGV4cGVjdGVkIGxpa2V3aXNlIHRv IHJlc3RyaWN0IHNpemUsIHRoZW4gdGhlcmUgd2lsbCBiZSBubyBwcmVwcm9jZXNzaW5nIGluIHRo ZSBzZW5zZSBvZiBoYXNoaW5nIGxvbmdlciBzdHJpbmdzLiBJZiBiYWJlbC1obWFjIGFsbG93cyBs b25nZXIga2V5cyAoYW5kIGhhc2hlcyB0aGVtKSB0aGVyZeKAmXMgbm8gcHJvYmxlbS4gQSB1c2Vy IHdhbnRpbmcgdG8gdXNlIGVpdGhlciBhIFVJIGZyb250LWVuZGluZyBhbiBpbmZvLW1vZGVsIG9y IGVudGVyIHNvbWV0aGluZyBkaXJlY3RseSBpbnRvIGJhYmVsLWhtYWMgd2lsbCBzaW1wbHkgdW5k ZXJzdGFuZCB0aGV5IGNhbuKAmXQgdXNlIHNvbWV0aGluZyBsb25nZXIgKHdoaWNoIHVzZXJzIGRv buKAmXQgdGVuZCB0byBoYXZlIGEgcHJvYmxlbSB3aXRoKS4NCg0KQnV0IGlmIHdlIGFyZSBjb25z Y2lvdXNseSBjb25zaWRlcmluZyBhIHVzZXIgbWlnaHQgZW50ZXIga2V5cyBkaXJlY3RseSB0byBi YWJlbC1obWFjIG9yIHZpYSBhIFVJIGZyb250LWVuZGluZyBhbiBpbmZvLW1vZGVsLCB0aGVuIGlu Zm8tbW9kZWwgYWxzbyBuZWVkcyB0byBwcm92aWRlIGFkdmljZSBhYm91dCB0aGUgQVNDSUkgdnMu IFVURi1uIGlucHV0IHN0cmluZyBpbnRlcnByZXRhdGlvbi4gVGhpcyB3YXMgYW4gaXRlbSBvZiBk aXNjdXNzaW9uIGluIEphbnVhcnkuIElmIHRoZSBpbmZvLW1vZGVsIFVJIGFuZCBiYWJlbC1obWFj IFVJIGludGVycHJldCB1c2VyIGlucHV0IGRpZmZlcmVudGx5LCB0aGVyZSB3aWxsIGJlIGEgcHJv YmxlbS4NCg0KU28uLi4NCllvdSBhbmQgSnVsaXVzeiBuZWVkIHRvIGZpZ3VyZSBvdXQgd2hhdCBv ciB3aGV0aGVyIHlvdSB3YW50IGJhYmVsLWhtYWMgdG8gaW1wb3NlIHJlc3RyaWN0aW9ucy4gRm9y IGluZm8tbW9kZWwsIG15IG5ldyBsYXRlc3Qgc3VnZ2VzdGlvbiBpczoNCg0KICBUaGlzIHZhbHVl IGlzIG9mIGEgbGVuZ3RoIHN1aXRhYmxlIGZvciB0aGUgYXNzb2NpYXRlZA0KICBiYWJlbC1tYWMt a2V5LWFsZ29yaXRobS4gVGhlIGxlbmd0aCBTSE9VTEQgbWVldCBtaW5pbXVtIGxlbmd0aA0KICBy ZWNvbW1lbmRhdGlvbnMgZm9yIGFjaGlldmluZyByZWFzb25hYmxlIHByb3RlY3Rpb24gYWdhaW5z dCBicnV0ZSBmb3JjZQ0KICBhdHRhY2tzLiBJZiB0aGUgYWxnb3JpdGhtIGlzIGJhc2VkIG9uIHRo ZSBITUFDDQogIGNvbnN0cnVjdGlvbiwgdGhlIGxlbmd0aCBTSE9VTEQgYmUgZ3JlYXRlciB0aGFu IG9yIGVxdWFsIHRvIDE2IGJ5dGVzIGFuZCBTSE9VTEQNCiBiZSBsZXNzIHRoYW4gb3IgZXF1YWwg dG8gdGhlIGJsb2NrIHNpemUgb2YgdGhlDQogIHVuZGVybHlpbmcgaGFzaCAod2hlcmUgIkhNQUMt U0hBMjU2IiBibG9jayBzaXplIGlzIDY0IGJ5dGVzDQogIGFzIGRlc2NyaWJlZCBpbiB7e1JGQzQ4 Njh9fSkuDQogIElmIHRoZSBhbGdvcml0aG0gaXMgIkJMQUtFMnMiLCB0aGUgbGVuZ3RoIE1VU1Qg YmUgbGVzcyB0aGFuIG9yIGVxdWFsIHRvDQogMzIgYnl0ZXMsIGFzIGRlc2NyaWJlZCBpbiB7e1JG Qzc2OTN9fSwgYW5kIFNIT1VMRCBiZSBncmVhdGVyIHRoYW4NCiBvciBlcXVhbCB0byAxNiBieXRl cy4NCiAgSWYgdmFsdWVzIGFyZSBwcm92aWRlZCB0aHJvdWdoIHN0cmluZ3MgaW5wdXQgdG8gYSB1 c2VyIGludGVyZmFjZSAoVUkpLCBJdCBpcyBleHBlY3RlZA0KICB0aGVzZSBpbnB1dCBzdHJpbmdz IHdpbGwgYmUgY29udmVydGVkIHRvIEFTQ0lJIHZhbHVlcyBvciBhbGxvdyB0aGUgdXNlcg0KICB0 byBleHBsaWNpdGx5IGlkZW50aWZ5IHRoZSBjb252ZXJzaW9uIHRvIHVzZSAod2l0aCBBU0NJSSBi ZWluZyBhbiBvcHRpb24pLg0KICBBIFVJIGlzIGV4cGVjdGVkIHRvIGltcG9zZSBhbnkgaW1wbGVt ZW50ZWQgbGVuZ3RoIHJlc3RyaWN0aW9ucywgc28gbm8NCiBhZGRpdGlvbmFsIHByb2Nlc3Npbmcg aXMgZG9uZSB0byB1c2VyIGlucHV0IHRvIG1ha2UgaXQgbG9uZ2VyIG9yIHNob3J0ZXIuDQoNCkJh cmJhcmENCg0KUG9zdGVsJ3MgTGF3IGlzbid0IHNvbWV0aGluZyB3ZSBzaG91bGQgYmUgZm9sbG93 aW5nIGluIHRoaXMgZGF5IGFuZCBhZ2UgKGZ1cnRoZXIgcmVhZGluZzogPGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pYWItcHJvdG9jb2wtbWFpbnRlbmFuY2UtMDM8aHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9y Z19odG1sX2RyYWZ0LTJEaWFiLTJEcHJvdG9jb2wtMkRtYWludGVuYW5jZS0yRDAzJmQ9RHdNRmFR JmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPUxvR3poQy04c2M4U1k4VHE0dnJmb2cmbT02UDRv YVpBV19MSl80aFZ6OWhkQ2xXb05jenRuZUlDR2hUWV9zaFlrRlVvJnM9eXowQ0hRMU9yUnpJbWhr a1VsRHRlRXNuS2Jwbkc1QVBPSHJWY0xKLVFqWSZlPT4+KS4NCg0KSSB3b3JyeSB0aGF0IGlmIHlv dSBhZGQgcmVzdHJpY3Rpb25zIGF0IHRoZSBpbmZvIG1vZGVsIGxheWVyLCB0aGUgVUkgbGF5ZXIg d2lsbCBwcmVwcm9jZXNzIHRoZSBrZXlzIG91dHNpZGUgb2YgYWxsIHN0YW5kYXJkcyBhbmQgdGhh dCBjb3VsZCBsZWFkIHRvIGludGVyb3BlcmFiaWxpdHkgaXNzdWVzLg0KDQpPbiBUaHUsIEF1ZyAx NSwgMjAxOSBhdCA1OjA0IFBNIFNUQVJLLCBCQVJCQVJBIEggPGJzNzY1MkBhdHQuY29tPG1haWx0 bzpiczc2NTJAYXR0LmNvbT4+IHdyb3RlOg0KIkJlIGxpYmVyYWwgaW4gd2hhdCB5b3UgYWNjZXB0 LCBhbmQgY29uc2VydmF0aXZlIGluIHdoYXQgeW91IHNlbmQiDQpUbyBiZSByb2J1c3QsIGluZm8t bW9kZWwgbmVlZHMgdG8gYmUgY29uc2VydmF0aXZlIGluIHdoYXQgaXQgc2VuZHMgdG8gYSBiYWJl bC1obWFjIGltcGxlbWVudGF0aW9uLiBBbmQgYmFiZWwtaG1hYyBuZWVkcyB0byBiZSBsaWJlcmFs IGluIHdoYXQgaXQgYWNjZXB0cy4NCg0KQnV0IGlmIHlvdSBjYW4gZ2V0IEp1bGl1c3ogdG8gYWdy ZWUgdG8gcmVzdHJpY3Rpb25zIGluIGJhYmVsLWhtYWMsIGFuZCBhbGwgdGhlIHJldmlld2VycyAo YmVjYXVzZSBpdOKAmXMgYSBzaWduaWZpY2FudCBjaGFuZ2UpLCBJ4oCZbSBmaW5lIHdpdGggdGhh dC4gSSBkbyB0aGluayBpdOKAmXMgZGFuZ2Vyb3VzIGF0IHRoaXMgcG9pbnQgaW4gdGhlIHJldmll dyBwcm9jZXNzICh1bmxlc3MgdGhlcmUgd2VyZSBjb21tZW50cyB0aGF0IGNvdWxkIGJlIHJlc29s dmVkIGJ5IHN1Y2ggcmVzdHJpY3Rpb25zPykuIE9UT0gsIGl0IG1pZ2h0IG1ha2UgcmV2aWV3ZXJz IGhhcHBpZXIgdG8gc2VlIHN1Y2ggcmVzdHJpY3Rpb25zLg0KQmFyYmFyYQ0KDQpGcm9tOiBEYXZp ZCBTY2hpbmF6aSA8ZHNjaGluYXppLmlldGZAZ21haWwuY29tPG1haWx0bzpkc2NoaW5hemkuaWV0 ZkBnbWFpbC5jb20+Pg0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxNSwgMjAxOSA3OjU1IFBNDQpU bzogU1RBUkssIEJBUkJBUkEgSCA8YnM3NjUyQGF0dC5jb208bWFpbHRvOmJzNzY1MkBhdHQuY29t Pj4NCkNjOiBiYWJlbEBpZXRmLm9yZzxtYWlsdG86YmFiZWxAaWV0Zi5vcmc+OyBKdWxpdXN6IENo cm9ib2N6ZWsgPGpjaEBpcmlmLmZyPG1haWx0bzpqY2hAaXJpZi5mcj4+DQpTdWJqZWN0OiBSZTog W2JhYmVsXSBpbmZvLW1vZGVsOiBwcmVwYXJpbmcgLTA5IG9uIGdpdGh1Yg0KDQpXaHkgYWRkIHJl c3RyaWN0aW9ucyB0byB0aGUgaW5mbyBtb2RlbCBhbmQgbm90IHRvIGJhYmVsLWhtYWM/IElmIHdl IGJlbGlldmUgc29tZXRoaW5nIGlzIGluc2VjdXJlIHNob3VsZG4ndCB3ZSBiYW4gaXQgZXZlbiB3 aGVuIHRoZSBpbmZvIG1vZGVsIGlzbid0IGJlaW5nIHVzZWQ/DQoNCk9uIFRodSwgQXVnIDE1LCAy MDE5IGF0IDQ6NDAgUE0gU1RBUkssIEJBUkJBUkEgSCA8YnM3NjUyQGF0dC5jb208bWFpbHRvOmJz NzY1MkBhdHQuY29tPj4gd3JvdGU6DQpBcyBSRkMyMTA0IHNheXM6IOKAnEtleXMgbG9uZ2VyIHRo YW4gTCBieXRlcyBhcmUgYWNjZXB0YWJsZSBidXQgdGhlIGV4dHJhIGxlbmd0aCB3b3VsZCBub3Qg c2lnbmlmaWNhbnRseSBpbmNyZWFzZSB0aGUgZnVuY3Rpb24gc3RyZW5ndGgu4oCdIFNpbmNlIDY0 ID0gMipMIGZvciBTSEEtMjU2LCBhIGtleSBsb25nZXIgdGhhbiA2NCBpcyBldmVuIGxlc3MgbGlr ZWx5IHRvIGluY3JlYXNlIHRoZSBmdW5jdGlvbiBzdHJlbmd0aC4gU28ga2V5IGxlbmd0aCA+IDY0 IHByb3ZpZGVzIG5vIGFkZGVkIHZhbHVlLiBCdXQgaXQgZG9lcyBpbmNyZWFzZSBjb21wbGV4aXR5 IGZvciBjcmVhdGluZyB0aGUg4oCccmVhbOKAnSBrZXkuIEluY3JlYXNlZCBjb21wbGV4aXR5IG1l YW5zIG1vcmUgdGhpbmdzIGNhbiBnbyB3cm9uZy4NCg0KSSBkb27igJl0IHRoaW5rIHdlIHNob3Vs ZCBhbGxvdyBhIDEtYnl0ZSBrZXkuIE15IHJlY29tbWVuZGF0aW9uIGZvciBTSEEtMjU2IHdhcyBN VVNUIGJlID4gOC4gSSBmb3VuZCB0aGlzIHNpdGU6IGh0dHBzOi8vd3d3LmtleWxlbmd0aC5jb20v ZW4vNC88aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X193d3cua2V5bGVuZ3RoLmNvbV9lbl80XyZkPUR3TUZhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3Zq SWcmcj1Mb0d6aEMtOHNjOFNZOFRxNHZyZm9nJm09Q1ZuV1VXbVhpdjJlR2xVdklEcnNieHF2bmtR MENKZXRaSjNveno5U0lqcyZzPWV6enZ4elpxeWkyM2t6RXZCZGhWdUwyU2ZuaktNc2E3V2N2ZTh5 c1piYXMmZT0+IHdoaWNoIHNheXMgTklTVCByZWNvbW1lbmRzIG1pbmltdW0gb2YgMTYgYnl0ZXMg Zm9yIFNIQS0yNTYga2V5cy4gSeKAmW0gZ29vZCB3aXRoIHJlcXVpcmluZyB0aGF0LCB0b28uIEl0 IHdvdWxkIGNlcnRhaW5seSBtYWtlIHVzIGN1cnJlbnQgb24gYmVzdCBwcmFjdGljZSBzZWN1cml0 eSByZWNvbW1lbmRhdGlvbnMuIFRoZXJl4oCZcyBzb21ldGhpbmcgdG8gYmUgc2FpZCBmb3IgZm9s bG93aW5nIGJlc3QgcHJhY3RpY2VzLg0KDQpJIGhhdmUgbm8gaWRlYSB3aGF0IHRvIGRvIGZvciBC bGFrZTJzLiBJIGNhbuKAmXQgZmluZCBhIG1pbmltdW0ga2V5IGxlbmd0aCByZWNvbW1lbmRhdGlv bi4gQnV0IHplcm8tbGVuZ3RoICh1bmtleWVkKSB1c2FnZSBwcm92aWRlcyBubyBtZWFuaW5nZnVs IHNlY3VyaXR5IGluIHRoZSBCYWJlbCB1c2UgY2FzZS4gWmVyby1sZW5ndGggaXMgcHJvYmFibHkg dGhlIGZpcnN0IHRoaW5nIGFuIGF0dGFja2VyIHdvdWxkIHRyeS4gQW5kIHRoZXnigJlkIGJlIGlt bWVkaWF0ZWx5IHJpZ2h0LiBUaGF0IGhhcmRseSBjb3VudHMgYXMgYSBicnV0ZSBmb3JjZSBhdHRh Y2suIFNvIEnigJltIG5vdCBjb21mb3J0YWJsZSB3aXRoIGFsbG93aW5nIHplcm8tbGVuZ3RoIGlu IGluZm8tbW9kZWwuDQoNCkFuZCBqdXN0IHRvIGJlIGNsZWFyLCBJ4oCZbSBub3Qgc3VnZ2VzdGlu ZyBhbnkgb2YgdGhlc2UgcmVzdHJpY3Rpb25zIGdvIGluIGJhYmVsLWhtYWMuIEp1c3QgaW5mby1t b2RlbC4NCkJhcmJhcmENCg0KRnJvbTogRGF2aWQgU2NoaW5hemkgPGRzY2hpbmF6aS5pZXRmQGdt YWlsLmNvbTxtYWlsdG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tPj4NClNlbnQ6IFRodXJzZGF5 LCBBdWd1c3QgMTUsIDIwMTkgNjo1NiBQTQ0KVG86IFNUQVJLLCBCQVJCQVJBIEggPGJzNzY1MkBh dHQuY29tPG1haWx0bzpiczc2NTJAYXR0LmNvbT4+DQpDYzogYmFiZWxAaWV0Zi5vcmc8bWFpbHRv OmJhYmVsQGlldGYub3JnPjsgSnVsaXVzeiBDaHJvYm9jemVrIDxqY2hAaXJpZi5mcjxtYWlsdG86 amNoQGlyaWYuZnI+Pg0KU3ViamVjdDogUmU6IFtiYWJlbF0gaW5mby1tb2RlbDogcHJlcGFyaW5n IC0wOSBvbiBnaXRodWINCg0KSWYgd2UncmUgY29uc2lkZXJpbmcgYWRkaW5nIHJlc3RyaWN0aW9u cyBzcGVjaWZpYyB0byBCYWJlbCAoYW5kL29yIHRoZSBpbmZvIG1vZGVsKSwgSSB0aGluayB3ZSBz aG91bGQgdGFrZSBhIHByaW5jaXBsZWQgYXBwcm9hY2guIFdoYXQgZnVuZGFtZW50YWwgcHJpbmNp cGxlcyBhcmUgd2UgdXNpbmcgdG8gZGVjaWRlIHRoZXNlIHJlc3RyaWN0aW9ucz8gSWYgd2UgYWxs b3cgYSAxLWJ5dGUga2V5IGJ1dCBkaXNhbGxvdyBhIDY1LWJ5dGUga2V5LCB0aGVuIHRoZSBwcmlu Y2lwbGUgd2UncmUgYWZ0ZXIgaXMgbm90IGltcHJvdmluZyBzZWN1cml0eT8NCg0KT24gVGh1LCBB dWcgMTUsIDIwMTkgYXQgMjo0NiBQTSBTVEFSSywgQkFSQkFSQSBIIDxiczc2NTJAYXR0LmNvbTxt YWlsdG86YnM3NjUyQGF0dC5jb20+PiB3cm90ZToNCkkgZGlzYWdyZWUuDQoNClRoZSBITUFDIHNw ZWNzIChSRkMyMTA0KSBzYXlzOg0KICAgQXBwbGljYXRpb25zIHRoYXQgdXNlIGtleXMgbG9uZ2Vy DQogICB0aGFuIEIgW2Jsb2NrIHNpemVdIGJ5dGVzIHdpbGwgZmlyc3QgaGFzaCB0aGUga2V5IHVz aW5nIEggYW5kIHRoZW4gdXNlIHRoZQ0KICAgcmVzdWx0YW50IEwgW2hhc2ggb3V0cHV0IHNpemVd IGJ5dGUgc3RyaW5nIGFzIHRoZSBhY3R1YWwga2V5IHRvIEhNQUMuIEluIGFueSBjYXNlIHRoZQ0K ICAgbWluaW1hbCByZWNvbW1lbmRlZCBsZW5ndGggZm9yIEsgaXMgTCBieXRlcyAoYXMgdGhlIGhh c2ggb3V0cHV0DQogICBsZW5ndGgpLiBTZWUgc2VjdGlvbiAzIGZvciBtb3JlIGluZm9ybWF0aW9u IG9uIGtleXMuDQphbmQgZnJvbSBzZWN0aW9uIDMNCg0KICAgVGhlIGtleSBmb3IgSE1BQyBjYW4g YmUgb2YgYW55IGxlbmd0aCAoa2V5cyBsb25nZXIgdGhhbiBCIGJ5dGVzIGFyZQ0KDQogICBmaXJz dCBoYXNoZWQgdXNpbmcgSCkuICBIb3dldmVyLCBsZXNzIHRoYW4gTCBieXRlcyBpcyBzdHJvbmds eQ0KDQogICBkaXNjb3VyYWdlZCBhcyBpdCB3b3VsZCBkZWNyZWFzZSB0aGUgc2VjdXJpdHkgc3Ry ZW5ndGggb2YgdGhlDQoNCiAgIGZ1bmN0aW9uLiAgS2V5cyBsb25nZXIgdGhhbiBMIGJ5dGVzIGFy ZSBhY2NlcHRhYmxlIGJ1dCB0aGUgZXh0cmENCg0KICAgbGVuZ3RoIHdvdWxkIG5vdCBzaWduaWZp Y2FudGx5IGluY3JlYXNlIHRoZSBmdW5jdGlvbiBzdHJlbmd0aC4gKEENCg0KICAgbG9uZ2VyIGtl eSBtYXkgYmUgYWR2aXNhYmxlIGlmIHRoZSByYW5kb21uZXNzIG9mIHRoZSBrZXkgaXMNCg0KICAg Y29uc2lkZXJlZCB3ZWFrLikNCg0KSW4gdGhpcyBsYW5ndWFnZSwgdGhlcmUgaXMgbm8gcmVxdWly ZW1lbnQgZm9yIGFwcGxpY2F0aW9ucyB1c2luZyBITUFDIHRvIGFjY2VwdCAob3IgYmUgYWJsZSB0 byB1c2UpIGtleXMgbG9uZ2VyIHRoYW4gQiBieXRlcy4gVGhlIHR3byBzdGF0ZW1lbnRzIGRvIHNh eSB3aGF0IG11c3QgaGFwcGVuICppZiogYSBrZXkgbG9uZ2VyIHRoYW4gQiBieXRlcyBpcyBwcm92 aWRlZC4gQnV0IGlmIEJhYmVsIHdhbnRzIHRvIHJlc3RyaWN0IGtleXMgdG8gbm8gbW9yZSB0aGFu IEIgYnl0ZXMsIHRoYXQgaXMgd2VsbCB3aXRoaW4gQmFiZWzigJlzIHB1cnZpZXcgdG8gZG8gc28u IFJGQzIxMDYgdmVyeSBjbGVhcmx5IHRlbGxzIGFwcGxpY2F0aW9ucyBnZXQgdG8gZGVjaWRlIHdo YXQgdG8gdXNlLg0KDQpUaGUgb3RoZXIgdGhpbmcgSSBnZXQgZnJvbSB0aGlzLCB0aG91Z2gsIGlz IHRoYXQgaXTigJlzIHJlY29tbWVuZGVkIHRvIGhhdmUgYXQgbGVhc3QgTCBieXRlcyBmb3IgYW4g SE1BQyBrZXkgKEwgPSAzMiBmb3IgU0hBLTI1NikuIEkgdGhpbmsgd2Ugc2hvdWxkIHJlZmxlY3Qg dGhpcyByZWNvbW1lbmRhdGlvbi4gV2UgY291bGQgZG8gaXQgZWl0aGVyIHdpdGggYSDigJxTSE9V TETigJ0gb3Ig4oCcTVVTVOKAnSBiZSBhdCBsZWFzdCB0aGUgb3V0cHV0IGhhc2ggbGVuZ3RoIChu b3Qgc2V0IHRoZSBtaW5pbXVtIGF0IDApLiBJIHNlZSBubyByZWFzb24gbm90IHRvIHVwZ3JhZGUg dGhhdCB0byBhIE1VU1QgZm9yIEJhYmVsLCBpZiB3ZSB3YW50LiBbSXTigJlzIGFsd2F5cyBvayB0 byBiZSBzdHJpY3RlciB0aGFuIGEgcmVmZXJlbmNlZCBzcGVjIChlLmcuLCBjaGFuZ2UgU0hPVUxE IHRvIE1VU1QpIOKAkyBpdOKAmXMganVzdCBub3Qgb2sgdG8gZG8gb3IgYWxsb3cgc29tZXRoaW5n IHRoYXQgdmlvbGF0ZXMgYSByZXF1aXJlbWVudCBmcm9tIHRoZSBzcGVjIChlLmcuLCBjaGFuZ2Ug TVVTVCB0byBTSE9VTEQpLl0gSSB0aGluayBhdCBsZWFzdCBhIE1VU1QgYmUgYXQgbGVhc3QgOCBi eXRlc+KAnSB3aXRoIGEg4oCcU0hPVUxEIGJlIGF0IGxlYXN0IHRoZSBvdXRwdXQgaGFzaCBsZW5n dGjigJ0gd291bGQgYmUgZ29vZCBmb3IgSE1BQy4gSXTigJlzIGFsc28gb2sgZm9yIHRoZSBpbmZv cm1hdGlvbiBtb2RlbCB0byBiZSBzdHJpY3RlciB0aGFuIHRoZSBiYWJlbC1obWFjIGltcGxlbWVu dGF0aW9uLg0KDQpCbGFrZTJzIGRvZXMgc3BlY2lmaWNhbGx5IGFsbG93IHplcm8tbGVuZ3RoIGtl eXMg4oCTIHRob3VnaCBJIGRvbuKAmXQga25vdyBob3cgYWR2aXNhYmxlIHRoYXQgaXMgaW4gYSBC YWJlbCB1c2FnZSBzY2VuYXJpby4gSSBkb27igJl0IGtub3cgd2hlbiBrZXkgbGVuZ3RoIG9mIDAg aXMgdXNlZnVsLiBCdXQgdGhlcmUgaXMgZGVmaW5pdGVseSBub3RoaW5nIHRoYXQgcHJldmVudHMg dXMgZnJvbSBiZWluZyBzdHJpY3RlciwgaWYgd2Ugd2FudGVkIHRvIGluc2lzdCBvbiBhIGtleSBs b25nZXIgdGhhbiAwLiBBZ2FpbiwgdGhpcyBzdHJpY3RuZXNzIGNhbiBiZSBpbiBpbmZvLW1vZGVs IG9ubHkgYW5kIGRvZXNu4oCZdCBoYXZlIHRvIGJlIHJlZmxlY3RlZCBpbiBiYWJlbC1obWFjLg0K DQpJIGRvIG5lZWQgc29tZSBtYXhpbXVtIHNpemUgb24gdGhlIHBhcmFtZXRlciAoaW5kZXBlbmRl bnQgb2Yga2V5IGFsZ29yaXRobSkg4oCTIHNvIGl0IHdvbuKAmXQgYmUgdW5saW1pdGVkIGxlbmd0 aCwgYW55d2F5LiBJ4oCZbSB0aGlua2luZyAxMjggYnl0ZXMgYXMgYW4gYWJzb2x1dGUgdXBwZXIg bGltaXQgYXQgdGhpcyB0aW1lLg0KQmFyYmFyYQ0KDQpBY2NvcmRpbmcgdG8gUkZDIDc2OTMsIEJs YWtlMnMga2V5cyBtdXN0IGJlIG9mIGxlbmd0aCBrayB3aGVyZSAwIDw9IGtrIDw9IDMyLiBTbyBo YXZpbmcgdGhlIGluZm8gbW9kZWwgZGljdGF0ZSB0aGF0IGtleXMgTVVTVCBmb2xsb3cgdGhhdCBp cyBwZXJmZWN0bHkgcmVhc29uYWJsZSB0byBtZS4NCg0KSG93ZXZlciwgYWNjb3JkaW5nIHRvIFJG QyA2MjM0LCBITUFDLVNIQS0yNTYgYWxsb3dzIGFsbCBrZXkgbGVuZ3RocyBrayB3aGVyZSAwIDw9 IGtrLiBJIGRvbid0IHRoaW5rIHRoZSBpbmZvcm1hdGlvbiBtb2RlbCBzaG91bGQgZXhwcmVzcyBh biBvcGluaW9uIGFzIHRvIHdoZXRoZXIga2V5cyBsb25nZXIgdGhhbiA2NCBieXRlcyBhcmUgc2Fm ZSBvciBub3QuIElmIHdlIGNob29zZSB0byBhZGQgdGhhdCBkaXN0aW5jdGlvbiB3ZSdsbCBuZWVk IHRvIGp1c3RpZnkgd2h5IHdlIHRoaW5rIHRoZSBrZXkgaGFzaGluZyBpcyB1bnNhZmUsIGFuZCBJ IGRvbid0IHRoaW5rIHRoZXJlIGlzIGFuIFJGQyB3ZSBjYW4gY2l0ZSBmb3IgdGhhdC4NCg0KU28g Z29pbmcgYmFjayB0byBKdWxpdXN6J3MgbGlzdGVkIG9wdGlvbnMgaW4gdGhlIG90aGVyIHRocmVh ZCA8aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9iYWJlbC9RbHZzUEI5eVlG UFRQd1F4YUxjV0lOM0hsMlk8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX19tYWlsYXJjaGl2ZS5pZXRmLm9yZ19hcmNoX21zZ19iYWJlbF9RbHZzUEI5 eVlGUFRQd1F4YUxjV0lOM0hsMlkmZD1Ed01GYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9 TG9HemhDLThzYzhTWThUcTR2cmZvZyZtPXI0ZEtXMEhOU3JqTlBYZFhJZEpfM2tHYzNYclJJeGRC YWM2MER1YTlGOVEmcz1oY3dpNVFEd0c3d3E5NmNFNXZVYko2TFlKMG1ObjZwMGlHc3RQb3Nrek84 JmU9Pj4sIEkgd291bGQgYXJndWUgZm9yIG9wdGlvbiAzICJidXJlYXVjcmF0aWMiIGJlY2F1c2Ug aXQgZm9sbG93cyB0aGUgZGVzaWduIHByaW5jaXBsZSAiVGhlIEJhYmVsIFdHIGRvZXMgbm90IG1h a2Ugc2VjdXJpdHkgZGVjaXNpb25zLCB3ZSBmb2xsb3cgd2hhdCBSRkNzIHRlbGwgdXMiLg0KDQpE YXZpZA0KDQpPbiBUaHUsIEF1ZyAxNSwgMjAxOSBhdCA5OjU4IEFNIFNUQVJLLCBCQVJCQVJBIEgg PGJzNzY1MkBhdHQuY29tPG1haWx0bzpiczc2NTJAYXR0LmNvbT4+IHdyb3RlOg0KPiA+IElzIHRo aXMgc3VnZ2VzdGluZyB0aGF0IGl0J3Mgb2sgZm9yIGluZm8tbW9kZWwgdG8gcHJvdmlkZSBiYWJl bC1obWFjDQo+ID4gd2l0aCBhbnkgdmFsdWUgYmV0d2VlbiAwIGFuZCA2NCBieXRlcyBpbiBsZW5n dGggZm9yIEhNQUMtU0hBMjU2IG9yDQo+ID4gYmV0d2VlbiAwIGFuZCAzMiBieXRlcyBpbiBsZW5n dGggZm9yIEJsYWtlMnMgYW5kIGJhYmVsLWhtYWMgY2FuIGJlDQo+ID4gZXhwZWN0ZWQgdG8gemVy by1wYWQ/IE9yIGFyZSB5b3Ugc3RpbGwgZXhwZWN0aW5nIGluZm8tbW9kZWwgdG8gZG8gdGhlDQo+ ID4gemVyby1wYWRkaW5nIGJlZm9yZSBwcm92aWRpbmcgdG8gYmFiZWwtaG1hYz8NCj4NCj4gVGhl IGZvcm1lci4gIFlvdSBnaXZlIG1lIGFueXRoaW5nIGJldHdlZW4gMCBhbmQgMzIvNjQsIGFuZCBJ IGRlYWwgd2l0aCBpdC4NCg0KQ29vbC4gVGhlbiBmcm9tIGEgcHVyZWx5IGluZm8tbW9kZWwgcGVy c3BlY3RpdmUsIGl0IHNvdW5kcyBsaWtlIHRoZSBrZXktdmFsdWUgcGFyYW1ldGVyIGxlbmd0aCBj b25zdHJhaW50cyBhcmU6DQoNCiAgVGhpcyB2YWx1ZSBpcyBvZiBhIGxlbmd0aCBzdWl0YWJsZSBm b3IgdGhlIGFzc29jaWF0ZWQNCiAgYmFiZWwtbWFjLWtleS1hbGdvcml0aG0uICBJZiB0aGUgYWxn b3JpdGhtIGlzIGJhc2VkIG9uIHRoZSBITUFDDQogIGNvbnN0cnVjdGlvbiwgdGhlIGxlbmd0aCBN VVNUIGJlIGJldHdlZW4gMCBhbmQgdGhlIGJsb2NrIHNpemUgb2YgdGhlDQogIHVuZGVybHlpbmcg aGFzaCBpbmNsdXNpdmUgKHdoZXJlICJITUFDLVNIQTI1NiIgYmxvY2sgc2l6ZSBpcyA2NCBieXRl cw0KICBhcyBkZXNjcmliZWQgaW4ge3tSRkM0ODY4fX0pLg0KICBJZiB0aGUgYWxnb3JpdGhtIGlz ICJCTEFLRTJzIiwgdGhlIGxlbmd0aCBNVVNUIGJlIGJldHdlZW4gMCBhbmQgMzIgYnl0ZXMNCiAg aW5jbHVzaXZlLCBhcyBkZXNjcmliZWQgaW4ge3tSRkM3NjkzfX0uDQoNCkFueXRoaW5nIGNvbXBs eWluZyB3aXRoIGluZm8tbW9kZWwgd29uJ3Qgc3VwcGx5IGFueXRoaW5nIGxvbmdlciB0aGFuIHRo ZSBpZGVudGlmaWVkIG1heCBsZW5ndGguDQpBIGJhYmVsLWhtYWMgaW1wbGVtZW50YXRpb24gbWF5 IGdldCBzb21ldGhpbmcgYXMgc2hvcnQgYXMgemVybyBsZW5ndGgsIGJ1dCB3aWxsIGJlIGV4cGVj dGVkIHRvIGRlYWwgd2l0aCBpdC4gSW5mby1tb2RlbCBkb2Vzbid0IGNhcmUgYW5kIGRvZXNuJ3Qg bmVlZCB0byBrbm93IHdoYXQgImRlYWwgd2l0aCBpdCIgbWVhbnMuDQpGb3IgSE1BQyBhbmQgQmxh a2UycyBhbGdvcml0aG1zLCAiZGVhbCB3aXRoIGl0IiBtZWFucyBobWFjLWJhYmVsIHdpbGwgemVy by1wYWQgc2hvcnRlciBzdHJpbmdzLCBiZWNhdXNlIHRoYXQncyB3aGF0IHRoZSBhbGdvcml0aG0g UkZDcyBzYXkgdG8gZG8gKGFuZCBub3QgYmVjYXVzZSBiYWJlbC1obWFjIGhhcyBhbnkgZXh0cmEg cmVxdWlyZW1lbnRzIGdvaW5nIGJleW9uZCB0aGUgYWxnb3JpdGhtIHNwZWNzKS4NCkluZm8tbW9k ZWwgd29uJ3Qgc2VuZCBzdHJpbmdzIGxvbmdlciB0aGFuIHRoZSBpbmRpY2F0ZWQgbGVuZ3RoLiBJ ZiB0aGVyZSBpcyBhIFVJIHRvIGluZm8gbW9kZWwgdGhhdCBhY2NlcHRzIGEgbG9uZ2VyIHN0cmlu ZywgaGFzaGVzIGl0LCBhbmQgdGhlbiBpbmZvLW1vZGVsIHByb3ZpZGVzIHRoZSBoYXNoZWQgdmFs dWUsIHRoYXQgaXMgd2hhdCBpdCBpcy4gTmVpdGhlciBpbmZvLW1vZGVsIG5vciBiYWJlbC1obWFj IGNhcmUgb3Iga25vdyBvciBuZWVkIHRvIGtub3cgYWJvdXQgdGhpcy4NCklmIGEgYmFiZWwtaG1h YyBpbXBsZW1lbnRhdGlvbiBkb2VzIGhhdmUgc3BlY2lhbCBoYW5kbGluZyBmb3IgbG9uZ2VyIHN0 cmluZ3MsIHRoYXQncyBmaW5lLCB0b28uIEJ1dCBhIHZhbHVlIGNvbWluZyBmcm9tIGluZm8tbW9k ZWwgd2lsbCBuZXZlciB0cmlnZ2VyIHRoaXMgc3BlY2lhbCBjb2RlLg0KRG9lcyB0aGF0IHNvdW5k IHJpZ2h0Pw0KQmFyYmFyYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KYmFiZWwgbWFpbGluZyBsaXN0DQpiYWJlbEBpZXRmLm9yZzxtYWlsdG86YmFi ZWxAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JhYmVs PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3 LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fYmFiZWwmZD1Ed01GYVEmYz1MRllaLW85X0hVTWVN VFNRaWN2aklnJnI9TG9HemhDLThzYzhTWThUcTR2cmZvZyZtPXI0ZEtXMEhOU3JqTlBYZFhJZEpf M2tHYzNYclJJeGRCYWM2MER1YTlGOVEmcz01aFVOajYtVmR6S19OcWNQX2pPT29SSnVRX1czODh2 NVlUNlpsMlJxeERnJmU9Pg0K --_000_2D09D61DDFA73D4C884805CC7865E6114E279084GAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3Jh cGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNv bGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8N CkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE0MDg2NDcyMTQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xODAzMjc0ODcyIDEyMTc0MTgxNzggNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCglt YXJnaW4tbGVmdDoyNS41cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0K QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo2MS41cHQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0Ojk3LjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMzMuNXB0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgltYXJnaW4tbGVmdDoxNjkuNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVm dDoyMDUuNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI0MS41cHQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1h cmdpbi1sZWZ0OjI3Ny41cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjMxMy41cHQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpbmtpbmcgb24gdGhp cyBvdmVybmlnaHQuLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhp bmsgbWluaW11bSBrZXkgbGVuZ3RocyBhcmUgbmVlZGVkLiA8bzpwPjwvbzpwPjwvcD4NCjx1bCBz dHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LTEwLjVwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+DQpJZiBpbmZvLW1vZGVsIG1pbiAmZ3Q7PSBiYWJlbC1obWFjIG1pbiAod2hpY2ggaW5jbHVk ZXMgdGhlIGNhc2Ugd2hlcmUgYmFiZWwtaG1hYyBtaW4gaXMgemVybyksIHRoZXJlIGlzIG5vIHBy ZS1wcm9jZXNzaW5nIHRoYXQgaGFwcGVucyBhdCB0aGUgVUkgLyBpbmZvLW1vZGVsIGxheWVyIGFz IGEgcmVzdWx0LiBFbnRlcmluZyB0aGUgc2FtZSB2YWx1ZSBkaXJlY3RseSB0byBiYWJlbC1obWFj IHRoYXQgaXMgYWxsb3dlZCBhbmQgcHJvdmlkZWQgdmlhIGluZm8tbW9kZWwNCiB3aWxsIHByb2R1 Y2UgdGhlIHNhbWUgcmVzdWx0cy48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LTEwLjVwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+DQpJZiBpbmZvLW1vZGVsIG1pbiAmbHQ7IGJhYmVsLWhtYWMgbWluICh3aGljaCBpbmNsdWRl cyB0aGUgY2FzZSB3aGVyZSBiYWJlbC1obWFjIHNldHMgYSBtaW4gYnV0IGluZm8tbW9kZWwgZG9l c27igJl0KSwgdGhlbiB3ZeKAmWxsIGdldCBlcnJvcnMgZnJvbSBzaG9ydCB2YWx1ZXMgc2VudCB2 aWEgaW5mby1tb2RlbC4gVGhpcyBpcyB1bmRlc2lyYWJsZS4gVXBzdHJlYW0gcmVzdHJpY3Rpb25z IGFsd2F5cyBuZWVkIHRvIGJlIGdyZWF0ZXIgdGhhbiBvciBlcXVhbA0KIHRvIGRvd25zdHJlYW0g bWluaW11bSByZXN0cmljdGlvbnMuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJl Zm9yZSwgSSB3b3VsZCBsaWtlIHRvIGhhdmUgbWluaW11bXMgc3BlY2lmaWVkIGluIGluZm8tbW9k ZWwuIElmIHdlIGhhdmUgdGhlbSBpbiBiYWJlbC1obWFjLCB0aGF04oCZcyBvaywgYnV0IHRoZW4g SSBuZWVkIHRvIG1ha2Ugc3VyZSBpbmZvLW1vZGVsIG1pbnMgJmd0Oz0gYmFiZWwtaG1hYyBtaW5z OyBidXQgaWYgYmFiZWwtaG1hYyBoYXMgbm8gbWluaW11bXMsIGl0IHdvbuKAmXQgY2F1c2UgcHJv YmxlbXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFsc28gbmVlZCB0byBzYXkgc29tZXRo aW5nIGFib3V0IHVwcGVyIGxpbWl0cy4gSSB1bmRlcnN0YW5kIHdoYXQgeW914oCZcmUgc2F5aW5n IGFib3V0IG5vdCB3YW50aW5nIHByZS1wcm9jZXNzaW5nIGF0IHRoZSBVSSB0aGF0IG1heSBvciBt YXkgbm90IGZvbGxvdyBzdGFuZGFyZHMuIEkgdGhpbmsgdGhhdOKAmXMgcmVhc29uYWJsZS4gSSBj YW4gaW5jbHVkZSBVSSBhZHZpY2UgdG8gZXhwbGFpbiB0aGlzIHdvdWxkDQogYmUgYSBiYWQgaWRl YS4gSW5mby1tb2RlbCBjYW7igJl0IG5vcm1hdGl2ZWx5IHJlcXVpcmUgYSBmcm9udC1lbmRpbmcg VUkgdG8gZG8gb3Igbm90IGRvIHNvbWV0aGluZywgYnV0IGFkdmljZSBpcyBvay48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJsYWtlczJzIGRlZmluZXMgbm8gbWVjaGFuaXNt IGZvciBwcm9jZXNzaW5nIGtleXMgbG9uZ2VyIHRoYW4gMzIuIFRoaXMgaXMgYSBoYXJkIGxpbWl0 IHBlciB0aGUgUkZDLiBJIHdvdWxkIGV4cGVjdCBhIGJhYmVsLWhtYWMgaW1wbGVtZW50YXRpb24g dG8gZW5mb3JjZSB0aGlzIGxpbWl0LCBpbXBsaWNpdGx5IChiZWNhdXNlIFJGQzc2OTMgc2F5cyBz bykuIEkgbmVlZCB0byBlbmZvcmNlIGl0IGluIGluZm8tbW9kZWwsDQogdG9vLCBvciBleHBlY3Qg ZXJyb3JzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIEhNQUMsIGtl eXMgbG9uZ2VyIHRoYW4gdGhlIGJsb2NrIHNpemUgZG9u4oCZdCBhZGQgdmFsdWUvc2VjdXJpdHku IFNvIGlmIGluZm8tbW9kZWwgcmVzdHJpY3RzIHNpemUsIGJ1dCBhbHNvIHN0YXRlcyB0aGF0IGFu eSBVSSBmZWVkaW5nIGl0IGlzIGV4cGVjdGVkIGxpa2V3aXNlIHRvIHJlc3RyaWN0IHNpemUsIHRo ZW4gdGhlcmUgd2lsbCBiZSBubyBwcmVwcm9jZXNzaW5nIGluIHRoZSBzZW5zZSBvZiBoYXNoaW5n DQogbG9uZ2VyIHN0cmluZ3MuIElmIGJhYmVsLWhtYWMgYWxsb3dzIGxvbmdlciBrZXlzIChhbmQg aGFzaGVzIHRoZW0pIHRoZXJl4oCZcyBubyBwcm9ibGVtLiBBIHVzZXIgd2FudGluZyB0byB1c2Ug ZWl0aGVyIGEgVUkgZnJvbnQtZW5kaW5nIGFuIGluZm8tbW9kZWwgb3IgZW50ZXIgc29tZXRoaW5n IGRpcmVjdGx5IGludG8gYmFiZWwtaG1hYyB3aWxsIHNpbXBseSB1bmRlcnN0YW5kIHRoZXkgY2Fu 4oCZdCB1c2Ugc29tZXRoaW5nIGxvbmdlciAod2hpY2ggdXNlcnMNCiBkb27igJl0IHRlbmQgdG8g aGF2ZSBhIHByb2JsZW0gd2l0aCkuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgaWYgd2Ug YXJlIGNvbnNjaW91c2x5IGNvbnNpZGVyaW5nIGEgdXNlciBtaWdodCBlbnRlciBrZXlzIGRpcmVj dGx5IHRvIGJhYmVsLWhtYWMgb3IgdmlhIGEgVUkgZnJvbnQtZW5kaW5nIGFuIGluZm8tbW9kZWws IHRoZW4gaW5mby1tb2RlbCBhbHNvIG5lZWRzIHRvIHByb3ZpZGUgYWR2aWNlIGFib3V0IHRoZSBB U0NJSSB2cy4gVVRGLW4gaW5wdXQgc3RyaW5nIGludGVycHJldGF0aW9uLiBUaGlzIHdhcyBhbg0K IGl0ZW0gb2YgZGlzY3Vzc2lvbiBpbiBKYW51YXJ5LiBJZiB0aGUgaW5mby1tb2RlbCBVSSBhbmQg YmFiZWwtaG1hYyBVSSBpbnRlcnByZXQgdXNlciBpbnB1dCBkaWZmZXJlbnRseSwgdGhlcmUgd2ls bCBiZSBhIHByb2JsZW0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvLi4uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UgYW5kIEp1bGl1c3ogbmVlZCB0byBmaWd1cmUg b3V0IHdoYXQgb3Igd2hldGhlciB5b3Ugd2FudCBiYWJlbC1obWFjIHRvIGltcG9zZSByZXN0cmlj dGlvbnMuIEZvciBpbmZvLW1vZGVsLCBteSBuZXcgbGF0ZXN0IHN1Z2dlc3Rpb24gaXM6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBUaGlzIHZhbHVlIGlzIG9mIGEgbGVuZ3RoIHN1aXRh YmxlIGZvciB0aGUgYXNzb2NpYXRlZDxicj4NCiZuYnNwOyBiYWJlbC1tYWMta2V5LWFsZ29yaXRo bS4gVGhlIGxlbmd0aCBTSE9VTEQgbWVldCBtaW5pbXVtIGxlbmd0aDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IHJlY29tbWVuZGF0aW9ucyBmb3IgYWNoaWV2aW5n IHJlYXNvbmFibGUgcHJvdGVjdGlvbiBhZ2FpbnN0IGJydXRlIGZvcmNlPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgYXR0YWNrcy4gSWYgdGhlIGFsZ29yaXRobSBp cyBiYXNlZCBvbiB0aGUgSE1BQzxicj4NCiZuYnNwOyBjb25zdHJ1Y3Rpb24sIHRoZSBsZW5ndGgg U0hPVUxEIGJlIGdyZWF0ZXIgdGhhbiBvciBlcXVhbCB0byAxNiBieXRlcyBhbmQgU0hPVUxEPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtiZSBsZXNzIHRoYW4gb3Ig ZXF1YWwgdG8gdGhlIGJsb2NrIHNpemUgb2YgdGhlPGJyPg0KJm5ic3A7IHVuZGVybHlpbmcgaGFz aCAod2hlcmUgJnF1b3Q7SE1BQy1TSEEyNTYmcXVvdDsgYmxvY2sgc2l6ZSBpcyA2NCBieXRlczxi cj4NCiZuYnNwOyBhcyBkZXNjcmliZWQgaW4ge3tSRkM0ODY4fX0pLiA8YnI+DQombmJzcDsgSWYg dGhlIGFsZ29yaXRobSBpcyAmcXVvdDtCTEFLRTJzJnF1b3Q7LCB0aGUgbGVuZ3RoIE1VU1QgYmUg bGVzcyB0aGFuIG9yIGVxdWFsIHRvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDszMiBieXRlcywgYXMgZGVzY3JpYmVkIGluIHt7UkZDNzY5M319LCBhbmQgU0hPVUxE IGJlIGdyZWF0ZXIgdGhhbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7b3IgZXF1YWwgdG8gMTYgYnl0ZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgSWYgdmFsdWVzIGFyZSBwcm92aWRlZCB0aHJvdWdoIHN0cmluZ3MgaW5wdXQg dG8gYSB1c2VyIGludGVyZmFjZSAoVUkpLCBJdCBpcyBleHBlY3RlZDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IHRoZXNlIGlucHV0IHN0cmluZ3Mgd2lsbCBiZSBj b252ZXJ0ZWQgdG8gQVNDSUkgdmFsdWVzIG9yIGFsbG93IHRoZSB1c2VyPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgdG8gZXhwbGljaXRseSBpZGVudGlmeSB0aGUg Y29udmVyc2lvbiB0byB1c2UgKHdpdGggQVNDSUkgYmVpbmcgYW4gb3B0aW9uKS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBBIFVJIGlzIGV4cGVjdGVkIHRvIGlt cG9zZSBhbnkgaW1wbGVtZW50ZWQgbGVuZ3RoIHJlc3RyaWN0aW9ucywgc28gbm88bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO2FkZGl0aW9uYWwgcHJvY2Vzc2luZyBp cyBkb25lIHRvIHVzZXIgaW5wdXQgdG8gbWFrZSBpdCBsb25nZXIgb3Igc2hvcnRlci48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QmFyYmFyYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBvc3RlbCdzIExhdyBpc24ndCBzb21ldGhpbmcgd2Ug c2hvdWxkIGJlIGZvbGxvd2luZyBpbiB0aGlzIGRheSBhbmQgYWdlIChmdXJ0aGVyIHJlYWRpbmc6 ICZsdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRpYWItMkRwcm90b2NvbC0yRG1h aW50ZW5hbmNlLTJEMDMmYW1wO2Q9RHdNRmFRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcm YW1wO3I9TG9HemhDLThzYzhTWThUcTR2cmZvZyZhbXA7bT02UDRvYVpBV19MSl80aFZ6OWhkQ2xX b05jenRuZUlDR2hUWV9zaFlrRlVvJmFtcDtzPXl6MENIUTFPclJ6SW1oa2tVbER0ZUVzbkticG5H NUFQT0hyVmNMSi1RalkmYW1wO2U9Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWFiLXByb3RvY29sLW1haW50ZW5hbmNlLTAzPC9hPiZndDspLjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3JyeSB0aGF0IGlmIHlvdSBhZGQgcmVzdHJp Y3Rpb25zIGF0IHRoZSBpbmZvIG1vZGVsIGxheWVyLCB0aGUgVUkgbGF5ZXIgd2lsbCBwcmVwcm9j ZXNzIHRoZSBrZXlzIG91dHNpZGUgb2YgYWxsIHN0YW5kYXJkcyBhbmQgdGhhdCBjb3VsZCBsZWFk IHRvIGludGVyb3BlcmFiaWxpdHkgaXNzdWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEF1ZyAxNSwgMjAxOSBhdCA1OjA0IFBN IFNUQVJLLCBCQVJCQVJBIEggJmx0OzxhIGhyZWY9Im1haWx0bzpiczc2NTJAYXR0LmNvbSI+YnM3 NjUyQGF0dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mcXVvdDtCZSBsaWJl cmFsIGluIHdoYXQgeW91IGFjY2VwdCwgYW5kIGNvbnNlcnZhdGl2ZSBpbiB3aGF0IHlvdSBzZW5k JnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRvIGJlIHJvYnVz dCwgaW5mby1tb2RlbCBuZWVkcyB0byBiZSBjb25zZXJ2YXRpdmUgaW4gd2hhdCBpdCBzZW5kcyB0 byBhIGJhYmVsLWhtYWMgaW1wbGVtZW50YXRpb24uIEFuZCBiYWJlbC1obWFjIG5lZWRzIHRvIGJl IGxpYmVyYWwgaW4gd2hhdCBpdCBhY2NlcHRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ QnV0IGlmIHlvdSBjYW4gZ2V0IEp1bGl1c3ogdG8gYWdyZWUgdG8gcmVzdHJpY3Rpb25zIGluIGJh YmVsLWhtYWMsIGFuZCBhbGwgdGhlIHJldmlld2VycyAoYmVjYXVzZSBpdOKAmXMgYSBzaWduaWZp Y2FudCBjaGFuZ2UpLCBJ4oCZbSBmaW5lIHdpdGggdGhhdC4gSSBkbyB0aGluayBpdOKAmXMgZGFu Z2Vyb3VzIGF0IHRoaXMNCiBwb2ludCBpbiB0aGUgcmV2aWV3IHByb2Nlc3MgKHVubGVzcyB0aGVy ZSB3ZXJlIGNvbW1lbnRzIHRoYXQgY291bGQgYmUgcmVzb2x2ZWQgYnkgc3VjaCByZXN0cmljdGlv bnM/KS4gT1RPSCwgaXQgbWlnaHQgbWFrZSByZXZpZXdlcnMgaGFwcGllciB0byBzZWUgc3VjaCBy ZXN0cmljdGlvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJhcmJh cmE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IERhdmlkIFNjaGlu YXppICZsdDs8YSBocmVmPSJtYWlsdG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+ZHNjaGluYXppLmlldGZAZ21haWwuY29tPC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6 PC9iPiBUaHVyc2RheSwgQXVndXN0IDE1LCAyMDE5IDc6NTUgUE08YnI+DQo8Yj5Ubzo8L2I+IFNU QVJLLCBCQVJCQVJBIEggJmx0OzxhIGhyZWY9Im1haWx0bzpiczc2NTJAYXR0LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmJzNzY1MkBhdHQuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9 Im1haWx0bzpiYWJlbEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJhYmVsQGlldGYub3JnPC9h PjsgSnVsaXVzeiBDaHJvYm9jemVrICZsdDs8YSBocmVmPSJtYWlsdG86amNoQGlyaWYuZnIiIHRh cmdldD0iX2JsYW5rIj5qY2hAaXJpZi5mcjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbYmFiZWxdIGluZm8tbW9kZWw6IHByZXBhcmluZyAtMDkgb24gZ2l0aHViPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldoeSBhZGQgcmVzdHJpY3Rp b25zIHRvIHRoZSBpbmZvIG1vZGVsIGFuZCBub3QgdG8gYmFiZWwtaG1hYz8gSWYgd2UgYmVsaWV2 ZSBzb21ldGhpbmcgaXMgaW5zZWN1cmUgc2hvdWxkbid0IHdlIGJhbiBpdCBldmVuIHdoZW4gdGhl IGluZm8gbW9kZWwgaXNuJ3QgYmVpbmcgdXNlZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUaHUsIEF1ZyAxNSwgMjAxOSBhdCA0OjQwIFBNIFNU QVJLLCBCQVJCQVJBIEggJmx0OzxhIGhyZWY9Im1haWx0bzpiczc2NTJAYXR0LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmJzNzY1MkBhdHQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6NC4uOHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyBSRkMyMTA0IHNheXM6IOKA nEtleXMgbG9uZ2VyIHRoYW4gTCBieXRlcyBhcmUgYWNjZXB0YWJsZSBidXQgdGhlIGV4dHJhIGxl bmd0aCB3b3VsZCBub3Qgc2lnbmlmaWNhbnRseSBpbmNyZWFzZSB0aGUgZnVuY3Rpb24gc3RyZW5n dGgu4oCdIFNpbmNlIDY0ID0gMipMIGZvciBTSEEtMjU2LCBhIGtleSBsb25nZXINCiB0aGFuIDY0 IGlzIGV2ZW4gbGVzcyBsaWtlbHkgdG8gaW5jcmVhc2UgdGhlIGZ1bmN0aW9uIHN0cmVuZ3RoLiBT byBrZXkgbGVuZ3RoICZndDsgNjQgcHJvdmlkZXMgbm8gYWRkZWQgdmFsdWUuIEJ1dCBpdCBkb2Vz IGluY3JlYXNlIGNvbXBsZXhpdHkgZm9yIGNyZWF0aW5nIHRoZSDigJxyZWFs4oCdIGtleS4gSW5j cmVhc2VkIGNvbXBsZXhpdHkgbWVhbnMgbW9yZSB0aGluZ3MgY2FuIGdvIHdyb25nLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SSBkb27igJl0IHRoaW5rIHdlIHNob3VsZCBhbGxvdyBhIDEt Ynl0ZSBrZXkuIE15IHJlY29tbWVuZGF0aW9uIGZvciBTSEEtMjU2IHdhcyBNVVNUIGJlICZndDsg OC4gSSBmb3VuZCB0aGlzIHNpdGU6DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5rZXlsZW5ndGguY29tX2VuXzRfJmFtcDtk PUR3TUZhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPUxvR3poQy04c2M4U1k4 VHE0dnJmb2cmYW1wO209Q1ZuV1VXbVhpdjJlR2xVdklEcnNieHF2bmtRMENKZXRaSjNveno5U0lq cyZhbXA7cz1lenp2eHpacXlpMjNrekV2QmRoVnVMMlNmbmpLTXNhN1djdmU4eXNaYmFzJmFtcDtl PSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cua2V5bGVuZ3RoLmNvbS9lbi80LzwvYT4g d2hpY2ggc2F5cyBOSVNUIHJlY29tbWVuZHMgbWluaW11bSBvZiAxNiBieXRlcyBmb3IgU0hBLTI1 NiBrZXlzLiBJ4oCZbSBnb29kIHdpdGggcmVxdWlyaW5nIHRoYXQsIHRvby4gSXQgd291bGQgY2Vy dGFpbmx5IG1ha2UgdXMgY3VycmVudCBvbiBiZXN0IHByYWN0aWNlIHNlY3VyaXR5IHJlY29tbWVu ZGF0aW9ucy4gVGhlcmXigJlzIHNvbWV0aGluZyB0byBiZSBzYWlkIGZvciBmb2xsb3dpbmcNCiBi ZXN0IHByYWN0aWNlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaGF2ZSBubyBpZGVh IHdoYXQgdG8gZG8gZm9yIEJsYWtlMnMuIEkgY2Fu4oCZdCBmaW5kIGEgbWluaW11bSBrZXkgbGVu Z3RoIHJlY29tbWVuZGF0aW9uLiBCdXQgemVyby1sZW5ndGggKHVua2V5ZWQpIHVzYWdlIHByb3Zp ZGVzIG5vIG1lYW5pbmdmdWwgc2VjdXJpdHkgaW4gdGhlIEJhYmVsIHVzZSBjYXNlLiBaZXJvLWxl bmd0aA0KIGlzIHByb2JhYmx5IHRoZSBmaXJzdCB0aGluZyBhbiBhdHRhY2tlciB3b3VsZCB0cnku IEFuZCB0aGV54oCZZCBiZSBpbW1lZGlhdGVseSByaWdodC4gVGhhdCBoYXJkbHkgY291bnRzIGFz IGEgYnJ1dGUgZm9yY2UgYXR0YWNrLiBTbyBJ4oCZbSBub3QgY29tZm9ydGFibGUgd2l0aCBhbGxv d2luZyB6ZXJvLWxlbmd0aCBpbiBpbmZvLW1vZGVsLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5BbmQganVzdCB0byBiZSBjbGVhciwgSeKAmW0gbm90IHN1Z2dlc3RpbmcgYW55IG9mIHRo ZXNlIHJlc3RyaWN0aW9ucyBnbyBpbiBiYWJlbC1obWFjLiBKdXN0IGluZm8tbW9kZWwuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJhcmJhcmE8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IERhdmlkIFNjaGluYXppICZsdDs8YSBocmVmPSJt YWlsdG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHNjaGluYXpp LmlldGZAZ21haWwuY29tPC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVn dXN0IDE1LCAyMDE5IDY6NTYgUE08YnI+DQo8Yj5Ubzo8L2I+IFNUQVJLLCBCQVJCQVJBIEggJmx0 OzxhIGhyZWY9Im1haWx0bzpiczc2NTJAYXR0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJzNzY1MkBh dHQuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpiYWJlbEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJhYmVsQGlldGYub3JnPC9hPjsgSnVsaXVzeiBDaHJvYm9j emVrICZsdDs8YSBocmVmPSJtYWlsdG86amNoQGlyaWYuZnIiIHRhcmdldD0iX2JsYW5rIj5qY2hA aXJpZi5mcjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbYmFiZWxdIGluZm8tbW9k ZWw6IHByZXBhcmluZyAtMDkgb24gZ2l0aHViPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHdlJ3JlIGNvbnNpZGVyaW5nIGFkZGluZyByZXN0cmlj dGlvbnMgc3BlY2lmaWMgdG8gQmFiZWwgKGFuZC9vciB0aGUgaW5mbyBtb2RlbCksIEkgdGhpbmsg d2Ugc2hvdWxkIHRha2UgYSBwcmluY2lwbGVkIGFwcHJvYWNoLiBXaGF0IGZ1bmRhbWVudGFsIHBy aW5jaXBsZXMgYXJlIHdlIHVzaW5nIHRvIGRlY2lkZQ0KIHRoZXNlIHJlc3RyaWN0aW9ucz8gSWYg d2UgYWxsb3cgYSAxLWJ5dGUga2V5IGJ1dCBkaXNhbGxvdyBhIDY1LWJ5dGUga2V5LCB0aGVuIHRo ZSBwcmluY2lwbGUgd2UncmUgYWZ0ZXIgaXMgbm90IGltcHJvdmluZyBzZWN1cml0eT88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUaHUsIEF1ZyAx NSwgMjAxOSBhdCAyOjQ2IFBNIFNUQVJLLCBCQVJCQVJBIEggJmx0OzxhIGhyZWY9Im1haWx0bzpi czc2NTJAYXR0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJzNzY1MkBhdHQuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkkgZGlzYWdyZWUuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBITUFDIHNwZWNz IChSRkMyMTA0KSBzYXlzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEFwcGxpY2F0aW9ucyB0aGF0IHVzZSBrZXlzIGxvbmdlcjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyB0aGFuIEINCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5bYmxvY2sgc2l6ZV08L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiBieXRlcyB3aWxsIGZpcnN0IGhhc2ggdGhlIGtleSB1c2luZyBIIGFuZCB0 aGVuIHVzZSB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcmVzdWx0YW50IEwNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5baGFzaCBvdXRwdXQgc2l6ZV0NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Ynl0ZSBzdHJpbmcgYXMgdGhl IGFjdHVhbCBrZXkgdG8gSE1BQy4gSW4gYW55IGNhc2UgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG1pbmltYWwg cmVjb21tZW5kZWQgbGVuZ3RoIGZvciBLIGlzIEwgYnl0ZXMgKGFzIHRoZSBoYXNoIG91dHB1dDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyBsZW5ndGgpLiBTZWUgc2VjdGlvbiAzIGZvciBtb3JlIGluZm9ybWF0aW9uIG9u IGtleXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5hbmQg ZnJvbSBzZWN0aW9uIDMNCjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDtU aGUga2V5IGZvciBITUFDIGNhbiBiZSBvZiBhbnkgbGVuZ3RoIChrZXlzIGxvbmdlciB0aGFuIEIg Ynl0ZXMgYXJlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGZpcnN0IGhhc2hl ZCB1c2luZyBIKS4mbmJzcDsgSG93ZXZlciwgbGVzcyB0aGFuIEwgYnl0ZXMgaXMgc3Ryb25nbHk8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZGlzY291cmFnZWQgYXMgaXQgd291 bGQgZGVjcmVhc2UgdGhlIHNlY3VyaXR5IHN0cmVuZ3RoIG9mIHRoZTxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyBmdW5jdGlvbi4mbmJzcDsgS2V5cyBsb25nZXIgdGhhbiBMIGJ5 dGVzIGFyZSBhY2NlcHRhYmxlIGJ1dCB0aGUgZXh0cmE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgbGVuZ3RoIHdvdWxkIG5vdCBzaWduaWZpY2FudGx5IGluY3JlYXNlIHRoZSBm dW5jdGlvbiBzdHJlbmd0aC4gKEE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg bG9uZ2VyIGtleSBtYXkgYmUgYWR2aXNhYmxlIGlmIHRoZSByYW5kb21uZXNzIG9mIHRoZSBrZXkg aXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgY29uc2lkZXJlZCB3ZWFrLik8 bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gdGhpcyBsYW5ndWFnZSwgdGhlcmUgaXMg bm8gcmVxdWlyZW1lbnQgZm9yIGFwcGxpY2F0aW9ucyB1c2luZyBITUFDIHRvIGFjY2VwdCAob3Ig YmUgYWJsZSB0byB1c2UpIGtleXMgbG9uZ2VyIHRoYW4gQiBieXRlcy4gVGhlIHR3byBzdGF0ZW1l bnRzIGRvIHNheSB3aGF0IG11c3QgaGFwcGVuICo8Yj5pZjwvYj4qDQogYSBrZXkgbG9uZ2VyIHRo YW4gQiBieXRlcyBpcyBwcm92aWRlZC4gQnV0IGlmIEJhYmVsIHdhbnRzIHRvIHJlc3RyaWN0IGtl eXMgdG8gbm8gbW9yZSB0aGFuIEIgYnl0ZXMsIHRoYXQgaXMgd2VsbCB3aXRoaW4gQmFiZWzigJlz IHB1cnZpZXcgdG8gZG8gc28uIFJGQzIxMDYgdmVyeSBjbGVhcmx5IHRlbGxzIGFwcGxpY2F0aW9u cyBnZXQgdG8gZGVjaWRlIHdoYXQgdG8gdXNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ VGhlIG90aGVyIHRoaW5nIEkgZ2V0IGZyb20gdGhpcywgdGhvdWdoLCBpcyB0aGF0IGl04oCZcyBy ZWNvbW1lbmRlZCB0byBoYXZlIGF0IGxlYXN0IEwgYnl0ZXMgZm9yIGFuIEhNQUMga2V5IChMID0g MzIgZm9yIFNIQS0yNTYpLiBJIHRoaW5rIHdlIHNob3VsZCByZWZsZWN0IHRoaXMgcmVjb21tZW5k YXRpb24uIFdlDQogY291bGQgZG8gaXQgZWl0aGVyIHdpdGggYSDigJxTSE9VTETigJ0gb3Ig4oCc TVVTVOKAnSBiZSBhdCBsZWFzdCB0aGUgb3V0cHV0IGhhc2ggbGVuZ3RoIChub3Qgc2V0IHRoZSBt aW5pbXVtIGF0IDApLiBJIHNlZSBubyByZWFzb24gbm90IHRvIHVwZ3JhZGUgdGhhdCB0byBhIE1V U1QgZm9yIEJhYmVsLCBpZiB3ZSB3YW50LiBbSXTigJlzIGFsd2F5cyBvayB0byBiZSBzdHJpY3Rl ciB0aGFuIGEgcmVmZXJlbmNlZCBzcGVjIChlLmcuLCBjaGFuZ2UgU0hPVUxEIHRvIE1VU1QpDQog 4oCTIGl04oCZcyBqdXN0IG5vdCBvayB0byBkbyBvciBhbGxvdyBzb21ldGhpbmcgdGhhdCB2aW9s YXRlcyBhIHJlcXVpcmVtZW50IGZyb20gdGhlIHNwZWMgKGUuZy4sIGNoYW5nZSBNVVNUIHRvIFNI T1VMRCkuXSBJIHRoaW5rIGF0IGxlYXN0IGEgTVVTVCBiZSBhdCBsZWFzdCA4IGJ5dGVz4oCdIHdp dGggYSDigJxTSE9VTEQgYmUgYXQgbGVhc3QgdGhlIG91dHB1dCBoYXNoIGxlbmd0aOKAnSB3b3Vs ZCBiZSBnb29kIGZvciBITUFDLiBJdOKAmXMgYWxzbyBvayBmb3IgdGhlDQogaW5mb3JtYXRpb24g bW9kZWwgdG8gYmUgc3RyaWN0ZXIgdGhhbiB0aGUgYmFiZWwtaG1hYyBpbXBsZW1lbnRhdGlvbi48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJsYWtlMnMgZG9lcyBzcGVjaWZpY2FsbHkgYWxs b3cgemVyby1sZW5ndGgga2V5cyDigJMgdGhvdWdoIEkgZG9u4oCZdCBrbm93IGhvdyBhZHZpc2Fi bGUgdGhhdCBpcyBpbiBhIEJhYmVsIHVzYWdlIHNjZW5hcmlvLiBJIGRvbuKAmXQga25vdyB3aGVu IGtleSBsZW5ndGggb2YgMCBpcyB1c2VmdWwuIEJ1dCB0aGVyZSBpcw0KIGRlZmluaXRlbHkgbm90 aGluZyB0aGF0IHByZXZlbnRzIHVzIGZyb20gYmVpbmcgc3RyaWN0ZXIsIGlmIHdlIHdhbnRlZCB0 byBpbnNpc3Qgb24gYSBrZXkgbG9uZ2VyIHRoYW4gMC4gQWdhaW4sIHRoaXMgc3RyaWN0bmVzcyBj YW4gYmUgaW4gaW5mby1tb2RlbCBvbmx5IGFuZCBkb2VzbuKAmXQgaGF2ZSB0byBiZSByZWZsZWN0 ZWQgaW4gYmFiZWwtaG1hYy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZG8gbmVlZCBz b21lIG1heGltdW0gc2l6ZSBvbiB0aGUgcGFyYW1ldGVyIChpbmRlcGVuZGVudCBvZiBrZXkgYWxn b3JpdGhtKSDigJMgc28gaXQgd29u4oCZdCBiZSB1bmxpbWl0ZWQgbGVuZ3RoLCBhbnl3YXkuIEni gJltIHRoaW5raW5nIDEyOCBieXRlcyBhcyBhbiBhYnNvbHV0ZSB1cHBlciBsaW1pdCBhdCB0aGlz DQogdGltZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QmFyYmFyYTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+QWNjb3JkaW5nIHRvIFJGQyA3NjkzLCBCbGFrZTJzIGtleXMgbXVzdCBiZSBvZiBs ZW5ndGgga2sgd2hlcmUmbmJzcDswICZsdDs9IGtrICZsdDs9IDMyLiBTbyBoYXZpbmcgdGhlIGlu Zm8gbW9kZWwgZGljdGF0ZSB0aGF0IGtleXMgTVVTVCBmb2xsb3cgdGhhdCBpcyBwZXJmZWN0bHkg cmVhc29uYWJsZSB0byBtZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkhvd2V2ZXIsIGFjY29yZGluZyB0byBSRkMgNjIzNCwgSE1BQy1T SEEtMjU2IGFsbG93cyBhbGwga2V5IGxlbmd0aHMga2sgd2hlcmUgMCAmbHQ7PSBray4gSSBkb24n dCB0aGluayB0aGUgaW5mb3JtYXRpb24gbW9kZWwgc2hvdWxkIGV4cHJlc3MgYW4gb3BpbmlvbiBh cyB0byB3aGV0aGVyIGtleXMgbG9uZ2VyIHRoYW4NCiA2NCBieXRlcyBhcmUgc2FmZSBvciBub3Qu IElmIHdlIGNob29zZSB0byBhZGQgdGhhdCBkaXN0aW5jdGlvbiB3ZSdsbCBuZWVkIHRvIGp1c3Rp Znkgd2h5IHdlIHRoaW5rIHRoZSBrZXkgaGFzaGluZyBpcyB1bnNhZmUsIGFuZCBJIGRvbid0IHRo aW5rIHRoZXJlIGlzIGFuIFJGQyB3ZSBjYW4gY2l0ZSBmb3IgdGhhdC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvIGdvaW5nIGJhY2sg dG8gSnVsaXVzeidzIGxpc3RlZCBvcHRpb25zIGluIHRoZSBvdGhlciB0aHJlYWQgJmx0OzxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f bWFpbGFyY2hpdmUuaWV0Zi5vcmdfYXJjaF9tc2dfYmFiZWxfUWx2c1BCOXlZRlBUUHdReGFMY1dJ TjNIbDJZJmFtcDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPUxv R3poQy04c2M4U1k4VHE0dnJmb2cmYW1wO209cjRkS1cwSE5TcmpOUFhkWElkSl8za0djM1hyUkl4 ZEJhYzYwRHVhOUY5USZhbXA7cz1oY3dpNVFEd0c3d3E5NmNFNXZVYko2TFlKMG1ObjZwMGlHc3RQ b3Nrek84JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v cmcvYXJjaC9tc2cvYmFiZWwvUWx2c1BCOXlZRlBUUHdReGFMY1dJTjNIbDJZPC9hPiZndDssDQog SSB3b3VsZCBhcmd1ZSBmb3Igb3B0aW9uIDMgJnF1b3Q7YnVyZWF1Y3JhdGljJnF1b3Q7IGJlY2F1 c2UgaXQgZm9sbG93cyB0aGUgZGVzaWduIHByaW5jaXBsZSAmcXVvdDtUaGUgQmFiZWwgV0cgZG9l cyBub3QgbWFrZSBzZWN1cml0eSBkZWNpc2lvbnMsIHdlIGZvbGxvdyB3aGF0IFJGQ3MgdGVsbCB1 cyZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkRhdmlkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5PbiBUaHUsIEF1ZyAxNSwgMjAxOSBhdCA5OjU4IEFNIFNUQVJLLCBC QVJCQVJBIEggJmx0OzxhIGhyZWY9Im1haWx0bzpiczc2NTJAYXR0LmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmJzNzY1MkBhdHQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mZ3Q7ICZndDsgSXMgdGhpcyBzdWdnZXN0aW5nIHRoYXQgaXQncyBv ayBmb3IgaW5mby1tb2RlbCB0byBwcm92aWRlIGJhYmVsLWhtYWM8YnI+DQomZ3Q7ICZndDsgd2l0 aCBhbnkgdmFsdWUgYmV0d2VlbiAwIGFuZCA2NCBieXRlcyBpbiBsZW5ndGggZm9yIEhNQUMtU0hB MjU2IG9yPGJyPg0KJmd0OyAmZ3Q7IGJldHdlZW4gMCBhbmQgMzIgYnl0ZXMgaW4gbGVuZ3RoIGZv ciBCbGFrZTJzIGFuZCBiYWJlbC1obWFjIGNhbiBiZTxicj4NCiZndDsgJmd0OyBleHBlY3RlZCB0 byB6ZXJvLXBhZD8gT3IgYXJlIHlvdSBzdGlsbCBleHBlY3RpbmcgaW5mby1tb2RlbCB0byBkbyB0 aGU8YnI+DQomZ3Q7ICZndDsgemVyby1wYWRkaW5nIGJlZm9yZSBwcm92aWRpbmcgdG8gYmFiZWwt aG1hYz88YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIGZvcm1lci4mbmJzcDsgWW91IGdpdmUgbWUg YW55dGhpbmcgYmV0d2VlbiAwIGFuZCAzMi82NCwgYW5kIEkgZGVhbCB3aXRoIGl0Ljxicj4NCjxi cj4NCkNvb2wuIFRoZW4gZnJvbSBhIHB1cmVseSBpbmZvLW1vZGVsIHBlcnNwZWN0aXZlLCBpdCBz b3VuZHMgbGlrZSB0aGUga2V5LXZhbHVlIHBhcmFtZXRlciBsZW5ndGggY29uc3RyYWludHMgYXJl Ojxicj4NCjxicj4NCiZuYnNwOyBUaGlzIHZhbHVlIGlzIG9mIGEgbGVuZ3RoIHN1aXRhYmxlIGZv ciB0aGUgYXNzb2NpYXRlZDxicj4NCiZuYnNwOyBiYWJlbC1tYWMta2V5LWFsZ29yaXRobS4mbmJz cDsgSWYgdGhlIGFsZ29yaXRobSBpcyBiYXNlZCBvbiB0aGUgSE1BQzxicj4NCiZuYnNwOyBjb25z dHJ1Y3Rpb24sIHRoZSBsZW5ndGggTVVTVCBiZSBiZXR3ZWVuIDAgYW5kIHRoZSBibG9jayBzaXpl IG9mIHRoZTxicj4NCiZuYnNwOyB1bmRlcmx5aW5nIGhhc2ggaW5jbHVzaXZlICh3aGVyZSAmcXVv dDtITUFDLVNIQTI1NiZxdW90OyBibG9jayBzaXplIGlzIDY0IGJ5dGVzPGJyPg0KJm5ic3A7IGFz IGRlc2NyaWJlZCBpbiB7e1JGQzQ4Njh9fSkuPGJyPg0KJm5ic3A7IElmIHRoZSBhbGdvcml0aG0g aXMgJnF1b3Q7QkxBS0UycyZxdW90OywgdGhlIGxlbmd0aCBNVVNUIGJlIGJldHdlZW4gMCBhbmQg MzIgYnl0ZXM8YnI+DQombmJzcDsgaW5jbHVzaXZlLCBhcyBkZXNjcmliZWQgaW4ge3tSRkM3Njkz fX0uPGJyPg0KPGJyPg0KQW55dGhpbmcgY29tcGx5aW5nIHdpdGggaW5mby1tb2RlbCB3b24ndCBz dXBwbHkgYW55dGhpbmcgbG9uZ2VyIHRoYW4gdGhlIGlkZW50aWZpZWQgbWF4IGxlbmd0aC48YnI+ DQpBIGJhYmVsLWhtYWMgaW1wbGVtZW50YXRpb24gbWF5IGdldCBzb21ldGhpbmcgYXMgc2hvcnQg YXMgemVybyBsZW5ndGgsIGJ1dCB3aWxsIGJlIGV4cGVjdGVkIHRvIGRlYWwgd2l0aCBpdC4gSW5m by1tb2RlbCBkb2Vzbid0IGNhcmUgYW5kIGRvZXNuJ3QgbmVlZCB0byBrbm93IHdoYXQgJnF1b3Q7 ZGVhbCB3aXRoIGl0JnF1b3Q7IG1lYW5zLjxicj4NCkZvciBITUFDIGFuZCBCbGFrZTJzIGFsZ29y aXRobXMsICZxdW90O2RlYWwgd2l0aCBpdCZxdW90OyBtZWFucyBobWFjLWJhYmVsIHdpbGwgemVy by1wYWQgc2hvcnRlciBzdHJpbmdzLCBiZWNhdXNlIHRoYXQncyB3aGF0IHRoZSBhbGdvcml0aG0g UkZDcyBzYXkgdG8gZG8gKGFuZCBub3QgYmVjYXVzZSBiYWJlbC1obWFjIGhhcyBhbnkgZXh0cmEg cmVxdWlyZW1lbnRzIGdvaW5nIGJleW9uZCB0aGUgYWxnb3JpdGhtIHNwZWNzKS48YnI+DQpJbmZv LW1vZGVsIHdvbid0IHNlbmQgc3RyaW5ncyBsb25nZXIgdGhhbiB0aGUgaW5kaWNhdGVkIGxlbmd0 aC4gSWYgdGhlcmUgaXMgYSBVSSB0byBpbmZvIG1vZGVsIHRoYXQgYWNjZXB0cyBhIGxvbmdlciBz dHJpbmcsIGhhc2hlcyBpdCwgYW5kIHRoZW4gaW5mby1tb2RlbCBwcm92aWRlcyB0aGUgaGFzaGVk IHZhbHVlLCB0aGF0IGlzIHdoYXQgaXQgaXMuIE5laXRoZXIgaW5mby1tb2RlbCBub3IgYmFiZWwt aG1hYyBjYXJlIG9yIGtub3cgb3IgbmVlZA0KIHRvIGtub3cgYWJvdXQgdGhpcy48YnI+DQpJZiBh IGJhYmVsLWhtYWMgaW1wbGVtZW50YXRpb24gZG9lcyBoYXZlIHNwZWNpYWwgaGFuZGxpbmcgZm9y IGxvbmdlciBzdHJpbmdzLCB0aGF0J3MgZmluZSwgdG9vLiBCdXQgYSB2YWx1ZSBjb21pbmcgZnJv bSBpbmZvLW1vZGVsIHdpbGwgbmV2ZXIgdHJpZ2dlciB0aGlzIHNwZWNpYWwgY29kZS48YnI+DQpE b2VzIHRoYXQgc291bmQgcmlnaHQ/PGJyPg0KQmFyYmFyYTxicj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KYmFiZWwgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmJhYmVsQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ YmFiZWxAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5m b19iYWJlbCZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj1M b0d6aEMtOHNjOFNZOFRxNHZyZm9nJmFtcDttPXI0ZEtXMEhOU3JqTlBYZFhJZEpfM2tHYzNYclJJ eGRCYWM2MER1YTlGOVEmYW1wO3M9NWhVTmo2LVZkektfTnFjUF9qT09vUkp1UV9XMzg4djVZVDZa bDJScXhEZyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2JhYmVsPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_2D09D61DDFA73D4C884805CC7865E6114E279084GAALPA1MSGUSRBF_-- From nobody Fri Aug 16 08:03:57 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 8461E12008D for ; Fri, 16 Aug 2019 08:03:55 -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 c25rJlxnvW-L for ; Fri, 16 Aug 2019 08:03:53 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3905E120047 for ; Fri, 16 Aug 2019 08:03:53 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7GF2qwX029023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Aug 2019 17:02:52 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x7GF2p2s025221; Fri, 16 Aug 2019 17:02:52 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 786CD568A3; Fri, 16 Aug 2019 17:02:54 +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 KWI4QiiX3L6c; Fri, 16 Aug 2019 17:02:53 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B2B08568A0; Fri, 16 Aug 2019 17:02:51 +0200 (CEST) Date: Fri, 16 Aug 2019 17:02:51 +0200 Message-ID: <87pnl5i25g.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: "STARK, BARBARA H" , "babel@ietf.org" In-Reply-To: References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> <87ftm3u0a6.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269981@GAALPA1MSGUSRBF.ITServices.sbc.com> <87blwrtudx.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E275E65@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Fri, 16 Aug 2019 17:02:52 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 16 Aug 2019 17:02:52 +0200 (CEST) X-Miltered: at korolev with ID 5D56C59C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D56C59B.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D56C59C.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D56C59B.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 : 5D56C59C.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D56C59B.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] info-model: preparing -09 on github 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, 16 Aug 2019 15:03:55 -0000 Barbara suggested: > This value is of a length suitable for the associated > babel-mac-key-algorithm. If the algorithm is based on the HMAC > construction, the length MUST be between 0 and the block size of the > underlying hash inclusive (where "HMAC-SHA256" block size is 64 bytes as > described in {{RFC4868}}). If the algorithm is "BLAKE2s", the length > MUST be between 0 and 32 bytes inclusive, as described in {{RFC7693}}. I fully support this formulation. David commented: > However, according to RFC 6234, HMAC-SHA-256 allows all key lengths kk where 0 > <= kk. I don't think the information model should express an opinion as to > whether keys longer than 64 bytes are safe or not. What is suggested by 6234 is to hash longer keys. By doing that, we'd be implying that Babel-HMAC is suitable for use with a human-entered keyphrase. Since Babel-HMAC is trivially vulnerable to brute-force attacks, this is not a good idea. (I'll add a few words on this subject to the security considerations of Babel-MAC.) Ideally, Babel-HMAC should be used with a randomly drawn key. In this case, the person drawing the key can draw a key of arbitrary length, and 32 bytes is a good choice for both algorithms. (Using a key larger than the hash size, while technically possible, does not increase security to my knowledge.) If use of a passphrase is desired, then the key should be derived using a KDF that makes brute-force attacks difficult, such as PBKDF2 or bcrypt. In that case, the original passphrase should be kept on a secure host (e.g. the network administator's carefully secured laptop), and only the resulting key be communicated through the management interface. Since key derivation functions are parametrisable in the size of the output key, the hashing procedure described for HMAC is not used. Finally, our goal is to get these protocols deployed by real people; thus, we should not forbid the use of short keys for testing. A UI should perhaps display a warning for a key with low entropy (either a short key or a key that contains multiple repeated strings, e.g. 123412341234...), but it should not prevent if from being used. In conclusion, Barbara's formulation above suits me. If you wish to change it, please preserve the two following properties: - make it clear that it's a key, not a passphrase; - allow short keys. -- Juliusz From nobody Fri Aug 16 08:08:27 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 54D35120047 for ; Fri, 16 Aug 2019 08:08:26 -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 6XX_Giffq4z5 for ; Fri, 16 Aug 2019 08:08:25 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7C2120052 for ; Fri, 16 Aug 2019 08:08:24 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7GF8GVX030679; Fri, 16 Aug 2019 17:08:16 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5AD85568E2; Fri, 16 Aug 2019 17:08:19 +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 P2Y3EP_AEpVc; Fri, 16 Aug 2019 17:08:18 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 750FE568E0; Fri, 16 Aug 2019 17:08:18 +0200 (CEST) Date: Fri, 16 Aug 2019 17:08:18 +0200 Message-ID: <87mug9i1wd.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'David Schinazi'" , "'babel@ietf.org'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E27796E@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> <87ftm3u0a6.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269981@GAALPA1MSGUSRBF.ITServices.sbc.com> <87blwrtudx.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E275E65@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114E27796E@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=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]); Fri, 16 Aug 2019 17:08:16 +0200 (CEST) X-Miltered: at korolev with ID 5D56C6E0.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D56C6E0.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 : 5D56C6E0.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] info-model: preparing -09 on github 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, 16 Aug 2019 15:08:26 -0000 > I don’t know how advisable that is in a Babel usage scenario. For testing. A 0-length key is a good way to signal the fact that this key is for testing and should not be used in production. Using the key 74657374 (which is the ASCII representation of the string "test") makes the message less obvious. -- Juliusz From nobody Fri Aug 16 12:42: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 9BC5012081A for ; Fri, 16 Aug 2019 12:42:45 -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 AKOHN3Wzujci for ; Fri, 16 Aug 2019 12:42:43 -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 BC99112080C for ; Fri, 16 Aug 2019 12:42:43 -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 x7GJdqQq047917; Fri, 16 Aug 2019 15:42:40 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2ue2pt0gbp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Aug 2019 15:42:40 -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 x7GJgdnU011099; Fri, 16 Aug 2019 15:42:39 -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 x7GJgZTg010983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Aug 2019 15:42:35 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id D6D054009E72; Fri, 16 Aug 2019 19:42:35 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30484.vci.att.com (Service) with ESMTPS id C46284000358; Fri, 16 Aug 2019 19:42:35 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.177]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0439.000; Fri, 16 Aug 2019 15:42:35 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" , "'David Schinazi'" CC: "'babel@ietf.org'" Thread-Topic: [babel] info-model: preparing -09 on github Thread-Index: AdVSswKr0W4Y1vOsQfS00DtIY7BoYgAM83CAAAdXLCD//+jbAP//C3uggAKFBgCAAUiwgP//9U3Q Date: Fri, 16 Aug 2019 19:42:35 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E279DAD@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> <87ftm3u0a6.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269981@GAALPA1MSGUSRBF.ITServices.sbc.com> <87blwrtudx.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E275E65@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnl5i25g.wl-jch@irif.fr> In-Reply-To: <87pnl5i25g.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.216.153] 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-08-16_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=674 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908160199 Archived-At: Subject: Re: [babel] info-model: preparing -09 on github 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, 16 Aug 2019 19:42:46 -0000 > Barbara suggested: >=20 > > This value is of a length suitable for the associated > > babel-mac-key-algorithm. If the algorithm is based on the HMAC > > construction, the length MUST be between 0 and the block size of the > > underlying hash inclusive (where "HMAC-SHA256" block size is 64 bytes > > as described in {{RFC4868}}). If the algorithm is "BLAKE2s", the > > length MUST be between 0 and 32 bytes inclusive, as described in > {{RFC7693}}. >=20 > I fully support this formulation. I'm happy to go with this. I'm putting it in my editor's copy. Barbara From nobody Fri Aug 16 13:27: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 20110120113 for ; Fri, 16 Aug 2019 13:27:02 -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 2wk6dOMXMFQu for ; Fri, 16 Aug 2019 13:27:00 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C53120018 for ; Fri, 16 Aug 2019 13:27:00 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id f9so6347498ljc.13 for ; Fri, 16 Aug 2019 13:27:00 -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=u6EKiIz9rGJQstWIJ3gH9e8BwXmyL/U6F1EsvY5t3kI=; b=M+GaTiE7fdmF15mH7JSJ82SmuOpGUrtA6U2jawI4OJ90WTQnTyOGuF5UjLkOkgTKLv IqZGO/+u0Siqo/lvK2BlMNzsfc66rbSfPAKf5VnRWmNiHtaNdU1vuMVLZgosz+T3yqVD R892M6KqSJJna5CRmdI3m5ud6IdWur+UU7GAVvVV2rVFGO+h/z8L+oBUr15wZVWzR3iC nN2dXL/Xa78CSv9g+SwhK5GTZzYYg1ZNDEiCCu69UlJNtWhOWpfrtj3sH/ERkUit9hbc Ni36xUfY7bTGaiRm8t704oNivIblGoWqYwRqrsBXTgfGn7U2q6+ejLPWBkr0ohOOOfdB NeRA== 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=u6EKiIz9rGJQstWIJ3gH9e8BwXmyL/U6F1EsvY5t3kI=; b=scw+cAVhqFbA6vhcsioP1Lsvftw5clk8aLd2maznHCc7Ntv3C9RHgwToKYyVSGqItU XOUxM785tPeScDnR3NoVLNPnSaThb/NPd97ySM1m0bdAmf/BOw/A07BR+9mgVyweHccz 5UKyVl8EjXkTOszbVoMTIHwVQMsp/n7WUQjoijLCMkFhg08BEiPKs0NNjU0dIoJxsgoW GCdhhQOKvL7vCTjgglp3J6txrsrVBdYjGfIokbXJWfFBsAYbCFduV3loAXmKczLxchDF 6UOvJRLLMtJfDFjwpSb9pQiHpa/QbRaOLCTn3W803nRlOC3Mo3KSjZEs45uAvjtieVuv Jmdg== X-Gm-Message-State: APjAAAVRTxNWGw32fUWarHwkHPPnUItIiaxgCsLgptkMN4+nkzquOetX GzTmQrYpaq5bjeWYCOM7nHl0b0bKwUDt/x4jRQ0= X-Google-Smtp-Source: APXvYqyz6ljEGQd/y1Rnb2KAP5of9OIFPfG7NiDNZq3CGjA5Fr4omURseB5uheCpEVLaqGWYtVjcAbp8umod7h2gxPI= X-Received: by 2002:a2e:81c3:: with SMTP id s3mr6573486ljg.70.1565987218542; Fri, 16 Aug 2019 13:26:58 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> <87ftm3u0a6.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269981@GAALPA1MSGUSRBF.ITServices.sbc.com> <87blwrtudx.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E275E65@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnl5i25g.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E279DAD@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E279DAD@GAALPA1MSGUSRBF.ITServices.sbc.com> From: David Schinazi Date: Fri, 16 Aug 2019 13:26:47 -0700 Message-ID: To: "STARK, BARBARA H" Cc: Juliusz Chroboczek , "babel@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e25523059041cf63" Archived-At: Subject: Re: [babel] info-model: preparing -09 on github 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, 16 Aug 2019 20:27:02 -0000 --000000000000e25523059041cf63 Content-Type: text/plain; charset="UTF-8" I'm getting a sense that I'm in the rough here. I don't feel too strongly about this issue, and I can live with this choice even though it's not my favorite. Thanks for letting me say my piece, and considering it as an option. David On Fri, Aug 16, 2019 at 12:42 PM STARK, BARBARA H wrote: > > Barbara suggested: > > > > > This value is of a length suitable for the associated > > > babel-mac-key-algorithm. If the algorithm is based on the HMAC > > > construction, the length MUST be between 0 and the block size of the > > > underlying hash inclusive (where "HMAC-SHA256" block size is 64 bytes > > > as described in {{RFC4868}}). If the algorithm is "BLAKE2s", the > > > length MUST be between 0 and 32 bytes inclusive, as described in > > {{RFC7693}}. > > > > I fully support this formulation. > > I'm happy to go with this. I'm putting it in my editor's copy. > Barbara > --000000000000e25523059041cf63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm getting a sense that I'm in the rough here. I = don't feel too strongly about this issue, and I can live with this choi= ce even though it's not my favorite. Thanks for letting me say my piece= , and considering it as an option.

David

=
On Fri, Au= g 16, 2019 at 12:42 PM STARK, BARBARA H <bs7652@att.com> wrote:
> Barbara suggested:
>
> > This value is of a length suitable for the associated
> > babel-mac-key-algorithm.=C2=A0 If the algorithm is based on the H= MAC
> > construction, the length MUST be between 0 and the block size of = the
> > underlying hash inclusive (where "HMAC-SHA256" block si= ze is 64 bytes
> > as described in {{RFC4868}}).=C2=A0 If the algorithm is "BLA= KE2s", the
> > length MUST be between 0 and 32 bytes inclusive, as described in<= br> > {{RFC7693}}.
>
> I fully support this formulation.

I'm happy to go with this. I'm putting it in my editor's copy.<= br> Barbara
--000000000000e25523059041cf63-- From nobody Fri Aug 16 13:38:29 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 8493B12008B for ; Fri, 16 Aug 2019 13:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taDabV9wB6fv for ; Fri, 16 Aug 2019 13:38:26 -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 12D66120018 for ; Fri, 16 Aug 2019 13:38:26 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7GKbNww013344 for ; Fri, 16 Aug 2019 16:38:25 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 2ue2qwsrt0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 16 Aug 2019 16:38:23 -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 x7GKcNIM021339 for ; Fri, 16 Aug 2019 16:38:23 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7GKcIxT021244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 16 Aug 2019 16:38:19 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 0CC584009E67 for ; Fri, 16 Aug 2019 20:38:18 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30487.vci.att.com (Service) with ESMTPS id ED4BA4009E66 for ; Fri, 16 Aug 2019 20:38:17 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.177]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0439.000; Fri, 16 Aug 2019 16:38:16 -0400 From: "STARK, BARBARA H" To: "'babel@ietf.org'" Thread-Topic: info-model: new editor copy Thread-Index: AdVUcBoX1yGJvKp/S6mpnwDkeKli1g== Date: Fri, 16 Aug 2019 20:38:16 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E27A043@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.216.153] 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-08-16_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=988 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908160207 Archived-At: Subject: [babel] info-model: new editor copy 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, 16 Aug 2019 20:38:27 -0000 Editor copy: https://bhstark2.github.io/babel-information-model/draft-ietf-= babel-information-model.html Diffs from -08: http://tools.ietf.org//rfcdiff?url1=3Dhttps://www.ietf.org/= id/draft-ietf-babel-information-model-08.txt&url2=3Dhttps://bhstark2.github= .io/babel-information-model/draft-ietf-babel-information-model.txt Changes from the previous editor copy to this one: babel-interface-split-horizon: Added reference to rfc6126bis. Added "An implementation MAY choose to expose this parameter as read-onl= y ("ro")." at end, consistent with other similar parameters. In intro, changed "... an implementation attempting to comply with..." to "= ... an implementation claiming compliance with..." Added references to rfc6126bis for "2-out-of-3" and "ETX" to babel-metric-c= omp-algorithms. Changed "may" to "MAY" in cases of: "...the data model MAY use a different = data type that allows differentiation between zero (0) and NULL." Deleted babel-mac-algorithm from interfaces object (I'd missed deleting it = from there previously) Added description of babel-mac-key-value length, as discussed Barbara From nobody Fri Aug 16 13:56: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 2394D12086C for ; Fri, 16 Aug 2019 13:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_3QNF3-ukpd for ; Fri, 16 Aug 2019 13:56:32 -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 DEC76120899 for ; Fri, 16 Aug 2019 13:56:31 -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 x7GKmG1v021150; Fri, 16 Aug 2019 16:56:28 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2ue2pt2494-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Aug 2019 16:56:19 -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 x7GKta5b014735; Fri, 16 Aug 2019 16:55:36 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7GKtU31014604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Aug 2019 16:55:30 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 9954E4009E7B; Fri, 16 Aug 2019 20:55:30 +0000 (GMT) Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (unknown [130.8.218.152]) by zlp30488.vci.att.com (Service) with ESMTPS id 8372A4009E65; Fri, 16 Aug 2019 20:55:30 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.177]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0439.000; Fri, 16 Aug 2019 16:55:30 -0400 From: "STARK, BARBARA H" To: "'David Schinazi'" CC: "'babel@ietf.org'" , "'Juliusz Chroboczek'" Thread-Topic: [babel] info-model: preparing -09 on github Thread-Index: AdVSswKr0W4Y1vOsQfS00DtIY7BoYgAM83CAAAdXLCD//+jbAP//C3uggAKFBgCAAUiwgP//9U3QgABlNYCAAD+U0A== Date: Fri, 16 Aug 2019 20:55:29 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E27A10F@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> <87ftm3u0a6.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269981@GAALPA1MSGUSRBF.ITServices.sbc.com> <87blwrtudx.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E275E65@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnl5i25g.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E279DAD@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.216.153] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6114E27A10FGAALPA1MSGUSRBF_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-16_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908160211 Archived-At: Subject: Re: [babel] info-model: preparing -09 on github 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, 16 Aug 2019 20:56:39 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6114E27A10FGAALPA1MSGUSRBF_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBpdCBtYXkgYmUgdXNlZnVsIHRvIHB1dCBzb21lIGFkZGl0aW9uYWwgdGV4dCBpbiB0 aGUgaW5mby1tb2RlbCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyAoc2ltaWxhciB0byB3aGF0IEp1 bGl1c3ogc3VnZ2VzdHMgZm9yIGJhYmVsLWhtYWMpLg0KRm9sbG93aW5nIGFyZSBzb21lIG9mIHRo ZSBwb2ludHM6DQoNCiAgKiAgIEV4cGxhaW4gdGhhdCB1c2luZyBBU0NJSSBmcm9tIHVzZXItaW5w dXQgdGV4dCBhcyBhIE1BQyBrZXkgZm9yIHByb2R1Y3Rpb24gc3lzdGVtcyBpc27igJl0IHJlY29t bWVuZGVkLg0KICAqICAgTGVuZ3RoIG9mIGtleXMgZm9yIEhNQUMgYWxnb3JpdGhtcyBpcyByZXN0 cmljdGVkIHRvIHRoZSBibG9jayBzaXplIGZvciB0aGUgYWxnb3JpdGhtLCBiZWNhdXNlIHRoZSBh bGdvcml0aG0gd2lsbCBzaW1wbHkgaGFzaCBhIGxvbmdlciBrZXkgZG93biB0byB0aGUgYmxvY2sg c2l6ZS4NCiAgKiAgIFplcm8gbGVuZ3RoIGtleXMgYXJlIGEgcmVhbGx5IGJhZCBpZGVhIGZvciBh IHByb2R1Y3Rpb24gc3lzdGVtLCBidXQgYXJlIHN1cHBvcnRlZCBmb3IgdGVzdGluZyBwdXJwb3Nl cy4NCiAgKiAgIEN1cnJlbnQgcmVjb21tZW5kZWQgYmVzdCBwcmFjdGljZXMgZnJvbSBOSVNUIGFy ZSB0byB1c2UgbGVuZ3RoIG9mIGF0IGxlYXN0IDE2IGJ5dGVzIGZvciBTSEEtMjU2LiBJdOKAmXMg YSBnb29kIGlkZWEgdG8gaWRlbnRpZnkgYW5kIHVzZSBiZXN0IHByYWN0aWNlIHJlY29tbWVuZGF0 aW9ucyBmb3Iga2V5IGxlbmd0aCBhbmQgY29tcGxleGl0eS4NCiAgKiAgIFJlYWQgYmFiZWwtaG1h YyBhbmQgc3BlY2lmaWNhdGlvbnMgZGVmaW5pbmcgTUFDIGFsZ29yaXRobSBmb3IgYWRkaXRpb25h bCBzZWN1cml0eSBhZHZpY2UgYXJvdW5kIGtleXMuDQogICogICBSZWFkIGJhYmVsLWR0bHMgYW5k IERUTFMgc3BlY2lmaWNhdGlvbnMgZm9yIGFkZGl0aW9uYWwgc2VjdXJpdHkgYWR2aWNlIGluIHVz aW5nIERUTFMuDQoNCkJhcmJhcmENCg0KRnJvbTogYmFiZWwgPGJhYmVsLWJvdW5jZXNAaWV0Zi5v cmc+IE9uIEJlaGFsZiBPZiBEYXZpZCBTY2hpbmF6aQ0KU2VudDogRnJpZGF5LCBBdWd1c3QgMTYs IDIwMTkgNDoyNyBQTQ0KVG86IFNUQVJLLCBCQVJCQVJBIEggPGJzNzY1MkBhdHQuY29tPg0KQ2M6 IGJhYmVsQGlldGYub3JnOyBKdWxpdXN6IENocm9ib2N6ZWsgPGpjaEBpcmlmLmZyPg0KU3ViamVj dDogUmU6IFtiYWJlbF0gaW5mby1tb2RlbDogcHJlcGFyaW5nIC0wOSBvbiBnaXRodWINCg0KSSdt IGdldHRpbmcgYSBzZW5zZSB0aGF0IEknbSBpbiB0aGUgcm91Z2ggaGVyZS4gSSBkb24ndCBmZWVs IHRvbyBzdHJvbmdseSBhYm91dCB0aGlzIGlzc3VlLCBhbmQgSSBjYW4gbGl2ZSB3aXRoIHRoaXMg Y2hvaWNlIGV2ZW4gdGhvdWdoIGl0J3Mgbm90IG15IGZhdm9yaXRlLiBUaGFua3MgZm9yIGxldHRp bmcgbWUgc2F5IG15IHBpZWNlLCBhbmQgY29uc2lkZXJpbmcgaXQgYXMgYW4gb3B0aW9uLg0KDQpE YXZpZA0KDQpPbiBGcmksIEF1ZyAxNiwgMjAxOSBhdCAxMjo0MiBQTSBTVEFSSywgQkFSQkFSQSBI IDxiczc2NTJAYXR0LmNvbTxtYWlsdG86YnM3NjUyQGF0dC5jb20+PiB3cm90ZToNCj4gQmFyYmFy YSBzdWdnZXN0ZWQ6DQo+DQo+ID4gVGhpcyB2YWx1ZSBpcyBvZiBhIGxlbmd0aCBzdWl0YWJsZSBm b3IgdGhlIGFzc29jaWF0ZWQNCj4gPiBiYWJlbC1tYWMta2V5LWFsZ29yaXRobS4gIElmIHRoZSBh bGdvcml0aG0gaXMgYmFzZWQgb24gdGhlIEhNQUMNCj4gPiBjb25zdHJ1Y3Rpb24sIHRoZSBsZW5n dGggTVVTVCBiZSBiZXR3ZWVuIDAgYW5kIHRoZSBibG9jayBzaXplIG9mIHRoZQ0KPiA+IHVuZGVy bHlpbmcgaGFzaCBpbmNsdXNpdmUgKHdoZXJlICJITUFDLVNIQTI1NiIgYmxvY2sgc2l6ZSBpcyA2 NCBieXRlcw0KPiA+IGFzIGRlc2NyaWJlZCBpbiB7e1JGQzQ4Njh9fSkuICBJZiB0aGUgYWxnb3Jp dGhtIGlzICJCTEFLRTJzIiwgdGhlDQo+ID4gbGVuZ3RoIE1VU1QgYmUgYmV0d2VlbiAwIGFuZCAz MiBieXRlcyBpbmNsdXNpdmUsIGFzIGRlc2NyaWJlZCBpbg0KPiB7e1JGQzc2OTN9fS4NCj4NCj4g SSBmdWxseSBzdXBwb3J0IHRoaXMgZm9ybXVsYXRpb24uDQoNCkknbSBoYXBweSB0byBnbyB3aXRo IHRoaXMuIEknbSBwdXR0aW5nIGl0IGluIG15IGVkaXRvcidzIGNvcHkuDQpCYXJiYXJhDQo= --_000_2D09D61DDFA73D4C884805CC7865E6114E27A10FGAALPA1MSGUSRBF_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE5Njg1ODg1MTc7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzI3MjY0NDAyIDEzOTI0MDU5OTYg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoz MjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJbWFyZ2luLWxlZnQ6MjAuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2Fs aWJyaTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjU2LjI1cHQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjkyLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6 MTI4LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE2NC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN CgltYXJnaW4tbGVmdDoyMDAuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMzYuMjVw dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjcyLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdp bi1sZWZ0OjMwOC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgdGhpbmsgaXQgbWF5IGJlIHVzZWZ1bCB0byBwdXQgc29tZSBhZGRpdGlvbmFsIHRleHQgaW4g dGhlIGluZm8tbW9kZWwgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgKHNpbWlsYXIgdG8gd2hhdCBK dWxpdXN6IHN1Z2dlc3RzIGZvciBiYWJlbC1obWFjKS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Rm9sbG93aW5nIGFyZSBzb21lIG9mIHRoZSBwb2ludHM6PG86cD48L286 cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi0xNS43NXB0O21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj4NCkV4cGxhaW4gdGhhdCB1c2luZyBBU0NJSSBmcm9tIHVzZXItaW5w dXQgdGV4dCBhcyBhIE1BQyBrZXkgZm9yIHByb2R1Y3Rpb24gc3lzdGVtcyBpc27igJl0IHJlY29t bWVuZGVkLg0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi0xNS43NXB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkxlbmd0 aCBvZiBrZXlzIGZvciBITUFDIGFsZ29yaXRobXMgaXMgcmVzdHJpY3RlZCB0byB0aGUgYmxvY2sg c2l6ZSBmb3IgdGhlIGFsZ29yaXRobSwgYmVjYXVzZSB0aGUgYWxnb3JpdGhtIHdpbGwgc2ltcGx5 IGhhc2ggYSBsb25nZXIga2V5IGRvd24gdG8gdGhlIGJsb2NrIHNpemUuPG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi0xNS43NXB0 O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClplcm8gbGVuZ3RoIGtleXMgYXJlIGEgcmVhbGx5 IGJhZCBpZGVhIGZvciBhIHByb2R1Y3Rpb24gc3lzdGVtLCBidXQgYXJlIHN1cHBvcnRlZCBmb3Ig dGVzdGluZyBwdXJwb3Nlcy4NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDotMTUuNzVwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+DQpDdXJyZW50IHJlY29tbWVuZGVkIGJlc3QgcHJhY3RpY2VzIGZyb20gTklTVCBhcmUgdG8g dXNlIGxlbmd0aCBvZiBhdCBsZWFzdCAxNiBieXRlcyBmb3IgU0hBLTI1Ni4gSXTigJlzIGEgZ29v ZCBpZGVhIHRvIGlkZW50aWZ5IGFuZCB1c2UgYmVzdCBwcmFjdGljZSByZWNvbW1lbmRhdGlvbnMg Zm9yIGtleSBsZW5ndGggYW5kIGNvbXBsZXhpdHkuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi0xNS43NXB0O21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NClJlYWQgYmFiZWwtaG1hYyBhbmQgc3BlY2lmaWNhdGlvbnMgZGVmaW5p bmcgTUFDIGFsZ29yaXRobSBmb3IgYWRkaXRpb25hbCBzZWN1cml0eSBhZHZpY2UgYXJvdW5kIGtl eXMuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi0xNS43NXB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClJlYWQgYmFiZWwt ZHRscyBhbmQgRFRMUyBzcGVjaWZpY2F0aW9ucyBmb3IgYWRkaXRpb25hbCBzZWN1cml0eSBhZHZp Y2UgaW4gdXNpbmcgRFRMUy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFyYmFyYTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBiYWJlbCAmbHQ7YmFiZWwtYm91 bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCkRhdmlkIFNjaGluYXppPGJy Pg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXVndXN0IDE2LCAyMDE5IDQ6MjcgUE08YnI+DQo8Yj5U bzo8L2I+IFNUQVJLLCBCQVJCQVJBIEggJmx0O2JzNzY1MkBhdHQuY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gYmFiZWxAaWV0Zi5vcmc7IEp1bGl1c3ogQ2hyb2JvY3playAmbHQ7amNoQGlyaWYuZnIm Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbYmFiZWxdIGluZm8tbW9kZWw6IHByZXBhcmlu ZyAtMDkgb24gZ2l0aHViPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSdtIGdldHRpbmcgYSBzZW5zZSB0aGF0IEknbSBpbiB0aGUgcm91Z2ggaGVyZS4gSSBk b24ndCBmZWVsIHRvbyBzdHJvbmdseSBhYm91dCB0aGlzIGlzc3VlLCBhbmQgSSBjYW4gbGl2ZSB3 aXRoIHRoaXMgY2hvaWNlIGV2ZW4gdGhvdWdoIGl0J3Mgbm90IG15IGZhdm9yaXRlLiBUaGFua3Mg Zm9yIGxldHRpbmcgbWUgc2F5IG15IHBpZWNlLCBhbmQgY29uc2lkZXJpbmcgaXQgYXMgYW4gb3B0 aW9uLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGF2aWQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g RnJpLCBBdWcgMTYsIDIwMTkgYXQgMTI6NDIgUE0gU1RBUkssIEJBUkJBUkEgSCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmJzNzY1MkBhdHQuY29tIj5iczc2NTJAYXR0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jmd0OyBCYXJiYXJhIHN1Z2dlc3RlZDo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGlzIHZh bHVlIGlzIG9mIGEgbGVuZ3RoIHN1aXRhYmxlIGZvciB0aGUgYXNzb2NpYXRlZDxicj4NCiZndDsg Jmd0OyBiYWJlbC1tYWMta2V5LWFsZ29yaXRobS4mbmJzcDsgSWYgdGhlIGFsZ29yaXRobSBpcyBi YXNlZCBvbiB0aGUgSE1BQzxicj4NCiZndDsgJmd0OyBjb25zdHJ1Y3Rpb24sIHRoZSBsZW5ndGgg TVVTVCBiZSBiZXR3ZWVuIDAgYW5kIHRoZSBibG9jayBzaXplIG9mIHRoZTxicj4NCiZndDsgJmd0 OyB1bmRlcmx5aW5nIGhhc2ggaW5jbHVzaXZlICh3aGVyZSAmcXVvdDtITUFDLVNIQTI1NiZxdW90 OyBibG9jayBzaXplIGlzIDY0IGJ5dGVzPGJyPg0KJmd0OyAmZ3Q7IGFzIGRlc2NyaWJlZCBpbiB7 e1JGQzQ4Njh9fSkuJm5ic3A7IElmIHRoZSBhbGdvcml0aG0gaXMgJnF1b3Q7QkxBS0UycyZxdW90 OywgdGhlPGJyPg0KJmd0OyAmZ3Q7IGxlbmd0aCBNVVNUIGJlIGJldHdlZW4gMCBhbmQgMzIgYnl0 ZXMgaW5jbHVzaXZlLCBhcyBkZXNjcmliZWQgaW48YnI+DQomZ3Q7IHt7UkZDNzY5M319Ljxicj4N CiZndDsgPGJyPg0KJmd0OyBJIGZ1bGx5IHN1cHBvcnQgdGhpcyBmb3JtdWxhdGlvbi48YnI+DQo8 YnI+DQpJJ20gaGFwcHkgdG8gZ28gd2l0aCB0aGlzLiBJJ20gcHV0dGluZyBpdCBpbiBteSBlZGl0 b3IncyBjb3B5Ljxicj4NCkJhcmJhcmE8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2D09D61DDFA73D4C884805CC7865E6114E27A10FGAALPA1MSGUSRBF_-- From nobody Fri Aug 16 15:53:41 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 A8E7A120113; Fri, 16 Aug 2019 15:53: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 Tse5IuSDlE10; Fri, 16 Aug 2019 15:53: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 696211200F8; Fri, 16 Aug 2019 15:53:37 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7GMrPoL030379; Sat, 17 Aug 2019 00:53:25 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 93C9D57422; Sat, 17 Aug 2019 00:53:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id BcgLTXYFdts4; Sat, 17 Aug 2019 00:53:27 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E826F57420; Sat, 17 Aug 2019 00:53:22 +0200 (CEST) Date: Sat, 17 Aug 2019 00:53:23 +0200 Message-ID: <87blwoiuxo.wl-jch@irif.fr> From: Juliusz Chroboczek To: Roman Danyliw Cc: Donald Eastlake , "babel-chairs@ietf.org" , The IESG , "babel@ietf.org" , "draft-ietf-babel-hmac@ietf.org" In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B3402CA5@marchand> References: <156520650683.8432.7109781814790904901.idtracker@ietfa.amsl.com> <87v9v7wyzz.wl-jch@irif.fr> <359EC4B99E040048A7131E0F4E113AFC01B3402CA5@marchand> 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, 17 Aug 2019 00:53:26 +0200 (CEST) X-Miltered: at korolev with ID 5D5733E5.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D5733E5.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 : 5D5733E5.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] Roman Danyliw's Discuss on draft-ietf-babel-hmac-08: (with DISCUSS and COMMENT) 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, 16 Aug 2019 22:53:40 -0000 > Ah, I see it now in Section 4.3 Thanks for the pointer. This text > explains the issues of around keys processing. I couldn't explicitly > find text explaining when multiple HMAC TLVs should be sent. Where > should I be looking? Section 5 (key rotation), formerly Appendix A: In order to perform key rotation, the new key is added to all the nodes; once this is done, both the old and the new key are sent in all packets, and packets are accepted if they are properly signed by either of the keys. At that point, the old key is removed. >> I'm leaving this sentence as is -- after trying it out, I don't think that >> mentioning the small amount of state caused by reception of a UDP packet >> (an ND entry) is informative. > I'm not tracking. "Whatsoever" is an absolute statement. By all means > caveat the sentence by saying no local Babel state (or something to that > effect). Done. >>> (8) Section 1. Per the “spoof of a malformed packet”, how would an >>> HMAC address this? Even assuming that a node discards the message >>> without processing if the HMAC is bad, this would still be a problem >>> from a malicious peer. >> Please explain. > The initial situation I had in mind was if there was a compromised Babel > node. It will have the key to produce a valid HMAC on the crafted > packet to cause the peer Babel node to process the packet. Yes, this protocol assumes that only honest nodes know the secret key. We make no guarantees, not even of any kind, if you've lost your keys. > Another situation which would not involve a malicious Babel node with > the key is a node running a buggy Babel implementation. Imagine this > implementation has some kind of (buffer overflow) vulnerability in the > routines which parses the packet payload to find the HMAC TLV. In the > worst circumstance, this could hypothetically compromise the Babel node > even before the code to verified HMAC and choose to discard the packet > or not is made. Yes, it could. That is the reason why HMAC keys sit in the packet trailer rather than in the packet body: you may use a simplified parser that is only able to parse the packet trailer. This parser does not modify any global state, it does not modify the packet (there's no need to clear the MAC before recomputing it), and it just returns one bit of information. You are expected to vet this specialised parser very carefully, or even run it out-of-process. This was debated by the WG; however, once both Toke (BIRD) and Weronika and Clara (babeld) had implemented parsing the packet trailer, we agreed that this approach makes the implementation much simpler and less error-prone. -- Juliusz From nobody Fri Aug 16 16:51:35 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 4C73A120113 for ; Fri, 16 Aug 2019 16:51:34 -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 4Ow2r9KNoKyn for ; Fri, 16 Aug 2019 16:51:33 -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 EEC4B1200EC for ; Fri, 16 Aug 2019 16:51:32 -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 x7GNpSwX005660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 17 Aug 2019 01:51:28 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x7GNpSLP020112 for ; Sat, 17 Aug 2019 01:51:28 +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 F1455574E4 for ; Sat, 17 Aug 2019 01:51:30 +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 BdrgQbAZqGJG for ; Sat, 17 Aug 2019 01:51:30 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0ED9C574E2 for ; Sat, 17 Aug 2019 01:51:29 +0200 (CEST) Date: Sat, 17 Aug 2019 01:51:29 +0200 Message-ID: <87blwozn26.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 17 Aug 2019 01:51:28 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 17 Aug 2019 01:51:28 +0200 (CEST) X-Miltered: at korolev with ID 5D574180.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D574180.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D574180.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D574180.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 : 5D574180.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D574180.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] MAC: rate limit challenge replies 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, 16 Aug 2019 23:51:34 -0000 Since we are limiting challenge requests, it makes no harm to limit challenge replies, and it increases our resistence to DoS. I've added the following text to the MAC draft: Since a challenge reply might be caused by a replayed challenge request, a node MUST impose a rate limitation to the challenge replies it sends; the limit SHOULD default to one challenge reply for each peer every 300ms and MAY be configurable. I hope nobody objects. -- Juliusz From nobody Fri Aug 16 17:15: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 24356120113; Fri, 16 Aug 2019 17:15:18 -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 J9qktfiasrOT; Fri, 16 Aug 2019 17:15:15 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E8B1200DE; Fri, 16 Aug 2019 17:15:15 -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 x7H0FAQM008902; Sat, 17 Aug 2019 02:15:10 +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 D3C805750C; Sat, 17 Aug 2019 02:15:12 +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 EXcpaHQYPLS3; Sat, 17 Aug 2019 02:15:11 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E9EF75750A; Sat, 17 Aug 2019 02:15:09 +0200 (CEST) Date: Sat, 17 Aug 2019 02:15:10 +0200 Message-ID: <87a7c8ir5d.wl-jch@irif.fr> From: Juliusz Chroboczek To: Benjamin Kaduk Cc: The IESG , draft-ietf-babel-hmac@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <20190814194802.GB88236@kduck.mit.edu> References: <156521429138.8333.12124544758210076970.idtracker@ietfa.amsl.com> <87h86pcmzk.wl-jch@irif.fr> <20190814194802.GB88236@kduck.mit.edu> 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, 17 Aug 2019 02:15:10 +0200 (CEST) X-Miltered: at korolev with ID 5D57470E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D57470E.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 : 5D57470E.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] Benjamin Kaduk's Discuss on draft-ietf-babel-hmac-08: (with DISCUSS and COMMENT) 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, 17 Aug 2019 00:15:18 -0000 >>> Also in Section 3.1, if we are going to claim that a "random string of >>> sufficient length" suffices to initialize a fresh index, we need to >>> provide guidance on what constitutes "sufficient length" to achieve the >>> needed property. >> Section 6 says [...] > And you don't want to make a forward reference to Section 6? I don't want to, since it makes this section more difficult to read, but I have done so. >>> Blake2s is a keyed MAC, but is not an HMAC construction. [...] >> I disagree. > Well, I am pretty uncomfortable about saying things that are not true! Ok. I've changed HMAC to MAC throughout the document, after consulting the list. >> I agree. This is something that we considered in the design of the >> protocol (which is why Nonces are allowed to be so large), but never >> implemented ourselves; it would probably be some work to get it right. >> Hence the very careful formulation ("might"). Let me know if you want to >> suggest a different formulation. > It's probably okay to leave this as speculative (since there's not an > existence proof), but I think it's irresponsible to not also include a > disclaimer of at least "Note that such schemes will need to consider what > degree of "freshness" is required of a challenge and the risk of replay for > the encoded state, among other things". Added "note however that any such scheme will need to prevent cookie replay". (I've once implemented just such a scheme for the BitTorrent DHT, and it's been running on hundred of thousands of nodes for almost ten years now with no massive meltdown of the DHT; so I'm pretty confident it's not that difficult.) >>> This is a symmetric-keyed scenario, so most attacks that involve a >>> compromised node will be "uninteresting", in that once the key is >>> exposed all guarantees are lost. However, it may still be worth noting >>> that a compromised node can cause disruption on multi-access links >>> without detection since there is no "end of generation" signal when a >>> node changes its index. >> Are we misunderstanding each other? > A and C both have state about B, which is retained when B reboots. > While B is still rebooting or otherwise initializing, C can forge a message > "from" B that A will accept, and C can continue to do so until A sees the > new (legitimate) index from B and switches over to the new generation. So > A has accepted false input but neither A nor B are aware of it. Ah, I see. It's worse than that -- if C knows the key, then it can perform a higher seqno attack on B, it doesn't need to wait for B to reboot. >>> Is there any need for initial PC value randomization? >> I don't see why. > I don't, either, but just wanted to get a second opinion from an actual > expert. I hope that's not me. >>> Do we want to recommend starting at 0 or 1 (or prohibit recipients from >>> assuming that the initial value for an index will be that)? >> The initial value as well as the rate of increase are arbitrary. For >> example, a node may use a hardware clock (suitably offset to fit in 32 >> bits) as the PC. > I agree that they're arbitrary, but have a lot of painful experience with > protocol participants making assumptions about underspecified behavior that > ended up not being protocol invariants, with subsequent breakage. If you > think the existing ecosystem is healthy enough that there's not a real risk > of problems down the line, I can accept that, but I wanted to raise the > topic. The ecosystem is pretty young, but we haven't had any issues with interoperability yet. I think that it's fair to say that if you encode your age in the PC, you deserve any trouble you get. >>> Does this rekeying option require an external operation/management actor >>> to trigger it? It might be worth mentioning with some operational >>> considerations. >> Disagree. > I think my main quesetion here is who determines, and how, "whenever a > collision becomes likely". Some protocols have in-band mechanisms for > peers to make such a determination and initiate rekeying automatically; > from what I understand, babel-hmac does not. If we actually expect > deployments to encounter scenarios where rekeying is necessary to preserve > security, we should be pretty clear about who has the responsibility to do > so. I've changed this to "by rekeying often enough that collisions are unlikely". Here's some background. Babel's evolution until now has been driven by the needs of our users; this has led to two very interesting extensions (Source-specific and RTT), and two extensions that are not being deployed (diversity routing and ToS-specific). The security extensions, on the other hand, have been designed due to IETF requirements, and they have no users known to us. We are waiting for the community to react to the code being available to discuss key management with them. Options include: - static keying, rekeying never happens; - central node that performs periodic key rotation (this could be as simple as a cron job that uses ssh to distribute keys); - key negotiation using another protocol (e.g. HNCP, the Homenet thing). I'm keeping an open mind; the only thing I'm planning to refuse is in-band key distribution or negotiation -- Babel is a routing protocol, not a key distribution protocol. >> > o among different nodes, it is only vulnerable to immediate replay: >> > if a node A has accepted a packet from C as valid, then a node B >> > will only accept a copy of that packet as authentic if B has >> > accepted an older packet from C and B has received no later packet >> > from C. >> >> > nit: I don't think "A has accepted a packet from C" is quite the right >> > precondition; it seems to be more like "A has received a valid packet >> > from C", since whether or not A (as an attacker) considers it valid is >> > irrelevant to whether (honest) B will. >> >> C is the attacker here, A is honest. > I was (apparently) reading this differently -- "replay" could be initiated > by an RFC 3552 attacker in the network even without knowledge of the key. I see. Reworded, thanks. >>> Section 4.1 >> >>> If we had identifiers for symmetric keys or HMAC algorithms, we could >>> include those identifiers in the pseudo-header and thereby gain some >>> protection from downgrade/HMAC-stripping attacks in the presence of a >>> weak keyed MAC algorithm. >> This is a symmetric algorithm, for downgrade attacks to work the victim >> would need to be configured with a weak key. I therefore don't see how >> this added complexity helps. > I've seen plenty of cases where systems are still configured with > single-DES keys as well as AES keys (whoops!). Right. I'm not too concerned. We're only using MAC here, so the strength of the hash is not likely to be the limiting factor. We could be using MD2 here, and we'd still be reasonably secure. (And if someone implements this protocol with MD2 hashing, I'd like to hear from them.) >>> It might be worth reiterating that every time a packet goes on the wire, >>> it gets a fresh PC, regardless of whether it's a "retransmit" after a >>> timeout or a new message. >> There are no retransmits in this protocol. > Hence the scare quotes. Can you guarantee that no one will look at this > and say "I'll just cache this challenge I send to a peer and re-send it > (rate limited) to that peer in response to traffic I can't authenticate, > until I get a valid reply"? I cannot. From an implementation point of view, however, this would be way more complicated than the correct implementation. >>> Validating the HMACs is the sort of operation that we tend to recommend >>> be done in constnt-time to avoid side channel attacks. I don't have a >>> concrete attack handy here at the moment, though. >> I frankly have no idea if that's necessary or not. FWIW, the protocol is >> asynchronous, and there is jitter applied to packets. > My super-quick assessment is that the timing channel could be used to "pick > off byte by byte" an attacker's guess at the HMAC of some fixed plaintext > that the attacker would later replay (with valid HMAC) to some other > participant. We never compare keys -- we compare MACs. So perhaps you could gain some information about how many bytes of the (per-packet) MAC match, but that gives you no information about how many bytes of the key match. If you really insist, I can mandate constant-time comparison, but I feel it would be confusing for the reader to mandate it without being able to explain how it improves the protocol's security. >>> Any reason to not just drop the whole packet if there are multiple PCs >>> present? I see this is not rfc7298bis but don't know what level of >>> breaking change is reasonable. >> It doesn't matter much, it's a "cannot happen" case. (Note that the HMAC >> has already been validted at this point, so it isn't a security issue.) > Oh, it's definitely not a security issue; this is more of a philosophical > question of what to do in the face of a peer with a "totally broken" > implementation. I really don't think it makes much importance. Since this formulation has been accepted by the WG, I'd rather not go through getting a different approach accepted. > The TLS ecosystem, for example, has been bitten by the need for > historical compatibility quirks and is now (over?)compensating by being > quite strict about rejecting malformed things. Indeed, RFC 8446 is what nightmares are made off: Experience has shown that many servers do not properly implement version negotiation, leading to "version intolerance" in which the server rejects an otherwise acceptable ClientHello with a version number higher than it supports. >>> I'd suggest explicitly stating that if there is a challenge reply that >>> doesn't validate, the packet should be discarded. >> This is already the case -- a packet with an incorrect challenge reply is >> treated just like a packet with no challenge reply. > This was an attempt to "consider all the ways in which a peer could > misbehave": it could send two, one valid and one invalid; or an invalid > challenge reply even though it didn't need to supply one at all; or ... > (This is basically the same philosophical question as above.) According to the text, the receiving peer will process all the challenge replies in order. The first valid reply will cause it to accept the packet, the remaining ones will be ignored (Section 4.3.1.3). Suppose that for some reason A sends to challenge requests in quick succession. B will send two challenge replies, and if we're unlucky, they will end up in the same packet; so we end up with a packet with two challenge replies, only the second of which will be accepted by A. This is perfectly normal (although somewhat extreme) behaviour in this protocol. >>> challenge reply is extremely cheap (it's just a bitwise comparison of >>> two strings of octets), a similar optimisation for challenge replies >>> is not worthwile. >> >>> Er, challenge reply validation still requires the HMAC validation step, >>> right? >> At this stage we've already verified the HMAC. The only thing we could >> potentially save would be a bitwise comparison, and that's not worth it. > Right, but just "validating a challenge reply" in vacuum could be taken to > include validating the HMAC on the containing packet. An editorial comment, > to be sure, but "poses minimal incremental cost" would avoid it. Done. > Consider a multi-access link with honest A and B, and attacker C. > A sends a challenge request to B, that C observes and records. B sends a > challenge reply, and A sends some more traffic. What happens if C starts > spamming replayed copies of that challenge request towards B? This note > about constructing Challenge Reply is during the preparse stage, before > index/PC validation. Can C cause B to spend a lot of time generating > challenge replies and reduce the amount of time spent sending actual > data? You're right. I've added a requirement to rate-limit challenge replies. (Since we're already rate-limiting requests, this does not slow down the protocol any more.) >> > Section 6 >> >> > This mechanism relies on two assumptions, as described in >> > Section 1.2. First, it assumes that the hash being used is >> >> > s/hash/MAC/ >> >> I'm confused. This section refers to pre-image attacks, which I was under >> the impression is a property of the hash. > The thing we're sending over the wire is a MAC (sometimes HMAC-SHA-256; > sometimes Blake2s; potentially other things in the future). MACs are > almost universally constructed using hash functions, so it's pretty natural > to think of them fairly interchangably, but there do exist other > constructions like CBC-MAC. Fixed. > (Also, I think technically we're concerned about *second* preimage > resistance, since we're effectively sending the first preimage as the > message.) Getting this second-preimage resistance from CBC-MAC > constructs that take variable-length input requires some care, though! Not sure. We're not sending the key. >>> It would require a bit more thought to convince me that 64-bit indices >>> are sufficient for *all* cases. >> Assume the attacker is able to crash the node at will, and that the node >> needs 10s to reboot. If we assume the attacker will start seeing >> collisions after 2^32 tries, then this will happen after 1360 years, which >> is slightly more than the duration of the Byzantine empire. > "Attacks only get better; never worse." > My point was to show that it's plausible for an attacker to be able to > trigger index generation, and that if we want to be robust in the face of > future attacks, we should consider a threat model that allows them to do so > at will. Just because we can't see how that would happen now doesn't mean > very much unless we have some sort of proof to back it up. Yes, that's why the protocol supports larger values. However, for the time being, I stand by the statement that "64-bit values are believed to be large enough for all practical applications". >>> present at the receiver. If the attacker is able to cause the >>> (Index, PC) pair to persist for arbitrary amounts of time (e.g., by >>> repeatedly causing failed challenges), then it is able to delay the >>> packet by arbitrary amounts of time, even after the sender has left >>> the network. >>> I'd suggest adding another sentence describing the potential >>> consequences of selectively delayed input (i.e., messing up the >>> routing). >> We don't know about any such consequences. Still, we believe it is good >> to avoid this situation. > Maybe I'm confused, but suppose a node advertises a really-low-metric path > to a prefix, but then drops off the network. Sorry, my brain went away when I wrote that. This is exactly the issue I had in mind when I suggested this requirement. I've added "which could allow it to redirect or blackhole traffic to destinations previously advertised by the sender". >>> nit: that's a comma splice in the parenthetical; a semicolon would be >>> better. >> I've added a conjunction, I didn't realise such usage is unacceptable. > Introspection suggests that it's a pet peeve of mine, I'm pretty sure this usage is standard in British English, which is the dialect I was taught. Thank you for educating me, I shall avoid it in the future. (*My* pet peeve is the use of a comma after i.e. and e.g., but who am I to argue with the RFC Editor.) -- Juliusz From nobody Fri Aug 16 17:29: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 099641200EF; Fri, 16 Aug 2019 17:29:04 -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.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156600174397.5240.13683119907753509924@ietfa.amsl.com> Date: Fri, 16 Aug 2019 17:29:04 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-hmac-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: Sat, 17 Aug 2019 00:29:04 -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 : MAC authentication for the Babel routing protocol Authors : Clara Do Weronika Kolodziejak Juliusz Chroboczek Filename : draft-ietf-babel-hmac-10.txt Pages : 21 Date : 2019-08-16 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-10 https://datatracker.ietf.org/doc/html/draft-ietf-babel-hmac-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-hmac-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 Aug 16 18:11: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 22E901200F7 for ; Fri, 16 Aug 2019 18:11: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 wvMklCWo0afL for ; Fri, 16 Aug 2019 18:11:04 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611B61200EF for ; Fri, 16 Aug 2019 18:11:04 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id t14so6810971lji.4 for ; Fri, 16 Aug 2019 18:11: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=pXx/LG3jVedzJIrdaC2NyRKBBu77kr2bWnPm4jva5es=; b=hz46lxTXqRoUIDCJliKzvkYpepfpKJtDQpZv3tmB/NYY+mcxpCBBkIblPW1Gz+5RUY JlpJ1wJT0u8AvG1Qy4cSCT+OJy3hihK8VPsUgDjEVECqIJ6ObHhXfdtv6wdKVs1T3ZlO sLRI30RVsUXKU5wYxKRf+AHDuP59QHW0tB3biAxIBdQCxrf92vvTRSno4bwTZ9ASWa81 k7VQeDmaZzQHapBjXiOz4PwHkilhOvP5BH0OK9LzjRLPCTTJwbwVP3pDqEzdRAyZrbBq gIeHy99xgemktzjbrDkzfPPB2SoSJMv+l5fLX6sNHluLV8XLuoGS7X3sKcG1hYW3nBZd ZMjA== 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=pXx/LG3jVedzJIrdaC2NyRKBBu77kr2bWnPm4jva5es=; b=r5Vxa4QVyeO9qEwmp6Vkv1lSXd99kiSi+W7xS+xf1XMtsEbuRY7IlGFtYKj6NHydlB g4S6clK8wuEllCqYNRyI1bIlFcH8WXdbA5NodkpNBINF9I1u9z6uyLltZDPIc7FxC0C3 hCRfcYUBbQQuki/2xxcvuE+Ob3AydIaU3S8xK+vk+kTKm1a0CxuVRleiGpiYl2f191XV xEZ9iiUfzEzmcC14DlsKbwBoU9jzk6EuULxIyvMGdf//wmSDUu10X4Je8mThpjsgzYqt y9dx/OR4A/qrOkIjX8qmqYYBQZ82Bw1kg8aKvcmKggERGKvkKAf/1Lkx27/NGt4fQJyE ZviA== X-Gm-Message-State: APjAAAUfkNyjJn8Q3h+SMNYIn0ynNoBcjuKuoOX9MXasinFZOx3pmHli onRo03Z4o9tNpuZzF0om4Vv1F2yEUeDDT2QJ7OQ= X-Google-Smtp-Source: APXvYqz9HbvDRHp0+7xecqAU/YAYavaAXtKFw4sljNhxT+UfupJa0h+yxGQOPe5beViwIcTSpIgRgN60XnawlY5F6kA= X-Received: by 2002:a2e:94cb:: with SMTP id r11mr6524070ljh.212.1566004262396; Fri, 16 Aug 2019 18:11:02 -0700 (PDT) MIME-Version: 1.0 References: <87blwozn26.wl-jch@irif.fr> In-Reply-To: <87blwozn26.wl-jch@irif.fr> From: David Schinazi Date: Fri, 16 Aug 2019 18:10:51 -0700 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF Content-Type: multipart/alternative; boundary="000000000000c6e6c3059045c77a" Archived-At: Subject: Re: [babel] MAC: rate limit challenge replies 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, 17 Aug 2019 01:11:06 -0000 --000000000000c6e6c3059045c77a Content-Type: text/plain; charset="UTF-8" Sounds like a good idea to me. David On Fri, Aug 16, 2019 at 4:51 PM Juliusz Chroboczek wrote: > Since we are limiting challenge requests, it makes no harm to limit > challenge replies, and it increases our resistence to DoS. I've added the > following text to the MAC draft: > > Since a challenge reply might be caused by a replayed challenge > request, a node MUST impose a rate limitation to the challenge > replies it sends; the limit SHOULD default to one challenge reply for > each peer every 300ms and MAY be configurable. > > I hope nobody objects. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --000000000000c6e6c3059045c77a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sounds like a good idea to me.

David

On Fri, Aug 16, 2019 at 4:51 PM Juliusz Chroboczek <jch@irif.fr> wrote:
Since we are limiting challenge requests, it makes= no harm to limit
challenge replies, and it increases our resistence to DoS.=C2=A0 I've a= dded the
following text to the MAC draft:

=C2=A0 =C2=A0Since a challenge reply might be caused by a replayed challeng= e
=C2=A0 =C2=A0request, a node MUST impose a rate limitation to the challenge=
=C2=A0 =C2=A0replies it sends; the limit SHOULD default to one challenge re= ply for
=C2=A0 =C2=A0each peer every 300ms and MAY be configurable.

I hope nobody objects.

-- Juliusz

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--000000000000c6e6c3059045c77a-- From nobody Fri Aug 16 18:29: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 4ECEE1200EF for ; Fri, 16 Aug 2019 18:28:59 -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 qYlVKrMwNyaY for ; Fri, 16 Aug 2019 18:28:58 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B309D1200D5 for ; Fri, 16 Aug 2019 18:28:57 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7H1SqxJ019421 for ; Sat, 17 Aug 2019 03:28:53 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id CDC0757626 for ; Sat, 17 Aug 2019 03:28:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id ZroxG93IvKfI for ; Sat, 17 Aug 2019 03:28:54 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C52A857624 for ; Sat, 17 Aug 2019 03:28:53 +0200 (CEST) Date: Sat, 17 Aug 2019 03:28:53 +0200 Message-ID: <87a7c8ziju.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 17 Aug 2019 03:28:53 +0200 (CEST) X-Miltered: at korolev with ID 5D575854.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D575854.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 : 5D575854.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [babel] 6126bis: new appendix 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, 17 Aug 2019 01:28:59 -0000 Please proofread. Appendix F. Compatibility with previous versions The protocol defined in this document is a successor to the protocol defined in [RFC6126] and [RFC7557]. While the two protocols are not entirely compatible, the new protocol has been designed so that it can be deployed in existing RFC 6126 networks without requiring a flag day. There are two optioal features that make the new protocol incompatible with its predecessor. First of all, RFC 6126 did not define Unicast hellos (Section 3.4.1), and an implementation of RFC 6126 will mis-interpret a Unicast Hello for a Multicast one; since the sequence number space of Unicast Hellos is distinct from the sequence space of Multicast Hellos, sending a Unicast Hello to an implementation of RFC 6126 will confuse its link quality estimator. Second, RFC 7557 did not define mandatory sub-TLVs (Section 4.4); thus, an implementation of RFCs 6126 and 7557 will not correctly ignore a TLV that carries an unknown mandatory sub-TLV; depending on the sub-TLV, this might cause routing pathologies. An implementation of this specification that never sends Unicast Hellos and doesn't implement any extensions that use mandatory sub- TLVs is safe to deploy in a network in which some nodes implement the old protocol. Two changes need to be made to an implementation of RFCs 6126 and 7557 so that it can safely interoperate in all cases with implementations of this protocol. First, it needs to be modified to either ignore or process Unicast Hellos. Second, it needs to be modified to parse sub-TLVs of all the TLVs that it understands and that allow sub-TLVs, and to ignore the TLV is an unknown mandatory sub-TLV is found. It is not necessary to parse unknown TLVs, since these are ignored in any case. There are other changes, but these are not of a nature to prevent interoperability: o the conditions on route acquisition (Section 3.5.3) have been relaxed; o route selection should no longer use the route's sequence number (Section 3.6); o the format of the packet trailer has been defined (Section 4.2); o router-ids with a value of all-zeros or all-ones have been forbidden (Section 4.1.2); o the compression state is now specific to an address family rather than an address encoding Section 4.5; o packet pacing is now recommended (Section 3.1). From nobody Fri Aug 16 18:30:32 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 189F91200E9; Fri, 16 Aug 2019 18:30:24 -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 JwkcE63-FF86; Fri, 16 Aug 2019 18:30:23 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04701200D5; Fri, 16 Aug 2019 18:30:22 -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 x7H1UHKU019625; Sat, 17 Aug 2019 03:30:17 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 8AE7E57632; Sat, 17 Aug 2019 03:30:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id kcpWDyeAeW13; Sat, 17 Aug 2019 03:30:19 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 8DE8C57630; Sat, 17 Aug 2019 03:30:19 +0200 (CEST) Date: Sat, 17 Aug 2019 03:30:19 +0200 Message-ID: <8736i0ino4.wl-jch@irif.fr> From: Juliusz Chroboczek To: Suresh Krishnan Cc: "The IESG" , draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <87wofnx0jl.wl-jch@irif.fr> References: <156526849047.7502.1019049975377859421.idtracker@ietfa.amsl.com> <87wofnx0jl.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 [194.254.61.138]); Sat, 17 Aug 2019 03:30:17 +0200 (CEST) X-Miltered: at korolev with ID 5D5758A9.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D5758A9.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 : 5D5758A9.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] Suresh Krishnan's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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, 17 Aug 2019 01:30:24 -0000 >> I think a consolidated change log from RFC6126 would be more helpful in the >> finished RFC for existing implementers. > I'll seriously consider it. Done in -14. From nobody Fri Aug 16 18:37:57 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 CA8361200E9 for ; Fri, 16 Aug 2019 18:37:55 -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 CzHA1kqsCO48 for ; Fri, 16 Aug 2019 18:37:54 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D57312008B for ; Fri, 16 Aug 2019 18:37:54 -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 x7H1bnlL020523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Aug 2019 03:37:49 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x7H1bnJV031477; Sat, 17 Aug 2019 03:37:49 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id D73BF57645; Sat, 17 Aug 2019 03:37:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id C4KzYTNOoItF; Sat, 17 Aug 2019 03:37:51 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D110557643; Sat, 17 Aug 2019 03:37:50 +0200 (CEST) Date: Sat, 17 Aug 2019 03:37:50 +0200 Message-ID: <871rxkinbl.wl-jch@irif.fr> From: Juliusz Chroboczek To: Donald Eastlake Cc: Martin Vigoureux , Babel at IETF In-Reply-To: References: <871rxrdad3.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]); Sat, 17 Aug 2019 03:37:49 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 17 Aug 2019 03:37:49 +0200 (CEST) X-Miltered: at korolev with ID 5D575A6D.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D575A6D.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D575A6D.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D575A6D.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 : 5D575A6D.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D575A6D.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] AEs: define a registry? 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, 17 Aug 2019 01:37:56 -0000 > I think Juliusz has a good idea below. It obviously has no technical > effect on the protocol. However, given that we are past IESG telechat > and no AD mentioned this, I wanted your input as to whether it would > be OK add this to the draft. I've added an AE registry. Specification Required, just like the rest. Please yell now if you object. -- Juliusz From nobody Fri Aug 16 19:19: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 9EE811200E9; Fri, 16 Aug 2019 19:18:58 -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 w-wiJfcgi7tH; Fri, 16 Aug 2019 19:18:56 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA29C1200D5; Fri, 16 Aug 2019 19:18:55 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7H2IoXp027681; Sat, 17 Aug 2019 04:18:50 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 075A8576E5; Sat, 17 Aug 2019 04:18:53 +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 2i_JRMmWxP6d; Sat, 17 Aug 2019 04:18:51 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 325C7576E3; Sat, 17 Aug 2019 04:18:51 +0200 (CEST) Date: Sat, 17 Aug 2019 04:18:51 +0200 Message-ID: <87zhk8h6us.wl-jch@irif.fr> From: Juliusz Chroboczek To: Benjamin Kaduk Cc: The IESG , draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <20190814230513.GD88236@kduck.mit.edu> References: <156521599894.8313.13827924927219698158.idtracker@ietfa.amsl.com> <87v9v57pjm.wl-jch@irif.fr> <20190814230513.GD88236@kduck.mit.edu> 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, 17 Aug 2019 04:18:50 +0200 (CEST) X-Miltered: at korolev with ID 5D57640A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D57640A.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 : 5D57640A.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] Benjamin Kaduk's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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, 17 Aug 2019 02:18:59 -0000 >>> Section 3.8.2.1 notes that "[d]ue to duplicate suppression, only a small >>> number of such requests will actually reach the source." (for seqno >>> requests intending to avoid starvation). [...] > It still feels like an internal inconsistency to me. How would you feel > about s/will actually reach/are expected to actually reach/? Ok, done. >>> I think we may need to have a discussion about the feasibility of >>> multicast acknowledgment requests with only a 16-bit nonce. >> >> Section 3.3. An acknowledgment MUST be sent to a unicast destination. > I saw that, which is why I specified "acknowledgment requests". The nonce is used to match an Ack with the corresponding Req. Since the Ack is sent over unicast, a node only needs to match the Acks to the Reqs it originated. A sequential counter is good enough if we assume that 65536 distinct values is enough to deal with packet duplication. In any case, even if there's a collision, the consequences are fairly mild: the node will wrongly believe that a packet has been acknowledged, which might cause the packet to fail to be resent, but Babel is designed to deal gracefully with packet loss. To avoid confusion, I've renamed the Nonce to Opaque. >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >> >>> Should there be a "changes since RFC 6126" section that is retained in >>> the published RFC? (I assume that Appendix F is going to be dropped.) >> >> Is that a hard requirement? We've updated all implementations, so it >> wouldn't be too useful to anyone, and it would be a fair amount of work. > This is the non-blocking Comment section, so no, it's not a hard > requirement. I've added such a section. >>> Section 1.2 >>> Second, unless the optional algorithm described in Section 3.5.5 is >>> implemented, Babel does impose a hold time when a prefix is >>> Similarly to my comment on the applicability doc, I'm not sure if >>> there's one or two things in Section 3.5.5 that would match this >>> description. >> I'm not sure what's missing. 3.5.5 clearly states that either you wait >> for a fixed timeout, or you do something that doesn't involve waiting for >> a fixed timeout. > Grammatically, an "optional algorithm" is a single thing. I've replaced this with "the second algorithm". >>> I'm trying to walk through this and missing a step or two. [...] >> We want to prove that the following property is preserved: >> >> P: NH(A) = B implies FD(B) < FD(A) [...] > Okay. So it sounds like I'm supposed to read "accepts an update from B" > and interpret that as meaning "that causes NH(A) to be B" as opposed to, > say, "this is valid metric data and I am recomputing my routing table in > response"? I can get behind that conclusion, but don't know if that's just > a term of art I missed or some clarification should be added. I've added "and when it switches next hops". >>> Section 2.5 >> >>> Using the minusculeu and majuscule forms of the same letter to mean >>> different things (e.g., source S and sequence number s) is something of >>> a readability anti-pattern. >> I agree. We need Greek letters in RFCs. (No Gothic, please.) > sadly, RFC 7997 doesn't really seem to support this cause :-/ Some people have no vision. >>> Section 3.2.6 >> >>> It would probably be helpful to readers to note that "neighbor that >>> advertised" and "next-hop" can be different due to being different >>> address families. >> >> They are completely different data structures. The neighbour is (a >> reference to) an entry of the neighbour table, the NH is an IP address. > That's true. Do we want to make it more clear to the reader that is going > through things quickly? It was difficult to write, there's no reason why it should be easy to read. Still, I've followed your advice. >>> neighbours. However, if a seqno request is resent by its originator, >>> the subsequent copies MAY be forwarded to a different neighbour than >>> the initial one. >> >>> Is MAY the appropriate level of strength? Trying the same neighbor >>> would be effective if the original was unsuccessful due to packet loss, >>> but is it possible for a routing pathology to occur that directs the >>> request in the "wrong direction" with respect to a link or node failure? [...] > Hmm. I might actually suggest a non-normative "may", then, Done. >> If we want to be consistent with the rest of Babel, it is legal to check >> and to ignore this TLV. Since this TLV is ignored in any case, the >> distinction is somewhat uninteresting. >> >> (I guess you're thinking about adding noise for security purposes. Please >> define a new TLV if that's required, I prefer protocol extensions to be >> explicit about their intent.) > I was originally going for steganographic-like side channels, but that's an > option, too. I'll wait until I can think up a use for the noise before I > write that draft, though ;) Heh. It's a link-local steganographic channel, so not very interesting. If you find a way to encode information in route updates in such a manner that it gets propagated to the rest of the network, I'll be more excited. >>> Section 4.6.3 >> >>> Sixteen bits of nonce does not provide much unguessability (I note that >>> LISP's rfc6830bis is recommending that their 24-bit nonce echo >>> functionality not be relied on for return-routability checks over the >>> public Internet). However, since these acknowledgment exchanges are >>> only between direct neighbors, it seems that they are only needed for >>> correlating responses to requests and not for unguessability. (In this >>> case it seems a sequence number would work just as well as a random >>> number, and we might want to discourage random assignment in the text to >>> avoid the risk of birthday collisions.) >>> On the other hand, multicast acknowledgment requests could be >>> problematic (and especially so when sequential nonces are used), and if >>> they are intended to be allowed then we may need to consider using a >>> larger and random nonce. >> >> Section 3.3: >> >> An acknowledgment MUST be sent to a unicast destination. > I understand that. Nonetheless, any time that an attacker C (e.g., on a > shared link) can send a message to A that changes how A interacts with B, > that puts up a flag that we need to think about the interaction more > carefully. In this case, *probably* B will ignore spurious acks from A, > but is that always true? Is that the only case we need to consider? Without a cryptographic protection mechanism, this protocol is completely insecure. The Ack nonce is not meant to be unguessable, it's just meant for the requestor to match the Acks it receives to the Reqs it sent. It's just a counter, except that the representation is a local implementation matter. To avoid confusion, I've renamed the Nonce to Opaque. >>> Section 5 >> >>> "Specification Required" also requires Expert Review. What guidance can >>> we provide to the experts for making registration decisions? [...] >> I think we can deal with that issue when the problem occurs. > It's unlikely to be a timely response if we do that; I expect an RFC would > be needed in order to change registry policy/guidance, and that would take > at least a few months. What do you suggest? >>> I don't understand the origin of the '256' in the MIN(1, 256/txcost) >>> formula (described as a probability estimate). >> We scale the values to fit in a 16-bit integer field without excessive >> loss of precision. > Sorry; I'm still confused. If alpha is a "probability estimate", shoudln't > it be between 0 and 1? MIN(1, .) then serves to cap the top of the range, > so I want 256/txcost to be between 0 and 1, aka txcost to be larger than > 256. I see that we send the rxcost(/txcost) values in the 16-bit integer > IHU field, and use 0xffff to indicate infinity, but within that 0..2^15-2 > range, assignment of costs is left fairly arbitrary. So a scaling factor > would presumably also be arbitrary, but why is this > partial-scale-and-partial-cap procedure useful versus just scaling over the > full 16-bit range into a probability estimate from 0 to 1? The scaling above gives a wireless link a cost between 256 and infinity, where 256 stands for lossless. Ethernet links use 2-out-of-3, so a working Ethernet gets a cost of K. Since you want to prefer Ethernet to Wireless, you pick K < 256. You couldn't do that if wireless got a cost of 1. I've added a recommendation to set K=96 for Ethernet links (this is what current implementations use). -- Juliusz From nobody Fri Aug 16 19:43:54 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 87E66120096; Fri, 16 Aug 2019 19:43:47 -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.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156600982748.5357.3656208216765182646@ietfa.amsl.com> Date: Fri, 16 Aug 2019 19:43:47 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-rfc6126bis-14.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, 17 Aug 2019 02:43:48 -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-14.txt Pages : 68 Date : 2019-08-16 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-14 https://datatracker.ietf.org/doc/html/draft-ietf-babel-rfc6126bis-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-rfc6126bis-14 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 Aug 16 20:50: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 7A7AD1200D5 for ; Fri, 16 Aug 2019 20:50:09 -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 HbJkI2rUaYJU for ; Fri, 16 Aug 2019 20:50:08 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076F1120096 for ; Fri, 16 Aug 2019 20:50:07 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x7H3jV7Z007928; Fri, 16 Aug 2019 23:50:05 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 2ue7mrj729-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Aug 2019 23:50:05 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7H3o4Lb009047; Fri, 16 Aug 2019 23:50:04 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7H3nx8a008917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Aug 2019 23:50:00 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 379F64009E67; Sat, 17 Aug 2019 03:49:59 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30487.vci.att.com (Service) with ESMTPS id 21A804009E66; Sat, 17 Aug 2019 03:49:59 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.177]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0439.000; Fri, 16 Aug 2019 23:49:58 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" , "'babel@ietf.org'" Thread-Topic: [babel] 6126bis: new appendix Thread-Index: AQHVVJss+GSY+tLCFEqQcvTHmv5ej6b+sndg Date: Sat, 17 Aug 2019 03:49:58 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E27AB62@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <87a7c8ziju.wl-jch@irif.fr> In-Reply-To: <87a7c8ziju.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.216.153] 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-08-17_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=710 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908170038 Archived-At: Subject: Re: [babel] 6126bis: new appendix 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, 17 Aug 2019 03:50:10 -0000 Editorial comments in-line. Barbara =20 > The protocol defined in this document is a successor to the protocol > defined in [RFC6126] and [RFC7557]. While the two protocols are not > entirely compatible, the new protocol has been designed so that it > can be deployed in existing RFC 6126 networks without requiring a > flag day. >=20 > There are two optioal features that make the new protocol optioal ->optional > incompatible with its predecessor. First of all, RFC 6126 did not > define Unicast hellos (Section 3.4.1), and an implementation of RFC Should RFC 6126 be [RFC6126]? Same comment for all references. > 6126 will mis-interpret a Unicast Hello for a Multicast one; since > the sequence number space of Unicast Hellos is distinct from the > sequence space of Multicast Hellos, sending a Unicast Hello to an > implementation of RFC 6126 will confuse its link quality estimator. > Second, RFC 7557 did not define mandatory sub-TLVs (Section 4.4); > thus, an implementation of RFCs 6126 and 7557 will not correctly > ignore a TLV that carries an unknown mandatory sub-TLV; depending on > the sub-TLV, this might cause routing pathologies. >=20 > An implementation of this specification that never sends Unicast > Hellos and doesn't implement any extensions that use mandatory sub- > TLVs is safe to deploy in a network in which some nodes implement the > old protocol. >=20 > Two changes need to be made to an implementation of RFCs 6126 and > 7557 so that it can safely interoperate in all cases with > implementations of this protocol. First, it needs to be modified to > either ignore or process Unicast Hellos. Second, it needs to be > modified to parse sub-TLVs of all the TLVs that it understands and > that allow sub-TLVs, and to ignore the TLV is an unknown mandatory is -> if=20 > sub-TLV is found. It is not necessary to parse unknown TLVs, since > these are ignored in any case. Suggestion: ", since these are ignored in any case" -> "that are ignored" > There are other changes, but these are not of a nature to prevent > interoperability: >=20 > o the conditions on route acquisition (Section 3.5.3) have been > relaxed; >=20 > o route selection should no longer use the route's sequence number > (Section 3.6); >=20 > o the format of the packet trailer has been defined (Section 4.2); >=20 > o router-ids with a value of all-zeros or all-ones have been > forbidden (Section 4.1.2); >=20 > o the compression state is now specific to an address family rather > than an address encoding Section 4.5; >=20 > o packet pacing is now recommended (Section 3.1). >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_babel&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4vrfog&m=3DWw- > PiMuGBmrgnsxmDiWQjuvjD2a3d9sjPHErqmsKK4o&s=3DYwB1wNm3C00CXoHIB > 0D-3MnLvK2IgsV59pdDIEETajI&e=3D From nobody Fri Aug 16 22:40: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 27E4B120113 for ; Fri, 16 Aug 2019 22:40:00 -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 jP6XRSAtHaDJ for ; Fri, 16 Aug 2019 22:39:57 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE091200B7 for ; Fri, 16 Aug 2019 22:39:56 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id l1so1121547lji.12 for ; Fri, 16 Aug 2019 22:39:56 -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=zKX6JgQCxBYar/MdUrvOn6ZbZZqAcxvOw7Q7sKzczSQ=; b=V74SLBh3TPiuUj5EJpY5B+HRdo1YIeGYn5kMibiYLJZsR5i/VAEdKbjfiO8XvCv6ZI YycfdH8M8Flf7hkQZ3a45gNU1x1CRjp+zXZdFSJz9d5x3QwA+uylahLb0LAGFUnq73LA oqQqePRhWZ0NDPCP633+sZsIcqLCR40ql+tP57VSQdlwt8ibIrethb4TsNHfvbaxdg7M S/roKHA/WUVbI/VSCg3PGLY8/Hg1dTnCL3C89MmYmJANXgJ0EGquN8dLG+J5NRXDrbUJ Xk2Jsq7oqtFAQg6rTdP/CCZpcc8a2wepOYEGbWC66OPjqdDuEkxm22Hr/6QwXWiarArZ Vk+w== 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=zKX6JgQCxBYar/MdUrvOn6ZbZZqAcxvOw7Q7sKzczSQ=; b=FR3qcoCKyqhXt4ymxVg+0j1Rm/AVggmI77CiMckjd3791XO5Y/fpKZCuUhoOGdunns t0YLJ4jbzZ8RwUH2IUcTPe4qbXxhVwaJCaKdjNHtKAtc/It1J/MZvLRW6iOja2Lng+CW O/OGc5RglWZ0jVs+tchaO2sJ9r4MeB9ChjMbNv3Y9368Fh0HTq/TnrdLPFmEZev54bBt 2dMLUWe4yA8M/LMGRAB5zosdoXmmwx/sH2XpAXTYIbwO/8qss+N6LiJhTWRVIAd1CTrh X9QWfg8/Schdr1OhwfNw7DaXrDaHEE5nTdb7uVeUYBNRJeMeqzWR0cCNLFQ/PXgGCsDM p/2Q== X-Gm-Message-State: APjAAAVSeB6L215YHLLLDl7tjYTvZP775G4/Q5qJu8kt2JLqsoogj5Fq rd8woS5vztpsYn1g9NJcoclJEsx0oG7O2vFXFws= X-Google-Smtp-Source: APXvYqys4XPsD/cxCXmiD9YAIsH5WmAfvWbWWN4fGUpl0Du0FLg0isWlHBIAeuhfj+N1tWPagr1+/DQWxGN1GN5CMo0= X-Received: by 2002:a2e:94cb:: with SMTP id r11mr6877942ljh.212.1566020394966; Fri, 16 Aug 2019 22:39:54 -0700 (PDT) MIME-Version: 1.0 References: <87a7c8ziju.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E27AB62@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E27AB62@GAALPA1MSGUSRBF.ITServices.sbc.com> From: David Schinazi Date: Fri, 16 Aug 2019 22:39:44 -0700 Message-ID: To: "STARK, BARBARA H" Cc: Juliusz Chroboczek , "babel@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005a613405904989e6" Archived-At: Subject: Re: [babel] 6126bis: new appendix 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, 17 Aug 2019 05:40:00 -0000 --0000000000005a613405904989e6 Content-Type: text/plain; charset="UTF-8" The new appendix looks good to me. David On Fri, Aug 16, 2019 at 8:50 PM STARK, BARBARA H wrote: > Editorial comments in-line. > Barbara > > > The protocol defined in this document is a successor to the protocol > > defined in [RFC6126] and [RFC7557]. While the two protocols are not > > entirely compatible, the new protocol has been designed so that it > > can be deployed in existing RFC 6126 networks without requiring a > > flag day. > > > > There are two optioal features that make the new protocol > > optioal ->optional > > > incompatible with its predecessor. First of all, RFC 6126 did not > > define Unicast hellos (Section 3.4.1), and an implementation of RFC > > Should RFC 6126 be [RFC6126]? Same comment for all references. > > > 6126 will mis-interpret a Unicast Hello for a Multicast one; since > > the sequence number space of Unicast Hellos is distinct from the > > sequence space of Multicast Hellos, sending a Unicast Hello to an > > implementation of RFC 6126 will confuse its link quality estimator. > > Second, RFC 7557 did not define mandatory sub-TLVs (Section 4.4); > > thus, an implementation of RFCs 6126 and 7557 will not correctly > > ignore a TLV that carries an unknown mandatory sub-TLV; depending on > > the sub-TLV, this might cause routing pathologies. > > > > An implementation of this specification that never sends Unicast > > Hellos and doesn't implement any extensions that use mandatory sub- > > TLVs is safe to deploy in a network in which some nodes implement the > > old protocol. > > > > Two changes need to be made to an implementation of RFCs 6126 and > > 7557 so that it can safely interoperate in all cases with > > implementations of this protocol. First, it needs to be modified to > > either ignore or process Unicast Hellos. Second, it needs to be > > modified to parse sub-TLVs of all the TLVs that it understands and > > that allow sub-TLVs, and to ignore the TLV is an unknown mandatory > > is -> if > > > sub-TLV is found. It is not necessary to parse unknown TLVs, since > > these are ignored in any case. > > Suggestion: ", since these are ignored in any case" -> "that are ignored" > > > There are other changes, but these are not of a nature to prevent > > interoperability: > > > > o the conditions on route acquisition (Section 3.5.3) have been > > relaxed; > > > > o route selection should no longer use the route's sequence number > > (Section 3.6); > > > > o the format of the packet trailer has been defined (Section 4.2); > > > > o router-ids with a value of all-zeros or all-ones have been > > forbidden (Section 4.1.2); > > > > o the compression state is now specific to an address family rather > > than an address encoding Section 4.5; > > > > o packet pacing is now recommended (Section 3.1). > > > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https- > > 3A__www.ietf.org_mailman_listinfo_babel&d=DwICAg&c=LFYZ- > > o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=Ww- > > PiMuGBmrgnsxmDiWQjuvjD2a3d9sjPHErqmsKK4o&s=YwB1wNm3C00CXoHIB > > 0D-3MnLvK2IgsV59pdDIEETajI&e= > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --0000000000005a613405904989e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The new appendix looks good to me.

Davi= d

On Fri, Aug 16, 2019 at 8:50 PM STARK, BARBARA H <bs7652@att.com> wrote:
Editorial comments in-line.
Barbara=C2=A0

>=C2=A0 =C2=A0 The protocol defined in this document is a successor to t= he protocol
>=C2=A0 =C2=A0 defined in [RFC6126] and [RFC7557].=C2=A0 While the two p= rotocols are not
>=C2=A0 =C2=A0 entirely compatible, the new protocol has been designed s= o that it
>=C2=A0 =C2=A0 can be deployed in existing RFC 6126 networks without req= uiring a
>=C2=A0 =C2=A0 flag day.
>
>=C2=A0 =C2=A0 There are two optioal features that make the new protocol=

optioal ->optional

>=C2=A0 =C2=A0 incompatible with its predecessor.=C2=A0 First of all, RF= C 6126 did not
>=C2=A0 =C2=A0 define Unicast hellos (Section 3.4.1), and an implementat= ion of RFC

Should RFC 6126 be [RFC6126]? Same comment for all references.

>=C2=A0 =C2=A0 6126 will mis-interpret a Unicast Hello for a Multicast o= ne; since
>=C2=A0 =C2=A0 the sequence number space of Unicast Hellos is distinct f= rom the
>=C2=A0 =C2=A0 sequence space of Multicast Hellos, sending a Unicast Hel= lo to an
>=C2=A0 =C2=A0 implementation of RFC 6126 will confuse its link quality = estimator.
>=C2=A0 =C2=A0 Second, RFC 7557 did not define mandatory sub-TLVs (Secti= on 4.4);
>=C2=A0 =C2=A0 thus, an implementation of RFCs 6126 and 7557 will not co= rrectly
>=C2=A0 =C2=A0 ignore a TLV that carries an unknown mandatory sub-TLV; d= epending on
>=C2=A0 =C2=A0 the sub-TLV, this might cause routing pathologies.
>
>=C2=A0 =C2=A0 An implementation of this specification that never sends = Unicast
>=C2=A0 =C2=A0 Hellos and doesn't implement any extensions that use = mandatory sub-
>=C2=A0 =C2=A0 TLVs is safe to deploy in a network in which some nodes i= mplement the
>=C2=A0 =C2=A0 old protocol.
>
>=C2=A0 =C2=A0 Two changes need to be made to an implementation of RFCs = 6126 and
>=C2=A0 =C2=A0 7557 so that it can safely interoperate in all cases with=
>=C2=A0 =C2=A0 implementations of this protocol.=C2=A0 First, it needs t= o be modified to
>=C2=A0 =C2=A0 either ignore or process Unicast Hellos.=C2=A0 Second, it= needs to be
>=C2=A0 =C2=A0 modified to parse sub-TLVs of all the TLVs that it unders= tands and
>=C2=A0 =C2=A0 that allow sub-TLVs, and to ignore the TLV is an unknown = mandatory

is -> if

>=C2=A0 =C2=A0 sub-TLV is found.=C2=A0 It is not necessary to parse unkn= own TLVs, since
>=C2=A0 =C2=A0 these are ignored in any case.

Suggestion: ", since these are ignored in any case" -> "t= hat are ignored"

>=C2=A0 =C2=A0 There are other changes, but these are not of a nature to= prevent
>=C2=A0 =C2=A0 interoperability:
>
>=C2=A0 =C2=A0 o=C2=A0 the conditions on route acquisition (Section 3.5.= 3) have been
>=C2=A0 =C2=A0 =C2=A0 =C2=A0relaxed;
>
>=C2=A0 =C2=A0 o=C2=A0 route selection should no longer use the route= 9;s sequence number
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(Section 3.6);
>
>=C2=A0 =C2=A0 o=C2=A0 the format of the packet trailer has been defined= (Section 4.2);
>
>=C2=A0 =C2=A0 o=C2=A0 router-ids with a value of all-zeros or all-ones = have been
>=C2=A0 =C2=A0 =C2=A0 =C2=A0forbidden (Section 4.1.2);
>
>=C2=A0 =C2=A0 o=C2=A0 the compression state is now specific to an addre= ss family rather
>=C2=A0 =C2=A0 =C2=A0 =C2=A0than an address encoding Section 4.5;
>
>=C2=A0 =C2=A0 o=C2=A0 packet pacing is now recommended (Section 3.1). >
> _______________________________________________
> babel mailing list
> babel@ietf.org=
> https://urldefense.proofpoint.com/v2/url?u= =3Dhttps-
> 3A__www.ietf.org_mailman_listinfo_babel&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4vrfog&m=3DWw-
> PiMuGBmrgnsxmDiWQjuvjD2a3d9sjPHErqmsKK4o&s=3DYwB1wNm3C00CXoHIB
> 0D-3MnLvK2IgsV59pdDIEETajI&e=3D

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--0000000000005a613405904989e6-- From nobody Sat Aug 17 01:42: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 2A73F120033 for ; Sat, 17 Aug 2019 01:42:17 -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 3WyQH58zQR4Y for ; Sat, 17 Aug 2019 01:42:15 -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 6D2D1120019 for ; Sat, 17 Aug 2019 01:42:15 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1566031332; bh=liIjxMLHTNkOVWJ+EC5VafKosg7efeqajOpjFoe3UeE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nb64KxU69Lfod+58gEVCu5qKUa5g4GzEElgIPYtr9Elaw+bn1Zud5OCKG9uOsxOm1 dnTN/9Bsi9LpUOFBOmNf671JxJvnkRs5fu9wRUjrqjS787LMlfpdcGDX9UBpU9FJPo w3oKUbGSOI3VCpN4u62Ee636bLVRMitfOpYUH+05Mg1SIkMe1DCP99+Y10k95qzk+y HKjC46IQwLVrWAnCag+l62NcDkShJzJAMwspcFxpmRoeSd0uTI1Ri5u65T50d+x0R0 7dOtcPVNZ4j5N+cNNyPV9J1kjtWWbn78ynYERvzzjQEgWzaLDtpYNAIEcuoudNniFD 9AfjnLqW/HlHw== To: David Schinazi , "STARK\, BARBARA H" Cc: "babel\@ietf.org" , Juliusz Chroboczek In-Reply-To: References: <87a7c8ziju.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E27AB62@GAALPA1MSGUSRBF.ITServices.sbc.com> Date: Sat, 17 Aug 2019 10:42:12 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87sgq0uqsb.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] 6126bis: new appendix 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, 17 Aug 2019 08:42:17 -0000 David Schinazi writes: > The new appendix looks good to me. +1 -Toke From nobody Sat Aug 17 12:10: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 E39181200D8; Sat, 17 Aug 2019 12:09:58 -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 dUInUmQzOt3L; Sat, 17 Aug 2019 12:09:57 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66E31200CD; Sat, 17 Aug 2019 12:09:56 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7HJ9oRv013170; Sat, 17 Aug 2019 21:09:50 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 05607295A4; Sat, 17 Aug 2019 21:09:53 +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 UmG-emz-HkCC; Sat, 17 Aug 2019 21:09:52 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 040EB2959F; Sat, 17 Aug 2019 21:09:50 +0200 (CEST) Date: Sat, 17 Aug 2019 21:09:50 +0200 Message-ID: <87wofbham9.wl-jch@irif.fr> From: Juliusz Chroboczek To: Barry Leiba Cc: "The IESG" , draft-ietf-babel-applicability@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156523541556.8428.14664793919655430943.idtracker@ietfa.amsl.com> References: <156523541556.8428.14664793919655430943.idtracker@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, 17 Aug 2019 21:09:50 +0200 (CEST) X-Miltered: at korolev with ID 5D5850FE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D5850FE.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 : 5D5850FE.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] Barry Leiba's No Objection on draft-ietf-babel-applicability-09: (with COMMENT) 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, 17 Aug 2019 19:09:59 -0000 > I agree with several other ADs that the document tries too hard to be a > marketing brochure. I do not find that sufficiently objectionable to > interfere, but it would be nice to tone it down a bit. I have done my best in -10. If you believe that more should be done, I would appreciate more concrete advice. -- Juliusz From nobody Sat Aug 17 12:19:55 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 1627E1200CD; Sat, 17 Aug 2019 12:19: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 GIkD7D1QvrTG; Sat, 17 Aug 2019 12:19:51 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B2212006D; Sat, 17 Aug 2019 12:19:50 -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 x7HJJjhT014354; Sat, 17 Aug 2019 21:19:45 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C5C42295CC; Sat, 17 Aug 2019 21:19:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id UJ5Km4ShcMTB; Sat, 17 Aug 2019 21:19:47 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 488FA295CA; Sat, 17 Aug 2019 21:19:47 +0200 (CEST) Date: Sat, 17 Aug 2019 21:19:47 +0200 Message-ID: <87v9uvha5o.wl-jch@irif.fr> From: Juliusz Chroboczek To: Benjamin Kaduk Cc: "The IESG" , draft-ietf-babel-applicability@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156521443702.8388.9968706791861758093.idtracker@ietfa.amsl.com> References: <156521443702.8388.9968706791861758093.idtracker@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, 17 Aug 2019 21:19:46 +0200 (CEST) X-Miltered: at korolev with ID 5D585351.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D585351.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 : 5D585351.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] Benjamin Kaduk's No Objection on draft-ietf-babel-applicability-09: (with COMMENT) 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, 17 Aug 2019 19:19:53 -0000 > When a use case calls for all nodes to participate in the IGP (as > opposed to just connecting to a local point of access and letting that > router run the IGP, there may be privacy considerations regarding the > mobility/connectivity of individual nodes in the information conveyed > over the routing protocol. It would be good to acknowledge that such > use cases may exist (or disclaim applicability to them) in this > document. Done. > Section 1.1 > It's probably worth expanding DSDV on first use. Done. > Section 2.2 > (side note: this is probably just me coming from an abstract > math/topology background and not a routing background, but the term > "non-transitive link" puzzles me a little bit. My understanding of the > non-transitivity property is that if A has a link to B, and B has a link > to C, then it's not necessarily the case that A can get traffic to/from > C via B. But that seems like more of a property of the node policy or > other constraints on B than of any particular link. I can live with > being puzzled, here, but if there's a quick explanation, I'd be > interested in hearing it.) It's a relationship between interfaces. Interface I can speak to interface J at the link layer. A transitive, symmetric link technology is a technology that guarantees that that relationship is an equivalence relation. 10BASE5 guarantees that this is the case by construction -- two stations can speak to each other if they are on the same coax. 802.11 in ad-hoc mode doesn't, here's some ASCII art for your greatest enjoyment: I X K X is an obstacle . X . . . . . J > Section 2.3 > All of the extensions designed to date interoperate with the base > protocol and with each other. This, again, is a consequence of the > protocol design: in order to check that two extensions to the Babel > protocol are interoperable, it is enough to verify that the > interaction of the two does not violate the base protocol's > assumptions. > As another reviewer noted, "interoperable" doesn't seem like quite the > right word; "compatible" seems potentially more appropriate, or perhaps > "usable with each other". Disgree. > Section 2.4.3 > Babel's loop-avoidance mechanism relies on making a route unreachable > after a retraction until all neighbours have been guaranteed to have > acted upon the retraction, even in the presence of packet loss. > Unless the optional algorithm described in Section 3.5.5 of > [RFC6126bis] is implemented, this entails that a node is unreachable > for a few minutes after the most specific route to it has been > retracted. [...] > Section 3.5.5 of draft-ietf-babel-rfc6126bis-07 seems to discuss two > different mechanismis to guarantee that no neighbor is using the current > node as next-hop for prefix P. (1) is that the operation being referred > to here, and (2) if so, should this be "one of the mechanisms"? > Basically, I'm not sure I'm chasing the reference in the way intended. Clarified. > Section 5 > I think we need to couch the "most deployments" language with something > like "at the time of this writing" -- there's no guarantee that it will > remain true in perpetuity. Done. > Given, e.g., https://www.krackattacks.com/, it's unclear to me that it's > reasonable to continue to claim that WPA2 provides a way to secure a > link layer. (WPA3 is not shaping up to do much better, given > https://www.schneier.com/blog/archives/2019/04/vulnerabilities_7.html .) I'm leaving it as it stands notwithstanding -- it's not this document's goal to describe best practices for WiFi security. -- Juliusz From nobody Sat Aug 17 12:30:49 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 3BBAB1200FF; Sat, 17 Aug 2019 12:30:47 -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 jwacb0EVOiXP; Sat, 17 Aug 2019 12:30:45 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4ED12009C; Sat, 17 Aug 2019 12:30:44 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7HJUY9m015482; Sat, 17 Aug 2019 21:30:34 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 8536229604; Sat, 17 Aug 2019 21:30:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id vTsKdL-RJzdo; Sat, 17 Aug 2019 21:30:36 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7AF2029601; Sat, 17 Aug 2019 21:30:32 +0200 (CEST) Date: Sat, 17 Aug 2019 21:30:32 +0200 Message-ID: <87tvafh9nr.wl-jch@irif.fr> From: Juliusz Chroboczek To: Roman Danyliw Cc: "The IESG" , draft-ietf-babel-applicability@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <156520668914.8405.11909335529336925535.idtracker@ietfa.amsl.com> References: <156520668914.8405.11909335529336925535.idtracker@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=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, 17 Aug 2019 21:30:34 +0200 (CEST) X-Miltered: at korolev with ID 5D5855DA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D5855DA.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 : 5D5855DA.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] Roman Danyliw's No Objection on draft-ietf-babel-applicability-09: (with COMMENT) 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, 17 Aug 2019 19:30:47 -0000 > -- Per the sentence, “Given a sufficiently friendly audience, the principles > behind Babel can be explained in 15 minutes, and a full description of the > protocol can be done in 52 minutes (one microcentury)”, what does this mean? > If this is to suggest to the reader that they too can learn Babel in 15 > minutes, it is unconvincing and reads like a marketing statement. I stand by my claim. I've done it multiple times, last time was back in July at Battlemesh, and a good part of the audience got it. > -- Per the phrase, “…including one that was reportedly written and debugged in > just two nights“, this statement is not convincing without context. It happened at an IETF meeting. The author was Markus Stenberg. Please indicate precisely what additional context you would expect. > -- Per the sentence, “In addition to the above, our implementation experience > indicates that Babel tends to be robust with respect to bugs: more often than > not, an implementation bug …”, this text is an improvement over -07 (thank > you), but I still view this as a high risk, anecdotal claim. I strongly > recommend it be removed. I've removed this paragraph. (I stand by my claim, but I've removed it from the document.) > (2) Section 2.2. This section uses the designation of “strong” vs. a “weak” > property. Where are those defined? https://en.wiktionary.org/wiki/weak#English meaning 9. This is standard usage in mathematics. > (3) Section 2.2. Per the sub-bullets of “These weak requirements make Babel a > robust protocol …”, what assurance does the phrase “does most likely not” > suggest? Furthermore, the claim that implementation bugs won’t collapse the > network based on an uncited “extensive” experience seems too strong of claim. The part about bugs has been removed. > (4) Per Section 3.1. How big is a “medium-sized hybrid network”? Covering a small European country and parts of its neighbours: https://wlan-si.net/en/map/ > (5) Per Section 3.1. What are “meshy wireless bits”? I believe the formulation is clear, and I like it. > (6) Section 3.2. Is there a citation for the successful deployment in > “large scale overlay networks, built out of thousands of tunnels > spanning continents”? Nothing that I can cite. The sentence in the draft was painstakingly negotiated with the CEO of the company who run the network. https://re6st.nexedi.com/ > (7) Section 3.4. The utility of Babel in small and home offices > surprised me as I wasn't expecting such networks to mix IPv4 and v6; and > use an IGP. Do you wish me to remove this bit? I only have two examples: - Dave Taht's network, which is used to cover a camping; - my home network. > (8) Section 5. Per the sentence “Due to its simplicity, Babel-HMAC …”, I’m > not sure that simplicity should be driving the choice of the security > properties. It seems like it should be the security requirements. Can we please agree to disagree on this subject? -- Juliusz From nobody Sat Aug 17 12:40: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 8A43712003F; Sat, 17 Aug 2019 12:40:19 -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.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156607081946.11072.7449512176034590989@ietfa.amsl.com> Date: Sat, 17 Aug 2019 12:40:19 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-applicability-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: Sat, 17 Aug 2019 19:40:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : Applicability of the Babel routing protocol Author : Juliusz Chroboczek Filename : draft-ietf-babel-applicability-10.txt Pages : 11 Date : 2019-08-17 Abstract: Babel is a routing protocol based on the distance-vector algorithm augmented with mechanisms for loop avoidance and starvation avoidance. This document describes a number of niches where Babel has been found to be useful and that are arguably not adequately served by more mature protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-applicability/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-applicability-10 https://datatracker.ietf.org/doc/html/draft-ietf-babel-applicability-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-applicability-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 Sat Aug 17 12:56: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 718091200FF; Sat, 17 Aug 2019 12:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 BoipIuv5_b7a; Sat, 17 Aug 2019 12:56:01 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 A0D8212003F; Sat, 17 Aug 2019 12:56:01 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id 18so13045133ioe.10; Sat, 17 Aug 2019 12:56:01 -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=3emoBR3vuGoe7q2UleadszSsX7J389Mc/zmQFXxfRTw=; b=oDpaj4kfPl/U66PUkobXeEgeo5iIPN0LNdRQWWBwTqyJ6FaOMgBzAcuN1vtfQ7O5Pt Dcg1wHgNhp+7xLSgIwN0bCVn44uxPMR04oZCTAgevzJmMEuGY5GvVq3CN+j9ByScO0SZ yg36lUnPJ+wM5gLuKuLfzLSzG0glP6OJY5fI9qGmVb11Zrr6C8UfCDAU4da2qYwPMZa/ 2oTx6b+4mP3bPUR2XNBPSWeRN6o0mgPo27duySb5tAVemqFiBNujvRsZgKz46gJnn9AF 7/V+5mXWq6vHqe4exMBnmFY8r/7ompSfkffxZOl2quE1PBz7h6KgVDgtLYGIP/CBnHEY DDEQ== 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=3emoBR3vuGoe7q2UleadszSsX7J389Mc/zmQFXxfRTw=; b=EcCAR+A52Dj4oMmRKVyh+sZfNlWv0TyYhnCeo+nWvhE17cXjkdH2TBIsitnrBY29Gp nR49iNgNU3uBGKvbeZcSlIeq3e7QyJTyrdQyDQ00zHNG4/SJ0C69PlqvYkAm6+mfSbe2 3ElV41jvDWpKvlaDZFQsyD67VrYfRwzb+3Xnl3wryTMVOPthT15OHXa3ZiiDxpnATrkH vPXGso6UAaV1oTCSaY/Gl44gl3+ccY3/03t12H8uzBbJwYk1bj5tv457WR2L5cUTQoCw a/dPa4FYZG/E1lslvmP1ORDeoOi1rvQTmF7Y7enAeM51/VGJPjs7QR/RCqLYhKb2DAzP YA2A== X-Gm-Message-State: APjAAAXk6z6VjkZhijGxHlsS29xfpKiIWlrt9j3A24eGAU4C103XD/iu gW/ZAG3C3R2oWXpSDpw5hs449rZwfLUohdwNliI= X-Google-Smtp-Source: APXvYqw4ks1QXwUs2O/XiqamlCZ/yaWVMTpaYGlUcSDAeVgytEWQIcTRpvbzkuQW+hlbJ/6A2GURyaXR+Wc5OXNbgIY= X-Received: by 2002:a02:ca0c:: with SMTP id i12mr17529629jak.82.1566071760931; Sat, 17 Aug 2019 12:56:00 -0700 (PDT) MIME-Version: 1.0 References: <156520668914.8405.11909335529336925535.idtracker@ietfa.amsl.com> <87tvafh9nr.wl-jch@irif.fr> In-Reply-To: <87tvafh9nr.wl-jch@irif.fr> From: Dave Taht Date: Sat, 17 Aug 2019 12:55:49 -0700 Message-ID: To: Juliusz Chroboczek Cc: Roman Danyliw , Donald Eastlake , babel-chairs , draft-ietf-babel-applicability@ietf.org, The IESG , Babel at IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] Roman Danyliw's No Objection on draft-ietf-babel-applicability-09: (with COMMENT) 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, 17 Aug 2019 19:56:04 -0000 > > (7) Section 3.4. The utility of Babel in small and home offices > > surprised me as I wasn't expecting such networks to mix IPv4 and v6; and > > use an IGP. > > Do you wish me to remove this bit? I only have two examples: > > - Dave Taht's network, which is used to cover a camping; > - my home network. I'm not sure what you mean by IGP? Having any commonly deployed IGP is a boon when you can't/don't want to bridge networks together. My original babel network was deployed in Nicaragua, some pics and discussion of that are here: https://www.youtube.com/watch?v=Wksh2DPHCDI&t=3s and it also goes into the diffulties with wifi multicast and bridging and the state of the queuing issues wifi had at the time (now fixed) The campground network here (it's not "my" network, but lupin lodge's ( https://www.google.com/maps/place/Lupin+Lodge/@37.1702044,-121.9809242,1374m/data=!3m1!1e3!4m8!3m7!1s0x808e37c562ac66c3:0xedf7d1fb2e08927d!5m2!4m1!1i2!8m2!3d37.1699311!4d-121.9784355 )had very difficult requirements - to cover 110 acres and multiple office buildings there was a mix of p2p radios and APs and multiple touch down points to wired (comcast) networks. This is in part where babel's source specific routing feature exists and where it was first tested. Lots of ravines. Redwoods... It was very mesh because trees fall, power lines fail, random people unplug things to plug in their hair dryers, it's a pretty hostile environment that always needed to have two or more paths to everything so I could fix it at leisure. At one point it was vastly more complicated than it is now, had about 36 radios in the field and 70 in the lab. Lab's shuttered... there's a vpn in place (also babeld) to connect multiple edge points.... It ran ipv6 and ipv4 up until recently but as one sad example, I had to kill the ipv6 support I'd had running everywhere as netflix started blocking the hurricane tunnel for it, and there is not as yet a good distribution mechanism across a network this meshy for dynamic ipv6 addresses I now get from comcast. babel was (and still is) the only protocol and daemon I'd ever found that could do both ipv6 and ipv4 in very limited memory on the radios (32MB ram) I started with. Even today more than 32MB ram is uncommon in outdoor wireless APs (although 802.11s has come pretty far along, I still don't think it suitable for this application) Anyway, having "a" routing protocol that worked well to connect up wireless and wired links always seemed a goodness for n networks as n > 5 and redundancy required. I wish I knew what aruba did these days. From nobody Sun Aug 18 03:28: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 C04D2120019; Sun, 18 Aug 2019 03:28:03 -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 jmgwHcmkcILC; Sun, 18 Aug 2019 03:28: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 F1DF4120013; Sun, 18 Aug 2019 03:28: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=1566124078; bh=8gm5iikmG7wW8t7igI8zuQDULo6n+uexFCkUBMtslAk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ffc2uuBWghj9MKRcZgjcpq28We/UnTzLc7O+TR4JnBmuJi9Y7SsfOjYee8pWaUY1c Erig0Bg3wE8TB2/4jMRE31Uwy0FG7iBor9/PCgZ6tMxfsJHsVmmW5LABg67Oq0yrsc KLreMu+jLkx695aROCV5czY0dTaD8sC5cmzqln+O9XCeZbVrZmtkfsUYMDsxheXmDf 55557GpWh5pXulxZbICZbSIkZsIP+6vZ4SdWxZmfzVBE6w1F6gUnoHjPspuFa7Rng1 5YSVgUBPj3b0W2JfLr2J2fdJA3/QpNhI2K0F6CGIgE0ZKXwowfzE7WHWU3j5uSX3zq ZlCS81tQPJZgg== To: Juliusz Chroboczek , Roman Danyliw Cc: Donald Eastlake , babel-chairs@ietf.org, draft-ietf-babel-applicability@ietf.org, The IESG , babel@ietf.org In-Reply-To: <87tvafh9nr.wl-jch@irif.fr> References: <156520668914.8405.11909335529336925535.idtracker@ietfa.amsl.com> <87tvafh9nr.wl-jch@irif.fr> Date: Sun, 18 Aug 2019 12:27:57 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87k1bavkcy.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Roman Danyliw's No Objection on draft-ietf-babel-applicability-09: (with COMMENT) 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, 18 Aug 2019 10:28:04 -0000 Juliusz Chroboczek writes: >> -- Per the sentence, =E2=80=9CGiven a sufficiently friendly audience, th= e principles >> behind Babel can be explained in 15 minutes, and a full description of t= he >> protocol can be done in 52 minutes (one microcentury)=E2=80=9D, what doe= s this mean?=20 >> If this is to suggest to the reader that they too can learn Babel in 15 >> minutes, it is unconvincing and reads like a marketing statement. > > I stand by my claim. I've done it multiple times, last time was back in > July at Battlemesh, and a good part of the audience got it. > >> -- Per the phrase, =E2=80=9C=E2=80=A6including one that was reportedly w= ritten and debugged in >> just two nights=E2=80=9C, this statement is not convincing without conte= xt. > > It happened at an IETF meeting. The author was Markus Stenberg. Please > indicate precisely what additional context you would expect. > >> -- Per the sentence, =E2=80=9CIn addition to the above, our implementati= on experience >> indicates that Babel tends to be robust with respect to bugs: more often= than >> not, an implementation bug =E2=80=A6=E2=80=9D, this text is an improveme= nt over -07 (thank >> you), but I still view this as a high risk, anecdotal claim. I strongly >> recommend it be removed. > > I've removed this paragraph. (I stand by my claim, but I've removed it > from the document.) > >> (2) Section 2.2. This section uses the designation of =E2=80=9Cstrong= =E2=80=9D vs. a =E2=80=9Cweak=E2=80=9D >> property. Where are those defined? > > https://en.wiktionary.org/wiki/weak#English meaning 9. > > This is standard usage in mathematics. > >> (3) Section 2.2. Per the sub-bullets of =E2=80=9CThese weak requirement= s make Babel a >> robust protocol =E2=80=A6=E2=80=9D, what assurance does the phrase =E2= =80=9Cdoes most likely not=E2=80=9D >> suggest? Furthermore, the claim that implementation bugs won=E2=80=99t = collapse the >> network based on an uncited =E2=80=9Cextensive=E2=80=9D experience seems= too strong of claim. > > The part about bugs has been removed. > >> (4) Per Section 3.1. How big is a =E2=80=9Cmedium-sized hybrid network= =E2=80=9D? > > Covering a small European country and parts of its neighbours: > > https://wlan-si.net/en/map/ > >> (5) Per Section 3.1. What are =E2=80=9Cmeshy wireless bits=E2=80=9D? > > I believe the formulation is clear, and I like it. > >> (6) Section 3.2. Is there a citation for the successful deployment in >> =E2=80=9Clarge scale overlay networks, built out of thousands of tunnels >> spanning continents=E2=80=9D? > > Nothing that I can cite. The sentence in the draft was painstakingly > negotiated with the CEO of the company who run the network. > > https://re6st.nexedi.com/ > >> (7) Section 3.4. The utility of Babel in small and home offices >> surprised me as I wasn't expecting such networks to mix IPv4 and v6; and >> use an IGP. > > Do you wish me to remove this bit? I only have two examples: > > - Dave Taht's network, which is used to cover a camping; > - my home network. I do this as well; including bridging multiple physical locations over VPN tunnels, and multi-homing my laptop; all using Babel... :) -Toke From nobody Sun Aug 18 15:13:26 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 395EE1200B9 for ; Sun, 18 Aug 2019 15:13:25 -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 e7kLpi35Qm6v for ; Sun, 18 Aug 2019 15:13:23 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF104120047 for ; Sun, 18 Aug 2019 15:13:23 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7IM59fk013305 for ; Sun, 18 Aug 2019 18:13:23 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2ufas24dyg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 18 Aug 2019 18:13:23 -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 x7IMDMYH004954 for ; Sun, 18 Aug 2019 18:13:22 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7IMDIFp004934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 18 Aug 2019 18:13:18 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id AA7DB4009E67 for ; Sun, 18 Aug 2019 22:13:18 +0000 (GMT) Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30487.vci.att.com (Service) with ESMTPS id 997184009E66 for ; Sun, 18 Aug 2019 22:13:18 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.177]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0439.000; Sun, 18 Aug 2019 18:13:17 -0400 From: "STARK, BARBARA H" To: "'babel@ietf.org'" Thread-Topic: info-model: those darned metrics Thread-Index: AdVWEa4ACwAdZKb8SpCpoTNd6E1jzQ== Date: Sun, 18 Aug 2019 22:13:17 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E27C846@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.238.35] 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-08-18_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=554 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908180244 Archived-At: Subject: [babel] info-model: those darned metrics 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, 18 Aug 2019 22:13:25 -0000 It looks like I missed updating some of the language in the descriptions fo= r calculated and received metrics. It says "At least one of babel-route-calculated-metric and babel-route-rece= ived-metric MUST be non-zero. Having both be non-zero is expected for a rou= te that is received and subsequently advertised." I think it should be "At least one of babel-route-calculated-metric and bab= el-route-received-metric will be non-NULL. Having both be non-NULL is expec= ted for a route that is received and subsequently advertised." There's no need for normative language here, since the values are read-only= and beyond the control of the info model. Does anyone disagree with this? Barbara From nobody Mon Aug 19 06:22:32 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 621351201C6; Mon, 19 Aug 2019 06:22:24 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 n7rOuVhvxX7p; Mon, 19 Aug 2019 06:22:21 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 6084F12080D; Mon, 19 Aug 2019 06:22:21 -0700 (PDT) Received: from 200116b82c4ebb00bd437b5a182d6e70.dip.versatel-1u1.de ([2001:16b8:2c4e:bb00:bd43:7b5a:182d:6e70]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hzhbz-0007aq-4d; Mon, 19 Aug 2019 15:22:15 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <87tvafh9nr.wl-jch@irif.fr> Date: Mon, 19 Aug 2019 15:22:14 +0200 Cc: Roman Danyliw , Donald Eastlake , babel-chairs@ietf.org, draft-ietf-babel-applicability@ietf.org, The IESG , babel@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7600BC69-E0A4-4C39-BEC0-20212E68FE7F@kuehlewind.net> References: <156520668914.8405.11909335529336925535.idtracker@ietfa.amsl.com> <87tvafh9nr.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1566220941;9664a75e; X-HE-SMSGID: 1hzhbz-0007aq-4d Archived-At: Subject: Re: [babel] Roman Danyliw's No Objection on draft-ietf-babel-applicability-09: (with COMMENT) 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: Mon, 19 Aug 2019 13:22:29 -0000 > On 17. Aug 2019, at 21:30, Juliusz Chroboczek wrote: >=20 >> -- Per the sentence, =E2=80=9CGiven a sufficiently friendly audience, = the principles >> behind Babel can be explained in 15 minutes, and a full description = of the >> protocol can be done in 52 minutes (one microcentury)=E2=80=9D, what = does this mean?=20 >> If this is to suggest to the reader that they too can learn Babel in = 15 >> minutes, it is unconvincing and reads like a marketing statement. >=20 > I stand by my claim. I've done it multiple times, last time was back = in > July at Battlemesh, and a good part of the audience got it. How did you evaluate that a =E2=80=9Cgood part of the audience got = it=E2=80=9D. If you cannot evaluate this appropriately, I would also = call it a marketing statement... From nobody Mon Aug 19 09:10: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 C3C9512010E; Mon, 19 Aug 2019 09:10:45 -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 lOcJxXCF-UP9; Mon, 19 Aug 2019 09:10:43 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA9D1200B5; Mon, 19 Aug 2019 09:10:43 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id x4so2300977ljj.6; Mon, 19 Aug 2019 09:10:43 -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=XUmusGZlNTx9V2RLSqpASY+qaSI9h5wq9/w6nTAsvN4=; b=cp0/uiBBN/9o3Iukvaqq4dJ1gOM0EEYEw8Ywj2MNQWTl5Lz2R+Wlijawd+Iu6Andou dSb4Np3TNWowdGat1JBxg5Rqqe58PqU9XGt8gzo3oON/oBaL0ahmcUBvXheE+5vSufel jn84KOD3L+bKVIqYxfCduZ2tCzA8cVYmaTtB5BV3721zwAa8rcJb8EppH2XV7s85az+c HY3XqPxtHF/azzVAN35XV13yuofNTBQr56YKUE/KH/VSFtrOK4sfR3NDeubOEEj2QwkS Ayo5Ry7NRaJdnS2efDUvnzW+SH7NuD6OgqkgDWCcacUr5yvxuYEjM8hxM2pqusy+N321 GU0Q== 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=XUmusGZlNTx9V2RLSqpASY+qaSI9h5wq9/w6nTAsvN4=; b=Ase3kyW5Mgxo4+K0LAVg8r5BxyPgF1eGYCznZ06n3EoFqJPJwAMZPsHuSXNRXzT0YI vAfAKbyAfSjaf0W3JToI4Vmd0tgbIHYwHV9E6tGhY7YTWafvlb1DXMpxl3+LzdxQJAYN SKZMfhtVSvRFx4VVDhcF6WI3bPI+9WSXefIa9Rya/2bK1ZnKty3kLr1Nm+w+ScdHlqDH /slRNE4bLQpwd3GzwBd40lAt03Ztn+VFjtMJZZQCSGdDGl3N52ZpWOwoWJ9DpSulYc4o MclkdItznGtEZbf/qUGhdx+WkZDM4Va1yuknhW+RXRD3Y7VKuBp3Gr9F7GNo+l8+c55k PDow== X-Gm-Message-State: APjAAAVfNMKpBy+AdO84nie4p5yhsLfsrLIhAhLT5Inq0+DMW5f2P1y8 MfN0UFhE47Bc85I1C+qmNQx/xlbMunneYY9dv7Q= X-Google-Smtp-Source: APXvYqwTs3/qRwZHDQL3mz20Qyvtt5j8AdojeL4SN6J9DmIRIDMtidt2VS6FWoIkGMaYFM0UUrsMDLTOrUL8G01zWLo= X-Received: by 2002:a2e:81c3:: with SMTP id s3mr13102673ljg.70.1566231041214; Mon, 19 Aug 2019 09:10:41 -0700 (PDT) MIME-Version: 1.0 References: <156520596444.8244.649940515091541992.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B34054D4@marchand> <359EC4B99E040048A7131E0F4E113AFC01B34056BD@marchand> In-Reply-To: From: David Schinazi Date: Mon, 19 Aug 2019 09:10:29 -0700 Message-ID: To: Roman Danyliw Cc: The IESG , "draft-ietf-babel-dtls@ietf.org" , Donald Eastlake , babel-chairs , Babel at IETF Content-Type: multipart/alternative; boundary="000000000000d90d7c05907a9423" Archived-At: Subject: Re: [babel] Roman Danyliw's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT) 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: Mon, 19 Aug 2019 16:10:46 -0000 --000000000000d90d7c05907a9423 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Roman, Would you be able to take a look at draft -09 and update your ballot position please? https://tools.ietf.org/html/draft-ietf-babel-dtls-09 Thanks, David On Tue, Aug 13, 2019 at 3:50 PM David Schinazi wrote: > Thanks Roman! We've now uploaded -09 with the new text: > https://tools.ietf.org/html/draft-ietf-babel-dtls-09 > > David > > On Tue, Aug 13, 2019 at 7:29 AM Roman Danyliw wrote: > >> Hi David! >> >> >> >> *From:* David Schinazi [mailto:dschinazi.ietf@gmail.com] >> *Sent:* Monday, August 12, 2019 11:01 PM >> *To:* Roman Danyliw >> *Cc:* The IESG ; draft-ietf-babel-dtls@ietf.org; Donald >> Eastlake ; babel-chairs ; Babel >> at IETF >> *Subject:* Re: Roman Danyliw's Discuss on draft-ietf-babel-dtls-07: >> (with DISCUSS and COMMENT) >> >> >> >> Thanks for your reply! >> >> >> >> On Mon, Aug 12, 2019 at 4:35 PM Roman Danyliw wrote: >> >> Ben=E2=80=99s recommendation to explicitly note that this authentication= needs to >> be solved in external profiles would address my concern too: >> >> >> >> https://mailarchive.ietf.org/arch/msg/babel/5AnLlaHPTEsBJpV7WVrZLpw07ls >> >> >> >> (I don=E2=80=99t know if you were waiting on Ben for anything else, but = =E2=80=A6) I >> didn=E2=80=99t see this discussion about profiles in the new -08 text. >> >> >> >> The new profile text was added after -08 was submitted, it's in this >> commit: >> >> >> https://github.com/jech/babel-drafts/commit/458a9ae6b9b136122d8668b26ba4= 03f4f3a57167 >> >> >> >> Does it resolve your concern? >> >> If yes we'll submit a -09 with this new text. >> >> >> >> [Roman] Understood. Yes, that text resolves my concern. Thank you. >> >> >> >> Roman >> > --000000000000d90d7c05907a9423 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roman,

Would you be able to take a l= ook at draft -09 and update your ballot position please?
Thanks,
David


On Tue, Aug 13, 201= 9 at 3:50 PM David Schinazi <dschinazi.ietf@gmail.com> wrote:
Thanks Roman! We've now uploa= ded -09 with the new text:

David

On Tue, Aug 13= , 2019 at 7:29 AM Roman Danyliw <rdd@cert.org> wrote:

Hi David!

=C2=A0

From: David Schinazi [mailto:dschinazi.ietf@gmail.com]
Sent: Monday, August 12, 2019 11:01 PM
To: Roman Danyliw <rdd@cert.org>
Cc: The IESG <= iesg@ietf.org>; draft-ietf-babel-dtls@ietf.org; Donald Eastlake <d3e3e3@gmail.com>= ; babel-chairs <babel-chairs@ietf.org>; Babel at IETF <babel@ietf.org>
Subject: Re: Roman Danyliw's Discuss on draft-ietf-babel-dtls-07= : (with DISCUSS and COMMENT)

=C2=A0

Thanks for your reply!

=C2=A0

On Mon, Aug 12, 2019 at 4:35 PM Roman Danyliw <rdd@cert.org> wrote:=

Ben=E2=80=99s recommendation to explicitly n= ote that this authentication needs to be solved in external profiles would address my concern too:

=C2=A0

https://mailarchi= ve.ietf.org/arch/msg/babel/5AnLlaHPTEsBJpV7WVrZLpw07ls=

=C2=A0

(I don=E2=80=99t know if you were waiting on= Ben for anything else, but =E2=80=A6) I didn=E2=80=99t see this discussion= about profiles in the new -08 text.

=C2=A0

The new profile text was added after -08 was submitt= ed, it's in this commit:

=C2=A0

Does it resolve your concern?

If yes we'll submit a -09 with this new text.=

=C2=A0

[Roman]=C2=A0 Understood.=C2=A0 Yes, that te= xt resolves my concern.=C2=A0 Thank you.

=C2=A0

Roman

--000000000000d90d7c05907a9423-- From nobody Tue Aug 20 13:55: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 598E3120086; Tue, 20 Aug 2019 13:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ZyVZbDX4eZiC; Tue, 20 Aug 2019 13:54:50 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 C5F9712016E; Tue, 20 Aug 2019 13:54:49 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id t50so315546edd.2; Tue, 20 Aug 2019 13:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=BBpf1bNmW98cP3mrRrHAGKI5gTGtxWeB0DwBCaEhy9E=; b=jgAsdn4ooIxlGQ+ZaJa4+jODuFS5k2IafgyG6ldnqwetOwFQBsTnkMBS56BstGSLFW /+WJ4m/qhaUyGTs/7ic/yTgKD/s1OA1tWZQnSNppJtax4Pd5Ta/GcRUc1i9XXXJcaR1J WKeut+45UCLuO1nR96BJ+DO6dJbt1imuVg8rQXLoX/HKKRHFIpw5+nB5X30+NxX1P6Ej 3UDIaDJctPetV1RNqpsClkH5g/X90+r67Y1p13f0aOe/CfYhSY4Kz4lVCJv23bDFEnkl pYrr6KS3rUGrvikWn75LyxvW+6PQpTJCnj4ypGHDmSQC84e3cmdwRouDoPOcVMoQT0lm vIgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=BBpf1bNmW98cP3mrRrHAGKI5gTGtxWeB0DwBCaEhy9E=; b=OXGrqLEjCZK9kwGedIP0X9k1vusA5+k2lifz61HtTRso2W+Ijd8FOsUAiyViOXBs4m WQk/5dAAbmv9behIyuQcJvSTI5bZR07wScaRiMdKf13c+S8JrZMZNUBlerKPBHv6Q6hp YqcRnkStiSsbqCITLE5qeXzbWshmvgcq+tLg4dxpvlyVrkEtNNhlQ2e2QT7X0e8X9wUG TzCA3VYPcYzqbhu1zTMD9ZG24N/LJUy8jemDzur/9u4PT1hjuwZPHYvwTmoMMqqdpn+q AI5HU5PqXYc99ToYo4+VMmFsNU1R0yO2CALhukqJ/nCjk9Ogb+zagBP+fLwCOL6hjWkg f++w== X-Gm-Message-State: APjAAAU/njq3oT44TlqSHceQYoVgH7rdOYpwnqya+CDwzQqQI/bvx1Ps Z/kKeTJWS8/yVYqZhS6SYlD3VMyYF2Rjm99ewWs= X-Google-Smtp-Source: APXvYqwyjgFCTpK6viSOHXwZuuz4y5OJWz3HjpZ9Y2I5hmmweU5I6269xA93F0Om9CcKrkxD4OSfoo9aa+2qajbSgiA= X-Received: by 2002:aa7:c35a:: with SMTP id j26mr29570009edr.270.1566334488298; Tue, 20 Aug 2019 13:54:48 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 20 Aug 2019 13:54:47 -0700 From: Alvaro Retana In-Reply-To: <875zn685ne.wl-jch@irif.fr> References: <156518456148.8400.6644665367614468260.idtracker@ietfa.amsl.com> <875zn685ne.wl-jch@irif.fr> MIME-Version: 1.0 Date: Tue, 20 Aug 2019 13:54:47 -0700 Message-ID: To: Juliusz Chroboczek Cc: babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , The IESG , draft-ietf-babel-rfc6126bis@ietf.org Content-Type: multipart/alternative; boundary="000000000000c64a97059092aa2b" Archived-At: Subject: Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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, 20 Aug 2019 20:54:54 -0000 --000000000000c64a97059092aa2b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On August 9, 2019 at 4:07:03 PM, Juliusz Chroboczek (jch@irif.fr) wrote: Juliusz: Hi! Sorry for the delay in getting back to you... > (A) Clear Defaults and Operational Guidance > While I appreciate Babel's flexibility in terms of the ability to use > different strategies, I believe that both defaults and clear guidance > should be provided. Given that "not all...strategies will give good > results" and that in most cases these are listed as possible choices, > I don't think that this document "has resolved known design choices" > [BCP9/rfc7127]. The cost/metric computation and route selection > specially concern me because I believe that a robust/clear specification > is at the heart of any routing protocol. After thinking it over very carefully, it is with utmost sadness that I must disagree with you on this latter point. It also makes me sad that we=E2=80=99re not agreeing. This document does three things: - it makes normative requirements where the issues are well-understood (e.g. strict monotnicity of the metric); - in all cases, it suggests algorithms that are known to work well; - it gives a statement of caution to the adventurous implementer. This gives enough information to the implementer to implement something that works, while not unduly restricting the possibilities of future experimentation. Specification doesn=E2=80=99t necessarily preclude experimentation=E2=80=A6= or deviation from the defaults. Without a clear specification I=E2=80=99m afraid that the text still reads = like an Experimental document to me. Compare this with RFC 4271, which proudly states: BGP can support any policy conforming to the destination-based forwarding paradigm. Yes, but it also specifies a clear Decision Process to guarantee that "BGP speakers within an AS do not make conflicting decisions regarding route selection that would cause forwarding loops to occur.=E2=80=9D (=C2=A79.1.2= ). Flexibility is build in, even allowing a Custom Decision Process [1], but defining what the base behavior should be to guarantee consistency. BGP speakers can have their own policies, but within a clear set of rules starting from a base behavior: we all know from rfc4271 what the default is= . [1] https://tools.ietf.org/html/draft-ietf-idr-custom-decision even though many such policies will cause persistent oscillations. (By no fault of theirs -- determining statically if a given set of BGP route policies gives rise to oscillations is an open research problem.) [Aside: Still inside an AS, the persistent oscillations [rfc3345] are the result of constrained information from route reflectors [rfc4456] or confederations [rfc5065]=E2=80=A6which are extensions to the base.] I think that BGP is in fact a good example of what I am asking for: There are all kinds of options and variations that individual ASes can decide to implement=E2=80=A6but rfc4271 clearly defines what the default behavior is. ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- ... > (e) =C2=A73.7.2 > Finally, a node MAY send a triggered update when the metric for a > given prefix changes in a significant manner, due to a received > update, because a link's cost has changed, or because a different > next hop has been selected. 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). > How much is "a significant manner"? What about "a minor fluctuation"? > Are the modifiers (next hop change, for example) the only conditions to > take into account, or are they just examples of when these > significant/minor changes may occur? I'm not sure what you're aiming for here. This enumeration lists a set of events for which an implementer might be tempted to send a triggered update, and states that it's a bad idea. > How can these terms be Normatively enforced? In order to comply, an implementation: - doesn't send an update when the metric changes by 1 and nothing else changes; - doesn't send an update when NH changes and nothing else changes; - doesn't send an update when seqno changes and nothing else changes. The boundary between minor and major fluctuation is left to the implementation, which is okay, since in any case that's only a MAY. The intent being that it's reasonable to send a triggered update when the metric fluctuation is large enough to indicate that the route has probably become unusable. If the implementation doesn't follow the MAY, then the fluctuation will be propagated by the next periodic update. The reason I=E2=80=99m asking these questions is because rfc2119 says that = the keywords defined there "MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm=E2= =80=9D. By using =E2=80=9CMAY=E2=80=9D (in this specific case) I assume that the do= cument is trying to define a behavior that can be expected across implementations=E2=80=A6bu= t the explanation indicates the opposite: the intent is not to define a common behavior. IMO, you then shouldn=E2=80=99t use rfc2119 keywords in these ca= ses. Thanks! Alvaro. --000000000000c64a97059092aa2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

Juliusz:

Hi!=C2=A0 Sorry for the delay in getting back to you...


> (A) Clea= r Defaults and Operational Guidance= =C2=A0

> While I appreciate Babel's flexibility in ter= ms of the ability to use=C2=A0=
> different strategies, I believe that both defaults and clear guida= nce=C2=A0
> should be pr= ovided. Given that "not all...strategies will give good=C2=A0
> results" and that in most= cases these are listed as possible choices,=C2=A0
> I don't think that this document "has= resolved known design choices"= =C2=A0
> [BCP9/rfc7127]. The cost/metric computation and route= selection=C2=A0
> speci= ally concern me because I believe that a robust/clear specification=C2=A0
> is at the heart of any = routing protocol.=C2=A0
After thinking it over very carefully, it is with utmost sadness that=C2=A0
I must disagree with you = on this latter point.

It also makes= me sad that we=E2=80=99re not agreeing.


=C2=A0This document does three things:=C2=A0

- it makes normative requiremen= ts where the issues are well-understood=C2=A0
(e.g. strict monotnicity of the metric);=C2=A0
- in all cases, it suggests algorith= ms that are known to work well;=C2=A0=
- it gives a statement of caution to the adventurous implementer= .=C2=A0

This gives enou= gh information to the implementer to implement something=C2=A0
that works, while not unduly restrictin= g the possibilities of future=C2=A0
experimentation.=C2=A0

Specification doesn=E2=80=99t nec= essarily preclude experimentation=E2=80=A6or deviation from the defaults.

Without a clear specification I=E2=80=99m afraid that the text still r= eads like an Experimental document to me.


Compare this with RFC = 4271, which proudly states:=C2=A0

BGP can support any policy conforming to the destination-based=C2=A0
forwarding paradigm.=C2=A0

Yes, but it also specifies a clear Decision Process to guara= ntee that "BGP speakers within an AS do not make conflicting decisions= regarding route selection that would cause forwarding loops to occur.=E2= =80=9D (=C2=A79.1.2).=C2=A0 Flexibility is build in, even allowing a Custom= Decision Process [1], but defining what the base behavior should be to gua= rantee consistency.=C2=A0 BGP speakers can have their own policies, but wit= hin a clear set of rules starting from a base behavior: we all know from rf= c4271 what the default is.

[1]=C2=A0https://tools.ietf.org/html/draft-iet= f-idr-custom-decision=C2=A0


even though many such polici= es will cause persistent oscillations. (By no=C2=A0
fault of theirs -- determining statically if a giv= en set of BGP route=C2=A0
p= olicies gives rise to oscillations is an open research problem.)=C2=A0

[Aside: Still inside an AS, the persistent oscillations [rfc3345] are= the result of constrained information from route reflectors [rfc4456] or c= onfederations [rfc5065]=E2=80=A6which are extensions to the base.]

I think that BGP is in fact a good example of what I am asking for= : =C2=A0There are all kinds of options and variations that individual ASes = can decide to implement=E2=80=A6but rfc4271 clearly defines what the defaul= t behavior is.



...

> ------------------= ----------------------------------------------------=C2=A0
> COMMENT:=C2=A0
> ---------------------------------------------= -------------------------=C2=A0

...


> (e) =C2=A73.7.2=C2=A0
=
> Finally, a node MAY send a triggered update when the metric for a<= span class=3D"Apple-converted-space">=C2=A0
> given prefix cha= nges in a significant manner, due to a received=C2=A0
> update, because a link's cost has chang= ed, or because a different=C2=A0
> next hop has been selected. A node SHOULD NOT send triggered upd= ates=C2=A0
> for other r= easons, such as when there is a minor fluctuation in a=C2=A0
> route's metric, when the selecte= d next hop changes, or to propagate a= =C2=A0
> new sequence number (except to satisfy a request, as = specified in=C2=A0
> Sec= tion 3.8).=C2=A0

> H= ow much is "a significant manner"? What about "a minor fluct= uation"?=C2=A0
> Ar= e the modifiers (next hop change, for example) the only conditions to=C2=A0
> take into account, or= are they just examples of when these= =C2=A0
> significant/minor changes may occur?=C2=A0

I'm not sure what you're = aiming for here. This enumeration lists a set of=C2=A0
events for which an implementer might be tempte= d to send a triggered=C2=A0update, and states that it's a bad idea.=C2=A0

> How can these terms be Normatively enforc= ed?=C2=A0

In order to c= omply, an implementation:=C2=A0

- doesn't send an update when the metric changes by 1 and noth= ing else=C2=A0
changes;=C2=A0
- doesn't send an up= date when NH changes and nothing else changes;=C2=A0
- doesn't send an update when seqno changes a= nd nothing else changes.=C2=A0=

The boundary between minor and major fluctuation is left to the=C2=A0
implementation, which is= okay, since in any case that's only a MAY. The=C2=A0
intent being that it's reasonable to sen= d a triggered update when the=C2=A0
metric fluctuation is large enough to indicate that the route has = probably=C2=A0
become unusa= ble. If the implementation doesn't follow the MAY, then the=C2=A0
fluctuation will be propagated = by the next periodic update.=C2=A0

The reason I=E2=80=99m a= sking these questions is because rfc2119 says that the keywords defined the= re "MUST only be used where it is actually required for interoperation= or to limit behavior which has potential for causing harm=E2=80=9D.=C2=A0 = By using =E2=80=9CMAY=E2=80=9D (in this specific case) I assume that the do= cument is trying to define a behavior that can be expected across implement= ations=E2=80=A6but the explanation indicates the opposite: the intent is no= t to define a common behavior.=C2=A0 IMO, you then shouldn=E2=80=99t use rf= c2119 keywords in these cases.


Thanks!

Alvaro.

--000000000000c64a97059092aa2b-- From nobody Tue Aug 20 13:58:31 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 7E944120086; Tue, 20 Aug 2019 13:58:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan via Datatracker To: "The IESG" Cc: draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Suresh Krishnan Message-ID: <156633470950.350.2139163872840335541.idtracker@ietfa.amsl.com> Date: Tue, 20 Aug 2019 13:58:29 -0700 Archived-At: Subject: [babel] Suresh Krishnan's No Objection on draft-ietf-babel-rfc6126bis-14: (with COMMENT) 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, 20 Aug 2019 20:58:30 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-babel-rfc6126bis-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for including explanatory text for describing expectations and limitations of Backward Compatibility in Appendix F, in order to address my DISCUSS point regarding issues with backward compatibility with RFC6126 implementations. From nobody Tue Aug 20 18:17:39 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 AC3CF120018; Tue, 20 Aug 2019 18:17:29 -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 9ERDCLERRVBw; Tue, 20 Aug 2019 18:17:27 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71D641200F9; Tue, 20 Aug 2019 18:17:27 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7L1HM2g019592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Aug 2019 03:17: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 x7L1HMSc012337; Wed, 21 Aug 2019 03:17: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 2083635705; Wed, 21 Aug 2019 03:17:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Ag9-p8sheZlg; Wed, 21 Aug 2019 03:17:24 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id F02BC35702; Wed, 21 Aug 2019 03:17:23 +0200 (CEST) Date: Wed, 21 Aug 2019 03:17:23 +0200 Message-ID: <87ftlv48rg.wl-jch@irif.fr> From: Juliusz Chroboczek To: Alvaro Retana Cc: babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , The IESG , draft-ietf-babel-rfc6126bis@ietf.org In-Reply-To: References: <156518456148.8400.6644665367614468260.idtracker@ietfa.amsl.com> <875zn685ne.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 21 Aug 2019 03:17:22 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 21 Aug 2019 03:17:22 +0200 (CEST) X-Miltered: at korolev with ID 5D5C9BA2.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D5C9BA2.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D5C9BA2.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D5C9BA2.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 : 5D5C9BA2.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D5C9BA2.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] Alvaro Retana's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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: Wed, 21 Aug 2019 01:17:30 -0000 > This document does three things: > - it makes normative requirements where the issues are well-understood > (e.g. strict monotnicity of the metric); > - in all cases, it suggests algorithms that are known to work well; > - it gives a statement of caution to the adventurous implementer. > This gives enough information to the implementer to implement something > that works, while not unduly restricting the possibilities of future > experimentation. > Without a clear specification I’m afraid that the text still reads like an > Experimental document to me. As explained previously, the normative language in this document guarantees the lack of forwarding loops (this has been proven). Additionally, the non-normative advice (Appendix A.2 and the penultimate paragraph of Section 3.6) guarantees convergence and the lack of persistent oscillations (this hasn't been formally proven yet, but we're all convinced that's the case). This is way more than BGP does, which only guarantees the lack of forwarding loops, and only after convergence (unlike Babel, BGP makes no attempt to avoid transitory loops). It is my understanding that BGP does not guarantee the lack of oscillations, not even in the absence of Confederations or Route Reflectors, and not even if the algorithm specified in RFC 4271 Section 9.1.2 is followed. Please see K.Varadhan, R.Govindan, and D Estrin. Persistent route oscillations in inter-domain routing. Computer Networks, 32:1–16, 2000. Please be aware that this is not a criticism of BGP -- this is pretty much the best we can do given the current state of the art without impairing BGP's flexibility. The same is true of Babel. > Compare this with RFC 4271, which proudly states: > BGP can support any policy conforming to the destination-based > forwarding paradigm. > Yes, but it also specifies a clear Decision Process to guarantee that "BGP > speakers within an AS do not make conflicting decisions regarding route > selection that would cause forwarding loops to occur.” (§9.1.2). We're not discussing loops, Alvaro, we're discussing oscillations. I am reasonably sure that Rekhter does not claim lack of oscillations. >> COMMENT: >> ---------------------------------------------------------------------- > By using “MAY” (in this specific case) I assume that the document is > trying to define a behavior that can be expected across > implementations… 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. -- Juliusz From nobody Thu Aug 22 07:22:38 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 4CA90120025; Thu, 22 Aug 2019 07:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXwdqhlgpogT; Thu, 22 Aug 2019 07:22:32 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 A39A1120103; Thu, 22 Aug 2019 07:22:32 -0700 (PDT) Received: from 200116b82c40a9005947ae461257db2e.dip.versatel-1u1.de ([2001:16b8:2c40:a900:5947:ae46:1257:db2e]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1i0nyu-0003bw-Lc; Thu, 22 Aug 2019 16:22:28 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <87imqzu1vc.wl-jch@irif.fr> Date: Thu, 22 Aug 2019 16:22:27 +0200 Cc: draft-ietf-babel-rfc6126bis@ietf.org, d3e3e3@gmail.com, babel-chairs@ietf.org, babel@ietf.org, The IESG Content-Transfer-Encoding: quoted-printable Message-Id: <0C555879-5AF3-487F-A65D-95918A546783@kuehlewind.net> References: <156517737995.8257.5538554979559246700.idtracker@ietfa.amsl.com> <877e7m8b88.wl-jch@irif.fr> <1A2B2C1B-1536-4E75-A8D7-C5612FB8AEDA@kuehlewind.net> <87imqzu1vc.wl-jch@irif.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1566483752;cc53d8bb; X-HE-SMSGID: 1i0nyu-0003bw-Lc Archived-At: Subject: Re: [babel] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-babel-rfc6126bis-12=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Thu, 22 Aug 2019 14:22:35 -0000 Hi Juliusz, Please see below. > On 14. Aug 2019, at 18:51, Juliusz Chroboczek wrote: >=20 >> I really don=E2=80=99t want to request to enforce a 3 second limit. = However, >> I would like this draft to specify a limit or at minimum discuss >> suitable values for specific scenario. >=20 > Appendix B specifies values that were found to be useful in etwo kinds = of > realistic scenarios. >=20 > The protocol structurally enforces minimum values of 10ms (time = intervals > are carried on the wire in units of 10ms). Values that small are not > unrealistic over gigabit Ethernet (a full-size frame over GBE is sent = in 12=C2=B5s). I would like to propose the following: 1) Let's move appendix B into the body of the document. I think these = are important information for an implementer and therefore it needs more = attention. 2) Maybe you can add something like: The protocol structurally would = allow for a minimum value of 10ms for the update interval, however, the = update interval must be chosen carefully as such a low value could cause = significant network load for slow links but may be a suitable for high = speed link.=20 I=E2=80=99m sure you have a better wording. My intention is simply to = add another warning, to think carefully instead of just pick some = default. >=20 >>>> More concretely I think there are these cases that need more = guidance: >>>=20 >>> I agree. I've added a short discussion of packet pacing at the end = of >>> 3.1, and I refer to it at suitable places. >=20 >> Thanks. I was also hoping that you could make any recommendation on = how >> to implement that e.g. a fixed delay of a certain (default) value or >> based on some other knowledge. If that is a SHOULD and no further >> implementation example is given, I would be afraid that the risk is = high >> that people simple don=E2=80=99t implement this part. >=20 > You do realise it's a very high bar you're setting? >=20 > There exist standard techniques for packet pacing (static delay, = dynamic > delay, deadline-first scheduling, etc.). I hope you're not requesting > that I transform this document in a tutorial about packet scheduling. >=20 > I'll point out that RFC 5340 does not explain how to pace Dijkstra > recomputation. There's a good discussion of the issue in Gredler's = book > about IS-IS. I have no idea whether Gredler's book reflects the = behaviour > of modern implementations. I wasn=E2=80=99t looking for a tutorial for pacing but rather a = reference to add. E.g. just naming different approaches for how to = implement pacing and provide a reference would be a good thing I think. = However, I will not block on this one thing. Your choice.=20 >=20 >>>> - Section 3.7.2. (Triggered Updates) advises to send a message = multiple >>>> times for redundancy in case of loss. 5 and 2 are mentioned as = example >>>> values. Please provide a normative default value and a normative = maximum >>>> value here. >=20 >>> Done for the normative max and recommendation to avoid tail loss. >>> I haven't made the default values normative. >=20 >> Why not?=20 >=20 > What exact problem are we trying to solve here? Do you expect that = the > current non-normative language will cause issues? Thanks for having a max value normatively there! I think that is the = important part. And this is also not blocking for me anymore. I just = wondering why you don=E2=80=99t call them default value rather then = examples. I think specifying default value normatively would be more = clear and is what we usually do in specs. However, I think in this case = it will not make a huge practical difference. >=20 >>>> - In section 4.1.1 the update interval needs a lower limit (e.g. 3 = seconds) >>>=20 >>> I strongly disagree. Sub-second convergence after a mobility event = is >>> required in some networks. >=20 >> (See above) Maybe then 0.1 seconds is a suitable minimum value=E2=80=A6= ? >=20 > As mentioned above, the protocol structurally imposes a lower bound of > 10ms, which is not unrealistic over GBE. >=20 >>>> and a recommend default value would be could as well (Note that = there >>>> are other part in section 3 where the update value is discussed as = well). >=20 >>> Appendix B. >=20 >> I think this needs normative language in the body of the document. >=20 > I'm sorry, Mirja, I disagree. See my comments about GBE above. >=20 >>>> - Section 3.8.2.4. mentions network load when requests are sent to = all >>>> neighbours after reboot. Please provide more guidance about how to = pace out >>>> these requests. >=20 >>> I've removed this section altogether. >=20 >> Why? >=20 > The mechanism is not essential, and we're unable to give more precise > guidance that applies across a wide range of networks. I prefer to = remove > the mechanism rather than give bad advice. I think it would be good to have a note on network load when rebooting = somewhere in the document. Maybe you can re-add a warning in the = security considerations section? Mirja >=20 > -- Juliusz >=20 >=20 From nobody Thu Aug 22 09:55:06 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 75CE91208F6; Thu, 22 Aug 2019 09:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 0XD-KoJttoD6; Thu, 22 Aug 2019 09:54:52 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 532BC12082E; Thu, 22 Aug 2019 09:54:52 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7MGsgtd027968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Aug 2019 12:54:47 -0400 Date: Thu, 22 Aug 2019 11:54:42 -0500 From: Benjamin Kaduk To: Juliusz Chroboczek Cc: The IESG , draft-ietf-babel-hmac@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org Message-ID: <20190822165441.GK60855@kduck.mit.edu> References: <156521429138.8333.12124544758210076970.idtracker@ietfa.amsl.com> <87h86pcmzk.wl-jch@irif.fr> <20190814194802.GB88236@kduck.mit.edu> <87a7c8ir5d.wl-jch@irif.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a7c8ir5d.wl-jch@irif.fr> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-hmac-08: (with DISCUSS and COMMENT) 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: Thu, 22 Aug 2019 16:54:56 -0000 On Sat, Aug 17, 2019 at 02:15:10AM +0200, Juliusz Chroboczek wrote: > >>> Also in Section 3.1, if we are going to claim that a "random string of > >>> sufficient length" suffices to initialize a fresh index, we need to > >>> provide guidance on what constitutes "sufficient length" to achieve the > >>> needed property. > > >> Section 6 says [...] > > > And you don't want to make a forward reference to Section 6? > > I don't want to, since it makes this section more difficult to read, but > I have done so. Looking at the -10, I'm more sympathetic to this concern, and won't object if you change it back. The -10 also seems to address (or render irrelevant) my other Discuss points, so I'll cleare my ballot position shortly. > >>> Blake2s is a keyed MAC, but is not an HMAC construction. > > [...] > > >> I disagree. > > > Well, I am pretty uncomfortable about saying things that are not true! > > Ok. I've changed HMAC to MAC throughout the document, after consulting > the list. Thank you, and my apologies for having to churn the document so much. > >> I agree. This is something that we considered in the design of the > >> protocol (which is why Nonces are allowed to be so large), but never > >> implemented ourselves; it would probably be some work to get it right. > >> Hence the very careful formulation ("might"). Let me know if you want to > >> suggest a different formulation. > > > It's probably okay to leave this as speculative (since there's not an > > existence proof), but I think it's irresponsible to not also include a > > disclaimer of at least "Note that such schemes will need to consider what > > degree of "freshness" is required of a challenge and the risk of replay for > > the encoded state, among other things". > > Added "note however that any such scheme will need to prevent cookie > replay". (I've once implemented just such a scheme for the BitTorrent > DHT, and it's been running on hundred of thousands of nodes for almost ten > years now with no massive meltdown of the DHT; so I'm pretty confident > it's not that difficult.) > > >>> This is a symmetric-keyed scenario, so most attacks that involve a > >>> compromised node will be "uninteresting", in that once the key is > >>> exposed all guarantees are lost. However, it may still be worth noting > >>> that a compromised node can cause disruption on multi-access links > >>> without detection since there is no "end of generation" signal when a > >>> node changes its index. > > >> Are we misunderstanding each other? > > > A and C both have state about B, which is retained when B reboots. > > While B is still rebooting or otherwise initializing, C can forge a message > > "from" B that A will accept, and C can continue to do so until A sees the > > new (legitimate) index from B and switches over to the new generation. So > > A has accepted false input but neither A nor B are aware of it. > > Ah, I see. It's worse than that -- if C knows the key, then it can > perform a higher seqno attack on B, it doesn't need to wait for B to reboot. Also true. I don't have a great sense for how likely B would be to detect that higher seqno attack (or whether there's anything useful it could do, having detected the attack); I brought this one up as potentially notable since there is a much lower chance of discovery. > >>> Is there any need for initial PC value randomization? > > >> I don't see why. > > > I don't, either, but just wanted to get a second opinion from an actual > > expert. > > I hope that's not me. > > >>> Do we want to recommend starting at 0 or 1 (or prohibit recipients from > >>> assuming that the initial value for an index will be that)? > > >> The initial value as well as the rate of increase are arbitrary. For > >> example, a node may use a hardware clock (suitably offset to fit in 32 > >> bits) as the PC. > > > I agree that they're arbitrary, but have a lot of painful experience with > > protocol participants making assumptions about underspecified behavior that > > ended up not being protocol invariants, with subsequent breakage. If you > > think the existing ecosystem is healthy enough that there's not a real risk > > of problems down the line, I can accept that, but I wanted to raise the > > topic. > > The ecosystem is pretty young, but we haven't had any issues with > interoperability yet. I think that it's fair to say that if you encode > your age in the PC, you deserve any trouble you get. Okay. > >>> Does this rekeying option require an external operation/management actor > >>> to trigger it? It might be worth mentioning with some operational > >>> considerations. > > >> Disagree. > > > I think my main quesetion here is who determines, and how, "whenever a > > collision becomes likely". Some protocols have in-band mechanisms for > > peers to make such a determination and initiate rekeying automatically; > > from what I understand, babel-hmac does not. If we actually expect > > deployments to encounter scenarios where rekeying is necessary to preserve > > security, we should be pretty clear about who has the responsibility to do > > so. > > I've changed this to "by rekeying often enough that collisions are unlikely". > > Here's some background. Babel's evolution until now has been driven by > the needs of our users; this has led to two very interesting extensions > (Source-specific and RTT), and two extensions that are not being deployed > (diversity routing and ToS-specific). The security extensions, on the > other hand, have been designed due to IETF requirements, and they have no > users known to us. We are waiting for the community to react to the code > being available to discuss key management with them. > > Options include: > > - static keying, rekeying never happens; > - central node that performs periodic key rotation (this could be as > simple as a cron job that uses ssh to distribute keys); > - key negotiation using another protocol (e.g. HNCP, the Homenet thing). > > I'm keeping an open mind; the only thing I'm planning to refuse is in-band > key distribution or negotiation -- Babel is a routing protocol, not a key > distribution protocol. Fair enough, and thanks for the extra background. (I'd also be interested in hearing from people who have consciously decided to not deploy the security extensions, but that's way off-topic for this thread and probably better unicast to me.) > >> > o among different nodes, it is only vulnerable to immediate replay: > >> > if a node A has accepted a packet from C as valid, then a node B > >> > will only accept a copy of that packet as authentic if B has > >> > accepted an older packet from C and B has received no later packet > >> > from C. > >> > >> > nit: I don't think "A has accepted a packet from C" is quite the right > >> > precondition; it seems to be more like "A has received a valid packet > >> > from C", since whether or not A (as an attacker) considers it valid is > >> > irrelevant to whether (honest) B will. > >> > >> C is the attacker here, A is honest. > > > I was (apparently) reading this differently -- "replay" could be initiated > > by an RFC 3552 attacker in the network even without knowledge of the key. > > I see. Reworded, thanks. > > >>> Section 4.1 > >> > >>> If we had identifiers for symmetric keys or HMAC algorithms, we could > >>> include those identifiers in the pseudo-header and thereby gain some > >>> protection from downgrade/HMAC-stripping attacks in the presence of a > >>> weak keyed MAC algorithm. > > >> This is a symmetric algorithm, for downgrade attacks to work the victim > >> would need to be configured with a weak key. I therefore don't see how > >> this added complexity helps. > > > I've seen plenty of cases where systems are still configured with > > single-DES keys as well as AES keys (whoops!). > > Right. I'm not too concerned. I'm not too concerned, either, but appreciate having the discussion. > We're only using MAC here, so the strength of the hash is not likely to be > the limiting factor. We could be using MD2 here, and we'd still be > reasonably secure. (And if someone implements this protocol with MD2 > hashing, I'd like to hear from them.) > > >>> It might be worth reiterating that every time a packet goes on the wire, > >>> it gets a fresh PC, regardless of whether it's a "retransmit" after a > >>> timeout or a new message. > > >> There are no retransmits in this protocol. > > > Hence the scare quotes. Can you guarantee that no one will look at this > > and say "I'll just cache this challenge I send to a peer and re-send it > > (rate limited) to that peer in response to traffic I can't authenticate, > > until I get a valid reply"? > > I cannot. From an implementation point of view, however, this would be > way more complicated than the correct implementation. Okay. > >>> Validating the HMACs is the sort of operation that we tend to recommend > >>> be done in constnt-time to avoid side channel attacks. I don't have a > >>> concrete attack handy here at the moment, though. > > >> I frankly have no idea if that's necessary or not. FWIW, the protocol is > >> asynchronous, and there is jitter applied to packets. > > > My super-quick assessment is that the timing channel could be used to "pick > > off byte by byte" an attacker's guess at the HMAC of some fixed plaintext > > that the attacker would later replay (with valid HMAC) to some other > > participant. > > We never compare keys -- we compare MACs. So perhaps you could gain some > information about how many bytes of the (per-packet) MAC match, but that > gives you no information about how many bytes of the key match. If you > really insist, I can mandate constant-time comparison, but I feel it would > be confusing for the reader to mandate it without being able to explain > how it improves the protocol's security. I do not insist. Most of my (trimmed from here) discussion was an attempt to convince myself that learning just the valid MAC value (vs. the key value, as you note) would not be of any real value to the attacker. > >>> Any reason to not just drop the whole packet if there are multiple PCs > >>> present? I see this is not rfc7298bis but don't know what level of > >>> breaking change is reasonable. > > >> It doesn't matter much, it's a "cannot happen" case. (Note that the HMAC > >> has already been validted at this point, so it isn't a security issue.) > > > Oh, it's definitely not a security issue; this is more of a philosophical > > question of what to do in the face of a peer with a "totally broken" > > implementation. > > I really don't think it makes much importance. Since this formulation has > been accepted by the WG, I'd rather not go through getting a different > approach accepted. > > > The TLS ecosystem, for example, has been bitten by the need for > > historical compatibility quirks and is now (over?)compensating by being > > quite strict about rejecting malformed things. > > Indeed, RFC 8446 is what nightmares are made off: > > Experience has shown that many servers > do not properly implement version negotiation, leading to "version > intolerance" in which the server rejects an otherwise acceptable > ClientHello with a version number higher than it supports. > > >>> I'd suggest explicitly stating that if there is a challenge reply that > >>> doesn't validate, the packet should be discarded. > > >> This is already the case -- a packet with an incorrect challenge reply is > >> treated just like a packet with no challenge reply. > > > This was an attempt to "consider all the ways in which a peer could > > misbehave": it could send two, one valid and one invalid; or an invalid > > challenge reply even though it didn't need to supply one at all; or ... > > (This is basically the same philosophical question as above.) > > According to the text, the receiving peer will process all the challenge > replies in order. The first valid reply will cause it to accept the > packet, the remaining ones will be ignored (Section 4.3.1.3). > > Suppose that for some reason A sends to challenge requests in quick > succession. B will send two challenge replies, and if we're unlucky, they > will end up in the same packet; so we end up with a packet with two > challenge replies, only the second of which will be accepted by A. This > is perfectly normal (although somewhat extreme) behaviour in this protocol. Thanks for helping me think it through. > >>> challenge reply is extremely cheap (it's just a bitwise comparison of > >>> two strings of octets), a similar optimisation for challenge replies > >>> is not worthwile. > >> > >>> Er, challenge reply validation still requires the HMAC validation step, > >>> right? > > >> At this stage we've already verified the HMAC. The only thing we could > >> potentially save would be a bitwise comparison, and that's not worth it. > > > Right, but just "validating a challenge reply" in vacuum could be taken to > > include validating the HMAC on the containing packet. An editorial comment, > > to be sure, but "poses minimal incremental cost" would avoid it. > > Done. > > > Consider a multi-access link with honest A and B, and attacker C. > > A sends a challenge request to B, that C observes and records. B sends a > > challenge reply, and A sends some more traffic. What happens if C starts > > spamming replayed copies of that challenge request towards B? This note > > about constructing Challenge Reply is during the preparse stage, before > > index/PC validation. Can C cause B to spend a lot of time generating > > challenge replies and reduce the amount of time spent sending actual > > data? > > You're right. I've added a requirement to rate-limit challenge replies. > (Since we're already rate-limiting requests, this does not slow down the > protocol any more.) Thanks! > >> > Section 6 > >> > >> > This mechanism relies on two assumptions, as described in > >> > Section 1.2. First, it assumes that the hash being used is > >> > >> > s/hash/MAC/ > >> > >> I'm confused. This section refers to pre-image attacks, which I was under > >> the impression is a property of the hash. > > > The thing we're sending over the wire is a MAC (sometimes HMAC-SHA-256; > > sometimes Blake2s; potentially other things in the future). MACs are > > almost universally constructed using hash functions, so it's pretty natural > > to think of them fairly interchangably, but there do exist other > > constructions like CBC-MAC. > > Fixed. > > > (Also, I think technically we're concerned about *second* preimage > > resistance, since we're effectively sending the first preimage as the > > message.) Getting this second-preimage resistance from CBC-MAC > > constructs that take variable-length input requires some care, though! > > Not sure. We're not sending the key. > > >>> It would require a bit more thought to convince me that 64-bit indices > >>> are sufficient for *all* cases. > > >> Assume the attacker is able to crash the node at will, and that the node > >> needs 10s to reboot. If we assume the attacker will start seeing > >> collisions after 2^32 tries, then this will happen after 1360 years, which > >> is slightly more than the duration of the Byzantine empire. > > > "Attacks only get better; never worse." > > > My point was to show that it's plausible for an attacker to be able to > > trigger index generation, and that if we want to be robust in the face of > > future attacks, we should consider a threat model that allows them to do so > > at will. Just because we can't see how that would happen now doesn't mean > > very much unless we have some sort of proof to back it up. > > Yes, that's why the protocol supports larger values. However, for the > time being, I stand by the statement that "64-bit values are believed to > be large enough for all practical applications". Okay. > >>> present at the receiver. If the attacker is able to cause the > >>> (Index, PC) pair to persist for arbitrary amounts of time (e.g., by > >>> repeatedly causing failed challenges), then it is able to delay the > >>> packet by arbitrary amounts of time, even after the sender has left > >>> the network. > > >>> I'd suggest adding another sentence describing the potential > >>> consequences of selectively delayed input (i.e., messing up the > >>> routing). > > >> We don't know about any such consequences. Still, we believe it is good > >> to avoid this situation. > > > Maybe I'm confused, but suppose a node advertises a really-low-metric path > > to a prefix, but then drops off the network. > > Sorry, my brain went away when I wrote that. This is exactly the issue > I had in mind when I suggested this requirement. I've added "which could > allow it to redirect or blackhole traffic to destinations previously > advertised by the sender". Thanks. > >>> nit: that's a comma splice in the parenthetical; a semicolon would be > >>> better. > > >> I've added a conjunction, I didn't realise such usage is unacceptable. > > > Introspection suggests that it's a pet peeve of mine, > > I'm pretty sure this usage is standard in British English, which is the > dialect I was taught. Thank you for educating me, I shall avoid it in the > future. Interesting; I did not know that. > (*My* pet peeve is the use of a comma after i.e. and e.g., but who am I to > argue with the RFC Editor.) My condolences! I can't imagine that gets any easier to deal with over time, either. Thanks again, Ben From nobody Thu Aug 22 09:55:12 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 3C23E120A70; Thu, 22 Aug 2019 09:55:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-babel-hmac@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156649290223.14801.7661944531675805593.idtracker@ietfa.amsl.com> Date: Thu, 22 Aug 2019 09:55:02 -0700 Archived-At: Subject: [babel] Benjamin Kaduk's No Objection on draft-ietf-babel-hmac-10: (with COMMENT) 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, 22 Aug 2019 16:55:04 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-babel-hmac-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-hmac/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss (and Comment) points! One further note on the added text: I think that there is only mixed consensus that PBKDF2 remains an algorithm that effectively hampers dictionary attacks, since it's parallelizable and not memory-hard, but I don't object to listing it here. From nobody Thu Aug 22 11:35:56 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 735B6120A8F for ; Thu, 22 Aug 2019 11:35:54 -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 8IQQUEHnCILC for ; Thu, 22 Aug 2019 11:35:53 -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 F2E29120041 for ; Thu, 22 Aug 2019 11:35:52 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7MIGe4d036393 for ; Thu, 22 Aug 2019 14:35:49 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 2uhxpku4v6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 22 Aug 2019 14:35:49 -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 x7MIZlE1030905 for ; Thu, 22 Aug 2019 14:35:49 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7MIZeBZ030583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 22 Aug 2019 14:35:40 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 70E14400B574 for ; Thu, 22 Aug 2019 18:35:40 +0000 (GMT) Received: from GAALPA1MSGHUBAF.ITServices.sbc.com (unknown [130.8.218.155]) by zlp30488.vci.att.com (Service) with ESMTPS id 5F13E400B573 for ; Thu, 22 Aug 2019 18:35:40 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.177]) by GAALPA1MSGHUBAF.ITServices.sbc.com ([130.8.218.155]) with mapi id 14.03.0468.000; Thu, 22 Aug 2019 14:35:39 -0400 From: "STARK, BARBARA H" To: "'babel@ietf.org'" Thread-Topic: info-model: those darned metrics Thread-Index: AdVWEa4ACwAdZKb8SpCpoTNd6E1jzQDBkHIA Date: Thu, 22 Aug 2019 18:35:39 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E282EE7@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114E27C846@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E27C846@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.194.205] 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-08-22_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=650 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908220160 Archived-At: Subject: Re: [babel] info-model: those darned metrics 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: Thu, 22 Aug 2019 18:35:55 -0000 > It looks like I missed updating some of the language in the descriptions = for > calculated and received metrics. >=20 > It says "At least one of babel-route-calculated-metric and babel-route- > received-metric MUST be non-zero. Having both be non-zero is expected for > a route that is received and subsequently advertised." >=20 > I think it should be "At least one of babel-route-calculated-metric and b= abel- > route-received-metric will be non-NULL. Having both be non-NULL is > expected for a route that is received and subsequently advertised." >=20 > There's no need for normative language here, since the values are read-on= ly > and beyond the control of the info model. In discussions with Mahesh on the YANG model, he expressed a preference to = have normative language of: "At least one of babel-route-calculated-metric and babel- route-received-metric MUST be non-NULL. Having both be non-NULL is expected for a route that is received and subsequently advertised." Would anyone have a problem with this? Barbara From nobody Thu Aug 22 12:37:28 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 4202A120B16; Thu, 22 Aug 2019 12:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 aVgsKliDfDtb; Thu, 22 Aug 2019 12:37:17 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 1835B120B39; Thu, 22 Aug 2019 12:37:16 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7MJbAwa029000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Aug 2019 15:37:13 -0400 Date: Thu, 22 Aug 2019 14:37:09 -0500 From: Benjamin Kaduk To: Juliusz Chroboczek Cc: The IESG , draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org Message-ID: <20190822193709.GN60855@kduck.mit.edu> References: <156521599894.8313.13827924927219698158.idtracker@ietfa.amsl.com> <87v9v57pjm.wl-jch@irif.fr> <20190814230513.GD88236@kduck.mit.edu> <87zhk8h6us.wl-jch@irif.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zhk8h6us.wl-jch@irif.fr> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT) 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: Thu, 22 Aug 2019 19:37:20 -0000 On Sat, Aug 17, 2019 at 04:18:51AM +0200, Juliusz Chroboczek wrote: > >>> Section 3.8.2.1 notes that "[d]ue to duplicate suppression, only a small > >>> number of such requests will actually reach the source." (for seqno > >>> requests intending to avoid starvation). > > [...] > > > It still feels like an internal inconsistency to me. How would you feel > > about s/will actually reach/are expected to actually reach/? > > Ok, done. > > >>> I think we may need to have a discussion about the feasibility of > >>> multicast acknowledgment requests with only a 16-bit nonce. > >> > >> Section 3.3. An acknowledgment MUST be sent to a unicast destination. > > > I saw that, which is why I specified "acknowledgment requests". > > The nonce is used to match an Ack with the corresponding Req. Since the > Ack is sent over unicast, a node only needs to match the Acks to the Reqs > it originated. A sequential counter is good enough if we assume that > 65536 distinct values is enough to deal with packet duplication. > > In any case, even if there's a collision, the consequences are fairly > mild: the node will wrongly believe that a packet has been acknowledged, > which might cause the packet to fail to be resent, but Babel is designed > to deal gracefully with packet loss. Fair enough, I am sufficiently convinced. > To avoid confusion, I've renamed the Nonce to Opaque. > > >>> ---------------------------------------------------------------------- > >>> COMMENT: > >>> ---------------------------------------------------------------------- > >> > >>> Should there be a "changes since RFC 6126" section that is retained in > >>> the published RFC? (I assume that Appendix F is going to be dropped.) > >> > >> Is that a hard requirement? We've updated all implementations, so it > >> wouldn't be too useful to anyone, and it would be a fair amount of work. > > > This is the non-blocking Comment section, so no, it's not a hard > > requirement. > > I've added such a section. > > >>> Section 1.2 > > >>> Second, unless the optional algorithm described in Section 3.5.5 is > >>> implemented, Babel does impose a hold time when a prefix is > > >>> Similarly to my comment on the applicability doc, I'm not sure if > >>> there's one or two things in Section 3.5.5 that would match this > >>> description. > > >> I'm not sure what's missing. 3.5.5 clearly states that either you wait > >> for a fixed timeout, or you do something that doesn't involve waiting for > >> a fixed timeout. > > > Grammatically, an "optional algorithm" is a single thing. > > I've replaced this with "the second algorithm". > > >>> I'm trying to walk through this and missing a step or two. > [...] > > >> We want to prove that the following property is preserved: > >> > >> P: NH(A) = B implies FD(B) < FD(A) > [...] > > > Okay. So it sounds like I'm supposed to read "accepts an update from B" > > and interpret that as meaning "that causes NH(A) to be B" as opposed to, > > say, "this is valid metric data and I am recomputing my routing table in > > response"? I can get behind that conclusion, but don't know if that's just > > a term of art I missed or some clarification should be added. > > I've added "and when it switches next hops". Great; thank you! > >>> Section 2.5 > >> > >>> Using the minusculeu and majuscule forms of the same letter to mean > >>> different things (e.g., source S and sequence number s) is something of > >>> a readability anti-pattern. > > >> I agree. We need Greek letters in RFCs. (No Gothic, please.) > > > sadly, RFC 7997 doesn't really seem to support this cause :-/ > > Some people have no vision. > > >>> Section 3.2.6 > >> > >>> It would probably be helpful to readers to note that "neighbor that > >>> advertised" and "next-hop" can be different due to being different > >>> address families. > >> > >> They are completely different data structures. The neighbour is (a > >> reference to) an entry of the neighbour table, the NH is an IP address. > > > That's true. Do we want to make it more clear to the reader that is going > > through things quickly? > > It was difficult to write, there's no reason why it should be easy to > read. Still, I've followed your advice. Thank you. > >>> neighbours. However, if a seqno request is resent by its originator, > >>> the subsequent copies MAY be forwarded to a different neighbour than > >>> the initial one. > >> > >>> Is MAY the appropriate level of strength? Trying the same neighbor > >>> would be effective if the original was unsuccessful due to packet loss, > >>> but is it possible for a routing pathology to occur that directs the > >>> request in the "wrong direction" with respect to a link or node failure? > > [...] > > > Hmm. I might actually suggest a non-normative "may", then, > > Done. > > >> If we want to be consistent with the rest of Babel, it is legal to check > >> and to ignore this TLV. Since this TLV is ignored in any case, the > >> distinction is somewhat uninteresting. > >> > >> (I guess you're thinking about adding noise for security purposes. Please > >> define a new TLV if that's required, I prefer protocol extensions to be > >> explicit about their intent.) > > > I was originally going for steganographic-like side channels, but that's an > > option, too. I'll wait until I can think up a use for the noise before I > > write that draft, though ;) > > Heh. It's a link-local steganographic channel, so not very interesting. > If you find a way to encode information in route updates in such a manner > that it gets propagated to the rest of the network, I'll be more excited. > > >>> Section 4.6.3 > >> > >>> Sixteen bits of nonce does not provide much unguessability (I note that > >>> LISP's rfc6830bis is recommending that their 24-bit nonce echo > >>> functionality not be relied on for return-routability checks over the > >>> public Internet). However, since these acknowledgment exchanges are > >>> only between direct neighbors, it seems that they are only needed for > >>> correlating responses to requests and not for unguessability. (In this > >>> case it seems a sequence number would work just as well as a random > >>> number, and we might want to discourage random assignment in the text to > >>> avoid the risk of birthday collisions.) > >>> On the other hand, multicast acknowledgment requests could be > >>> problematic (and especially so when sequential nonces are used), and if > >>> they are intended to be allowed then we may need to consider using a > >>> larger and random nonce. > >> > >> Section 3.3: > >> > >> An acknowledgment MUST be sent to a unicast destination. > > > I understand that. Nonetheless, any time that an attacker C (e.g., on a > > shared link) can send a message to A that changes how A interacts with B, > > that puts up a flag that we need to think about the interaction more > > carefully. In this case, *probably* B will ignore spurious acks from A, > > but is that always true? Is that the only case we need to consider? > > Without a cryptographic protection mechanism, this protocol is completely > insecure. The Ack nonce is not meant to be unguessable, it's just meant > for the requestor to match the Acks it receives to the Reqs it sent. It's > just a counter, except that the representation is a local implementation > matter. > > To avoid confusion, I've renamed the Nonce to Opaque. > > >>> Section 5 > >> > >>> "Specification Required" also requires Expert Review. What guidance can > >>> we provide to the experts for making registration decisions? > > [...] > > >> I think we can deal with that issue when the problem occurs. > > > It's unlikely to be a timely response if we do that; I expect an RFC would > > be needed in order to change registry policy/guidance, and that would take > > at least a few months. > > What do you suggest? It's hard for me as an outsider to be confident about giving good advice. Some potential options include: (1) leave it as-is and trust that the expert will be reasonable (2) note that the expert can ask the WG/list for further input if they are uncertain (3) direct the expert that requests should only be approved if they are of general applicability, well specified, and do not have any obvious omissions or potentially a combination thereof. (3) is aligned with a fairly common pattern that we see, though it's by no means a universal pattern. > >>> I don't understand the origin of the '256' in the MIN(1, 256/txcost) > >>> formula (described as a probability estimate). > > >> We scale the values to fit in a 16-bit integer field without excessive > >> loss of precision. > > > Sorry; I'm still confused. If alpha is a "probability estimate", shoudln't > > it be between 0 and 1? MIN(1, .) then serves to cap the top of the range, > > so I want 256/txcost to be between 0 and 1, aka txcost to be larger than > > 256. I see that we send the rxcost(/txcost) values in the 16-bit integer > > IHU field, and use 0xffff to indicate infinity, but within that 0..2^15-2 > > range, assignment of costs is left fairly arbitrary. So a scaling factor > > would presumably also be arbitrary, but why is this > > partial-scale-and-partial-cap procedure useful versus just scaling over the > > full 16-bit range into a probability estimate from 0 to 1? > > The scaling above gives a wireless link a cost between 256 and infinity, > where 256 stands for lossless. Ethernet links use 2-out-of-3, so > a working Ethernet gets a cost of K. Since you want to prefer Ethernet to > Wireless, you pick K < 256. You couldn't do that if wireless got a cost > of 1. Oh! Now it makes sense; thank you! I think I was focused too much on the details of the algorithm and forgot that this is ETX-specific, and thus that we want to kick any/all wireless links up into a less-preferred range since wired links are likely to be more reliable. On the other hand, that also means that this is less an inherent property of the ETX algorithms and perhaps more of an implementation parameter, so I might consider tweaking the language slightly to reiterate that this formula is an implementation option and not a requirement (e.g., "A node using this ETX variant for link quality estimation [...]") > I've added a recommendation to set K=96 for Ethernet links (this is what > current implementations use). Great! I think at this point that all my Discuss points have been addressed on one way or another, so I will go update my ballot position. Thanks again, Ben From nobody Thu Aug 22 12:55:25 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 CD5BB120BF1 for ; Thu, 22 Aug 2019 12:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlRlk2HanQNE for ; Thu, 22 Aug 2019 12:55:21 -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 07803120BE1 for ; Thu, 22 Aug 2019 12:55:20 -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 x7MJnonm002757 for ; Thu, 22 Aug 2019 15:55:19 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 2uj1ekge69-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 22 Aug 2019 15:55:18 -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 x7MJrTPE031212 for ; Thu, 22 Aug 2019 15:53:29 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7MJrNwn030972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 22 Aug 2019 15:53:24 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id D4669400AE37 for ; Thu, 22 Aug 2019 19:53:23 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30488.vci.att.com (Service) with ESMTPS id C3395400AE36 for ; Thu, 22 Aug 2019 19:53:23 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.177]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0468.000; Thu, 22 Aug 2019 15:53:23 -0400 From: "STARK, BARBARA H" To: "'babel@ietf.org'" Thread-Topic: info-model: updated editor's draft Thread-Index: AdVZIUeVhkI2OMBkSOelKCCwJVx6Ig== Date: Thu, 22 Aug 2019 19:53:23 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E283143@GAALPA1MSGUSRBF.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.194.205] 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-08-22_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=794 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908220168 Archived-At: Subject: [babel] info-model: updated editor's draft 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: Thu, 22 Aug 2019 19:55:23 -0000 I think I've got everything in the newest Editor's Copy at=20 https://bhstark2.github.io/babel-information-model/draft-ietf-babel-informa= tion-model.html Changes from the previous copy are: removed vestigial "and babel-nbr-stats" from babel-stats-reset description changed babel-interface-reference slightly to change it from "Reference to = an IPv6 interface object..." to: "Reference to an interface object that can= be used to send and receive IPv6 packets..." changed zero to NULL in descriptions of route-received-metric and calculate= d-received-metric (as mentioned on the list) added text to Security Considerations to include some of the points being m= entioned in the YANG model and discussion of MAC key length and value gener= ation. Fixed some typos. If no-one has complaints about this copy, I'll upload it as -09. I think I'= ve addressed all comments. WGLC end date was yesterday. Barbara From nobody Thu Aug 22 12:59: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 C4C6D120BF1; Thu, 22 Aug 2019 12:59: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.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156650395271.14864.52756353331686153@ietfa.amsl.com> Date: Thu, 22 Aug 2019 12:59:12 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-yang-model-03.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, 22 Aug 2019 19:59:13 -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 : YANG Data Model for Babel Authors : Mahesh Jethanandani Barbara Stark Filename : draft-ietf-babel-yang-model-03.txt Pages : 37 Date : 2019-08-22 Abstract: This document defines a data model for the Babel routing protocol. The data model is defined using the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-yang-model-03 https://datatracker.ietf.org/doc/html/draft-ietf-babel-yang-model-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-yang-model-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 22 13:05: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 6E37E120C24 for ; Thu, 22 Aug 2019 13:05:05 -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 1SraflMPerzo for ; Thu, 22 Aug 2019 13:05:03 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 D7BDA120C23 for ; Thu, 22 Aug 2019 13:05:03 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id d1so4299064pgp.4 for ; Thu, 22 Aug 2019 13:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Sbbvums90/lGXMt6AZHB0afKmez+etD/lGK04TmEj/o=; b=mbKTq0rzOEEbWGt/gAaXyykZkeAfkN1zH1oz9ZLijGQijNUb6IH3y5KKGDirXoUFJZ Ws1hl52Tc1ZLGpK1LMJDOfzJroRd9BDLHqVMPPSkMO7sM9/EPNinKtOAxw0UyV/MGgaD CpYqLhTZYKWD5FH0KyY9hUhfubeuQuX9Ckno92J0P76/kY6QQ1SweCtN1+0O5svQGeJG M2oVmfKs4zJ2GbWUbcxtSxV6UMVkiNH3lN041jz0cX7TUK8RQvKmpYKbXiDGM6xYRnoD LdPrfo1MDC3m729VexfSk/26aYtwtuh68fnFVkRfeCCOG5GZWgZ05X/fJ5QSuypnUMT2 +t6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=Sbbvums90/lGXMt6AZHB0afKmez+etD/lGK04TmEj/o=; b=j5YeRf4raLyJYoNEZULqA6DAyeblNZLrqvdxNkcugaNLshNG5AaTLggKgr18v0ueeZ uVqU3mUnCFxQ6lzB0V0wsx9uWjxRdvf3zngqxXc6pFyF2EP9MzUkpbbtMy6mEJ1XRkgm YKteIxtU8R94XgfjMDZML4RDHs1/OygDE0mlQZJx2W6WYc+sinYB2dn1MppzXjp3zdEj qsUbP4UsZpvwAZbIQJZvtFX/amFLM2ZwvVpDOyr/xZTowcFuEIHUGjxBIQclbHCjJ5VT hDNlW1y9fMKCoZFr0tzfQmZO7jG8tFAdolPVLKEL4CBmaSI8A+VfaBPRm8y+8ay8oKD0 /NdQ== X-Gm-Message-State: APjAAAXSBTVn/Cmx7D/faM7bmADCER40pjk0BdDKjjoLB+wi/tDSqiWf /wH8+zblmQ0SKjdpU3Fjx57bRAfRsi4= X-Google-Smtp-Source: APXvYqycXa5eI5hTIqEAl2Cm2wJEBpsIem3lAfikgyOo2CE1bfSXBTJtpO6N8xJXFc/IkxIQ92g+JQ== X-Received: by 2002:a17:90a:630a:: with SMTP id e10mr1424986pjj.25.1566504302438; Thu, 22 Aug 2019 13:05:02 -0700 (PDT) Received: from [10.33.122.240] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id e6sm242554pfl.37.2019.08.22.13.05.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Aug 2019 13:05:01 -0700 (PDT) From: Mahesh Jethanandani Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 22 Aug 2019 13:05:01 -0700 References: <156650395271.14864.52756353331686153@ietfa.amsl.com> To: Babel at IETF In-Reply-To: <156650395271.14864.52756353331686153@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-yang-model-03.txt 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: Thu, 22 Aug 2019 20:05:06 -0000 This version of the draft closely tracks the -09 version of the = information model that Barbara is about to post. In addition, it updates = the Security section of the document (thanks Barbara), and adds several = examples of Babel configuration (thanks Juliusz). Enjoy! > On Aug 22, 2019, at 12:59 PM, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : YANG Data Model for Babel > Authors : Mahesh Jethanandani > Barbara Stark > Filename : draft-ietf-babel-yang-model-03.txt > Pages : 37 > Date : 2019-08-22 >=20 > Abstract: > This document defines a data model for the Babel routing protocol. > The data model is defined using the YANG data modeling language. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-babel-yang-model/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-babel-yang-model-03 > https://datatracker.ietf.org/doc/html/draft-ietf-babel-yang-model-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-babel-yang-model-03 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel Mahesh Jethanandani mjethanandani@gmail.com From nobody Thu Aug 22 13:14:08 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 A3BD912011B; Thu, 22 Aug 2019 13:14:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156650484666.14898.2074657771112629308.idtracker@ietfa.amsl.com> Date: Thu, 22 Aug 2019 13:14:06 -0700 Archived-At: Subject: [babel] Benjamin Kaduk's No Objection on draft-ietf-babel-rfc6126bis-14: (with COMMENT) 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, 22 Aug 2019 20:14:07 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-babel-rfc6126bis-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my Discuss points! I am happy to see the expanded text on update representation and parser state in Section 4.5 -- that's enough to clear my discuss point, though I probably would have added even a bit more text if I was writing it myself. Section 4.5 In addition to the above, an Update TLV can omit a prefix of the prefix being announced, which is then extracted from the preceding Update TLV in the same address family (IPv4 or IPv6). Finally, as a nit: from a rhetorical sense, I'd suggest "omit an initial portion of the prefix", to avoid using the word "prefix" with two different meanings in the same sentence. Appendix B Link cost: estimated using ETX on wireless links; 2-out-of-3 with C=96 on wired links. Perhaps "ETX as described in Appendix A.2.2". Appendix C At a minimum, they discard routes with a destination prefix in fe80::/64, ff00::/8, 127.0.0.1/32, 0.0.0.0/32 and 224.0.0.0/8. 127.0.0.1/32 as opposed to /8? Appendix F There are two optioal features that make the new protocol incompatible with its predecessor. First of all, RFC 6126 did not nit: "optional" Two changes need to be made to an implementation of RFCs 6126 and 7557 so that it can safely interoperate in all cases with implementations of this protocol. First, it needs to be modified to either ignore or process Unicast Hellos. Second, it needs to be modified to parse sub-TLVs of all the TLVs that it understands and that allow sub-TLVs, and to ignore the TLV is an unknown mandatory sub-TLV is found. It is not necessary to parse unknown TLVs, since nit: "if an unknown" There are other changes, but these are not of a nature to prevent interoperability: [...] o the compression state is now specific to an address family rather than an address encoding Section 4.5; It seems like an old implementation that decompresses an update to different contents than a new implementation does, would have some effect on routing. Am I missing something? From nobody Thu Aug 22 14:21:50 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 273231200A4; Thu, 22 Aug 2019 14:21:47 -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.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: babel@ietf.org Message-ID: <156650890705.14793.12762440824511421761@ietfa.amsl.com> Date: Thu, 22 Aug 2019 14:21:47 -0700 Archived-At: Subject: [babel] I-D Action: draft-ietf-babel-information-model-09.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, 22 Aug 2019 21:21:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Babel routing protocol WG of the IETF. Title : Babel Information Model Authors : Barbara Stark Mahesh Jethanandani Filename : draft-ietf-babel-information-model-09.txt Pages : 21 Date : 2019-08-22 Abstract: This Babel Information Model can be used to create data models under various data modeling regimes. It allows a Babel implementation (via a management protocol or interface) to report on its current state and may allow some limited configuration of protocol constants. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-babel-information-model-09 https://datatracker.ietf.org/doc/html/draft-ietf-babel-information-model-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-information-model-09 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 Aug 22 15:37:35 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 3BB16120099 for ; Thu, 22 Aug 2019 15:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZ7K_YeJfK-j for ; Thu, 22 Aug 2019 15:37:31 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 170EC120098 for ; Thu, 22 Aug 2019 15:37:31 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7MMZKGi042578; Thu, 22 Aug 2019 18:37:27 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2uj32p9j6a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Aug 2019 18:37:27 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7MMbPQM023539; Thu, 22 Aug 2019 18:37:26 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7MMbJZY023319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 22 Aug 2019 18:37:19 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 40F1D4009E69; Thu, 22 Aug 2019 22:37:19 +0000 (GMT) Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (unknown [130.8.218.150]) by zlp30487.vci.att.com (Service) with ESMTPS id 2A0FE4000695; Thu, 22 Aug 2019 22:37:19 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.177]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0468.000; Thu, 22 Aug 2019 18:37:18 -0400 From: "STARK, BARBARA H" To: "'Mahesh Jethanandani'" , "'Babel at IETF'" Thread-Topic: [babel] I-D Action: draft-ietf-babel-yang-model-03.txt Thread-Index: AQHVWSQfQdMpA/qywUuoroR2yhFdkacH2oiA///nL+A= Date: Thu, 22 Aug 2019 22:37:17 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E283694@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <156650395271.14864.52756353331686153@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.194.205] 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-08-22_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908220198 Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-yang-model-03.txt 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: Thu, 22 Aug 2019 22:37:33 -0000 If information-model is good to proceed (?), should we start WGLC on the YA= NG model? I think it's ready for WGLC. Barbara > -----Original Message----- >=20 > This version of the draft closely tracks the -09 version of the informati= on > model that Barbara is about to post. In addition, it updates the Security > section of the document (thanks Barbara), and adds several examples of > Babel configuration (thanks Juliusz). >=20 > Enjoy! >=20 > > On Aug 22, 2019, at 12:59 PM, internet-drafts@ietf.org wrote: > > > > > > 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 : YANG Data Model for Babel > > Authors : Mahesh Jethanandani > > Barbara Stark > > Filename : draft-ietf-babel-yang-model-03.txt > > Pages : 37 > > Date : 2019-08-22 > > > > Abstract: > > This document defines a data model for the Babel routing protocol. > > The data model is defined using the YANG data modeling language. > > > > > > > > The IETF datatracker status page for this draft is: > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf= . > > org_doc_draft-2Dietf-2Dbabel-2Dyang-2Dmodel_&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMT > > SQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_iOjRzLegD > > 04hmeefG8&s=3DAjP_NNrsKhvvtRB3_dHazihUcbQUY8OZI5xarpRPaw8&e=3D > > > > There are also htmlized versions available at: > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_h= t > > ml_draft-2Dietf-2Dbabel-2Dyang-2Dmodel-2D03&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTS > > QicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_iOjRzLegD0 > > 4hmeefG8&s=3DXDT_z6LWxE-EOISiKS8v4pyyaXxvuo95rRzLalMfmmw&e=3D > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf= . > > org_doc_html_draft-2Dietf-2Dbabel-2Dyang-2Dmodel- > 2D03&d=3DDwICAg&c=3DLFYZ- > > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_ > > iOjRzLegD04hmeefG8&s=3DzLoc5L3C6b1_2- > 8fvxTLW0FKnPHpFYAtZGGAHuGihk4&e=3D > > > > A diff from the previous version is available at: > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_rfcd > > iff-3Furl2-3Ddraft-2Dietf-2Dbabel-2Dyang-2Dmodel- > 2D03&d=3DDwICAg&c=3DLFYZ- > > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_ > > iOjRzLegD04hmeefG8&s=3D3_Q-7qmIRU- > 303jl5JYXJpjYz4kEWbleQYGy3dEgdA0&e=3D > > > > > > 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.i= etf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_inter= n > > et-2Ddrafts_&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfo > > g&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_iOjRzLegD04hmeefG8&s=3D7NN- > GZMWj_DTjzEgK0Wl > > GQWtRWOvQWNylXvAM2mx3GQ&e=3D > > > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mail > > man_listinfo_babel&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8T > > > q4vrfog&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_iOjRzLegD04hmeefG8&s=3DrUTcW > YJnELa2k2 > > bfGoAPDjTlA-2b1ifUVN53gcNI3Ck&e=3D >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 > _______________________________________________ > babel mailing list > babel@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_babel&d=3DDwICAg&c=3DLFYZ- > o9_HUMeMTSQicvjIg&r=3DLoGzhC- > 8sc8SY8Tq4vrfog&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_iOjRzLegD04hmeefG8& > s=3DrUTcWYJnELa2k2bfGoAPDjTlA-2b1ifUVN53gcNI3Ck&e=3D From nobody Thu Aug 22 18:09:46 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 4A5B6120168 for ; Thu, 22 Aug 2019 18:09:45 -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 0ZLCHuYIaesw for ; Thu, 22 Aug 2019 18:09:43 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 11192120271 for ; Thu, 22 Aug 2019 18:09:43 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id q139so5176278pfc.13 for ; Thu, 22 Aug 2019 18:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GwybvkJiNw+3HvVh5y5adQbTrOetlRAcocg7L1HnvaM=; b=W5VX9ftszUJW9Lojl+3u4fnV7bHBTFu2W95Fj9eZoDIStYwBSMqIMJh4tPkFJPauZ9 UVFH2aV9Yn2xbH5DywwzZossLqVA2ZX8FN6gKSIxoU6P13fTll5WAPqVEHMHebkUDniE gUQPr8N9S8RZnTDQm7xk7dKlQdieI91iGFFEksHwNomv8+O8QPXRp/UNLLWT1yVUKD0x qvaFxV/mDmETYqJ7RXHW5vYearAr6ThOGEi3s8lw1CWIp5YQiT565T7dY3dM8uDyMScx YMRzCPQyaJyiOsmuXMP97L5UniV9cLWPv/77x5Zzd6GBu+swYwRvp/YEoVt9/L59mck7 Gbrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GwybvkJiNw+3HvVh5y5adQbTrOetlRAcocg7L1HnvaM=; b=hPuCVjE9RN/rGrnqdJKnqDwKiyRTEGendQKU1yai2nwzs3Z6BvXAqRRtCbiECa5ZGo dF+5wlApjSZn3cnaex/hEJonoI6QrpAcbxP67SeD8dnoWLGyy1rzwxr7aeA1UDU8ZiBJ Guhcro5TTsBAqq9Lp7R4m9jwDjKZg4sV36Hd1O9+s8nlt1V0wK1xawnqN82l6OOGZl4i VCJJ6UhqlRvVNGUEBItfnrtIdsqwOJDf01+9tHCTxxn3b4A2FCqDAMeFadN2DMooi8ps 7tHTGYY35QMcepAK/ywI+cJr+sBY6pa86P4voOLBrJzx+KIflEDlFjm39no9NuynTKB0 mVsA== X-Gm-Message-State: APjAAAVduOd6zRghsVhdOAlMh1k2KMl873+kyqjalpbq/55jKAFgiSo6 ucjEpq8mBH+7Ybjg3zAlNT0= X-Google-Smtp-Source: APXvYqwkpbCphq4jJsWOGattjMjkyk7dvdWOsG/UaRMMHyPFOaH8aj18ODc0+XfjsJKxzWIt2WGFBQ== X-Received: by 2002:a05:6a00:46:: with SMTP id i6mr2288110pfk.196.1566522582439; Thu, 22 Aug 2019 18:09:42 -0700 (PDT) Received: from [10.33.122.240] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id l123sm687978pfl.9.2019.08.22.18.09.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Aug 2019 18:09:41 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <8458C4D1-CB17-42B0-BAC6-E960C4EB15AB@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_184D6A54-856F-43A9-B6D8-E9389F501181" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 22 Aug 2019 18:09:40 -0700 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E283694@GAALPA1MSGUSRBF.ITServices.sbc.com> Cc: Babel at IETF To: "STARK, BARBARA H" References: <156650395271.14864.52756353331686153@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114E283694@GAALPA1MSGUSRBF.ITServices.sbc.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-yang-model-03.txt 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, 23 Aug 2019 01:09:45 -0000 --Apple-Mail=_184D6A54-856F-43A9-B6D8-E9389F501181 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Barbara, The reason I have not asked for WGLC for the Babel YANG model is because = it lacks a routing policy module.=20 Let me follow up on that on a separate thread. Cheers. > On Aug 22, 2019, at 3:37 PM, STARK, BARBARA H wrote: >=20 > If information-model is good to proceed (?), should we start WGLC on = the YANG model? I think it's ready for WGLC. > Barbara >=20 >> -----Original Message----- >>=20 >> This version of the draft closely tracks the -09 version of the = information >> model that Barbara is about to post. In addition, it updates the = Security >> section of the document (thanks Barbara), and adds several examples = of >> Babel configuration (thanks Juliusz). >>=20 >> Enjoy! >>=20 >>> On Aug 22, 2019, at 12:59 PM, internet-drafts@ietf.org wrote: >>>=20 >>>=20 >>> 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. >>>=20 >>> Title : YANG Data Model for Babel >>> Authors : Mahesh Jethanandani >>> Barbara Stark >>> Filename : draft-ietf-babel-yang-model-03.txt >>> Pages : 37 >>> Date : 2019-08-22 >>>=20 >>> Abstract: >>> This document defines a data model for the Babel routing protocol. >>> The data model is defined using the YANG data modeling language. >>>=20 >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf = .= >>> org_doc_draft-2Dietf-2Dbabel-2Dyang-2Dmodel_&d=3DDwICAg&c=3DLFYZ- >> o9_HUMeMT >>> SQicvjIg&r=3DLoGzhC- >> 8sc8SY8Tq4vrfog&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_iOjRzLegD >>> 04hmeefG8&s=3DAjP_NNrsKhvvtRB3_dHazihUcbQUY8OZI5xarpRPaw8&e=3D >>>=20 >>> There are also htmlized versions available at: >>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_ht = = >>> ml_draft-2Dietf-2Dbabel-2Dyang-2Dmodel-2D03&d=3DDwICAg&c=3DLFYZ- >> o9_HUMeMTS >>> QicvjIg&r=3DLoGzhC- >> 8sc8SY8Tq4vrfog&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_iOjRzLegD0 >>> 4hmeefG8&s=3DXDT_z6LWxE-EOISiKS8v4pyyaXxvuo95rRzLalMfmmw&e=3D >>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf = .= >>> org_doc_html_draft-2Dietf-2Dbabel-2Dyang-2Dmodel- >> 2D03&d=3DDwICAg&c=3DLFYZ- >>> o9_HUMeMTSQicvjIg&r=3DLoGzhC- >> 8sc8SY8Tq4vrfog&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_ >>> iOjRzLegD04hmeefG8&s=3DzLoc5L3C6b1_2- >> 8fvxTLW0FKnPHpFYAtZGGAHuGihk4&e=3D >>>=20 >>> A diff from the previous version is available at: >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- = >> 3A__www.ietf.org_rfcd >>> iff-3Furl2-3Ddraft-2Dietf-2Dbabel-2Dyang-2Dmodel- >> 2D03&d=3DDwICAg&c=3DLFYZ- >>> o9_HUMeMTSQicvjIg&r=3DLoGzhC- >> 8sc8SY8Tq4vrfog&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_ >>> iOjRzLegD04hmeefG8&s=3D3_Q-7qmIRU- >> 303jl5JYXJpjYz4kEWbleQYGy3dEgdA0&e=3D >>>=20 >>>=20 >>> 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 . >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> = https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_intern = = >>> et-2Ddrafts_&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC- >> 8sc8SY8Tq4vrfo >>> g&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_iOjRzLegD04hmeefG8&s=3D7NN- >> GZMWj_DTjzEgK0Wl >>> GQWtRWOvQWNylXvAM2mx3GQ&e=3D >>>=20 >>> _______________________________________________ >>> babel mailing list >>> babel@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- = >> 3A__www.ietf.org_mail >>> man_listinfo_babel&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC- >> 8sc8SY8T >>>=20 >> q4vrfog&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_iOjRzLegD04hmeefG8&s=3DrUTcW >> YJnELa2k2 >>> bfGoAPDjTlA-2b1ifUVN53gcNI3Ck&e=3D >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >>=20 >>=20 >> _______________________________________________ >> babel mailing list >> babel@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- = >> 3A__www.ietf.org_mailman_listinfo_babel&d=3DDwICAg&c=3DLFYZ- >> o9_HUMeMTSQicvjIg&r=3DLoGzhC- >> 8sc8SY8Tq4vrfog&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_iOjRzLegD04hmeefG8& >> s=3DrUTcWYJnELa2k2bfGoAPDjTlA-2b1ifUVN53gcNI3Ck&e=3D Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_184D6A54-856F-43A9-B6D8-E9389F501181 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Barbara,

The reason = I have not asked for WGLC for the Babel YANG model is because it lacks a = routing policy module. 

Let me follow up on that on a separate = thread.

Cheers.

On Aug 22, 2019, at 3:37 PM, = STARK, BARBARA H <bs7652@att.com> wrote:

If information-model is good to = proceed (?), should we start WGLC on the YANG model? I think it's ready = for WGLC.
Barbara

-----Original Message-----

This version of the draft closely tracks the = -09 version of the information
model that Barbara is about = to post. In addition, it updates the Security
section of = the document (thanks Barbara), and adds several examples of
Babel configuration (thanks Juliusz).

Enjoy!

On Aug 22, 2019, at 12:59 PM, internet-drafts@ietf.org wrote:


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 =           : YANG Data = Model for Babel
      Authors =         : Mahesh Jethanandani
          &nb= sp;            = ; Barbara Stark
Filename =        : = draft-ietf-babel-yang-model-03.txt
Pages =           : 37
= Date =            : = 2019-08-22

Abstract:
 This= document defines a data model for the Babel routing protocol.
 The data model is defined using the YANG data modeling = language.



The = IETF datatracker status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatrac= ker.ietf.
org_doc_draft-2Dietf-2Dbabel-2Dyang-2Dmodel_&d=3DDwICAg&= ;c=3DLFYZ-
o9_HUMeMT
SQicvjIg&r=3DLoGzhC-
8sc8SY8Tq4vrfog&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_i= OjRzLegD
04hmeefG8&s=3DAjP_NNrsKhvvtRB3_dHazihUcbQUY8OZI5xarpRPaw8&a= mp;e=3D

There are also htmlized versions = available at:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ie= tf.org_ht
ml_draft-2Dietf-2Dbabel-2Dyang-2Dmodel-2D03&d=3DDwICAg&= c=3DLFYZ-
o9_HUMeMTS
QicvjIg&r=3DLoGzhC-
8sc8SY8Tq4vrfog&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_i= OjRzLegD0
4hmeefG8&s=3DXDT_z6LWxE-EOISiKS8v4pyyaXxvuo95rRzLalMfmmw&am= p;e=3D
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatrac= ker.ietf.
org_doc_html_draft-2Dietf-2Dbabel-2Dyang-2Dmodel-
2D03&d=3DDwICAg&c=3DLFYZ-
o9_HUMeMTSQicvjIg&r=3DLoGzhC-
8sc8SY8Tq4vrfog&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_<= br class=3D"">
iOjRzLegD04hmeefG8&s=3DzLoc5L3C6b1_2-
8fvxTLW0FKnPHpFYAtZGGAHuGihk4&e=3D

A diff = from the previous version is available at:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
3A__www.ietf.org_rfcd
iff-3Furl2-3Ddraft-2Dietf-2Dbabel-2Dyang-2Dmodel-
2D03&d=3DDwICAg&c=3DLFYZ-
o9_HUMeMTSQicvjIg&r=3DLoGzhC-
8sc8SY8Tq4vrfog&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_<= br class=3D"">
iOjRzLegD04hmeefG8&s=3D3_Q-7qmIRU-
303jl5JYXJpjYz4kEWbleQYGy3dEgdA0&e=3D


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:
https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.o= rg_intern
et-2Ddrafts_&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&= r=3DLoGzhC-
8sc8SY8Tq4vrfo
g&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_iOjRzLegD04hmeefG8&s=3D7= NN-
GZMWj_DTjzEgK0Wl
GQWtRWOvQWNylXvAM2mx3GQ&e=3D

_______________________________________________
babel mailing list
babel@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
3A__www.ietf.org_mail
man_listinfo_babel&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjI= g&r=3DLoGzhC-
8sc8SY8T

q4vrfog&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_iOjRzLegD= 04hmeefG8&s=3DrUTcW
YJnELa2k2
bfGoAPDjTlA-2b1ifUVN53gcNI3Ck&e=3D

Mahesh Jethanandani
mjethanandani@gmail.com



_______________________________________________
babel mailing list
babel@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
3A__www.ietf.org_mailman_listinfo_babel&d=3DDwICAg&c=3D= LFYZ-
o9_HUMeMTSQicvjIg&r=3DLoGzhC-
8sc8SY8Tq4vrfog&m=3DCSM4tDMAcQ5mo5ig0a4vXrbx_iOjRzLegD04hme= efG8&
s=3DrUTcWYJnELa2k2bfGoAPDjTlA-2b1ifUVN53gcNI3Ck&e=3D

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_184D6A54-856F-43A9-B6D8-E9389F501181-- From nobody Thu Aug 22 19:05:49 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 ED998120170 for ; Thu, 22 Aug 2019 19:05:47 -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 rs0PryvdgDlr for ; Thu, 22 Aug 2019 19:05:45 -0700 (PDT) Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (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 3BFF912011B for ; Thu, 22 Aug 2019 19:05:45 -0700 (PDT) Received: by mail-pf1-x441.google.com with SMTP id f17so5300201pfn.6 for ; Thu, 22 Aug 2019 19:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bBcZYee0OKjO2Ney8fS5qqBYl/Rt75BXZEAcgdWN9JA=; b=tm4rhnH6pJ6ay271waFOxllCrZVE/BiaKrYbGo1Df9buU9GHAgT07sn4/sxO/nsbWV mF8wOS1qg8Ysd/LmvB9++tR/IWyqEEXHiH5Rq/6CFcr5jLRWydVikt6jNOInJ6jTn5/t pcNL7AnTSnwYIY6UYRcjLAkJwrCuib9ZSSNN0VNFMersq4cipHW5mu5dqLwq0MrDP5rT zSChnLVB14pk40CMJVvs+bE3BThBHeSXaaJJGSyCZ8NG56yLhTRx3ZRN93m8ox9tYaFn wmm7nJkdOMpf78Xk1JZOv0iLCQmp5cwzazaHWdPfHp1oqjS7+bxMhk02HXqr4Lpeizd2 m+Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=bBcZYee0OKjO2Ney8fS5qqBYl/Rt75BXZEAcgdWN9JA=; b=DKDYpYHGPY4HKeL2K5mi5uvV1KxDiH31QXLiLPF/x19FGrRAa69zfqo95v3CixVXvI d2IMhkpVQ3Gf+C7LsgCLRKbdmB5lYNKT2INxyxZOvFR9fx44GP3V0tbmezXTOK2asd++ 9QwaoyStjnml9ffHIZPPn1izZyqKlRki8QnnJfwzMApTFLdSS5KdmSWrBie3HhDBZtLt CZl0UES0qOOp7YNfCeEaCAyuzs92pozqm5tPY4IKps8KXPIbPrw/1vc5OkskioXSJq32 1vNtOcMrxsxobFZVLp2yMMD6u+hUZxv7MsLNJjrXOYLzsMJaCKP+7KV7n/b8+GpDMxeY qXJg== X-Gm-Message-State: APjAAAU7rnVhO4NsWi0Btl+sv0TqC7z3jUK8WlWXwIavGrx4Johj1tfj l8r6i92CrsE0//UeR1fK8+A= X-Google-Smtp-Source: APXvYqyXsAHxThsd1EnEL/3UrkNqZKWg1l2lwewxNUKrK7SSjukoLfYJUe/2FpLk8g7Er92BmC4fPw== X-Received: by 2002:a65:684a:: with SMTP id q10mr1832374pgt.417.1566525944517; Thu, 22 Aug 2019 19:05:44 -0700 (PDT) Received: from [10.33.122.240] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id i124sm752201pfe.61.2019.08.22.19.05.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Aug 2019 19:05:43 -0700 (PDT) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A77D74D0-189F-49AB-B921-D1FBC5B3E248" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 22 Aug 2019 19:05:42 -0700 In-Reply-To: <87lfwn5d3d.wl-jch@irif.fr> Cc: babel@ietf.org, Barbara Stark To: Juliusz Chroboczek References: <87lfwn5d3d.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Babel filtering: routing policies 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, 23 Aug 2019 02:05:48 -0000 --Apple-Mail=_A77D74D0-189F-49AB-B921-D1FBC5B3E248 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Juliusz, Following up on this e-mail to understand how to implement the routing = policies for Babel. > On Jul 24, 2019, at 2:36 PM, Juliusz Chroboczek wrote: >=20 > Dear Barbara, dear Mahesh, >=20 > All distance-vector routing protocols, including BGP and Babel, > intrinsically support flexible routing policies. In the Babel = community, > we consider the way of defining such policies as an implementation > feature, and they are not part of the protocol definition. >=20 > The following therefore applies to babeld, the "reference" = implementation. >=20 > In babeld, we speak about filter chains. A route goes through each = filter > in a filter chain at four points in Babel: >=20 > "in" chain, when the route is learnt from a neighbour; > "install" chain, when the route is installed in the kernel; > "redistribute" chain, when the route is learnt from the kernel; > "out" chain, when the route is announced to a neighbour. In order to make sure we are talking the same language, would you say a = given chain is equivalent of a =E2=80=9Cdefined set=E2=80=9D as defined = by draft-ietf-rtgwg-policy-model = ? I = understand that these are babel specific, so I will extend the policy = model to add these chains as =E2=80=9Cdefined sets". I am also assuming = that there is one instance of each chain (or defined set). In other = words, we are not looking at multiple =E2=80=9Cin=E2=80=9D chains, as an = example. >=20 > When a filter chain is applied, the individual filters in a chain are > checked, and the first filter that applies to the route is executed. > A filter can perfrom the following actions: >=20 > "allow" -- pass the route unchanged, equivalent to "metric 0"; > "deny" -- drop the route; > "metric nnn" -- add nnn to the metric value. >=20 > There exist other actions, more specialised -- see the manual page for > details. I see two more, src-prefix and table. Is there more? >=20 > Babeld implements a rich language for matching routes -- it can match = on > next-hop address, on destination prefix, on destination prefix length, = on > the router-id of the originating router, etc. Again, see the manual = page > for details. I am looking at the following conditions (in the routing policy model = language) specified in the man page. ip prefix This entry only applies to routes in the given prefix. eq plen This entry only applies to routes with a prefix length = equal to plen. le plen This entry only applies to routes with a prefix length = less or equal to plen. ge plen This entry only applies to routes with a prefix length = greater or equal to plen. src-ip prefix This entry only applies to routes with a source prefix in = the given prefix. src-eq plen This entry only applies to routes with a source prefix = length equal to plen. src-le plen This entry only applies to routes with a source = prefix length less or equal to plen. src-ge plen This entry only applies to routes with a source prefix = length greater or equal to plen. neigh address This entry only applies to routes learned from a = neighbour with link-local address address. id id This entry only applies to routes originated by a router = with router-id id. proto p This entry only applies to kernel routes with kernel = protocol number p. If neither proto nor local is specified, this entry applies to = all non-local kernel routes with a protocol different from "boot". local This entry only applies to local addresses. if interface For an input filter, this specifies the interface over = which the route is learned. For an output filter, this specifies the interface = over which this route is advertised. For a redistribute statement, this specifies = the interface over which the route forwards packets. Note, the policy module defines a default set of conditions like prefix = sets, so some of your examples should be take care of with them. Anything else that I am missing? >=20 > Examples > =3D=3D=3D=3D=3D=3D=3D=3D >=20 > ## Default filters >=20 > in allow >=20 > out allow >=20 > redistribute local allow > redistribute deny >=20 > install allow >=20 > These are the default chains if no filters are defined, and are = suitable > for a mesh node with no attached prefixes. They say that babeld is > promiscuous (it learns all routes and announces all routes), it only > redistributes local node addresses, and installs any routes that it = learns > unchanged. >=20 > ## Traditional router >=20 > redistribute proto 2 allow > redistribute deny >=20 > This overrides the default to not redistribute any local addresses, = but to > redistribute any locally attached prefixes. This is the default = behaviour > or a traditional router. >=20 > ## Traditional router with redistribution >=20 > redistribute proto 2 allow > redistribute proto 11 metric 32384 > redistribute deny >=20 > This says to additionally redistribute any routes learned from > Zebra/Quagga/FRR, but to attach them with a higher metric -- Babel = routes > will thus be preferred to FRR routes. >=20 > ## Stub router >=20 > redistribute proto 2 allow > redistribute deny >=20 > out ip 192.168.42.0/24 allow > out ip 2001:db8:4242::/48 allow > out deny >=20 > This says to learn routes promiscuously, but to only reannounce routes = in > the given prefixes. This is typical of a stub router, that only = announces > routes in the local prefixes. >=20 > ## Default router >=20 > out ip 0.0.0.0/0 le 0 allow > out ip ::/0 le 0 allow > out deny >=20 > This router only announces default routes. >=20 > ## IPv6 border router >=20 > in ip ::/0 allow > in deny >=20 > out if eth0 ip 2001:db8:4242::/48 le 48 allow > out if eth0 deny >=20 > out if eth1 ip 2001:db8:5757::/48 le 48 allow > out if eth1 deny >=20 > This router sits at the interface between two networks, and only = announces > a route summarising a whole network to the other network. This = reduces > the amount of traffic, at the cost of non-optimal routing. >=20 > ## Ignoring bad routers >=20 > in if eth0 nh fe80::1 deny > in router-id 12:34:56:78:9a:bc deny > in allow >=20 > This router ignores routes from a given next hop as well as routes > originated by a given router-id. This can be used to temporarily > blackhole a mis-configured router, before it is fixed. >=20 > -- Juliusz >=20 >=20 >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_A77D74D0-189F-49AB-B921-D1FBC5B3E248 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Juliusz,

Following = up on this e-mail to understand how to implement the routing policies = for Babel.

On Jul 24, 2019, at 2:36 PM, Juliusz = Chroboczek <jch@irif.fr> wrote:

Dear = Barbara, dear Mahesh,

All distance-vector = routing protocols, including BGP and Babel,
intrinsically = support flexible routing policies.  In the Babel community,
we consider the way of defining such policies as an = implementation
feature, and they are not part of the = protocol definition.

The following = therefore applies to babeld, the "reference" implementation.

In babeld, we speak about filter chains. =  A route goes through each filter
in a filter chain = at four points in Babel:

 "in" chain, = when the route is learnt from a neighbour;
=  "install" chain, when the route is installed in the kernel;
 "redistribute" chain, when the route is learnt from = the kernel;
 "out" chain, when the route is = announced to a neighbour.

In order to make sure we are talking the same language, = would you say a given chain is equivalent of a =E2=80=9Cdefined set=E2=80=9D= as defined by draft-ietf-rtgwg-policy-model? I understand that these = are babel specific, so I will extend the policy model to add these = chains as =E2=80=9Cdefined sets". I am also assuming that there is one = instance of each chain (or defined set). In other words, we are not = looking at multiple =E2=80=9Cin=E2=80=9D chains, as an = example.


When a filter = chain is applied, the individual filters in a chain are
checked, and the first filter that applies to the route is = executed.
A filter can perfrom the following actions:

 "allow" -- pass the route unchanged, = equivalent to "metric 0";
 "deny" -- drop the = route;
 "metric nnn" -- add nnn to the metric = value.

There exist other actions, more = specialised -- see the manual page for
details.

I see two = more, src-prefix and table. Is there more?


Babeld implements a rich language for matching = routes -- it can match on
next-hop address, on destination = prefix, on destination prefix length, on
the router-id of = the originating router, etc.  Again, see the manual page
for details.

I am looking at the following conditions (in the = routing policy model language) specified in the man page.

       ip prefix
              This entry only applies to routes in the given prefix.

       eq plen
              This entry only applies to routes with a prefix length =
equal to plen.

       le plen
              This entry only applies to routes with a prefix length =
less or equal to plen.

       ge plen
              This entry only applies to routes with a prefix length =
greater or equal to plen.=


       src-ip prefix
              This entry only applies to routes with a source prefix in =
the given prefix.

       src-eq plen
              This entry only applies to routes with a source prefix =
length equal to plen.

       src-le plen
              This  entry  only  applies  to  routes with a source =
prefix length less or equal to
              plen.

       src-ge plen
              This entry only applies to routes with a source prefix =
length greater or  equal  to
              plen.

       neigh address
              This  entry only applies to routes learned from a =
neighbour with link-local address
              address.

       id id  This entry only =
applies to routes originated by a router with router-id id.

       proto p
              This entry only applies to kernel routes with kernel =
protocol number p.  If =
neither
              proto  =
nor  local  is  =
specified, this entry applies to all non-local kernel routes
              with a protocol different from "boot".

       local  This =
entry only applies to local addresses.

       if interface
              For an input filter, this specifies the interface over =
which the route is  learned.
              For  an  output  filter,  this  specifies  the  interface  =
over which this route is
              advertised.  For a redistribute statement, this specifies =
the interface over  which
              the route forwards packets.
Note, the = policy module defines a default set of conditions like prefix sets, so = some of your examples should be take care of with them.

Anything else that I am = missing?


Examples
=3D=3D=3D=3D=3D=3D=3D=3D

## = Default filters

   in = allow

   out allow

   redistribute local allow
   redistribute deny

   install allow

These are the default chains if no filters are defined, and = are suitable
for a mesh node with no attached prefixes. =  They say that babeld is
promiscuous (it learns all = routes and announces all routes), it only
redistributes = local node addresses, and installs any routes that it learns
unchanged.

## Traditional = router

 redistribute proto 2 allow
 redistribute deny

This = overrides the default to not redistribute any local addresses, but to
redistribute any locally attached prefixes.  This is the = default behaviour
or a traditional router.
## Traditional router with redistribution

 redistribute proto 2 allow
=  redistribute proto 11 metric 32384
=  redistribute deny

This says to = additionally redistribute any routes learned from
Zebra/Quagga/FRR, but to attach them with a higher metric -- = Babel routes
will thus be preferred to FRR routes.

## Stub router

=  redistribute proto 2 allow
 redistribute = deny

 out ip 192.168.42.0/24 allow
 out ip 2001:db8:4242::/48 allow
=  out deny

This says to learn routes = promiscuously, but to only reannounce routes in
the given = prefixes.  This is typical of a stub router, that only announces
routes in the local prefixes.

## = Default router

 out ip 0.0.0.0/0 le 0 = allow
 out ip ::/0 le 0 allow
=  out deny

This router only announces = default routes.

## IPv6 border router

 in ip ::/0 allow
=  in deny

 out if eth0 ip = 2001:db8:4242::/48 le 48 allow
 out if eth0 deny

 out if eth1 ip 2001:db8:5757::/48 le 48 = allow
 out if eth1 deny

This router sits at the interface between two networks, and = only announces
a route summarising a whole network to the = other network.  This reduces
the amount of traffic, = at the cost of non-optimal routing.

## = Ignoring bad routers

 in if eth0 nh = fe80::1 deny
 in router-id 12:34:56:78:9a:bc deny
 in allow

This router = ignores routes from a given next hop as well as routes
originated by a given router-id.  This can be used to = temporarily
blackhole a mis-configured router, before it = is fixed.

-- Juliusz





Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_A77D74D0-189F-49AB-B921-D1FBC5B3E248-- From nobody Fri Aug 23 15: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 D3F2712002E for ; Fri, 23 Aug 2019 15:27:11 -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 RlaHJNzTtZfh for ; Fri, 23 Aug 2019 15:27:09 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758F612000F for ; Fri, 23 Aug 2019 15:27:09 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7NMR1KQ020709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 24 Aug 2019 00:27: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 x7NMR0br002811; Sat, 24 Aug 2019 00:27:01 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 6412044E27; Sat, 24 Aug 2019 00:27:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id SxHhC7_A731q; Sat, 24 Aug 2019 00:27:02 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 38BA744E25; Sat, 24 Aug 2019 00:27:02 +0200 (CEST) Date: Sat, 24 Aug 2019 00:27:01 +0200 Message-ID: <874l277c22.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mahesh Jethanandani Cc: babel@ietf.org, Barbara Stark In-Reply-To: References: <87lfwn5d3d.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 24 Aug 2019 00:27:01 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 24 Aug 2019 00:27:01 +0200 (CEST) X-Miltered: at korolev with ID 5D606835.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D606834.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D606835.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D606834.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 : 5D606835.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D606834.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 filtering: routing policies 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, 23 Aug 2019 22:27:12 -0000 > In order to make sure we are talking the same language, would you say a given > chain is equivalent of a “defined set” as defined by > draft-ietf-rtgwg-policy-model? No. A chain would correspond to a sequence of policy statements, if I read this document right. > I understand that these are babel specific, I think that only matching on router-id is Babel-specific, all the others are fairly generic. > will extend the policy model to add these chains as “defined sets". I don't think you need to extend anything. Matching on router-id is not essential. On the other hand, it looks to me like it's more expressive than anything that any implementation of Babel known to me has ever implemented. Since I'm still not sure what's the purpose of the YANG model, I don't know if that's a problem or not. > There exist other actions, more specialised -- see the manual page for > details. > I see two more, src-prefix and table. Is there more? Not in babeld. I haven't checked BIRD. -- Juliusz From nobody Fri Aug 23 15:29:17 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 0D83F12000F for ; Fri, 23 Aug 2019 15:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9gVC2Sps9UTr for ; Fri, 23 Aug 2019 15:29:14 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F4CA12002E for ; Fri, 23 Aug 2019 15:29:13 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7NMT5Rw020873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 24 Aug 2019 00:29:05 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x7NMT5UH002934; Sat, 24 Aug 2019 00:29:05 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 1BB9C44E2E; Sat, 24 Aug 2019 00:29:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id toFTPPqb8fGq; Sat, 24 Aug 2019 00:29:07 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 4238544E2C; Sat, 24 Aug 2019 00:29:07 +0200 (CEST) Date: Sat, 24 Aug 2019 00:29:06 +0200 Message-ID: <8736hr7byl.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'Mahesh Jethanandani'" , "'Babel at IETF'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E283694@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <156650395271.14864.52756353331686153@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114E283694@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 24 Aug 2019 00:29:05 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 24 Aug 2019 00:29:05 +0200 (CEST) X-Miltered: at korolev with ID 5D6068B1.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D6068B1.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D6068B1.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D6068B1.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 : 5D6068B1.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D6068B1.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] I-D Action: draft-ietf-babel-yang-model-03.txt 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, 23 Aug 2019 22:29:15 -0000 > If information-model is good to proceed (?), should we start WGLC on the > YANG model? I think it's ready for WGLC. Has anyone reviewed it? -- Juliusz From nobody Fri Aug 23 18:22:58 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 12341120043 for ; Fri, 23 Aug 2019 18:22:57 -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 t-faSDXKGfrm for ; Fri, 23 Aug 2019 18:22:55 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC3812002E for ; Fri, 23 Aug 2019 18:22:55 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7O1EbWf018147; Fri, 23 Aug 2019 21:22:54 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2ujsw8sr35-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Aug 2019 21:22:54 -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 x7O1Mqk6015355; Fri, 23 Aug 2019 21:22:52 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7O1Mi3q015133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 23 Aug 2019 21:22:44 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id ABB034009E8F; Sat, 24 Aug 2019 01:22:44 +0000 (GMT) Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (unknown [130.8.218.153]) by zlp30488.vci.att.com (Service) with ESMTPS id 96E064009E80; Sat, 24 Aug 2019 01:22:44 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.177]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0468.000; Fri, 23 Aug 2019 21:22:43 -0400 From: "STARK, BARBARA H" To: Juliusz Chroboczek CC: Mahesh Jethanandani , Babel at IETF Thread-Topic: [babel] I-D Action: draft-ietf-babel-yang-model-03.txt Thread-Index: AQHVWSQfQdMpA/qywUuoroR2yhFdkacH2oiA///nL+CAAdNnAP//7XUd Date: Sat, 24 Aug 2019 01:22:43 +0000 Message-ID: <0FE9D6D0-1F00-4715-82C7-491973EE3FB6@att.com> References: <156650395271.14864.52756353331686153@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114E283694@GAALPA1MSGUSRBF.ITServices.sbc.com>, <8736hr7byl.wl-jch@irif.fr> In-Reply-To: <8736hr7byl.wl-jch@irif.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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-08-24_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=433 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908240011 Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-yang-model-03.txt 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, 24 Aug 2019 01:22:57 -0000 I did. In gory detail.=20 WGLC would be to ask others to review.=20 Barbara=20 On Aug 23, 2019, at 6:29 PM, Juliusz Chroboczek wrote: >> If information-model is good to proceed (?), should we start WGLC on the >> YANG model? I think it's ready for WGLC. >=20 > Has anyone reviewed it? >=20 > -- Juliusz >=20 From nobody Fri Aug 23 19:53:28 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 47DAF1200B8 for ; Fri, 23 Aug 2019 19:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 fNX6Ezf_mUTz for ; Fri, 23 Aug 2019 19:53:26 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE50B120047 for ; Fri, 23 Aug 2019 19:53:25 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7O2ivtH029485; Fri, 23 Aug 2019 22:53:22 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2uju4p9rxj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Aug 2019 22:53:21 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7O2rKa8017767; Fri, 23 Aug 2019 22:53:20 -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 x7O2rDX8017693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 23 Aug 2019 22:53:13 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 2187E4005C30; Sat, 24 Aug 2019 02:53:13 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30484.vci.att.com (Service) with ESMTPS id 0E4F0400037A; Sat, 24 Aug 2019 02:53:13 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.177]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0468.000; Fri, 23 Aug 2019 22:53:12 -0400 From: "STARK, BARBARA H" To: "'Juliusz Chroboczek'" , "'Mahesh Jethanandani'" CC: "'babel@ietf.org'" Thread-Topic: Babel filtering: routing policies Thread-Index: AQHVQmgDyo9Vkb0NwkaC+50PaFzuzqcIbMYAgAFVPICAAARxEA== Date: Sat, 24 Aug 2019 02:53:11 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114E2877EB@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <87lfwn5d3d.wl-jch@irif.fr> <874l277c22.wl-jch@irif.fr> In-Reply-To: <874l277c22.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.245.205] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-24_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=752 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908240029 Archived-At: Subject: Re: [babel] Babel filtering: routing policies 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, 24 Aug 2019 02:53:27 -0000 SW4gbG9va2luZyBhdCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGd3 Zy1wb2xpY3ktbW9kZWwtMDYsIEknbSBsZWZ0IHdvbmRlcmluZyBpZiBhbnkgb2YgdGhpcyBpcyB1 c2VmdWwgd3J0IEJhYmVsLiBJIGNhbid0IHNlZSBhbnlvbmUgaW1wbGVtZW50aW5nIHRoZSBob29r cyB0byBtYWtlIHN1Y2ggcG9saWN5IGNvbmZpZ3VyYWJsZSBpbiBCYWJlbCAoYmVjYXVzZSBpdCBk b2Vzbid0IHNlZW0gdG8gYmUgbmVlZGVkKS4gSWYgc29tZW9uZSByZWFsbHkgd2FudHMgc29tZXRo aW5nIGxpa2UgdGhpcyBpbiB0aGUgZnV0dXJlLCBtYXliZSB0aGV5IGNhbiBkbyBpdCB0aGVuPw0K QmFyYmFyYQ0KDQo+ID4gSW4gb3JkZXIgdG8gbWFrZSBzdXJlIHdlIGFyZSB0YWxraW5nIHRoZSBz YW1lIGxhbmd1YWdlLCB3b3VsZCB5b3Ugc2F5DQo+ID4gYSBnaXZlbiBjaGFpbiBpcyBlcXVpdmFs ZW50IG9mIGEg4oCcZGVmaW5lZCBzZXTigJ0gYXMgZGVmaW5lZCBieQ0KPiA+IGRyYWZ0LWlldGYt cnRnd2ctcG9saWN5LW1vZGVsPw0KPiANCj4gTm8uICBBIGNoYWluIHdvdWxkIGNvcnJlc3BvbmQg dG8gYSBzZXF1ZW5jZSBvZiBwb2xpY3kgc3RhdGVtZW50cywgaWYgSSByZWFkDQo+IHRoaXMgZG9j dW1lbnQgcmlnaHQuDQo+IA0KPiA+IEkgdW5kZXJzdGFuZCB0aGF0IHRoZXNlIGFyZSBiYWJlbCBz cGVjaWZpYywNCj4gDQo+IEkgdGhpbmsgdGhhdCBvbmx5IG1hdGNoaW5nIG9uIHJvdXRlci1pZCBp cyBCYWJlbC1zcGVjaWZpYywgYWxsIHRoZSBvdGhlcnMgYXJlDQo+IGZhaXJseSBnZW5lcmljLg0K PiANCj4gPiB3aWxsIGV4dGVuZCB0aGUgcG9saWN5IG1vZGVsIHRvIGFkZCB0aGVzZSBjaGFpbnMg YXMg4oCcZGVmaW5lZCBzZXRzIi4NCj4gDQo+IEkgZG9uJ3QgdGhpbmsgeW91IG5lZWQgdG8gZXh0 ZW5kIGFueXRoaW5nLiAgTWF0Y2hpbmcgb24gcm91dGVyLWlkIGlzIG5vdA0KPiBlc3NlbnRpYWwu DQo+IA0KPiBPbiB0aGUgb3RoZXIgaGFuZCwgaXQgbG9va3MgdG8gbWUgbGlrZSBpdCdzIG1vcmUg ZXhwcmVzc2l2ZSB0aGFuIGFueXRoaW5nIHRoYXQNCj4gYW55IGltcGxlbWVudGF0aW9uIG9mIEJh YmVsIGtub3duIHRvIG1lIGhhcyBldmVyIGltcGxlbWVudGVkLiAgU2luY2UgSSdtDQo+IHN0aWxs IG5vdCBzdXJlIHdoYXQncyB0aGUgcHVycG9zZSBvZiB0aGUgWUFORyBtb2RlbCwgSSBkb24ndCBr bm93IGlmIHRoYXQncyBhDQo+IHByb2JsZW0gb3Igbm90Lg0KPiANCj4gPiAgICAgVGhlcmUgZXhp c3Qgb3RoZXIgYWN0aW9ucywgbW9yZSBzcGVjaWFsaXNlZCAtLSBzZWUgdGhlIG1hbnVhbCBwYWdl IGZvcg0KPiA+ICAgICBkZXRhaWxzLg0KPiANCj4gPiBJIHNlZSB0d28gbW9yZSwgc3JjLXByZWZp eCBhbmQgdGFibGUuIElzIHRoZXJlIG1vcmU/DQo+IA0KPiBOb3QgaW4gYmFiZWxkLiAgSSBoYXZl bid0IGNoZWNrZWQgQklSRC4NCj4gDQo+IC0tIEp1bGl1c3oNCg== From nobody Sat Aug 24 02:53:32 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 100841200B3 for ; Sat, 24 Aug 2019 02:53:30 -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 vCOQy45KxnMd for ; Sat, 24 Aug 2019 02:53:27 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FBF112003F for ; Sat, 24 Aug 2019 02:53:27 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x7O9rIMe006520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 24 Aug 2019 11:53:18 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x7O9rIxO002413; Sat, 24 Aug 2019 11:53:18 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 1DC9D46326; Sat, 24 Aug 2019 11:53:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 70vJHuiie5M0; Sat, 24 Aug 2019 11:53:20 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D85E546323; Sat, 24 Aug 2019 11:53:17 +0200 (CEST) Date: Sat, 24 Aug 2019 11:53:16 +0200 Message-ID: <87lfviga9f.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'Mahesh Jethanandani'" , "'babel@ietf.org'" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E2877EB@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <87lfwn5d3d.wl-jch@irif.fr> <874l277c22.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E2877EB@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 24 Aug 2019 11:53:19 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 24 Aug 2019 11:53:18 +0200 (CEST) X-Miltered: at korolev with ID 5D61090E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5D61090E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D61090E.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5D61090E.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 : 5D61090E.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5D61090E.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 filtering: routing policies 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, 24 Aug 2019 09:53:30 -0000 > In looking at https://tools.ietf.org/html/draft-ietf-rtgwg-policy-model-06, > I'm left wondering if any of this is useful wrt Babel. I can't see > anyone implementing the hooks to make such policy configurable in Babel > (because it doesn't seem to be needed). Babeld implements quite a bit of this already, see the section "filtering rules" in the babeld documentation. BIRD uses an even richer language, see https://bird.network.cz/?get_doc&v=20&f=bird-5.html There's a human-readable description here: https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-14#appendix-C (Which it's not too late to proof-read, by the way.) The question, of course, is whether we want to model that in a unusual object model encoded over XML, or whether it can remain an implementation detail. I'm not going to bore you with my opinion (since you already know my take on unusual object models encoded in XML). -- Juliusz From nobody Sat Aug 24 02:54: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 89D1F1200B3 for ; Sat, 24 Aug 2019 02:54:38 -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 O_ba9L56xiT0 for ; Sat, 24 Aug 2019 02:54: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 131FF12003F for ; Sat, 24 Aug 2019 02:54: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 x7O9sTwB006815; Sat, 24 Aug 2019 11:54:29 +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 AEBCC46343; Sat, 24 Aug 2019 11:54:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id N59uskQNDzMP; Sat, 24 Aug 2019 11:54:27 +0200 (CEST) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 64D6146340; Sat, 24 Aug 2019 11:54:27 +0200 (CEST) Date: Sat, 24 Aug 2019 11:54:26 +0200 Message-ID: <87k1b2ga7h.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: Mahesh Jethanandani , Babel at IETF In-Reply-To: <0FE9D6D0-1F00-4715-82C7-491973EE3FB6@att.com> References: <156650395271.14864.52756353331686153@ietfa.amsl.com> <2D09D61DDFA73D4C884805CC7865E6114E283694@GAALPA1MSGUSRBF.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 24 Aug 2019 11:54:30 +0200 (CEST) X-Miltered: at korolev with ID 5D610955.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D610955.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 : 5D610955.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] I-D Action: draft-ietf-babel-yang-model-03.txt 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, 24 Aug 2019 09:54:39 -0000 >>> If information-model is good to proceed (?), should we start WGLC on the >>> YANG model? I think it's ready for WGLC. >> Has anyone reviewed it? > I did. In gory detail. You're my hero, Barbara. I want to be you when I grow up. -- Juliusz From nobody Sat Aug 24 18:19:22 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 6CF791200A4 for ; Sat, 24 Aug 2019 18:19:20 -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 e8KfE26QLwEj for ; Sat, 24 Aug 2019 18:19:18 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 5EE1F120046 for ; Sat, 24 Aug 2019 18:19:18 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id c81so9212644pfc.11 for ; Sat, 24 Aug 2019 18:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=T/Wbs6T/BPVweMHlAwF077hRyXek5uUZR5/Qqx7Empw=; b=oLvU6dD0sHaa8D57J9QkAsMYgsutslssJ1j8y0EoGoghpY19aUwEbtzhFuKwzczMYl +6kFFVTwIkR493clNz9wR22WnFLxr3Ah8nlDZN75L6pa5DjjUBlSttoqcOnMd2pVUT4d aPEhrqoO+DvgRpSWLqr2xv+c7KU8UmWBsQtRi5RvX0ykrf345duODU7B5/WhzRzQ36Xu UUkvQxnub8Aph6keJFPswsRb4xLuK72KsxXwIAwTu7wyk7uC72BpkV1MFNXBBjaOAsdS vmQgZ1043XpeNeB0Ar58V6QpVnk+61ZrpWDiZp6C/YpttbnRLTOWBA063unziiA6YvWV dshQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=T/Wbs6T/BPVweMHlAwF077hRyXek5uUZR5/Qqx7Empw=; b=pxDTgZz26a/I2j7OPaBsnuKdD7mz483X6hFsS10h8BGv/0sKephgK9feX1APPO/W84 Vq25717JdCLkFd2Fo6Xv3JnoYEM3/I2/tlj/SGY7xIGvXY4tcPSUBYKMLFeuZD/fNtlY Qo+DluWdPqVcL23cJBqREusKTDUTxdHPxfkmz8jngtFHR+lmDAv+XZnGcRudOrWOcsTX KMwpc5aX1aPg0N4gpRgPWggJ0hl3i/B0e6sd2ULBjm7XqaB9ExsqjqHApM7GxRTe4b25 8nHcvZu0fUoQp6Q/ITzy+pLqk4+/GTWS0mXtcGVPDaK5vXYR6TzkmPSb6JOdh8hACAmb gzlw== X-Gm-Message-State: APjAAAUZfXfoE3zBNrVivf5tg3lgcIQIZssxJJKMYibaWWGT/PoUQp1T OpnuaOjdscbKgcxbwCf5+lE= X-Google-Smtp-Source: APXvYqzPwxoylOj0ba7LqoSZx/HeV4FfVOLyz6cjZUbvLtb5DuKN5C6vb+SaKGZtm6rlBxrWTbJXvA== X-Received: by 2002:a17:90a:23c8:: with SMTP id g66mr12643214pje.123.1566695957728; Sat, 24 Aug 2019 18:19:17 -0700 (PDT) Received: from [192.168.1.122] (c-73-93-49-153.hsd1.ca.comcast.net. [73.93.49.153]) by smtp.gmail.com with ESMTPSA id h195sm11707956pfe.20.2019.08.24.18.19.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Aug 2019 18:19:16 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <62465DB0-7F74-4539-B7B7-314E7ECE034F@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C73FE8B9-149D-440D-ADC3-1B9FE38D247A" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 24 Aug 2019 18:19:15 -0700 In-Reply-To: <87lfviga9f.wl-jch@irif.fr> Cc: "STARK, BARBARA H" , "babel@ietf.org" To: Juliusz Chroboczek References: <87lfwn5d3d.wl-jch@irif.fr> <874l277c22.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E2877EB@GAALPA1MSGUSRBF.ITServices.sbc.com> <87lfviga9f.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Babel filtering: routing policies 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, 25 Aug 2019 01:19:20 -0000 --Apple-Mail=_C73FE8B9-149D-440D-ADC3-1B9FE38D247A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Juliusz, > On Aug 24, 2019, at 2:53 AM, Juliusz Chroboczek wrote: >=20 > The question, of course, is whether we want to model that in a unusual > object model encoded over XML, or whether it can remain an = implementation > detail. I'm not going to bore you with my opinion (since you already = know > my take on unusual object models encoded in XML). If you rewind back a few meetings (103 to be precise), I did ask this = question to the WG. Martin, our AD was the one to respond in the = affirmative.=20 This is something that is bound to come up when this document goes = through IESG LC, so I am being proactive by addressing it now. Cheers. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_C73FE8B9-149D-440D-ADC3-1B9FE38D247A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Juliusz,

On Aug 24, 2019, at 2:53 AM, Juliusz = Chroboczek <jch@irif.fr> wrote:

The question, of course, is = whether we want to model that in a unusual
object model encoded over XML, or whether it can remain an = implementation
detail.  I'm not going to bore you with my opinion = (since you already know
my take on unusual object models encoded in = XML).

If you rewind = back a few meetings (103 to be precise), I did ask this question to the = WG. Martin, our AD was the one to respond in the = affirmative. 

This is something = that is bound to come up when this document goes through IESG LC, so I = am being proactive by addressing it now.

Cheers.

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_C73FE8B9-149D-440D-ADC3-1B9FE38D247A-- From nobody Sat Aug 24 19:46:51 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 BB08D1200E9; Sat, 24 Aug 2019 19:46:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-babel-rfc6126bis@ietf.org, Donald Eastlake , babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <156670120875.21554.10994837694906657697.idtracker@ietfa.amsl.com> Date: Sat, 24 Aug 2019 19:46:48 -0700 Archived-At: Subject: [babel] Alissa Cooper's Abstain on draft-ietf-babel-rfc6126bis-14: (with COMMENT) 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: Sun, 25 Aug 2019 02:46:49 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-babel-rfc6126bis-14: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Part of the response to my DISCUSS argued that making this specification comply with BCP 61 would harm the reputation of the IETF. I'd rather continue to support BCP 61 than have this protocol standardized in the IETF, if that is what the choice is. If the WG consensus is that deploying this protocol with no MTI security protections is appropriate despite the mountain of evidence that exists showing that deployments of insecure protocols on private networks or in limited domains still often get compromised, I don't see a need to discuss this further. From nobody Sun Aug 25 20:30:45 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 DD80E1200A4; Sun, 25 Aug 2019 20:30:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: babel-chairs@ietf.org, d3e3e3@gmail.com, martin.vigoureux@nokia.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156679024386.30912.17907592784043223693.idtracker@ietfa.amsl.com> Date: Sun, 25 Aug 2019 20:30:43 -0700 Archived-At: Subject: [babel] babel - New Meeting Session Request for IETF 106 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: Mon, 26 Aug 2019 03:30:44 -0000 A new meeting session request has just been submitted by Donald E. Eastlake 3rd, a Chair of the babel working group. --------------------------------------------------------- Working Group Name: Babel routing protocol Area Name: Routing Area Session Requester: Donald Eastlake Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 21 Conflicts to Avoid: Chair Conflict: bess idr rtgwg nvo3 Technology Overlap: homenet manet rtgarea People who must be present: Donald E. Eastlake 3rd Russ White Martin Vigoureux Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Aug 25 21:52:46 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 09C66120823 for ; Sun, 25 Aug 2019 21:52:45 -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 aYT_oBdKs-xI for ; Sun, 25 Aug 2019 21:52:43 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 F2FCA1200A4 for ; Sun, 25 Aug 2019 21:52:42 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id bj8so9376897plb.4 for ; Sun, 25 Aug 2019 21:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JRawpdPfeyR05JamX4wz50OGZ9LNI67vlWPccN67Xz8=; b=TSVSE0RyoGfiwhaMGqpncQvCqz2HIMOet7DsQ47FYODBoZB7gY7WmXvfHPF/D/iYxe wSueRKCJ0vg6Fmtg3OXa0vWPHloiHGFyIo3MHt/1mRXyAGe2oh1XRTz2FPLbw4wepGLZ 3bsfDbagUz/PUOdaGT2z3OdB8rb+Ge0csDaSZtiRml8MglQADDvTnc6BtxSU5Kl8OJts CcyjUwHTxG1ugxlDFoL3vXLJokHkMI14IWFAZEzxTdf+awtwWtZcrNppTGQ3TzJpFg9d HdVylnmf6py4XEGrWXv0Lxm+F2FvDrueFWJ/jDvqYJvuf9vXDk5u1AYUGFd+gfDaipkD tNYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JRawpdPfeyR05JamX4wz50OGZ9LNI67vlWPccN67Xz8=; b=NKNzBXzZIIa0AeYVmGUhAhHQPUAS611tITzIAXCFlnXeXRk1ZD8KXe3Vn0N/Qw7SET O2r9ri1ohWaTsttv9U/m7I190hrKT8IQupWKj5J03FIsE7ZKkVA3q92g/p2IhTZrgazA gXLhpXs5rAR+W6NzehsqHOoDDHeA3HuqffBKF5e9tZ7Asg92YgbalCsCwRUIMsH1XMlh HdFStJo5SMdHEVi4scCNut2lQ4pKEb0W9QinU92gao3URxdPMGCKIf9DsyPDS4F1cS+0 /iiJ7BG7gmuqjORDUONvRQb6pysIbpT/NyvGvV5kzS5uo7n+R3seEmuYwbvHvXeUDzEf JfyA== X-Gm-Message-State: APjAAAV//dIHQCbYk/G3IEZUw5yf3rjd2ocWc/Fi4YBcQH5JlZJNa/c9 sFhCe1g9ZWNJSeqAlgVlO4o= X-Google-Smtp-Source: APXvYqxAs8uiUuS/EUAabUb2zaV2/BsZrQWO7nmDsNgEcWTHtboZmjhCByifRKVp6N+kPdJN0QPTmQ== X-Received: by 2002:a17:902:b68f:: with SMTP id c15mr17305957pls.104.1566795162387; Sun, 25 Aug 2019 21:52:42 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:808a:6ea6:5ac:ad11? ([2601:647:5600:5020:808a:6ea6:5ac:ad11]) by smtp.gmail.com with ESMTPSA id c5sm10359935pfo.175.2019.08.25.21.52.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Aug 2019 21:52:41 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <0D53377C-509C-40B2-997C-B184876C6028@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_202D553E-CA59-4914-BFB4-694ED59935CA" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sun, 25 Aug 2019 21:52:39 -0700 In-Reply-To: <874l277c22.wl-jch@irif.fr> Cc: babel@ietf.org, Barbara Stark To: Juliusz Chroboczek References: <87lfwn5d3d.wl-jch@irif.fr> <874l277c22.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Babel filtering: routing policies 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: Mon, 26 Aug 2019 04:52:45 -0000 --Apple-Mail=_202D553E-CA59-4914-BFB4-694ED59935CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 23, 2019, at 3:27 PM, Juliusz Chroboczek wrote: >=20 >> In order to make sure we are talking the same language, would you say = a given >> chain is equivalent of a =E2=80=9Cdefined set=E2=80=9D as defined by >> draft-ietf-rtgwg-policy-model? >=20 > No. A chain would correspond to a sequence of policy statements, if > I read this document right. According to the routing policy draft. Policy statements in turn consist of simple condition-action tuples. but what you seem to be defining by =E2=80=9Cinstall=E2=80=9D, = =E2=80=9Credistribute=E2=80=9D and =E2=80=9Cout=E2=80=9D are ... The models provides a set of generic sets that can be used for matching in policy conditions. These sets are applicable for route selection across multiple routing protocols. They may be further augmented by protocol-specific models which have their own defined sets.=20 If not, how would you define your sets? =20 >=20 >> I understand that these are babel specific, >=20 > I think that only matching on router-id is Babel-specific, all the = others > are fairly generic. >=20 >> will extend the policy model to add these chains as =E2=80=9Cdefined = sets". >=20 > I don't think you need to extend anything. Matching on router-id is = not > essential. >=20 > On the other hand, it looks to me like it's more expressive than = anything > that any implementation of Babel known to me has ever implemented. = Since > I'm still not sure what's the purpose of the YANG model, I don't know = if > that's a problem or not. If any particular implementation does not support the more expressive = policy statement, they can choose to deviate (not support) these = policies. It can choose to support only the policies it defines. Thanks. >=20 >> There exist other actions, more specialised -- see the manual page = for >> details. >=20 >> I see two more, src-prefix and table. Is there more? >=20 > Not in babeld. I haven't checked BIRD. >=20 > -- Juliusz --Apple-Mail=_202D553E-CA59-4914-BFB4-694ED59935CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 23, 2019, at 3:27 PM, Juliusz Chroboczek <jch@irif.fr> = wrote:

In order to make sure we = are talking the same language, would you say a given
chain = is equivalent of a =E2=80=9Cdefined set=E2=80=9D as defined by
draft-ietf-rtgwg-policy-model?

No.  A chain would correspond to a sequence of policy = statements, if
I read this document right.

According = to the routing policy draft.

   Policy statements in turn consist of simple =
condition-action tuples.

but what you seem to be defining by =E2=80=9Cinstall=E2=80=9D, = =E2=80=9Credistribute=E2=80=9D and =E2=80=9Cout=E2=80=9D are = ...

   The models provides a set of generic sets =
that can be used for
   matching in policy conditions.  These sets are applicable for route
   selection across multiple routing protocols.  They may be further
   augmented by protocol-specific models which have their own defined
   sets.

If not, how would you define your sets?
 

I understand that these are babel specific,

I think that only matching on = router-id is Babel-specific, all the others
are fairly = generic.

will extend the policy model to add these chains as = =E2=80=9Cdefined sets".

I = don't think you need to extend anything.  Matching on router-id is = not
essential.

On the other = hand, it looks to me like it's more expressive than anything
that any implementation of Babel known to me has ever = implemented.  Since
I'm still not sure what's the = purpose of the YANG model, I don't know if
that's a = problem or not.

If any particular implementation does not support the = more expressive policy statement, they can choose to deviate (not = support) these policies. It can choose to support only the policies it = defines.

Thanks.


=    There exist other actions, more specialised -- see the = manual page for
   details.

I see two more, src-prefix and table. Is there more?

Not in babeld.  I haven't = checked BIRD.

-- Juliusz

= --Apple-Mail=_202D553E-CA59-4914-BFB4-694ED59935CA-- From nobody Tue Aug 27 10:59: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 45BA912012E; Tue, 27 Aug 2019 10:58:57 -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, 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 (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLFpsIjh3n_2; Tue, 27 Aug 2019 10:58:55 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 07BE9120116; Tue, 27 Aug 2019 10:58:54 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x7RHwqsB045649; Tue, 27 Aug 2019 13:58:53 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x7RHwqsB045649 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1566928733; bh=ikibI1d2ZZojXNPKODbDkriuoRU6TEnW0FFNJ79Ptfc=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=L0yMZEi/anP6F2o9n8ZsiotcEClIXtLxIPmXTPN0hpbq/iPOfQE8AjFiPw8lXvxG8 f2/c38tp9hP/h5RSt+rVRUIgdgmXTXjpJmEdTz+q1O+ck+nEJVkeEa+dhFPGvLoTyP CZ05ojUSrRH6CnmvYzT20uUxiB3qHDL6MCCBab1s= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x7RHwkeP025842; Tue, 27 Aug 2019 13:58:46 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0468.000; Tue, 27 Aug 2019 13:58:37 -0400 From: Roman Danyliw To: David Schinazi CC: The IESG , "draft-ietf-babel-dtls@ietf.org" , Donald Eastlake , babel-chairs , Babel at IETF Thread-Topic: Roman Danyliw's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT) Thread-Index: AQHVTVX/GUz1qFLfsU6ZzqI2Nk9MnqbyP5aAgAGAUwCABG7OgIAAgEeAgAB8qLCAAM+gAIAI/lmAgAxtomA= Date: Tue, 27 Aug 2019 17:58:37 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B3441E7D@marathon> References: <156520596444.8244.649940515091541992.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B34054D4@marchand> <359EC4B99E040048A7131E0F4E113AFC01B34056BD@marchand> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC01B3441E7Dmarathon_" MIME-Version: 1.0 Archived-At: Subject: Re: [babel] Roman Danyliw's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT) 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, 27 Aug 2019 17:58:58 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC01B3441E7Dmarathon_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQhDQoNClRoYW5rcyBmb3IgcHVibGlzaGluZyB0aGVzZSBjaGFuZ2VzIGFzIC0wOS4g IFRoZSByZXZpc2VkIHRleHQgYWRkcmVzc2VkIG15IGNvbmNlcm5zIGFuZCBJ4oCZdmUgY2xlYXJl ZCBteSBiYWxsb3QgdG8gcmVmbGVjdCB0aGF0Lg0KDQpUaGFua3MsDQpSb21hbg0KDQpGcm9tOiBE YXZpZCBTY2hpbmF6aSBbbWFpbHRvOmRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbV0NClNlbnQ6IE1v bmRheSwgQXVndXN0IDE5LCAyMDE5IDEyOjEwIFBNDQpUbzogUm9tYW4gRGFueWxpdyA8cmRkQGNl cnQub3JnPg0KQ2M6IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1iYWJlbC1k dGxzQGlldGYub3JnOyBEb25hbGQgRWFzdGxha2UgPGQzZTNlM0BnbWFpbC5jb20+OyBiYWJlbC1j aGFpcnMgPGJhYmVsLWNoYWlyc0BpZXRmLm9yZz47IEJhYmVsIGF0IElFVEYgPGJhYmVsQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFJvbWFuIERhbnlsaXcncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYt YmFiZWwtZHRscy0wNzogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KSGkgUm9tYW4sDQoN CldvdWxkIHlvdSBiZSBhYmxlIHRvIHRha2UgYSBsb29rIGF0IGRyYWZ0IC0wOSBhbmQgdXBkYXRl IHlvdXIgYmFsbG90IHBvc2l0aW9uIHBsZWFzZT8NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWJhYmVsLWR0bHMtMDkNCg0KVGhhbmtzLA0KRGF2aWQNCg0KDQpPbiBUdWUs IEF1ZyAxMywgMjAxOSBhdCAzOjUwIFBNIERhdmlkIFNjaGluYXppIDxkc2NoaW5hemkuaWV0ZkBn bWFpbC5jb208bWFpbHRvOmRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhhbmtz IFJvbWFuISBXZSd2ZSBub3cgdXBsb2FkZWQgLTA5IHdpdGggdGhlIG5ldyB0ZXh0Og0KaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmFiZWwtZHRscy0wOQ0KDQpEYXZpZA0K DQpPbiBUdWUsIEF1ZyAxMywgMjAxOSBhdCA3OjI5IEFNIFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0 Lm9yZzxtYWlsdG86cmRkQGNlcnQub3JnPj4gd3JvdGU6DQpIaSBEYXZpZCENCg0KRnJvbTogRGF2 aWQgU2NoaW5hemkgW21haWx0bzpkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmRzY2hp bmF6aS5pZXRmQGdtYWlsLmNvbT5dDQpTZW50OiBNb25kYXksIEF1Z3VzdCAxMiwgMjAxOSAxMTow MSBQTQ0KVG86IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZzxtYWlsdG86cmRkQGNlcnQub3Jn Pj4NCkNjOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4+OyBk cmFmdC1pZXRmLWJhYmVsLWR0bHNAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtYmFiZWwtZHRs c0BpZXRmLm9yZz47IERvbmFsZCBFYXN0bGFrZSA8ZDNlM2UzQGdtYWlsLmNvbTxtYWlsdG86ZDNl M2UzQGdtYWlsLmNvbT4+OyBiYWJlbC1jaGFpcnMgPGJhYmVsLWNoYWlyc0BpZXRmLm9yZzxtYWls dG86YmFiZWwtY2hhaXJzQGlldGYub3JnPj47IEJhYmVsIGF0IElFVEYgPGJhYmVsQGlldGYub3Jn PG1haWx0bzpiYWJlbEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogUm9tYW4gRGFueWxpdydzIERp c2N1c3Mgb24gZHJhZnQtaWV0Zi1iYWJlbC1kdGxzLTA3OiAod2l0aCBESVNDVVNTIGFuZCBDT01N RU5UKQ0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkhDQoNCk9uIE1vbiwgQXVnIDEyLCAyMDE5IGF0 IDQ6MzUgUE0gUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPG1haWx0bzpyZGRAY2VydC5vcmc+ PiB3cm90ZToNCkJlbuKAmXMgcmVjb21tZW5kYXRpb24gdG8gZXhwbGljaXRseSBub3RlIHRoYXQg dGhpcyBhdXRoZW50aWNhdGlvbiBuZWVkcyB0byBiZSBzb2x2ZWQgaW4gZXh0ZXJuYWwgcHJvZmls ZXMgd291bGQgYWRkcmVzcyBteSBjb25jZXJuIHRvbzoNCg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5p ZXRmLm9yZy9hcmNoL21zZy9iYWJlbC81QW5MbGFIUFRFc0JKcFY3V1ZyWkxwdzA3bHMNCg0KKEkg ZG9u4oCZdCBrbm93IGlmIHlvdSB3ZXJlIHdhaXRpbmcgb24gQmVuIGZvciBhbnl0aGluZyBlbHNl LCBidXQg4oCmKSBJIGRpZG7igJl0IHNlZSB0aGlzIGRpc2N1c3Npb24gYWJvdXQgcHJvZmlsZXMg aW4gdGhlIG5ldyAtMDggdGV4dC4NCg0KVGhlIG5ldyBwcm9maWxlIHRleHQgd2FzIGFkZGVkIGFm dGVyIC0wOCB3YXMgc3VibWl0dGVkLCBpdCdzIGluIHRoaXMgY29tbWl0Og0KaHR0cHM6Ly9naXRo dWIuY29tL2plY2gvYmFiZWwtZHJhZnRzL2NvbW1pdC80NThhOWFlNmI5YjEzNjEyMmQ4NjY4YjI2 YmE0MDNmNGYzYTU3MTY3DQoNCkRvZXMgaXQgcmVzb2x2ZSB5b3VyIGNvbmNlcm4/DQpJZiB5ZXMg d2UnbGwgc3VibWl0IGEgLTA5IHdpdGggdGhpcyBuZXcgdGV4dC4NCg0KW1JvbWFuXSAgVW5kZXJz dG9vZC4gIFllcywgdGhhdCB0ZXh0IHJlc29sdmVzIG15IGNvbmNlcm4uICBUaGFuayB5b3UuDQoN ClJvbWFuDQo= --_000_359EC4B99E040048A7131E0F4E113AFC01B3441E7Dmarathon_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIERhdmlkITxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciBwdWJsaXNoaW5nIHRoZXNlIGNo YW5nZXMgYXMgLTA5LiZuYnNwOyBUaGUgcmV2aXNlZCB0ZXh0IGFkZHJlc3NlZCBteSBjb25jZXJu cyBhbmQgSeKAmXZlIGNsZWFyZWQgbXkgYmFsbG90IHRvIHJlZmxlY3QgdGhhdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Um9tYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBEYXZpZCBTY2hpbmF6aSBbbWFpbHRvOmRzY2hpbmF6aS5pZXRm QGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEF1Z3VzdCAxOSwgMjAxOSAx MjoxMCBQTTxicj4NCjxiPlRvOjwvYj4gUm9tYW4gRGFueWxpdyAmbHQ7cmRkQGNlcnQub3JnJmd0 Ozxicj4NCjxiPkNjOjwvYj4gVGhlIElFU0cgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7OyBkcmFmdC1p ZXRmLWJhYmVsLWR0bHNAaWV0Zi5vcmc7IERvbmFsZCBFYXN0bGFrZSAmbHQ7ZDNlM2UzQGdtYWls LmNvbSZndDs7IGJhYmVsLWNoYWlycyAmbHQ7YmFiZWwtY2hhaXJzQGlldGYub3JnJmd0OzsgQmFi ZWwgYXQgSUVURiAmbHQ7YmFiZWxAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBSb21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWJhYmVsLWR0bHMtMDc6ICh3 aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFJvbWFuLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+V291bGQgeW91IGJlIGFibGUgdG8gdGFrZSBhIGxvb2sgYXQg ZHJhZnQgLTA5IGFuZCB1cGRhdGUgeW91ciBiYWxsb3QgcG9zaXRpb24gcGxlYXNlPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmFiZWwtZHRscy0wOSIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJhYmVsLWR0 bHMtMDk8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkRhdmlkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gVHVlLCBBdWcgMTMsIDIwMTkgYXQgMzo1MCBQTSBEYXZpZCBTY2hp bmF6aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbSI+ZHNjaGlu YXppLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIFJvbWFuISBX ZSd2ZSBub3cgdXBsb2FkZWQgLTA5IHdpdGggdGhlIG5ldyB0ZXh0OjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWJhYmVsLWR0bHMtMDkiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iYWJlbC1kdGxzLTA5PC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXZpZDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUs IEF1ZyAxMywgMjAxOSBhdCA3OjI5IEFNIFJvbWFuIERhbnlsaXcgJmx0OzxhIGhyZWY9Im1haWx0 bzpyZGRAY2VydC5vcmciIHRhcmdldD0iX2JsYW5rIj5yZGRAY2VydC5vcmc8L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgRGF2 aWQhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1l PSJtXy0xMTQzNjkwMzkzMDI0NjM1NTM4X21fMzQ2NDY3Mjg2NzQ2MzI4Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBEYXZpZCBTY2hpbmF6aSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpk c2NoaW5hemkuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kc2NoaW5hemkuaWV0ZkBn bWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDEyLCAyMDE5 IDExOjAxIFBNPGJyPg0KPGI+VG86PC9iPiBSb21hbiBEYW55bGl3ICZsdDs8YSBocmVmPSJtYWls dG86cmRkQGNlcnQub3JnIiB0YXJnZXQ9Il9ibGFuayI+cmRkQGNlcnQub3JnPC9hPiZndDs8YnI+ DQo8Yj5DYzo8L2I+IFRoZSBJRVNHICZsdDs8YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmllc2dAaWV0Zi5vcmc8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpk cmFmdC1pZXRmLWJhYmVsLWR0bHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kcmFmdC1pZXRm LWJhYmVsLWR0bHNAaWV0Zi5vcmc8L2E+OyBEb25hbGQgRWFzdGxha2UgJmx0OzxhIGhyZWY9Im1h aWx0bzpkM2UzZTNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZDNlM2UzQGdtYWlsLmNvbTwv YT4mZ3Q7OyBiYWJlbC1jaGFpcnMgJmx0OzxhIGhyZWY9Im1haWx0bzpiYWJlbC1jaGFpcnNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5iYWJlbC1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0OzsNCiBC YWJlbCBhdCBJRVRGICZsdDs8YSBocmVmPSJtYWlsdG86YmFiZWxAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5iYWJlbEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBS b21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWJhYmVsLWR0bHMtMDc6ICh3aXRo IERJU0NVU1MgYW5kIENPTU1FTlQpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzIGZvciB5b3VyIHJlcGx5ITxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgQXVn IDEyLCAyMDE5IGF0IDQ6MzUgUE0gUm9tYW4gRGFueWxpdyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJk ZEBjZXJ0Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJkZEBjZXJ0Lm9yZzwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlbuKAmXMgcmVjb21tZW5kYXRpb24gdG8g ZXhwbGljaXRseSBub3RlIHRoYXQgdGhpcyBhdXRoZW50aWNhdGlvbiBuZWVkcyB0byBiZSBzb2x2 ZWQgaW4gZXh0ZXJuYWwgcHJvZmlsZXMNCiB3b3VsZCBhZGRyZXNzIG15IGNvbmNlcm4gdG9vOjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0 dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvYmFiZWwvNUFuTGxhSFBURXNCSnBW N1dWclpMcHcwN2xzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y Zy9hcmNoL21zZy9iYWJlbC81QW5MbGFIUFRFc0JKcFY3V1ZyWkxwdzA3bHM8L2E+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+KEkgZG9u4oCZdCBrbm93IGlm IHlvdSB3ZXJlIHdhaXRpbmcgb24gQmVuIGZvciBhbnl0aGluZyBlbHNlLCBidXQg4oCmKSBJIGRp ZG7igJl0IHNlZSB0aGlzIGRpc2N1c3Npb24gYWJvdXQNCiBwcm9maWxlcyBpbiB0aGUgbmV3IC0w OCB0ZXh0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBuZXcgcHJvZmlsZSB0ZXh0 IHdhcyBhZGRlZCBhZnRlciAtMDggd2FzIHN1Ym1pdHRlZCwgaXQncyBpbiB0aGlzIGNvbW1pdDo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEg aHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2plY2gvYmFiZWwtZHJhZnRzL2NvbW1pdC80NThhOWFl NmI5YjEzNjEyMmQ4NjY4YjI2YmE0MDNmNGYzYTU3MTY3IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly9naXRodWIuY29tL2plY2gvYmFiZWwtZHJhZnRzL2NvbW1pdC80NThhOWFlNmI5YjEzNjEyMmQ4 NjY4YjI2YmE0MDNmNGYzYTU3MTY3PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RG9lcyBpdCByZXNvbHZlIHlvdXIgY29uY2Vybj88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYg eWVzIHdlJ2xsIHN1Ym1pdCBhIC0wOSB3aXRoIHRoaXMgbmV3IHRleHQuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bUm9tYW5dJm5ic3A7IFVuZGVyc3Rvb2QuJm5ic3A7 IFllcywgdGhhdCB0ZXh0IHJlc29sdmVzIG15IGNvbmNlcm4uJm5ic3A7IFRoYW5rIHlvdS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Sb21hbjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_359EC4B99E040048A7131E0F4E113AFC01B3441E7Dmarathon_-- From nobody Tue Aug 27 11:50: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 E224A120116 for ; Tue, 27 Aug 2019 11:50:12 -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 R2OHgQGpqQ_Y for ; Tue, 27 Aug 2019 11:50:11 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 5D2E31200C7 for ; Tue, 27 Aug 2019 11:50:11 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id f19so12198060plr.3 for ; Tue, 27 Aug 2019 11:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zHaTznyR3fL6ywe3G1xHnTCufdc3dhxZ8MDHiL9PVOU=; b=joTvQ/hGl+uLDobEFSOUD38OnpcP2ufHBmW5svxo8RuGR67st8Z0k7XQALScc6jygz sDvCFLlUfDJkqXuiIaX8WZW8cvNoSGs53dx71zbYKRPpaAQSAdapAw68q1r0ba9Ril5o zFGV1yHQ4HUzKDd9zxR1M8P/Nc781lpHEQ0Ov0xoKJtz+QD8RpNutYPSd3vyJi/J68/9 YxhuOGS7uPcEQssN/CpQ7lQMI2D3xuHnj0EPGen/TiUfOZiANEYlqniRf3TZaTJmhiJG +cwDXm8yOGPhzjJ90DNI96ryGxqX/84x13clAa7Ou5QGoO2NR22LI7g+ps75xsqLH1TL 0/Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zHaTznyR3fL6ywe3G1xHnTCufdc3dhxZ8MDHiL9PVOU=; b=XZ7x63JEzm8MzFxzLWjAsrvpvN6pWUsEAJWdxKNh8kDA/SUlpA3E35CTQk/iSRrkQ3 HVPoE5yNSsO4TOJmdoO718TbyaBzyjC5AUiIfBX912852bXCDp9Am9a6UYZYEzHMDTZK SkB0ZIKtLt6rJepnUbgYLOJ/AK3PnYrUxjKmjPWcwdB5cG3blSyWIOqkKBRVukmuTxBr uctQq8P/tdbshskl0dEJNj9+Sxa6ICUK1lwVZuZEgcM1KtzJbCeiLSWK4hZkYuCpb/5b +4GEQBaCdJ6L5Hv6LQHCr6C5T1qBmpkakY7aa+kvBsK8ioKIKjY0kU7PpiRldlQoRIZc SBeA== X-Gm-Message-State: APjAAAUziPbgoPEBQwSRbudtgXP0L5sCeElrN75LUiYS3S7c8ZbWcZTo H5Y+UQQ4lJfrgFrPS6wFuP4= X-Google-Smtp-Source: APXvYqzxuorUc592du8JQZN6lhXk4Ot5B6K+lM4qrrNyu8yZeSf2UPlOD0C3tqr/CmIEDnqbCL/fpA== X-Received: by 2002:a17:902:6a84:: with SMTP id n4mr326682plk.109.1566931810897; Tue, 27 Aug 2019 11:50:10 -0700 (PDT) Received: from [10.33.122.240] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id 4sm19395pfe.76.2019.08.27.11.50.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Aug 2019 11:50:09 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <09520869-37AC-4C70-930C-47321CC603E0@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0C8C49BD-A269-488D-9E8F-B11772F2DD0A" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 27 Aug 2019 11:50:08 -0700 In-Reply-To: <874l277c22.wl-jch@irif.fr> Cc: babel@ietf.org, Barbara Stark To: Juliusz Chroboczek References: <87lfwn5d3d.wl-jch@irif.fr> <874l277c22.wl-jch@irif.fr> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [babel] Babel filtering: routing policies 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, 27 Aug 2019 18:50:13 -0000 --Apple-Mail=_0C8C49BD-A269-488D-9E8F-B11772F2DD0A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 23, 2019, at 3:27 PM, Juliusz Chroboczek wrote: >=20 > I don't think you need to extend anything. Matching on router-id is = not > essential. >=20 > On the other hand, it looks to me like it's more expressive than = anything > that any implementation of Babel known to me has ever implemented. = Since > I'm still not sure what's the purpose of the YANG model, I don't know = if > that's a problem or not. After reviewing the man page on babeld, and = draft-ietf-rtgwg-policy-model, I have to agree with Juliusz that = draft-ietf-rtgwg-policy-model does more than what is expressed in the = babeld man page. There are a few things like router-id that the routing = policy module does not model, which Juliusz says is not necessary. Therefore I am inclined not to try to define a module to extend the = routing policy for babeld. If anyone disagrees, please speak up now. Thanks. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_0C8C49BD-A269-488D-9E8F-B11772F2DD0A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Aug 23, 2019, at 3:27 PM, Juliusz Chroboczek <jch@irif.fr> = wrote:

I don't think you need to extend = anything.  Matching on router-id is not
essential.

On the other hand, it looks to = me like it's more expressive than anything
that any implementation of Babel known to me has ever = implemented.  Since
I'm still not sure what's the purpose of the YANG model, I = don't know if
that's a = problem or not.

After = reviewing the man page on babeld, and draft-ietf-rtgwg-policy-model, I = have to agree with Juliusz that draft-ietf-rtgwg-policy-model does = more than what is expressed in the babeld man page. There are a few = things like router-id that the routing policy module does not model, = which Juliusz says is not necessary.

Therefore I am inclined not to try to define a = module to extend the routing policy for babeld. If anyone disagrees, = please speak up now.

Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_0C8C49BD-A269-488D-9E8F-B11772F2DD0A-- From nobody Tue Aug 27 12:16:02 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 C75AE1207FE for ; Tue, 27 Aug 2019 12:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tVViVqg4csA for ; Tue, 27 Aug 2019 12:15:58 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEAF912012E for ; Tue, 27 Aug 2019 12:15:57 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x7RJFAQi018146; Tue, 27 Aug 2019 15:15:55 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 2unag0r1vw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Aug 2019 15:15:38 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7RJEOFd021635; Tue, 27 Aug 2019 15:14:25 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x7RJEJbg021532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 27 Aug 2019 15:14:19 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 723DE4009E70; Tue, 27 Aug 2019 19:14:19 +0000 (GMT) Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (unknown [130.8.218.151]) by zlp30485.vci.att.com (Service) with ESMTPS id 5EFB540006FE; Tue, 27 Aug 2019 19:14:19 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.177]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0468.000; Tue, 27 Aug 2019 15:14:18 -0400 From: "STARK, BARBARA H" To: Mahesh Jethanandani CC: Juliusz Chroboczek , "babel@ietf.org" Thread-Topic: Babel filtering: routing policies Thread-Index: AQHVQmgDyo9Vkb0NwkaC+50PaFzuzqcIbMYAgAFVPICABgy6AP//w7Ow Date: Tue, 27 Aug 2019 19:14:18 +0000 Message-ID: References: <87lfwn5d3d.wl-jch@irif.fr> <874l277c22.wl-jch@irif.fr>,<09520869-37AC-4C70-930C-47321CC603E0@gmail.com> In-Reply-To: <09520869-37AC-4C70-930C-47321CC603E0@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A20C2859F5AB4881A3B3A0A9A0B9F95Fattcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-27_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=721 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908270180 Archived-At: Subject: Re: [babel] Babel filtering: routing policies 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, 27 Aug 2019 19:16:00 -0000 --_000_A20C2859F5AB4881A3B3A0A9A0B9F95Fattcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I=92m speaking up to agree with Mahesh=92s assessment. +1 Barbara On Aug 27, 2019, at 2:50 PM, Mahesh Jethanandani > wrote: On Aug 23, 2019, at 3:27 PM, Juliusz Chroboczek > wrote: I don't think you need to extend anything. Matching on router-id is not essential. On the other hand, it looks to me like it's more expressive than anything that any implementation of Babel known to me has ever implemented. Since I'm still not sure what's the purpose of the YANG model, I don't know if that's a problem or not. After reviewing the man page on babeld, and draft-ietf-rtgwg-policy-model, = I have to agree with Juliusz that draft-ietf-rtgwg-policy-model does more t= han what is expressed in the babeld man page. There are a few things like r= outer-id that the routing policy module does not model, which Juliusz says = is not necessary. Therefore I am inclined not to try to define a module to extend the routing= policy for babeld. If anyone disagrees, please speak up now. Thanks. Mahesh Jethanandani mjethanandani@gmail.com --_000_A20C2859F5AB4881A3B3A0A9A0B9F95Fattcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I=92m speaking up to agree with Mahesh=92s assessment.&nbs= p;
+1
Barbara 

On Aug 27, 2019, at 2:50 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:



On Aug 23, 2019, at 3:27 PM, Juliusz Chroboczek <jch@irif.fr> wrote:

I don't think you need to extend anything.  Matching on router-id is no= t
essential.

On the other hand, it looks to me like it's more expressive than anything
that any implementation of Babel known to me has ever implemented.  Since<= /span>
I'm still not sure what's the purpose of the YANG model, I don't know if
that's a problem or not.

After reviewing the man page on babeld, and draft-ietf-rtgwg-policy-mo= del, I have to agree with Juliusz that draft-ietf-rtgwg-policy-model d= oes more than what is expressed in the babeld man page. There are a few thi= ngs like router-id that the routing policy module does not model, which Juliusz says is not necessary.

Therefore I am inclined not to try to define a module to extend the ro= uting policy for babeld. If anyone disagrees, please speak up now.

Thanks.

Mahesh Jethanandani
mjeth= anandani@gmail.com



--_000_A20C2859F5AB4881A3B3A0A9A0B9F95Fattcom_-- From nobody Fri Aug 30 18:09: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 7C1A4120872; Fri, 30 Aug 2019 18:09:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: babel-chairs@ietf.org, d3e3e3@gmail.com, martin.vigoureux@nokia.com, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156721378249.25857.4273535189222580776.idtracker@ietfa.amsl.com> Date: Fri, 30 Aug 2019 18:09:42 -0700 Archived-At: Subject: [babel] babel - Update to a Meeting Session Request for IETF 106 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, 31 Aug 2019 01:09:53 -0000 An update to a meeting session request has just been submitted by Donald E. Eastlake 3rd, a Chair of the babel working group. --------------------------------------------------------- Working Group Name: Babel routing protocol Area Name: Routing Area Session Requester: Donald Eastlake Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 21 Conflicts to Avoid: Chair Conflict: bess idr rtgwg nvo3 Technology Overlap: homenet manet rtgarea Key Participant Conflict: netconf netmod People who must be present: Donald E. Eastlake 3rd Russ White Martin Vigoureux Resources Requested: Special Requests: ---------------------------------------------------------